'what' doesn't use perror to print open errors, Sys V/3.0
John Woods
john at frog.UUCP
Tue May 2 06:54:00 AEST 1989
In article <1153 at aplcen.apl.jhu.edu>, bink at aplcen.apl.jhu.edu (Ubben Greg) writes:
> In article <10156 at smoke.BRL.MIL> gwyn at 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 at frog.UUCP, ...!mit-eddie!jfw, jfw at eddie.mit.edu
More information about the Comp.bugs.sys5
mailing list