[fpc-devel] Problem with Now() and time changed by ntpd

Vinzent Höfler JeLlyFish.software at gmx.net
Thu Nov 3 18:40:48 CET 2011


On Thu, 03 Nov 2011 17:38:01 +0100, Hans-Peter Diettrich  
<DrDiettrich1 at aol.com> wrote:

>> FPC's Now on Windows uses GetLocalTime as well. For its implementation  
>> please take a look here:  
>> http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/client/time.c?revision=52912&view=markup  
>> (line 277ff)
>
> That code doesn't make sense, without additional information :-(
>
>    283     do
>    284     {
>    285         SystemTime.HighPart =  
> SharedUserData->SystemTime.High1Time;
>    286         SystemTime.LowPart = SharedUserData->SystemTime.LowPart;
>    287     }
>    288     while (SystemTime.HighPart !=  
> SharedUserData->SystemTime.High2Time);
>
> As long as no functions are involved, the loop copies the same  
> information into SystemTime, over and over again.

Nope. SystemTime.HighXTime is most probably a "volatile", so it is read
each time through the loop. I can only guess what High1Time and High2Time  
is
(I'd assume they basically map to the same variable, so you're right, that
is a bit strange somehow, but well...), but this is a common pattern to
counterfeit wrong time reads when a wrap-around happens during reading the
individual parts.

Consider reading the values when the time value is $0000:$FFFF. First you
read the $FFFF, then the time value changes to $0001:0000 and next you
read the high part as $0001. Net result: $0001:$FFFF. Thus, a big time jump
happens. Seldom enough to detect in testing, but often enough to cause
disastrous results at the customer site from time to time.

By checking the high part again, the problem is avoided.

[Well, at least as long as the reading does not take a huge amount of time,
so that another wrap of the high part happens... ;)]


Vinzent.



More information about the fpc-devel mailing list