From owner-svn-src-all@freebsd.org Mon Dec 28 03:14:47 2015 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D72C7A4D56E for ; Mon, 28 Dec 2015 03:14:47 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BC0661846; Mon, 28 Dec 2015 03:14:47 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-250-125.lns20.per4.internode.on.net [121.45.250.125]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id tBS3ELVh022776 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 27 Dec 2015 19:14:24 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: svn commit: r292777 - in head: lib/libc/sys sys/kern To: Bruce Evans , Ian Lepore References: <201512271537.tBRFb7nN095297@repo.freebsd.org> <1451236237.1369.9.camel@freebsd.org> <20151227184101.GG70867@zxy.spb.ru> <1451243810.1369.10.camel@freebsd.org> <20151227193046.GE4535@zxy.spb.ru> <8D7D617E-FF9E-4D74-87CB-1F3EE65D108A@gmail.com> <1451247868.1369.16.camel@freebsd.org> <20151228093724.D1014@besplex.bde.org> Cc: NGie Cooper , Slawa Olhovchenkov , Dmitry Chagin , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org From: Julian Elischer Message-ID: <5680A907.4020407@freebsd.org> Date: Mon, 28 Dec 2015 11:14:15 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20151228093724.D1014@besplex.bde.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2015 03:14:47 -0000 On 28/12/2015 7:23 AM, Bruce Evans wrote: > On Sun, 27 Dec 2015, Ian Lepore wrote: > >> On Sun, 2015-12-27 at 12:05 -0800, NGie Cooper wrote: >>>> On Dec 27, 2015, at 11:30, Slawa Olhovchenkov >>>> wrote: >>> >>> � >>> >>>>> I have no idea what you mean by that -- I didn't say anything at >>>>> all >>>>> about panic. >>>> >>>> As I understund commit log -- this is prevent kernel panic at some >>>> call (with illegal arguments). This accpetable irrelevant to bugs >>>> in >>>> calling code. >>> >>> This also makes us POSIX compliant and more compatible with >>> Linux: >>> http://pubs.opengroup.org/onlinepubs/007908799/xsh/clock_settime.html >>> (search for �negative�). >>> Thanks kib! >>> -NGie >> >> This thread just keeps becoming more and more surrealistic. First >> someone tries to reply to the original commit (I guess?) by replying >> with a complete non sequitur to my reply. Now you cite a document >> that >> says nothing directly related to the commit at all. >> >> The only reference to "negative" in what you cited is part of >> specifying how to truncate/round fractional values that fall between >> two representable values given the resolution of the clock you're >> setting. > > It also has an obfuscated verbose spelling of negative as "less than > zero" in the description of [EINVAL]. This is the specification of > a invalid timespec which is repeated ad nauseum. The upper limit is > spelled even more verbosely as "greater than or equal to 1000 million". > The correct spelling of this is ">= 1000000000" but that is hard to > read in another way (too many 0's to count quickly). Spelling this > value is remarkably difficult. There are about 10 different spellings > that are no good since they depend on the locale or language (natural > or programming). Mixing digits and words is ugly. 1 billion is > shorter but is off by a factor of 1000 in some locales. > so, now that you have all that loaded into your interneal cache, how about suggesting the least suboptimal behaviour. > I stared at this description many times. It doesn't allow considering > negative times as invalid generally. setitimer(2) has to be specially > broken to disallow them. This bug is missing for nanosleep(). FreeBSD > still documents a non-POSIX limit of 100000000 seconds for > setitimer(2), > but its implementation has been broken to overflow instead of enforcing > this limit. Note that this is 1 followed by 8 zeros and applies to > the seconds value, while the limit for nanoseconds os 1 followed by 9 > zeros. > > Different spellings of 1 followed by a large number of zeros makes thes > value hard to grep for. 1 followed by 8 zeros is in about 50 man pages > (counting links). It is documented as the limit on seconds in > get/setitimer(2). mtree(8) misspells 1 followed by 9 zeros as 1 > followed > by 8 zeros. alarm(3) is implemented using itimers and documents the > same limit. ularm(3) documents the bizarre limit of 1 followed by 14 > zeros "in case this value fits in an the unsigned integer". This is > alarm(3)'s documented but not actual limit of 10**8 seconds converted > to microseconds. It is reachable on systems with >= 47 bit longs. > This spelling is not used in any man page for the limit on the number > of nanoseconds (as in POSIX). > >> Later in that document they specifically require EINVAL for negative >> fractional second values. If they intended to to prohibit negative >> whole-second values, that would certainly have been the place to >> mention it, and they don't. > > This is the "obfuscated verbose spelling" part. This is not really > a restriction on negative fractions. It is just that negative > fractions > are represented as a negative integer plus a proper fraction, where by > definition a proper fraction is nonnegative and less than 1. > Normalization gives this (except when it would overflow). The > requirement is essentially that callers don't pass unnormalized values. > > Bruce