Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!decvax!ima!mirror!frog!john
From: john@frog.UUCP (John Woods)
Newsgroups: comp.bugs.sys5
Subject: Re: 'what' doesn't use perror to print open errors, Sys V/3.0
Message-ID: <1350@frog.UUCP>
Date: 1 May 89 20:54:00 GMT
References: <3759@sugar.hackercorp.com> <10156@smoke.BRL.MIL> <1153@aplcen.apl.jhu.edu>
Organization: Misanthropes-R-Us
Lines: 25

In article <1153@aplcen.apl.jhu.edu>, bink@aplcen.apl.jhu.edu (Ubben Greg) writes:
> In article <10156@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
> > (1) "what" uses fopen() to open the file.  perror() is inappropriate
> > except when a system call reports failure.  fopen() is not a system call.
> I regularly use perror() to report the failure of an fopen().  It works on
> all the systems I've used because, of course, the fopen() doesn't make any
> other system calls after the open().  Is this really a bad thing to do?

"Of course" you actually know no such thing.

However, the SVID guarantees that if fopen() or freopen() fails, then errno
shall contain a valid error code.  (note, as usual, the refusal to state
what errno contains if fopen() succeeds.  It will contain a dragon.)

"system call" is not well enough defined to be the determinant of whether
errno is usable or not (after all, why IS open() a system call, and why
IS NOT fopen() a system call?).  What you ought to rely on is what a common
manual documents.

(Gee, one of the rare times when Doug Gwyn isn't right.  He must have done
this deliberately to reassure all of us that he's human :-).

-- 
John Woods, Charles River Data Systems, Framingham MA, (508) 626-1101
...!decvax!frog!john, john@frog.UUCP, ...!mit-eddie!jfw, jfw@eddie.mit.edu