Date: Mon, 28 Dec 2015 11:14:15 +0800 From: Julian Elischer <julian@freebsd.org> To: Bruce Evans <brde@optusnet.com.au>, Ian Lepore <ian@freebsd.org> Cc: NGie Cooper <yaneurabeya@gmail.com>, Slawa Olhovchenkov <slw@zxy.spb.ru>, Dmitry Chagin <dchagin@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r292777 - in head: lib/libc/sys sys/kern Message-ID: <5680A907.4020407@freebsd.org> In-Reply-To: <20151228093724.D1014@besplex.bde.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <slw@zxy.spb.ru> >>>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5680A907.4020407>