utimensat UTIME_NOW granularity bug

[Christopher Faylor]

On Fri, Oct 09, 2009 at 06:45:51AM -0600, Eric Blake wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>According to Christopher Faylor on 10/8/2009 10:58 PM:
>> 
>> I don't like "MILLION" or "BILLION".  I think a real number is clearer
>> for that.  Maybe it's jsut me but when I see million I can't help myself
>> from checking to see if it's 1000000 or 1024*1024.  And, if you're going
>> to assign constants to 1 with a bunch of zeros where do you draw the
>> line?
>
>OK, here's the respin without the churn.
>
>> 
>> It looks like you either don't need the systime() call or it should
>> call systime_ns.
>
>Done.  hires_us still uses systime().
>
>> 
>>>       long long x = time_in->tv_sec * NSPERSEC +
>>> -			    time_in->tv_nsec / (NSPERSEC/100000) + FACTOR;
>>> +			    time_in->tv_nsec / (BILLION / NSPERSEC) + FACTOR;
>> 
>> I'm too tired now to figure out why you switched these but it seems
>> odd that you switched the numerator and denominator  here but
>> 
>>>   long long x = time_in->tv_sec * NSPERSEC +
>>> -			time_in->tv_usec * (NSPERSEC/1000000) + FACTOR;
>>> +			time_in->tv_usec * (NSPERSEC / MILLION) + FACTOR;
>
>Because the number 100000 is unrelated to anything else in this file; just
>because NSPERSEC/1000000 gives the right answer doesn't mean it expresses
>the right equation.  We are really calculating these two values:
>
>tv_nsec / 100 (nsecs) - scaling down
>tv_nsec * 10 (usecs) - scaling up
>
>so that x will be in terms of 100ns ticks.  The relations should be:
>
>/ 100 = 1000000000/NSPERSEC = 1000000000/10000000
>*  10 =   NSPERSEC/1000000  =   10000000/1000000
>
>since NSPERSEC falls in between nanoseconds and microseconds.


I'm still not convinced that this switch makes anything clearer but, that's ok.

Please check in.

Thanks.

cgf