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.