Date: Sun, 7 Jul 2013 12:26:11 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Jilles Tjoelker <jilles@stack.nl> Cc: Jim Harris <jimharris@FreeBSD.org>, src-committers@FreeBSD.org, Pawel Jakub Dawidek <pjd@FreeBSD.org>, svn-src-all@FreeBSD.org, Bruce Evans <brde@optusnet.com.au>, svn-src-head@FreeBSD.org Subject: Re: svn commit: r252672 - head/sbin/nvmecontrol Message-ID: <20130707114237.L897@besplex.bde.org> In-Reply-To: <20130706195108.GA34684@stack.nl> References: <201307040026.r640QOCd079203@svn.freebsd.org> <20130704105843.B982@besplex.bde.org> <20130706184249.GD25842@garage.freebsd.pl> <20130706195108.GA34684@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130707114237.L897>