Path: utzoo!attcan!uunet!husc6!cmcl2!brl-adm!umd5!mimsy!chris From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.lang.c Subject: Re: #define void int vs. #define void char Message-ID: <11823@mimsy.UUCP> Date: 6 Jun 88 02:21:51 GMT References: <8085@elsie.UUCP> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 33 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, 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