Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!brl-tgr!gwyn From: gwyn@brl-tgr.ARPA (Doug Gwyn) Newsgroups: net.sources.bugs,net.lang.c,net.unix-wizards Subject: Re: efopen.c (about void voids) Message-ID: <2460@brl-tgr.ARPA> Date: Sat, 26-Oct-85 07:42:16 EST Article-I.D.: brl-tgr.2460 Posted: Sat Oct 26 07:42:16 1985 Date-Received: Sun, 27-Oct-85 07:31:02 EST References: <1741@watdcsu.UUCP> <2109@brl-tgr.ARPA> <796@rlgvax.UUCP> <493@ttrdc.UUCP> <210@l5.uucp> <267@frog.UUCP> Distribution: net Organization: Ballistic Research Lab Lines: 15 Xref: watmath net.sources.bugs:550 net.lang.c:6847 net.unix-wizards:15469 > Although I am sure that someone has a compiler for which the following will > not make sense, in general the construct > > #ifndef lint > #define void int > #endif > > allows one to have one's cake and eat it too. Not always, since this introduces a mismatch between the application code and the C library. There may also be compilers that get unhappy when your int-valued functions don't return a value, etc. The #define void int kludge should really only be applied when the compiler doesn't know about void.