Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 6 Jul 2013 22:36:04 -0700
From:      Garrett Cooper <yaneurabeya@gmail.com>
To:        Bruce Evans <brde@optusnet.com.au>
Cc:        Jim Harris <jimharris@FreeBSD.org>, "src-committers@FreeBSD.org" <src-committers@FreeBSD.org>, Pawel Jakub Dawidek <pjd@FreeBSD.org>, Jilles Tjoelker <jilles@stack.nl>, "svn-src-all@FreeBSD.org" <svn-src-all@FreeBSD.org>, Bruce Evans <brde@optusnet.com.au>, "svn-src-head@FreeBSD.org" <svn-src-head@FreeBSD.org>
Subject:   Re: svn commit: r252672 - head/sbin/nvmecontrol
Message-ID:  <9C9CE501-055E-44A6-82BD-FFB44A04B30F@gmail.com>
In-Reply-To: <20130707114237.L897@besplex.bde.org>
References:  <201307040026.r640QOCd079203@svn.freebsd.org> <20130704105843.B982@besplex.bde.org> <20130706184249.GD25842@garage.freebsd.pl> <20130706195108.GA34684@stack.nl> <20130707114237.L897@besplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
One minor interjection and I'll butt out of the discussion...

Sent from my iPhone

On Jul 6, 2013, at 7:26 PM, Bruce Evans <brde@optusnet.com.au> wrote:

> On Sat, 6 Jul 2013, Jilles Tjoelker wrote:
>=20
>> 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
>>> [...]
>>=20
>>> 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:
>>=20
>>>    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.
>=20
> 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 t=
hey added the man pages for sysexits(3).  Before that, it was
> so rarely used that it had no man page.
>=20
>>> 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 !=3D 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.
>=20
> That's fine for suites of programs that agree on exit codes.  You can't
> depend on this for anything else.
>=20
>>> 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.
>>=20
>> 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.
>>=20
>> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> The original style rule against using cryptic error codes hasn't been
> restored.  =46rom the 4.4BSD style guide:
>=20
> %    /*
> %     * 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." */=

>=20
> (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).
>=20
> 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.

Your argument would be valid if computers were parsing output and putting it=
 in more meaningful forms, but it's invalid when humans need to understand w=
hy things fail. Many devs who consume FreeBSD don't understand the concept o=
f man 5 errno, and if they don't, I doubt end-users of FreeBSD (and its deri=
vatives) will.

Thanks.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9C9CE501-055E-44A6-82BD-FFB44A04B30F>