Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!gatech!uflorida!umd5!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.lang.c Subject: Re: More ANSI comment help wanted: #define void int vs. #define void char Message-ID: <8068@brl-smoke.ARPA> Date: 10 Jun 88 19:35:48 GMT References: <8085@elsie.UUCP> <8023@brl-smoke.ARPA> <8087@elsie.UUCP> <8090@elsie.UUCP> Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 44 I think this is a nonissue on which too much effort is being expended. The original example (#define void int) is just an illustration of why it MIGHT under SOME circumstances be USEFUL to be permitted to use #define to redefine keywords. NO redefinition of "void" is UNIVERSALLY proper. To take a specific case: Although I did not draft the part about "#define void int", my applications are prepared to do just that when the (non-ANSI) C compilation environment warrants, as it does on older 4BSD systems and on some microcomputer C implementations (those that do not provide the "void" extension to K&R [1st Edition] C). The specific mechanism I use is to include, in virtually EVERY application, a private headerthat I set up once for each compilation environment. This defines a bunch of stuff the implementation of which varies from system to system but the use of which remains the same. Here is an extract of relevant portions of one implementation of : typedef char *pointer; /* generic pointer (void *) */ #define const /* nothing */ /* (undefine for ANSI C) */ /* ANSI C definitions */ #ifndef EXIT_SUCCESS #define EXIT_SUCCESS 0 #endif #ifndef EXIT_FAILURE #define EXIT_FAILURE 1 #endif /* other kludges for deficient C implementations etc.: */ /*#define strchr index /* 7th Edition UNIX, 4.2BSD */ /*#define strrchr rindex /* 7th Edition UNIX, 4.2BSD */ /*#define void int /* K&R 1st Edition followers */ Notice the last line. I came up with this well before X3J11, and I have seen other programmers do the same. Notice also that my applications NEVER contain the "void *" that you worry about being broken by "#define void int"; instead I always use the generic "pointer" type for such pointers, and define it appropriately in this header. So in my situation, "#define void int" is sometimes useful, but "#define void char" never is (and can be harmful). There is certainly no need to change the X3J11 example.