svn commit: r292777 - in head: lib/libc/sys sys/kern

[Bruce Evans]

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 at 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.

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