wayne@ames.arpa (08/26/87)
No flame against the poster, but when I saw the following come by today it reminded me of what I think is the absolute *WORST* of the "UNIX philosophy": >>>> #define STRERR() ((errno >=0 && errno < sys_nerr) ? \ >>>> sys_errlist[errno] : "Unknown error") What's wrong with this? Simply that it doesn't tell you what the unknown value of errno *IS*! When I first saw code like this in "perror" itself I absolutely could not believe it. Sure it takes a miniscule amount more work to print "Unknown error 666." But you see, that's *exactly* what I meant by "UNIX philosophy": it's fine as long as you don't ever make a mistake, but boy if you ever should, then not only is UNIX not going to help, it's gonna *HIDE* the one piece of debugging information it has! "The number you reached, which I am not going to tell you so you won't know whether you misdialed or not and will have to try again, is not in service." Sheesh! Wayne Hathaway ultra!wayne@Ames.ARPA Ultra Network Technologies 2140 Bering drive with a domain server: San Jose, CA 95131 wayne@Ultra.COM 408-922-0100
gwyn@brl-smoke.ARPA (Doug Gwyn ) (08/26/87)
In article <9001@brl-adm.ARPA> ultra!wayne@ames.arpa (Wayne Hathaway) writes: >... Sure it takes a >miniscule amount more work to print "Unknown error 666." But you see, >that's *exactly* what I meant by "UNIX philosophy": it's fine as long >as you don't ever make a mistake, but boy if you ever should, then not >only is UNIX not going to help, it's gonna *HIDE* the one piece of >debugging information it has! Apparently what you mean by "UNIX philosophy" has nothing to do with actual UNIX philosophy, since I'm one of the more vocal proponents of the latter and I would not have left out the error number in the message. In fact, two weeks ago I wrote an error-handling package quite similar in spirit to errno and friends, and after trying the best it can to return a meaningful error message, the last resort of the message-finder module is to build a string with the error number in it. The fact that a lot of old UNIX code was implemented in a rush, just to get some job done in a research environment, and was never cleaned up by the commercial vendors does NOT mean that that is recommended practice! By the way, why not implement strerror() which will be required in Standard C, rather than inventing bug-prone, incompatible approaches to the same problem? It would make a nice addition to your C library. extern char *strerror( int errnum );
greg@utcsri.UUCP (08/26/87)
In article <9001@brl-adm.ARPA> wayne@ames.arpa writes: >>>>> #define STRERR() ((errno >=0 && errno < sys_nerr) ? \ >>>>> sys_errlist[errno] : "Unknown error") > >What's wrong with this? Simply that it doesn't tell you what the >unknown value of errno *IS*! When I first saw code like this in >"perror" itself I absolutely could not believe it. Sure it takes a >miniscule amount more work to print "Unknown error 666." But you see, >that's *exactly* what I meant by "UNIX philosophy": it's fine as long >as you don't ever make a mistake, but boy if you ever should, then not >only is UNIX not going to help, it's gonna *HIDE* the one piece of >debugging information it has! > > "The number you reached, which I am not going to tell you > so you won't know whether you misdialed or not and will > have to try again, is not in service." > My favorite is the error message from the MS-DOS 'rmdir' command: 'Invalid path, File not found, or Directory not empty'. As you may have guessed, this is the only error message that rmdir can produce. ' ... or maybe I'm just stupid.' -- ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg Have vAX, will hack...
bhj@clsib21.UUCP (Burt Janz) (08/26/87)
In article <9001@brl-adm.ARPA>, ultra!wayne@ames.arpa (Wayne Hathaway) writes: > >>>> #define STRERR() ((errno >=0 && errno < sys_nerr) ? \ > >>>> sys_errlist[errno] : "Unknown error") > > What's wrong with this? Simply that it doesn't tell you what the > unknown value of errno *IS*! When I first saw code like this in > Wayne Hathaway ultra!wayne@Ames.ARPA Hmmmm... ever heard of running cpp by itself, grokking the output, and seeing where the macros are expanded? ...works for me... Burt Janz
guy%gorodish@Sun.COM (Guy Harris) (08/27/87)
> > What's wrong with this? Simply that it doesn't tell you what the > > unknown value of errno *IS*! When I first saw code like this in > > Wayne Hathaway ultra!wayne@Ames.ARPA > > Hmmmm... ever heard of running cpp by itself, grokking the output, > and seeing where the macros are expanded? I'm sure he's heard of that; however, this won't tell you a damn thing. He doesn't want to know where the macros are expanded; he wants to know what the value of "errno" is when the program is E X E C U T E D. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
henry@utzoo.UUCP (Henry Spencer) (08/27/87)
> By the way, why not implement strerror() ...
Better yet, use the existing public-domain implementation, in the string
library I sent to comp.sources.unix a while back. It's "stringlib" in
volume 6 of the archives, as I recall. The strerror() in there matched
the then-current ANSI draft, and I think still matches the current one.
--
"There's a lot more to do in space | Henry Spencer @ U of Toronto Zoology
than sending people to Mars." --Bova | {allegra,ihnp4,decvax,utai}!utzoo!henrympl@sfsup.UUCP (08/28/87)
In article <6339@brl-smoke.ARPA>, gwyn@brl-smoke.UUCP writes: > In article <9001@brl-adm.ARPA> ultra!wayne@ames.arpa (Wayne Hathaway) writes: > >... Sure it takes a > >miniscule amount more work to print "Unknown error 666." But you see, [...] > By the way, why not implement strerror() which will be.... Which reminds me, back in the ancient days I implemented an error package for naive users of our software. Our routine was basically: error(severity, what, __FILE__, __LINE__) It printed a message telling the user how severe the error was according to severity. What is what the software was trying to do (ie make directory or whatever). Errno was then examined to print an appropriate message as to *why* the thing failed. Finally, a log file was kept with the user, time, and all the arguments, so if the user called the administrator, he could tell *exactly* what went wrong by looking at the log file and resorting to the source, if necessary. In practice, few people ever called because they couldn't figure out an error message. A message like: "WARNING: can't read the file "foobar": you don't have permission to read it" is pretty obvious. This is how *we* interpreted the UNIX(R) philosophy. The compiler and operating environment (through __FILE__, errno, etc.) provided us with a great way to print meaningful messages - it was up to *us*, the application writers to use the information. Mike Lindner attunix!mpl
dml@rabbit1.UUCP (David Langdon) (08/28/87)
in article <9001@brl-adm.ARPA>, ultra!wayne@ames.arpa (Wayne Hathaway) says: > > No flame against the poster, but when I saw the following come by > today it reminded me of what I think is the absolute *WORST* of the > "UNIX philosophy": > >>>>> #define STRERR() ((errno >=0 && errno < sys_nerr) ? \ >>>>> sys_errlist[errno] : "Unknown error") > > What's wrong with this? Simply that it doesn't tell you what the > unknown value of errno *IS*! When I first saw code like this in > "perror" itself I absolutely could not believe it. Sure it takes a > miniscule amount more work to print "Unknown error 666." > > Wayne Hathaway ultra!wayne@Ames.ARPA Not only doesn't it tell you what the problem was, it also will not get through the preprocessor under some of the older UNIX dialects. -- David Langdon Rabbit Software Corp. (215) 647-0440 7 Great Valley Parkway East Malvern PA 19355 ...!ihnp4!{cbmvax,cuuxb}!hutch!dml ...!psuvax1!burdvax!hutch!dml
ken@argus.UUCP (Kenneth Ng) (08/28/87)
In article <526@clsib21.UUCP>, bhj@clsib21.UUCP (Burt Janz) writes: > In article <9001@brl-adm.ARPA>, ultra!wayne@ames.arpa (Wayne Hathaway) writes: > > >>>> #define STRERR() ((errno >=0 && errno < sys_nerr) ? \ > > What's wrong with this? Simply that it doesn't tell you what the > > unknown value of errno *IS*! When I first saw code like this in > > Wayne Hathaway ultra!wayne@Ames.ARPA > Hmmmm... ever heard of running cpp by itself, grokking the output, > and seeing where the macros are expanded? > Burt Janz But if the software was properly written I wouldn't have to do this. Kenneth Ng: Post office: NJIT - CCCC, Newark New Jersey 07102 uucp !ihnp4!allegra!bellcore!argus!ken *** NOT ken@bellcore.uucp *** bitnet(prefered) ken@orion.bitnet
peter@sugar.UUCP (08/29/87)
> Hmmmm... ever heard of running cpp by itself, grokking the output, > and seeing where the macros are expanded? > > ...works for me... Well, some PC compilers have cpp as a builtin. In fact I'd say most PC compilers do this. There's no way to get the cpp output. When I complained about this, I was roundly shouted down. Now I suppose I'll get flamed for pointing this out. -- -- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter -- U <--- not a copyrighted cartoon :->
bhj@clsib21.UUCP (09/01/87)
In article <1021@argus.UUCP>, ken@argus.UUCP (Kenneth Ng) writes: > In article <526@clsib21.UUCP>, bhj@clsib21.UUCP (Burt Janz) writes: > > In article <9001@brl-adm.ARPA>, ultra!wayne@ames.arpa (Wayne Hathaway) writes: > > > >>>> #define STRERR() ((errno >=0 && errno < sys_nerr) ? \ > > > What's wrong with this? Simply that it doesn't tell you what the > > > unknown value of errno *IS*! When I first saw code like this in > > > Wayne Hathaway ultra!wayne@Ames.ARPA > > Hmmmm... ever heard of running cpp by itself, grokking the output, > > and seeing where the macros are expanded? > > Burt Janz > > But if the software was properly written I wouldn't have to do this. > Kenneth Ng: Post office: NJIT - CCCC, Newark New Jersey 07102 Ah, but if the code had been properly written, this discussion wouldn't be taking place. Remember, the original complaint was about errno not being set by a macro... Frankly, it gets me peeved when I pick up someone else's code and have to wade through it, trying to figure out what macros are used where, and having to UNhide all of those wonderful macros which are HIDing stuff. Many is the time I've used the output of cpp as the source to the modified code. And, I've also modified the output to cpp and created macros again, thus perpetuating the problem. The major problem with macros occurs when too much manipulation is done within them. I try to keep my macro usage to a minimum, preferring to either create functions or to directly use code. I know, macros are supposed to help you with that. But macros are often NOT named effectively, and this contributes to the confusion. All I can suggest with the macro not returning errno is: rewrite it. Burt Janz
jpn@teddy.UUCP (John P. Nelson) (09/02/87)
>Well, some PC compilers have cpp as a builtin. In fact I'd say most >PC compilers do this. There's no way to get the cpp output. Well, I dont know about *most* PC compilers, but both Microsoft C and Turbo C have ways to get preprocessed output. TurboC provides a seperate preprocessor program, even though the regular compiler has the preitiesunet!ing bo$S i
peter@sugar.UUCP (Peter da Silva) (09/05/87)
In article <4319@teddy.UUCP>, jpn@teddy.UUCP (John P. Nelson) writes: > >Well, some PC compilers have cpp as a builtin. In fact I'd say most > >PC compilers do this. There's no way to get the cpp output. > > Well, I dont know about *most* PC compilers, but both Microsoft C > and Turbo C have ways to get preprocessed output. TurboC provides > a seperate preprocessor program, even though the regular compiler > has the preprocesser built-in! Well, Microsoft 'C' (as of Version 3) is actually a port of their Xenix compiler, so it's sort of the exception that proves the rule. Turbo 'C' is beginning to look like an exception to all the rules. However, those of us with Lattice, Aztec, or Microsoft pre-version-3 are still up the creek. I don't know about Mix, de Smet, ECO-C, or Mark Williams... but I would be surprised to learn they're any different. In the Mac, most 'C' compilers are monolithic for speed. On the Amiga, both Lattice and Aztec faithfully acrry on the bugs in their PC versions. Aztec even has memory models (on a 68000!). -- -- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter -- 'U` <-- Public domain wolf.
crs@cpsc6b.cpsc6a.att.com (C. R. Seaman) (09/15/87)
In article <368@rabbit1.UUCP>, dml@rabbit1.UUCP (David Langdon) writes: < in article <9001@brl-adm.ARPA>, ultra!wayne@ames.arpa (Wayne Hathaway) says: < > < >>>>> #define STRERR() ((errno >=0 && errno < sys_nerr) ? \ < >>>>> sys_errlist[errno] : "Unknown error") < > < > What's wrong with this? Simply that it doesn't tell you what the < > unknown value of errno *IS*! When I first saw code like this in perror... Maybe I am missing something here... I see how easy it would be to insert the code to output the error number, but why bother? If perror doesn't know what the error is, (meaning, the number is greater than sys_nerr), what good will knowing the number do you? WHERE ARE YOU GOING TO LOOK IT UP? -- Chris Seaman | o\ /o crs@cpsc6a.att.com <or> | || See "Attack of the Killer Smiley"! ..!ihnp4!cpsc6a!crs | \vvvvvv/ Coming Soon to a newsgroup near you! | \____/
guy%gorodish@Sun.COM (Guy Harris) (09/16/87)
> If perror doesn't know what the error is, (meaning, the number is greater > than sys_nerr), what good will knowing the number do you? Well, for one thing, you can give the error number when you file a bug report for the program, instead of just saying it printed "Unknown error".... I've found that programs that refuse to divulge useful information rarely make your life better by doing so; programs that just say "sorry, I couldn't open this file" instead of giving an error message (or, equally bad, programs that print an error code in numeric form!) make it a lot harder to fix the problem. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com