Path: utzoo!utgpu!water!watmath!clyde!att!mtunx!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!umd5!cvl!elsie!ado From: ado@elsie.UUCP (Arthur David Olson) Newsgroups: comp.lang.c Subject: Re: More ANSI comment help wanted: #define void int vs. #define void char Message-ID: <8090@elsie.UUCP> Date: 9 Jun 88 00:36:46 GMT References: <8085@elsie.UUCP> <8023@brl-smoke.ARPA> <8087@elsie.UUCP> <8028@brl-smoke.ARPA> Organization: NIH-LEC, Bethesda, MD Lines: 36 > "extern char exit();" is plain wrong on EVERYbody's system. Whether > or not this causes a problem depends on the implementation. > If a header is included that has e.g. "extern exit();" in it > then there is a type clash, too. Thanks for the posting; these points should definitely help in improving my comment. Let's see if I can get some more help. Consider this code: ------------------------- extern void * malloc(); char * getten() { return malloc(10); } -------------------------- where this dumb function just returns a point to ten character's worth of allocated storage. Now if we #define void int as the standard suggests for backporting purposes, "old" compilers will happily compile the code without complaint--and on systems where (int *) != (char *), all hell will mysteriously break loose at runtime. In this case, if we #define void char the problem is avoided. So: are there any instances where a #define void char will introduce runtime problems (that is, cause "quiet changes") rather than causing compile-time problems ("noisy changes")? (Again, I'm interested in concrete examples.) -- Grocery swaps ends for Chinese native. (5) ado@ncifcrf.gov ADO is a trademark of Ampex.