Time to slow down and be more careful

Gary E. Miller gem at rellim.com
Tue Apr 18 19:19:53 UTC 2017


Yo Eric!

On Tue, 18 Apr 2017 15:08:11 -0400
"Eric S. Raymond" <esr at thyrsus.com> wrote:

> Hal Murray <hmurray at megapathdsl.net>:
> > 
> > gem at rellim.com said:  
> > > It is not a bug, but doing it there is a bug.  Follow along while
> > > I do the math:   
> > ...
> > 
> > The case Eric was considering was the local clock is 1970 and the
> > target time is post 2036.  That requires the step adjustment to be
> > more than 31 bits of seconds.
> > 
> > That would work if we applied Eric's suggestion of doing the pivot
> > way back when the l_fp format is extracted from the packets.  Then
> > the arithmetic with the 4 time stamps will get a big offset.  
> 
> What would really be going on here is busting our time arithmetic out
> of the 32-bit box...

Not really.  ntpd still does int64_t arithmetic in a 32-bit binary.
All the ntpd math is the same.

The 32-bit problem is elsewhere.

The 32-bit problem is that you have to deal with timespec(32)
for system time.  That  breaks in 2038.  When we read system time
in timespec(32) we do not know if the currennt year is 1971 or 2039.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20170418/ae26f260/attachment.bin>


More information about the devel mailing list