[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: standards/51024 (NetBSD misses the mandatory waitid() syscall)
The following reply was made to PR standards/51024; it has been noted by GNATS.
From: Robert Elz <kre%munnari.OZ.AU@localhost>
Subject: Re: standards/51024 (NetBSD misses the mandatory waitid() syscall)
Date: Thu, 21 Apr 2016 08:47:18 +0700
Date: Wed, 20 Apr 2016 08:55:01 +0000 (UTC)
From: David Holland <dholland-bugs%netbsd.org@localhost>
| Am I supposed to interpret this to *prohibit* wait() from returning
| more than 8 bits of status?
| That is... stupid.
In most situations I would agree with that reasoning, but here I am not
sure that I do.
We need to work out just what the status is for, and how it is intended
to be used.
Basic POSIX allows just two values to be passed to exit() (by applications)
EXIT_SUCCESS and EXIT_FAILURE (strictly, 3, with 0 as well, but if there's
a system where EXIT_SUCCESS and 0 are not the same thing I have yet to see it.)
Allowing applications to use other values (even just another 254 of them)
is an extension (one of the posix options.)
If the exit status is just to say whether a program worked or not, then
two values is enough. It is nice to have a few more than that so it
is easy for parent processes (especially shell scripts) to determine what
kind of "not worked" it was, when a program failed - eg: a program like
grep can "fail" because the pattern was not in the file(s), or because
one or more files could not be opened, or because of a regular expression
syntax error (or illegal option or similar.)
However, more than a small set of such different codes would soon become
unmanageable - about the biggest rational set I have seen are the
<sysexits.h> values that sendmail originally introduced (or maybe delivermail
before it). There are 15 of them (plus "ok").
So, we need to ask ourselves, just what is the point of allowing more than
a couple of hundred exit codes (or even that many) ?
No-one I have asked has ever supplied a reason why they'd rationally need
more than 10 or 15.
If we start having programs generate zillions of different error exit codes
then we might end up with a system that does like some others I could
name (but won't) where the program (or shell equivalent) ends up printing
something like "Error 12073" ... and then the user has to go look up
the value in a list soewhere to find out what that really means.
The other reason one might decide to use more exit codes, is to stop using
them to indicate success/failure status and instead start using them to
return answers. But if we do that, are 32 bit integers really enough?
Surely we really need at least 64 bits these days (32 might have been enough
back in the 1980's, but now?) And what about floats - or character strings?
Or even general structs. Clearly we would need a much richer exit value
mechanism than just a simple integer.... One might even suggest that one
exit value might be an array of char strings with a name=value type syntax,
so it can be used by programs to export values back to the parent's
The thought of any of this simply makes me ill.
Hence, actually prohibiting systems from implementing more than a reasonably
small set of exit values, such that they can only rationally be used for
either success, or a fairly generic failure type, is not something I
necessarily see as a mistake, or stupid - it might actually be enlightened.
Main Index |
Thread Index |