Work item list: l_fp_time and l_fp_offset
Gary E. Miller
gem at rellim.com
Wed Apr 26 20:26:24 UTC 2017
Yo Achim!
On Wed, 26 Apr 2017 22:20:17 +0200
Achim Gratz via devel <devel at ntpsec.org> wrote:
> Gary E. Miller via devel writes:
> >> What exactly do you suggest to replace it with?
> >
> > Timespec with time64_t.
>
> Is that POSIX yet?
Nope. There is no generic standardized solution yet. Until an
OS gives us a way to set time past 2038 nothing that NTP can do.
> > As Linux 64-bit uses now for native time. Then
> > the timestamp arithmetic does not lose precision and the first
> > time64_t rollover is centuries from now.
>
> I'm not sure what you try to gain there, but you are certainly not be
> able to stuff that into registers or call stack and instead have
> pointers to a structure.
Well, that is what ntpd does now on 64 bit linux and glibc, so not a
change at all. It just works. I see no reason to try to fight Linux
or glibc. Go with their flow.
> Again, as long as you can reconcile the time
> at startup, there is absolutely no problem with any rollover during
> the operation of ntpd that results from the use of l_fp.
Yes, agreed. The startup is the problem. Once we have that
everything is good.
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/20170426/5fdc9108/attachment.bin>
More information about the devel
mailing list