Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.bugs.sys5
Subject: Re: 'what' doesn't use perror to print open errors, Sys V/3.0
Message-ID: <1533@auspex.auspex.com>
Date: 2 May 89 03:38:36 GMT
References: <3759@sugar.hackercorp.com> <10156@smoke.BRL.MIL> <1153@aplcen.apl.jhu.edu> <10178@smoke.BRL.MIL>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 24

>Yes, because there can be causes for fopen() failing that are not related
>to system calls the fopen() implementation may make.  For example, suppose
>there is a fixed array of FILE structures and they've all been allocated.
>No system call will occur, and any perror() you do will give completely
>mileading information about the problem.

In which case I'd prefer to use "open" to open the file, and "fdopen" to
turn it into a standard I/O stream; given the choice between using a
strictly conforming application not using anything outside the ANS which
just says "Sorry, I can't open your file", and one that uses POSIX
functions but tells me *why* it can't be opened, there'd better be a big
cost difference, or the latter'd better not be available on all the
platforms I'm interested in, or the former had better be better than the
latter for other reasons, 'cause I'm going to count the better error
disagnostic as a serious point in favor of the latter application....

>By now everyone must have seen at least one report "not a typewriter"
>due to a call to perror() under inappropriate circumstances.

I'd be willing put up with a few of those, if it's the price I have to
pay for better error diagnostics.  (I'd really have preferred it if
"errno" had been officially guaranteed to be set properly after failure
of things such as "fopen" (assuming that, in this hypothetical world,
some other error-reporting mechanism weren't used), but....)