From owner-svn-src-head@FreeBSD.ORG Sun Jul 7 05:36:14 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1E302C63; Sun, 7 Jul 2013 05:36:14 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-gh0-x22f.google.com (mail-gh0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 90CBE119A; Sun, 7 Jul 2013 05:36:13 +0000 (UTC) Received: by mail-gh0-f175.google.com with SMTP id z19so1264975ghb.6 for ; Sat, 06 Jul 2013 22:36:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=x/Waj2fly9J1WySxi//s8ybjYZPeWRIUjh4g2INBN/Y=; b=fXgDDpKH8PdtW7XeDZGiWXzYJN0EZ1savsUk2HS8hxtGpaA+e5CD3HDQiin+ce4Fs+ 10FgwWgsox5heQiNEDQ3bLtvLCP1PFL2map8rpJmU0CFMOOf0ffCnJ5tVMPTWsUPYc3Z 5fo2j/23yceCvf7c+C1KmzNWQ1RSI4Fjv/YeitTtXrCjRd3l2QaOvpm9zotkzE8jPIP8 EBj41Eac0cthbmhxSDJLMXfS1cvqcyyxRuvrRniORtv1k4YgobRDsSQ0hcCPWphZrHPg Q6YtKOrEKm0n1Juq/fK7xONkOibEG9vdh3U2zYyySn5e05Aku3V21DMpEnmX0vC78wYD xHXw== X-Received: by 10.236.31.202 with SMTP id m50mr9340824yha.19.1373175372704; Sat, 06 Jul 2013 22:36:12 -0700 (PDT) Received: from [10.77.122.209] (mobile-166-147-108-080.mycingular.net. [166.147.108.80]) by mx.google.com with ESMTPSA id e69sm26783412yhl.3.2013.07.06.22.36.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 06 Jul 2013 22:36:12 -0700 (PDT) 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> Mime-Version: 1.0 (1.0) In-Reply-To: <20130707114237.L897@besplex.bde.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9C9CE501-055E-44A6-82BD-FFB44A04B30F@gmail.com> X-Mailer: iPhone Mail (10B329) From: Garrett Cooper Subject: Re: svn commit: r252672 - head/sbin/nvmecontrol Date: Sat, 6 Jul 2013 22:36:04 -0700 To: Bruce Evans Cc: Jim Harris , "src-committers@FreeBSD.org" , Pawel Jakub Dawidek , Jilles Tjoelker , "svn-src-all@FreeBSD.org" , Bruce Evans , "svn-src-head@FreeBSD.org" X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 05:36:14 -0000 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 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.=