geacc022%timevx@CIT-HAMLET.ARPA (07/19/85)
Why should a cast to (void) be necessary in a statement like
(void) printf("foo\n");
? Why not say that the expression in the definition
<statement> = <expression>";" is automatically cast to type void?
I put the casts to void in because they keep lint happy, but I'll
be the first to say they look ugly and impair readability...and why
are they really necessary, anyway?
Gary Ansok
GEACC022%TIMEVX @ CIT-HAMLET.ARPA
GEA @ CALTECH.BITNET
...ucbvax!cithep!timevx#geacc022
"All the world loves a straight man."mjs@eagle.UUCP (M.J.Shannon) (07/20/85)
> > Why should a cast to (void) be necessary in a statement like > > (void) printf("foo\n"); > > ? Why not say that the expression in the definition > <statement> = <expression>";" is automatically cast to type void? > > Gary Ansok The cast is necessary because printf() returns a value. Lint (very properly) warns that the value is unused without the cast. Would you prefer that lint say nothing if you had a code fragment something like: ... log(d); ... Insofar as the language is concerned, failing to do *something* with a returned value is at least suspect. Casting the value to void *does* use the value, but should generate no extra code; in some implementations, it could allow better code generation because the compiler is told explicitly to ignore the value, perhaps leaving more (or different) registers available for subsequent code. -- Marty Shannon UUCP: ihnp4!eagle!mjs Phone: +1 201 522 6063
atbowler@watmath.UUCP (Alan T. Bowler [SDG]) (07/25/85)
For functions like MEMCPY whose return value will normally be ignored
perhaps a more sensible approach is the one used by the Waterloo
SDG version of Lint. It has a lint directive which indicates
that is applied where the function is defined, which tells LINT
that this routine has an optional result, and it is really not
an error to ignore it.
This avoids a lot of clutter in source code like
(void) memcpy(a, b, c);
used sparingly it is a great help.meissner@rtp47.UUCP (Michael Meissner) (07/29/85)
Whenever I use things like printf with lint, I define things like:
#define Printf (void) printf
#define Fputs (void) fputs
/* ... */
Printf("Hello World!\n");
Which translates to:
(void) printf("Hello World!\n");
Thus lint is kept happy, and my program is not cluttered up with casts to void.
Michael Meissner
Data General
...{ inhp4, decvax }!mcnc!rti-sel!rtp47!meissnerpilotti@telesoft.UUCP (Keith Pilotti @shine) (07/31/85)
In article <> mjs@eagle.UUCP (M.J.Shannon) writes: >> Why should a cast to (void) be necessary in a statement like >> (void) printf("foo\n"); >>... >The cast is necessary because printf() returns a value. >... The use of (void) also points out the fact that the programmer *intentionally* is ignoring the return value of the function. At the very least it is useful documentation. /+\ Keith ________________________________________________________ KEITH F. PILOTTI -- TeleSoft (619) 457-2700 x172 10639 Roselle St, SanDiego, CA 92121 (UUCP) {decvax,ucbvax}!sdcsvax!telesoft!pilotti (ARPA) Pilotti@UCSD
thau@h-sc1.UUCP (robert thau) (08/02/85)
> The use of (void) also points out the fact that the programmer > *intentionally* is ignoring the return value of the function. > At the very least it is useful documentation. > > KEITH F. PILOTTI -- TeleSoft (619) 457-2700 x172 *** Flame warning *** printf() is invariably used as a formatted-output statement, not as a value-returning function. A "(void)" which makes this fact explicit not only adds no information to a program, but obscures things by hiding the actual code behind a forest of (face it, folks) lint directives. What's worse, there are far too many people who believe that "(void)", "/*ARGSUSED*/" and the ilk are documentation rather than clutter; their code is generally bereft of comments which *explain* data structures, *elucidate* obscure algorithms, and *clarify* code. DOWN WITH LINT SALAD!!! *** Flameout *** -- Robert Thau \ Keeper of the *FLAME* )) rst@tardis.ARPA ( ( h-sc1%thau@harvard.ARPA \\
kimcm@diku.UUCP (Kim Christian Madsen) (08/04/85)
In article <116@rtp47.UUCP> meissner@rtp47.UUCP (Michael Meissner) writes: > >Whenever I use things like printf with lint, I define things like: > > #define Printf (void) printf > #define Fputs (void) fputs > > /* ... */ > > Printf("Hello World!\n"); > >Which translates to: > > (void) printf("Hello World!\n"); > >Thus lint is kept happy, and my program is not cluttered up with casts to void. That's a mediocre solution, it shouldn't be necessary lint should know the set of standard functions which results needn't be used. It's not accept- able to either put (void) in front of printf(), scanf(), ...etc. or make defines like "#define Printf (void) printf". Regards Kim Chr. Madsen a.k.a. kimcm@diku.uucp
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (08/04/85)
The people proposing ways of making (void)printf( ... ); easier to enter into their code are missing the point of lint's complaint! The printf() function CAN FAIL and if you don't test for it, Murphy says that it WILL fail, under the worst possible circumstances (e.g., while updating YOUR pay record). Instead of looking for ways to avoid testing printf return, how about making your code more robust.
thau@h-sc1.UUCP (robert thau) (08/05/85)
> The people proposing ways of making > (void)printf( ... ); > easier to enter into their code are missing the point of lint's > complaint! > > The printf() function CAN FAIL and if you don't test for it, > Murphy says that it WILL fail, under the worst possible > circumstances (e.g., while updating YOUR pay record). > Instead of looking for ways to avoid testing printf return, > how about making your code more robust. I just checked the manual page on printf(3), both on this machine (2.xbsd), and on one of the local vaxen (4.2bsd, with local hacks). Neither documents a return value for printf, under normal or erroneous circumstances. How does one check? Just asking ... -- Robert Thau \ Keeper of the *FLAME* )) rst@tardis.ARPA ( ( h-sc1%thau@harvard.ARPA \\
mjs@eagle.UUCP (M.J.Shannon) (08/05/85)
> In article <116@rtp47.UUCP> meissner@rtp47.UUCP (Michael Meissner) writes: > > > >Whenever I use things like printf with lint, I define things like: > > > > #define Printf (void) printf > > #define Fputs (void) fputs > > > > /* ... */ > > > > Printf("Hello World!\n"); > > > >Which translates to: > > > > (void) printf("Hello World!\n"); > > > >Thus lint is kept happy, and my program is not cluttered up with casts to void. > > That's a mediocre solution, it shouldn't be necessary lint should know the > set of standard functions which results needn't be used. It's not accept- > able to either put (void) in front of printf(), scanf(), ...etc. or make > defines like "#define Printf (void) printf". > > Regards > Kim Chr. Madsen > a.k.a. kimcm@diku.uucp And programs that do this don't recover from write errors, like when a filesystem runs out of space. That's what lint *correctly* complains about. -- Marty Shannon UUCP: ihnp4!eagle!mjs Phone: +1 201 522 6063 Warped people are throwbacks from the days of the United Federation of Planets.
gwyn@BRL.ARPA (VLD/VMB) (08/05/85)
"The printf function returns the number of characters transmitted, or a negative value if an output error was encountered." - ANSI X3J11 draft standard - similar wording in 1984 /usr/group Standard - similar wording in System V Interface Definition 4.2BSD printf returns 0, or EOF if an output error was encountered. If you are trying to write code that runs unmodified both in standard environments and on 4.2BSD (not recommended), then testing whether printf returns a negative value is sufficient.
ron@brl-tgr.ARPA (Ron Natalie <ron>) (08/06/85)
> I just checked the manual page on printf(3), both on this machine (2.xbsd), > and on one of the local vaxen (4.2bsd, with local hacks). Neither documents > a return value for printf, under normal or erroneous circumstances. How does > one check? > Obviously didn't look very hard. In INTRO(3S) which is an introduction to all the STDIO routines has a DIAGNOSTICS heading that describes the uniform error returns for all subroutines in the package. -Ron
guy@sun.uucp (Guy Harris) (08/06/85)
> printf() is invariably used as a formatted-output statement, > not as a value-returning function. "invariably"? Wrong. The S5R2 "ls" uses the return value from "printf" (which is the number of characters printed) to do its columnation. I'm sure there are other examples out there. > DOWN WITH LINT SALAD!!! It's unfortunate that so much effort has to be wasted on silencing harmless "lint" complaints, but as anybody who's tried porting code to machines which don't fit the VAX model of the world (32-bit "int"s, 32-bit pointers, signed characters, little-endian byte order, etc.) will tell you, better to run "lint" on the code and either spend the effort (void)ing everything or filtering out the harmless complaints than to spend the effort on several extra compile/run/debug/edit/compile... cycles fixing the problems caused by code that assumes that model of the world. (I've done it; I know whereof I speak.) Guy Harris
foss@ihuxe.UUCP (foss) (08/06/85)
> > The people proposing ways of making > > (void)printf( ... ); > > easier to enter into their code are missing the point of lint's > > complaint! > > > > The printf() function CAN FAIL and if you don't test for it, > > Murphy says that it WILL fail, under the worst possible > > circumstances (e.g., while updating YOUR pay record). > > Instead of looking for ways to avoid testing printf return, > > how about making your code more robust. > > I just checked the manual page on printf(3), both on this machine (2.xbsd), > and on one of the local vaxen (4.2bsd, with local hacks). Neither documents > a return value for printf, under normal or erroneous circumstances. How does > one check? The subroutine printf(3) calls the system call write(2). If sucessful, the return value is set to the number of characters written, else -1 is returned and errno is set to describe the error.
wjafyfe@watmath.UUCP (Andy Fyfe) (08/07/85)
> The printf() function CAN FAIL and if you don't test for it, > Murphy says that it WILL fail, under the worst possible > circumstances (e.g., while updating YOUR pay record). /usr/lib/news/expire uses fprintf to re-write the active file. It didn't take the time to check the return value, and happened to run one night when /usr was full. Result -- a 0 length active file and a great deal of unhappy news software. printf (and fprintf) DO FAIL! (Since someone asked, printf and fprintf return EOF if they fail. (This is documented in our "UW Modified" man page). And don't forget to check fclose, since output may not actually be written until the file is closed. And don't let exit do the fclose's for you (since it doesn't check for errors)!) --Andy Fyfe ...!{decvax, allegra, ihnp4, et. al}!watmath!wjafyfe wjafyfe@waterloo.csnet
peter@kitty.UUCP (Peter DaSilva) (08/07/85)
> If you are trying to write code that runs unmodified both in > standard environments and on 4.2BSD (not recommended), ... Why not? I try to make sure my code runs on K&R, 4.2, SV, and MS-DOS without modification. Apart from system calls I'm usually successful.
simsong@mit-eddie.UUCP (Simson L. Garfinkel) (08/07/85)
In article <2564@sun.uucp> guy@sun.uucp (Guy Harris) writes: >It's unfortunate that so much effort has to be wasted on silencing harmless >"lint" complaints, but as anybody who's tried porting code to machines which >don't fit the VAX model of the world (32-bit "int"s, 32-bit pointers, signed >characters, little-endian byte order, etc.) will tell you, better to run >"lint" on the code and either spend the effort (void)ing everything or >filtering out the harmless complaints than to spend the effort on several >extra compile/run/debug/edit/compile... cycles fixing the problems caused by >code that assumes that model of the world. (I've done it; I know whereof I >speak.) > > Guy Harris Normally, when I am working on a project that must be transportable, I use a file on my system called "COMPILER_DEPENDENCIES.h" On a VAX, this file looks like this: #typedef int32 unsigned int #typedef int16 unsigned short int . . . On my IBM/PC (lattice C, UGH!), the file is "COMP_DPD.h" and it looks like this: #typedef int32 unsigned long int #typedef int16 unsigned int I use sint16 for signed integers. Then, throughout the code, no int's, just int16 or 32, depending on what. I want. Hope this helps. ................................................................simson
tmb@talcott.UUCP (Thomas M. Breuel) (08/08/85)
In article <1310@eagle.UUCP>, mjs@eagle.UUCP (M.J.Shannon) writes: > > In article <116@rtp47.UUCP> meissner@rtp47.UUCP (Michael Meissner) writes: > > >Whenever I use things like printf with lint, I define things like: > > > #define Printf (void) printf > > > #define Fputs (void) fputs > > That's a mediocre solution, it shouldn't be necessary lint should know the > > set of standard functions which results needn't be used. It's not accept- > > able to either put (void) in front of printf(), scanf(), ...etc. or make > > defines like "#define Printf (void) printf". > And programs that do this don't recover from write errors, like when a > filesystem runs out of space. That's what lint *correctly* complains about. The fundamental problem here is that the way stdio indicates that a write failed is just inconvenient. In 99.999% of all cases, you don't want to care about failing printf's. The appropriate default action is to print a diagnostic message (where?) and to kill the process, not to return a failure code that has to be checked every single time you print something. Thomas.
jdb@mordor.UUCP (John Bruner) (08/08/85)
> > That's a mediocre solution, it shouldn't be necessary lint should know the > > set of standard functions which results needn't be used. It's not accept- > > able to either put (void) in front of printf(), scanf(), ...etc. or make > > defines like "#define Printf (void) printf". > > And programs that do this don't recover from write errors, like when a > filesystem runs out of space. That's what lint *correctly* complains about. For instance, the "passwd" program, which, when copying "passwd" to "ptmp", will blissfully truncate the password file if the root filesystem is out of space. This problem has been around since (at least) V6 and STILL isn't fixed in either 4.2BSD or System V. (The 4.2BSD "passwd" program doesn't bother to cast fprintf(), which the manual page doesn't document as returning a value anyway. In System V, "passwd" calls putpwent(), which does check for an error and returns an error indication. Unfortunately, "passwd" doesn't bother to check (or cast to (void)) the return value from putpwent().) -- John Bruner (S-1 Project, Lawrence Livermore National Laboratory) MILNET: jdb@mordor [jdb@s1-c.ARPA] (415) 422-0758 UUCP: ...!ucbvax!dual!mordor!jdb ...!seismo!mordor!jdb -- John Bruner (S-1 Project, Lawrence Livermore National Laboratory) MILNET: jdb@mordor [jdb@s1-c.ARPA] (415) 422-0758 UUCP: ...!ucbvax!dual!mordor!jdb ...!seismo!mordor!jdb
chris@umcp-cs.UUCP (Chris Torek) (08/08/85)
>The fundamental problem here is that the way stdio indicates that >a write failed is just inconvenient. In 99.999% of all cases, you >don't want to care about failing printf's. The appropriate default >action is to print a diagnostic message (where?) and to kill the >process, not to return a failure code that has to be checked >every single time you print something. True; however, if you are ever writing something intended as a general library, *never ever ever* put something like that in without at the very least providing some way around it. When you need to recover and can't, you'll be sorry. . . . -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland
bright@dataio.UUCP (Walter Bright) (08/08/85)
In article <4894@mit-eddie.UUCP> simsong@mit-eddie.UUCP (Simson L. Garfinkel) writes: >Normally, when I am working on a project that must be transportable, I >use a file on my system called "COMPILER_DEPENDENCIES.h" On a VAX, this >file looks like this: >#typedef int32 unsigned int >#typedef int16 unsigned short int > >On my IBM/PC (lattice C, UGH!), the file is "COMP_DPD.h" and it looks >like this: >#typedef int32 unsigned long int ^^^^^^^^^^^^^ Lattice doesn't support unsigned long! >#typedef int16 unsigned int The above syntax won't work on any compiler I've ever heard of. For Lattice C, try this: #define int32 long #define uns32 <cause syntax error> #define int16 int #define uns16 unsigned #define int8 short #define uns8 char If you try to port code to Lattice C that uses an uns32, you will get a syntax error at the location in the code that needs to be rewritten so it doesn't require an unsigned long.
roy@phri.UUCP (Roy Smith) (08/08/85)
[ assorted babble about (void) hiding printf(3S) errors leading to the observation that printf doesn't return any kind of error status] > [...] printf(3) calls the system call write(2). If sucessful, the return > value is set to the number of characters written, else -1 is returned and > errno is set to describe the error. Not quite. Printf(3) calls putc(3) which (on most implementations) is a macro which calls _flsbuf() (or something similar) when an internal buffer gets full, which in turn eventually calls write(2). The point is that write(2) doesn't get called on every invocation of printf, so when printf returns, the write errors have not yet happened. This behaviour is documented in the 4.2 manual page for putc, but not in the Sys5 manual. In either case, if you want to check for write errors, printf is not the way to go. -- Roy Smith <allegra!phri!roy> System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016
gwyn@BRL.ARPA (VLD/VMB) (08/09/85)
typedef unsigned short int16; typedef unsigned long int32; (note the bug fix, also) is equivalent to what you were trying to do, but does not need to be rewritten for different machines. In any case, most experienced C programmers will use "short" when 16 bits is known to suffice and "long" when 32 bits are needed. This is certainly not the main portability problem.
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (08/09/85)
> > If you are trying to write code that runs unmodified both in > > standard environments and on 4.2BSD (not recommended), ... > > Why not? I try to make sure my code runs on K&R, 4.2, SV, and MS-DOS > without modification. Apart from system calls I'm usually successful. The reason why not is, you have to limit yourself to a fairly puny common subset and implement your own replacements for such useful functions as drand48(), hsearch(), tempnam(), getopt(), etc. etc. Also, it is hard to use the basic utilities via popen() since they don't behave the same in many cases. You also cannot exploit the more powerful features of "make", you have a "ranlib" problem, etc. I am very much in favor of both C and Portable OS standards, which are now in the works, to make this business much less painful in the future. For right now, I develop software for a UNIX System V plus directory access routines minus AT&T-only kernel features (shared memory, FIFOs, etc.) and install a suitable environment as needed on non-UNIX System V hosts that I take my software to. Since this is close to the environment being standardized, I expect little work to be needed to continue porting my applications for the foreseeable future, and I haven't had to give up use of the more nifty System V development support aids.
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (08/09/85)
> The subroutine printf(3) calls the system call write(2). > If sucessful, the return value is set to the number of characters > written, else -1 is returned and errno is set to describe the error. Gee, yet another alternate universe.
peter@kitty.UUCP (Peter DaSilva) (08/09/85)
> > That's a mediocre solution, it shouldn't be necessary lint should know the > > set of standard functions which results needn't be used. It's not accept- > > able to either put (void) in front of printf(), scanf(), ...etc. or make > > defines like "#define Printf (void) printf". > > And programs that do this don't recover from write errors, like when a > filesystem runs out of space. That's what lint *correctly* complains about. OK. How about Printf(fmt,a,b,c,d,e,f,g,h,i,j,k,l) { assert(printf(fmt,...)!=FAIL); }
peter@baylor.UUCP (Peter da Silva) (08/12/85)
> > > If you are trying to write code that runs unmodified both in > > > standard environments and on 4.2BSD (not recommended), ... > > > > Why not? I try to make sure my code runs on K&R, 4.2, SV, and MS-DOS > > without modification. Apart from system calls I'm usually successful. > > The reason why not is, you have to limit yourself to a fairly puny > common subset and implement your own replacements for such useful > functions as drand48(), hsearch(), tempnam(), getopt(), etc. etc. Our native library doesn't have drand48, hsearch or getopt, and tempnam is just a throwback to the days before sprintf. > Also, it is hard to use the basic utilities via popen() since they > don't behave the same in many cases. You also cannot exploit the I don't use popen either. It doesn't run on non-UNIX systems. > more powerful features of "make", you have a "ranlib" problem, etc. I don't even have MAKE on my IBM-PC. And before you flame me about using an IBM-PC, it's a requirement of the job. The remainder of your message suffers from the same flaws. Not everyone has access to all those neat bells & whistles... this group is for 'C' standards, not UNIX standards. 'C' isn't an integral part of UNIX any more... Semiflame: And SV isn't automatically THE STANDARD ENVIRONMENT either. -- Peter da Silva (the mad Australian) UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter MCI: PDASILVA; CIS: 70216,1076
chris@umcp-cs.UUCP (Chris Torek) (08/13/85)
>. . . and tempnam is just a throwback to the days before sprintf.
Not really; tempnam (or mktemp) is not the same as doing
sprintf(fname, "/tmp/x%d", getpid());
(or variations thereupon) as it actually makes sure that such a
file doesn't already exist (what happens when you get the same pid
as someone else did earlier?).
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP: seismo!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris@marylandgwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (08/15/85)
> > The reason why not is, you have to limit yourself to a fairly puny > > common subset and implement your own replacements for such useful > > functions as drand48(), hsearch(), tempnam(), getopt(), etc. etc. > > Our native library doesn't have drand48, hsearch or getopt, and tempnam is > just a throwback to the days before sprintf. I SAID that if you stick to a lowest common denominator, you would not be able to use these nifty functions. (Judging by your remark, I don't think you know what tempnam does.) If you really enjoy re-implementing almost everything from scratch, more power to you, but I think it's uneconomical. > > Also, it is hard to use the basic utilities via popen() since they > > don't behave the same in many cases. You also cannot exploit the > > I don't use popen either. It doesn't run on non-UNIX systems. > > > more powerful features of "make", you have a "ranlib" problem, etc. These comments were specifically directed at the problems of developing code for a UNIX-like target system (I had 4.2BSD in mind) if a standard environment is not available. You could even provide substantially the same environment on your MS-DOS system. The Software Tools Users Group has shown the way. I did this once for a RSTS/E system, which is not inherently very much like UNIX, and two or three times for variants of UNIX. Are you aware of the current efforts to generate (international) standards for a portable operating system interface? This should make the application developer's work much easier in the long run.
peter@baylor.UUCP (Peter da Silva) (08/16/85)
> >. . . and tempnam is just a throwback to the days before sprintf. > > Not really; tempnam (or mktemp) is not the same as doing > > sprintf(fname, "/tmp/x%d", getpid()); > > (or variations thereupon) as it actually makes sure that such a > file doesn't already exist (what happens when you get the same pid > as someone else did earlier?). Never occured to me that you could get this, but of course you can. well, you just do this: for(c='a'; c<='z'; c++) { sprintf(fname, "/tmp/x%s%c", getpid(), c); if(access(fname, 7)) break; } if(c>'z') panic which is, of course, basically what mktemp must do. Never mind. -- Peter da Silva (the mad Australian werewolf) UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter MCI: PDASILVA; CIS: 70216,1076
mll@proper.UUCP (Marc Lavine) (08/17/85)
In article <> bright@dataio.UUCP (Walter Bright writes: >In article <4894@mit-eddie.UUCP> simsong@mit-eddie.UUCP (Simson L. Garfinkel) writes: >>Normally, when I am working on a project that must be transportable, I >>use a file on my system called "COMPILER_DEPENDENCIES.h" On a VAX, this >>file looks like this: >>#typedef int32 unsigned int >>#typedef int16 unsigned short int >> >>On my IBM/PC (lattice C, UGH!), the file is "COMP_DPD.h" and it looks >>like this: >>#typedef int32 unsigned long int > ^^^^^^^^^^^^^ Lattice doesn't support unsigned long! The latest version of Lattice C (version 3.00) treats unsigned as a true modifier, not as its own type, therefore Lattice now supports unsigned longs. -- Marc Lavine UUCP: ...ihnp4!dual!proper!mll MCI Mail: MLavine
peter@baylor.UUCP (Peter da Silva) (08/18/85)
> I SAID that if you stick to a lowest common denominator, you would not > be able to use these nifty functions. And I said our native library (not the cross-compiler library) doesn't have them. I.E... WE DON'T HAVE THESE ROUTINES! We are forced to stick to the lowest common denominator because that's all we have. It's more economical to write the specific parts of them that we may want in our system then to write the whole shebang. Lots of people are in this situation... ever hear of V7? > These comments were specifically directed at the problems of developing > code for a UNIX-like target system (I had 4.2BSD in mind) if a standard > environment is not available. Well, you could have made that clearer. I thought we were talking about the 'C' language here, not UNIX. Or has this suddenly turned into "net.unix.c"? > You could even provide substantially the same environment on your MS-DOS > system. The Software Tools Users Group has shown the way. I did this > once for a RSTS/E system, which is not inherently very much like UNIX, At least it supports multitasking. How do you implement popen on that poor excuse for a file server known as MS-DOS? > Are you aware of the current efforts to generate (international) > standards for a portable operating system interface? This should make That sounds like an awfully low common denominator to me... some operating systems have an awfully limited set of operations. > the application developer's work much easier in the long run. And I have implemented much of Software Tools on RSX, so I know whereof I speak. -- Peter da Silva (the mad Australian werewolf) UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter MCI: PDASILVA; CIS: 70216,1076
peter@baylor.UUCP (Peter da Silva) (08/19/85)
> The latest version of Lattice C (version 3.00) treats unsigned as a true > modifier, not as its own type, therefore Lattice now supports unsigned longs. Damn. I just forked out bucks for 2.15! Is 3.0 the same as Microsoft 'C' 3.0? If not, what is it? I wonder if I can get an upgrade... -- Peter (Made in Australia) da Silva UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter MCI: PDASILVA; CIS: 70216,1076