svn commit: r252672 - head/sbin/nvmecontrol

[Bruce Evans]

On Sat, 6 Jul 2013, Jilles Tjoelker wrote:

> On Sat, Jul 06, 2013 at 08:42:49PM +0200, Pawel Jakub Dawidek wrote:
>> On Thu, Jul 04, 2013 at 11:44:28AM +1000, Bruce Evans wrote:
>>> Many style bugs are visible in this patch:
>> [...]
>>> - sysexits.h is used
>> [...]
>
>> Bruce, until sysexits(3) doesn't explicitly say it shouldn't be used,
>> please stop calling this a bug, because you are just confusing people.
>> At this point sysexits(3) actually even suggests it is blessed by
>> style(9). This is how it starts:
>
>> 	According to style(9), it is not a good practice to call exit(3)
>> 	with arbitrary values to indicate a failure condition when
>> 	ending a program. Instead, the pre-defined exit codes from
>> 	sysexits should be used, so the caller of the process can get a
>> 	rough estimation about the failure class without looking up the
>> 	source code.

This is just another bug in sysexits(3).  This is not according to
style(9), since style(9) was fixed to not say that after I complained
previously :-).  It has never been normal practice to use sysexits(3),
but someone who likes it added recommendations to use it to style(9) 
when they added the man pages for sysexits(3).  Before that, it was
so rarely used that it had no man page.

>> In my personal opinion it doesn't hurt to use sysexits(3) - if you don't
>> want to interpret exit status then treat every value != 0 as an error.
>> In HAST (IIRC) I do interpret exit status - if I get EX_TEMPFAIL, I know
>> I can try to restart the process, if I get something else I don't
>> restart it, as I risk an infinite loop.

That's fine for suites of programs that agree on exit codes.  You can't
depend on this for anything else.

>> Apart from my personal opinion, if you want to call it a bug and not
>> confuse people, then start discussion and change the manual page to
>> recommend avoiding sysexits(3). As of now we are just sending mixed
>> signals and create confusion.
>
> This is indeed confusing, because style(9) itself does not recommend
> sysexits at all. This was changed in 2008 but sysexits(3) was not
> adjusted along with that.
>
> The text in style(9) that only allows 0 or 1 is not universally valid
> either. Firstly, in some application areas like mail delivery, it is
> conventional and documented to use and interpret sysexits codes. (So if
> HAST uses sysexits, it should document that fact.) Secondly, some other
> utilities such as test, cmp and diff use 0 for a "true" condition, 1 for
> a "false" condition and greater than 1 (usually 2) for failures.

0 and 1 are all that are universally valid.  Programs shouldn't generate
more than these unless they have special requirements/protocols.  But
nonzero meaning "failed" should be accepted by all POSIX programs.

This is even more implementation-defined than I remembered in plain C
programs.  In C99, EXIT_SUCCESS (0) is mapped to success in some
implementation-defined way; EXIT_FAILURE (1) is mapped to failure
in some implementation-defined way; for all other exit() args, the
whole mapping is implementation-defined, so 2 and everything in
sysexits.h may be mapped to success.  Therefore, portable C programs
must not use anythying except 0 or 1 (preferably spelled using the
C99 macros).  Not using sysexits.h also keeps the sources portable.
sysexits.h is in neither C99 nor POSIX.

style(9) isn't the place to give portability lessons like the above.
I think we discussed using EXIT_SUCCESS and EXIT_FAILURE when we changed
it to not mention sysexits, but for some reason it hard code 0 and 1.

The original style rule against using cryptic error codes hasn't been
restored.  From the 4.4BSD style guide:

% 	/*
% 	 * Exits should be 0 on success, and 1 on failure.  Don't denote
% 	 * all the possible exit points, using the integers 1 through 300.
% 	 */
% 	exit(0);    /* Avoid obvious comments such as "Exit 0 on success." */

(Here 300 is off by 45.  Exit statuses less than 0 and greater than 255
give implementation-defined behaviour that is worse than usual.)  I think
this rule is to limit cryptic undocumented exit codes.  I don't like
sysexits because it gives cryptic documented exit codes instead.  All
that can be safeley done (except in prgram suites) is map all nonzero
exit codes to "failed" (or killed by a signal).

In another thread involving Pawel, phk campaigns against errno and asks
for error strings (even if they are only in English).  Using perror()
did this long ago for program termination, and using the err() family
does it better.  Except possibly for program suites -- translating a
single numeric error is easier for programs than translating an
unstructured string.  I actually prefer using binary representations
for programs.

Bruce