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 <b...@optusnet.com.au> wrote: > 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. 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 why things fail. Many devs who consume FreeBSD don't understand the concept of man 5 errno, and if they don't, I doubt end-users of FreeBSD (and its derivatives) will. Thanks. _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
