Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.bugs.sys5
Subject: Re: 'what' doesn't use perror to print open errors, Sys V/3.0
Message-ID: <10205@smoke.BRL.MIL>
Date: 4 May 89 13:19:16 GMT
References: <3759@sugar.hackercorp.com> <10156@smoke.BRL.MIL> <1153@aplcen.apl.jhu.edu> <1350@frog.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 20

In article <1350@frog.UUCP> john@frog.UUCP (John Woods) writes:
>In article <1153@aplcen.apl.jhu.edu>, bink@aplcen.apl.jhu.edu (Ubben Greg) writes:
>>[...]
>(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 :-).

That was Ubben Greg, not me.  It's well known that I'm not human.

SVID and POSIX requirements that fopen() always set errno appropriately
upon failure are fairly recent innovations, and not all UNIX implementations
religiously do that.  It's certainly true that it's not clear what really
is or should be a "system call" versus a "library function", but at one time
you could apply the rule:  If it's in the UPM Section 2 it's a system call;
if it's in Section 3 it's a library function.

Thus my UNIX System V emulation for 4.nBSD systems takes considerable pains
to set errno on failure for all its emulations of System V system calls,
but doesn't do anything special when non-math library functions fail.
That's consistent with traditional practice, although not apparently with
POSIX.