Yo Eric! On Tue, 18 Apr 2017 15:08:11 -0400 "Eric S. Raymond" <e...@thyrsus.com> wrote:
> Hal Murray <hmur...@megapathdsl.net>:
> >
> > g...@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
g...@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
pgpoq4XifNGug.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
