gnu@l5.uucp (John Gilmore) (10/21/85)
In article <493@ttrdc.UUCP>, levy@ttrdc.UUCP (Daniel R. Levy) writes: > (void)whatever is not supported at all under VAX/VMS C. It will barf > severely on (originally) Unix C programs which have been heavily larded with > (void)'s for the sake of lint. Not the entire C world is Unix. 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...
campbell@maynard.UUCP (Larry Campbell) (10/22/85)
In article <493@ttrdc.UUCP>, levy@ttrdc.UUCP (Daniel R. Levy) writes: > (void)whatever is not supported at all under VAX/VMS C. It will barf > severely on (originally) Unix C programs which have been heavily larded with > (void)'s for the sake of lint. Not the entire C world is Unix. Version 1 of VAX-11 C may not have supported the void type, but version 2 certainly does. -- Larry Campbell decvax!genrad The Boston Software Works, Inc. \ 120 Fulton St. seismo!harvard!wjh12!maynard!campbell Boston MA 02109 / / ihnp4 cbosgd ARPA: maynard.UUCP:campbell@harvard.ARPA
$VK0%CLVM.BITNET@WISCVM.ARPA (Valdis Kletnieks) (10/22/85)
>In article <493@ttrdc.UUCP>, levy@ttrdc.UUCP (Daniel R. Levy) writes: >> (void)whatever is not supported at all under VAX/VMS C. It will barf >> severely on (originally) Unix C programs which have been heavily larded with >> (void)'s for the sake of lint. Not the entire C world is Unix. >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... Valdis Kletnieks Systems Programmer Educational Resources Center Clarkson University BITNET: $VK0@CLVM.BITNET UUCP: {pur-ee,ccvaxa,sun}!csd-gould!clutx!vk0 decvax!sii!trixie!csd-gould!clutx!vk0 ICBM: 44 40N 75 00W
mikes@3comvax.UUCP (Mike Shannon) (10/24/85)
> 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... Unixoid life forms!? Unixoid life forms!?!!! Where? Where? (look out behind you, I think I see a Unixoid life form!) -- Michael Shannon {ihnp4,hplabs}!oliveb!3comvax!mikes
gt3403b@gitpyr.UUCP (Ray Chen) (10/25/85)
In article <2316@brl-tgr.ARPA>, $VK0%CLVM.BITNET@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
seaton@tron.DEC (Ian Seaton, Dedicated Mail, REO2-F/D3, DTN 830 3593) (10/28/85)
---------------------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@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!.