Re: standards/51024 (NetBSD misses the mandatory waitid() syscall)

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR standards/51024; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
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>
     Message-ID:  <20160420085501.749AD7AA93%mollari.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 
 environment.
 
 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.
 
 kre