[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: David Holland <dholland-bugs%netbsd.org@localhost>
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
Main Index |
Thread Index |