Making voids work portably (was re: efopen.c)
Ian Seaton, Dedicated Mail, REO2-F/D3, DTN 830 3593
seaton at tron.DEC
Mon Oct 28 21:18:43 AEST 1985
---------------------Reply to mail dated 22-OCT-1985 03:15---------------------
In his reply to the answer to the reply to the problem of VOID Valdis Kletnieks
said:
> 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...
I hate to disagree but, not only does VAX/VMS C V2 support (void) but
DEC also has a little program call MMS (Module Management System) which is
a 'make' for VMS systems, it does all that 'make' does and a little more so
COPTS="/DEFINE=(void=int)" would work IF IT WAS NEEDED!.
Now...MY pet hate is all these so called compilers that don't seem to
understand the concept of scoping. Time and again I have found programs on
the net falling down because of bad scoping, a thing which VAX/VMS C is good
at!
Remember, those curly little brackets mean the end of the scope of any
variables declared within them (unless declared otherwise!).
Roll on ANSI Standards...
Share and Enjoy...
Ian Seaton
DEC Reading, England
UUCP: !dec-thrint!
decwrl!dec-rhea!dec-tron !seaton
!dec-blott !
ARPA: seaton%tron.DEC at DECWRL.ARPA
Note: These machines with dec- infront of them, they're all VAXen running
VMS you know! Call me a UNIXoid at your own peril!.
More information about the Comp.sources.bugs
mailing list