[comp.lang.c] #define void int vs. #define void char

chris@mimsy.UUCP (Chris Torek) (06/06/88)

In article <8085@elsie.UUCP> ado@elsie.UUCP (Arthur David Olson) writes:
>[the Rationale attached to the draft proposed C standard] contains a
>sample keyword redefinition:
>	#define void int
>along with a note that "The redefinitions of void and const could be
>useful in retrofitting more modern C code to an older implementation."
>Since the Standard requires a void * to have the same representation
>as a char *, and since a char * may not have the same representation
>as an int *, this definition seems suboptimal.

>[but ado was told that] while "#define void char" might be better when
>it comes to pointers, there were other cases where "#define void int"
>was better.  Can anyone give a concrete example?

It is certainly true that `#define void int' (or `typedef int void;')
has been used in the past; you even see this in various books on C.
Indeed, this is the root of an objection I have to the `void *' syntax
for generic pointers.  Had the standard included the line

	typedef void *pointer_t;	/* or (char *) */

in <stddef.h>, one could implement pointer_t on old compilers virtually
painlessly.

Of course, `void *' does somewhat carry the notion that the pointer
does not point to anything in particular, or at least not to anything
concrete.  It is also probably not difficult to implement (it was
certainly trivial in the 4.3-tahoe compilers), so this is just a minor
irritant.  On the other hand, too many minor irritants can keep people
from using something at all. . . .
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris

karl@haddock.ISC.COM (Karl Heuer) (06/06/88)

In article <11823@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>Indeed, this is the root of an objection I have to the `void *' syntax
>for generic pointers.  Had the standard included the line
>	typedef void *pointer_t;	/* or (char *) */
>in <stddef.h>, one could implement pointer_t on old compilers virtually
>painlessly.

My temporary workaround is to use "Void *" (note the capital V) for generic
pointers.  It's easy to make this work on either K&R or ANSI compilers.  I
chose not to make a non-standard "pointer_t" because "Void *" more closely
resembles the "real" syntax, and is easy to fix when I decide that the
workaround is no longer necessary.

My alternate solution would be to write a PD preprocessor that converts
"void *" to "char *", and other similar hacks.  (But to be worthwhile it
should also handle function prototypes; since this is nontrivial, I haven't
done it yet.)

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint

ado@elsie.UUCP (Arthur David Olson) (06/11/88)

A response to an earlier article of mine convinces me that I failed to be
clear and succinct.  Let me try again.

QUESTION 1.
	What's an example of code that compiles but does the wrong thing if you
		#define void int
	?

QUESTION 2.
	What's an example of code that compiles but does the wrong thing if you
		#define void char
	?
==============================================================================
Here are my best answers so far:

ANSWER 1.
	The code
		extern void * malloc();

		char * getten() { return malloc(10); }
	on machines where (int *) != (char *).

ANSWER 2.
	I know of no such code.
==============================================================================
If you have better answers, I'd appreciate hearing from you.
-- 
	ado@ncifcrf.gov			ADO is a trademark of Ampex.

garys@bunker.UUCP (Gary M. Samuelson) (07/01/88)

In article <11823@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
==[but ado was told that] while "#define void char" might be better when
==it comes to pointers, there were other cases where "#define void int"
==was better.

= ...  Had the standard included the line
=	typedef void *pointer_t;	/* or (char *) */
=in <stddef.h>, one could implement pointer_t on old compilers virtually
=painlessly.

=Of course, `void *' does somewhat carry the notion that the pointer
=does not point to anything in particular, or at least not to anything
=concrete.

I've got it !  For the generic pointer type, how about: (noalias *)
Guaranteed not to point to anything in particular!

:-) :-) :-?

Gary Samuelson

michael@stb.UUCP (Michael) (07/15/88)

Actually, I'd like ANSI to require being able to say 
#define void int
I have a compiler that knows void, has the preprocessor merged with the
rest of the compilation, does not allow me to define void as anything
(gives an error, "keyword redefined"). The problem? I have a program that
is partially converted to using voids, so I get type mismatch errors,
but if I try re-definning void I get a "Keyword redefinition error".

Very annoying.
				Michael
: --- 
: Michael Gersten			 uunet.uu.net!denwa!stb!michael
:				sdcsvax!crash!gryphon!denwa!stb!michael
: What would have happened if we had lost World War 2. Well, the west coast
: would be owned by Japan, we would all be driving foreign cars, hmm...

will.summers@p6.f18.n114.z1.fidonet.org (will summers) (07/28/88)

 > Actually, I'd like ANSI to require being able to say
 > #define void int
 
I think it does so require.  The Jan '88 draft says that keywords are
reserved in translation phases 7 and 8.  Preprocessor directives and
macro expansions occur in translation phase 4.  So as I see it that
"keyword redefinition error" you got would indicate a broke compiler
under ANSI C.
 
    \/\/ill
 


--  
St. Joseph's Hospital/Medical Center - Usenet <=> FidoNet Gateway
Uucp: ...ncar!noao!asuvax!stjhmc!18.6!will.summers
Internet: will.summers@p6.f18.n114.z1.fidonet.org

gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/29/88)

In article <10475@stb.UUCP> michael@stb.UUCP (Michael) writes:
>Actually, I'd like ANSI to require being able to say 
>#define void int

Gee, I thought it did.  Of course, the resulting code is not
necessarily going to be correct.