Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!julius.cs.uiuc.edu!apple!agate!shelby!neon!Gang-of-Four!dkeisen
From: dkeisen@Gang-of-Four.Stanford.EDU (Dave Eisen)
Newsgroups: comp.lang.c
Subject: Re: perror/strerror after fopen (was FILE *fp[];)
Message-ID: <1990Nov29.164552.452@Neon.Stanford.EDU>
Date: 29 Nov 90 16:45:52 GMT
References: <1990Nov27.131327.21662@agate.berkeley.edu> <14603@smoke.brl.mil> <28078@mimsy.umd.edu>
Sender: news@Neon.Stanford.EDU (USENET News System)
Organization: Sequoia Peripherals
Lines: 30

>In article <14603@smoke.brl.mil> gwyn@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@mimsy.umd.edu> chris@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@Gang-of-Four.Stanford.EDU
1447 N. Shoreline Blvd.
Mountain View, CA 94043           
(415) 967-5644