Making voids work portably (was re: efopen.c)

[Ray Chen]

In article <2316 at brl-tgr.ARPA>, $VK0%CLVM.BITNET at WISCVM.ARPA (Valdis Kletnieks) writes:
> >Void is well defined and pretty easily portable, though it's true that
> >many compilers don't fully implement it.  If you write the code
> >with void, it can be trivially made to work on systems without broken voids
> >by adding COPTS='-Dvoid=int' to the Makefile -- without source changes.
> >*That*'s portability...
> 
> Well, Daniel Levy SAID that he was running it under VAX/VMS C.  This (at
> least as far as I can see) sort of implies that he is running VAX/VMS.
> The problem with adding COPTS='-Dvoid=int' to the Makefile is that "make"
> is NOT a VAX/VMS command.  If we are going to talk about portability, let's
> at least make sure that we have portable utilities as well.  Adding to a
> control file for a non-existent utility will NOT make it all better, no matter
> what the Unixoid life forms out there are trying to convince us...

So what if you don't have make?  Add -Dvoid=int to the command invoking the
compiler and put it into a shell script/DCL file (for you VMS'ers out there)/
ms-dos batch file/whatever.  

Or if the program has an include file that's included in all the files,
add the line "#define void int" to the file.

Or put "#define void int" into an include file "sysdepend.h" and include
it in every file so that you'll have a place to take care of any other
strange system dependencies you run across.  (Plus, when your compiler
get's around to supporting void, the fix will be trivial.)

The point is, void can be used cleanly and portably as long as you aren't
trying to use lint with a compiler that doesn't support void.  Even then,
void will work, things just won't pass lint because you'll be casting things
to int or whatever instead of void.

Enough of this silly discussion.

	Ray Chen
	gitpyr!chen

Georgia Insitute of Technology, Atlanta Georgia, 30332
...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!chen