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