🚀 go-pugleaf

In article <3759@sugar.hackercorp.com> karl@sugar.hackercorp.com (Karl Lehenbauer) writes:
>Several years have elapsed, which should have been long enough to make all
>the programs distributed with Unix follow the perror() conventions that
>the manuals tell us our programs are to follow.

(1) "what" uses fopen() to open the file.  perror() is inappropriate
except when a system call reports failure.  fopen() is not a system call.

(2) SCCS was developed long ago and hasn't been modernized.

In article <3759@sugar.hackercorp.com>, karl@sugar.hackercorp.com (Karl Lehenbauer) writes:
> Several years have elapsed, which should have been long enough to make all
> the programs distributed with Unix follow the perror() conventions that
> the manuals tell us our programs are to follow.

The perror() function has been SVID level 2 since 1985, which
means that it is no longer guaranteed to be supported after 1988.
I believe it will be in the next SVID (Issue 3), but it may go
away after that.

This matters, of course, only if you value the SVID.

     Steve

-- 
Stephen J. Friedl / V-Systems, Inc. / Santa Ana, CA / +1 714 545 6442 
3B2-kind-of-guy   / friedl@vsi.com  / {attmail, uunet, etc}!vsi!friedl

As long as Bush is in office, you'll never see Nancy Reagan in *my* .sig.

In article <10156@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
: In article <3759@sugar.hackercorp.com> karl@sugar.hackercorp.com (Karl Lehenbauer) writes:
: >Several years have elapsed, which should have been long enough to make all
: >the programs distributed with Unix follow the perror() conventions that
: >the manuals tell us our programs are to follow.
:
: (1) "what" uses fopen() to open the file.  perror() is inappropriate
: except when a system call reports failure.  fopen() is not a system call.

According to the manual pages for Microport V/386 3.0e, fopen returns
an error status in errno and perror is defined to work for system
calls and library functions.

I don't have the manual pages for other systems handy, but I seem to
recall similar wording for BSD and SunOS.

---
Bill                            { uunet | novavax } !twwells!bill

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?
confirm: 

					-- Greg Ubben
					   bink@aplcen.apl.jhu.edu

In article <1153@aplcen.apl.jhu.edu> bink@aplcen.apl.jhu.edu (Greg Ubben) writes:
>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?

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.

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

If you have a fairly high degree of certainty that nothing could have
gone wrong that didn't involve a system call failure, then feel free to
use perror(), but you're always taking a risk when using perror() after
a non system-call library function.

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

> > (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?

It's not bad on an X/Open system.

X/Open recognized the widespread use of perror() after library routines
that can experience underlying system errors, and gave this practice
its blessing.

Therefore, systems that claim compliance to Issue III of the X/Open
Portability Guide will set errno for these functions as documented.
Note that IEEE Standard 1003.1 (POSIX) also appears to require this
behavior for systems implementing the Standard C Language Binding.

Dave Decot
Past Chair
X/Open System Interface Working Group

>The perror() function has been SVID level 2 since 1985, which
>means that it is no longer guaranteed to be supported after 1988.
>I believe it will be in the next SVID (Issue 3), but it may go
>away after that.

And then again, it may not.  "perror" is in the pANS for C, so even if
AT&T rips it out of the SVID, vendors will probably have to provide it
anyway in their C implementations.

>According to the manual pages for Microport V/386 3.0e, fopen returns
>an error status in errno and perror is defined to work for system
>calls and library functions.
>
>I don't have the manual pages for other systems handy, but I seem to
>recall similar wording for BSD and SunOS.

No, I checked the 4.3-tahoe and SunOS 4.0 "fopen" man pages; they
mention "errno" nowhere.

>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....)

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.

In article <1350@frog.UUCP> john@frog.UUCP (John Woods) writes:

   "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.

A system call is a subroutine documented in Chapter 2. :-)

Actually, a system call is an entry point which is a one-for-one mapping to a
particular kernel service.  Open(2) is a system call which returns a file
descriptor, which is a kernel data structure.  Fopen(2) on the other hand
returns a non-kernel data structure called a stream, which is typedefed as
FILE in stdio.h.  One field in the structure is the file descriptor, and one
piece of fopen is a call to open to get that file descriptor.  System functions
are the primatives which are used either by themselves or implicitly by 
subroutines which add some value.  (For another example, compare the 
execve(2) system call with the various execxxx(3) subroutines.)
-- 
Andy Sherman/AT&T Bell Laboratories/Murray Hill, NJ           *NEW ADDRESS*
AUDIBLE:  (201) 582-5928                                      *NEW PHONE*
READABLE: andys@ulysses.ATT.COM  or att!ulysses!andys         *NEW EMAIL*
The views and opinions are my own.  Who else would want them? *OLD DISCLAIMER*

>Actually, a system call is an entry point which is a one-for-one mapping to a
>particular kernel service.  Open(2) is a system call which returns a file
>descriptor, which is a kernel data structure. 

On *some* implementations of the UNIX system interface, "open" is a
system call which returns a file descriptor, which is a kernel data
structure.  I don't think it is in Apollo's DOMAIN/OS (or is that
"Domain/OS"?) implementation, for example.

In article <11506@ulysses.homer.nj.att.com> andys@ulysses.homer.nj.att.com (Andy Sherman) writes:
: A system call is a subroutine documented in Chapter 2. :-)

Right you are. And that is the only definition that is meaningful to
a programmer.

: Actually, a system call is an entry point which is a one-for-one mapping to a
: particular kernel service.  Open(2) is a system call which returns a file
: descriptor, which is a kernel data structure.  Fopen(2) on the other hand
: returns a non-kernel data structure called a stream, which is typedefed as
: FILE in stdio.h.  One field in the structure is the file descriptor, and one
: piece of fopen is a call to open to get that file descriptor.  System functions
: are the primatives which are used either by themselves or implicitly by
: subroutines which add some value.  (For another example, compare the
: execve(2) system call with the various execxxx(3) subroutines.)

There isn't a thing in the world requiring fopen to be implemented in
user code. It could just as easily be implemented as a system call.
And in some Unix versions, the different exec calls *are* implemented
all as system calls or as minor variations on a small number of
system calls (that is to say, each is really a small subroutine which
diddles in a slightly different way its arguments and then does one
of a few system calls).

And then consider sleep(). I know of one system where sleep was
implemented as a system call (and documented in section 2) because
the standard version of sleep would hang occasionally. Consider:

	alarm(n);
	pause();

(the guts of sleep) and what happens if the process doesn't run for n
seconds. Have you ever had tail hang on a heavily loaded system? (I
have.) Guess why.

---
Bill                            { uunet | novavax } !twwells!bill