perror/strerror after fopen (was FILE *fp[];)

Dave Eisen dkeisen at Gang-of-Four.Stanford.EDU
Fri Nov 30 03:45:52 AEST 1990


>In article <14603 at smoke.brl.mil> gwyn at smoke.brl.mil (Doug Gwyn) writes:
>>Please don't do this; on UNIX, perror() will report the reason for the last
>>SYSTEM CALL failure, not the reason for failure of a library routine such as
>>fopen().  Sometimes there is a close relation between these but at other
>>times there is not, leading to such absurd diagnostics as "Error opening
>>file: not a tty".
>


In article <28078 at mimsy.umd.edu> chris at mimsy.umd.edu (Chris Torek) writes:
>Some of us regard this as a bug, rather than a feature.  I am not
>particularly happy with the whole idea of a global `error number',
>but there it is.


And a surprisingly easy bug to deal with. I can't imagine writing
library code that didn't make sure errno (and other appropriate
global error numbers) were set to the most reasonable value possible.

I never saw this as a horrible extra burden in writing the code; I
never saw it as optional, either.




--
Dave Eisen                      	    dkeisen at Gang-of-Four.Stanford.EDU
1447 N. Shoreline Blvd.
Mountain View, CA 94043           
(415) 967-5644



More information about the Comp.lang.c mailing list