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>