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

[David Holland <dholland-bugs%netbsd.org@localhost>]

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

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: standards/51024 (NetBSD misses the mandatory waitid() syscall)
Date: Mon, 30 May 2016 04:07:08 +0000

 On Thu, Apr 21, 2016 at 01:50:00AM +0000, Robert Elz wrote:
  >    |  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.)
 
 That would be VMS...
 
  >  Allowing applications to use other values (even just another 254 of them)
  >  is an extension (one of the posix options.)
  >  [...]
  >  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) ?
 
 It allows you to use them for signalling. For example (offhand, so may
 not be that persuasive if examined too closely) given some kind of
 preforking httpd that runs application-server things with exec, you
 might conceivably define the exit codes as
    0 - everything went fine, nothing to do
    1 - something went wrong
    2 - something went badly wrong
    3+ - everything went fine; you should close this fd
 
 Yes, this can become gross, and if you want to generate significant
 output that's what stdout (or other things) is for, but there's no
 reason a cooperating subnet of processes can't do productive things
 even if it doesn't make sense in the general case.
 
 A perhaps more persuasive argument is: we provide an integer result
 argument. Is there any reason *to* arbitrarily truncate it, vs.
 rather than delivering the value as submitted or as much of it as can
 be carried through readily? I can't think of any.
 
 One could also make an argument that like errno is a special case of
 an exception, an exit code is also a special case of an exception and
 there should be a way to throw system-level exceptions out of
 programs. That's definitely into crazy talk though :-)
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost