🚀 go-pugleaf

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