[prev in list] [next in list] [prev in thread] [next in thread]
List: busybox
Subject: Re: [PATCH v2] ntpd: make NTP client and server Y2036/2038-ready
From: Miroslav Lichvar <mlichvar () redhat ! com>
Date: 2023-01-18 8:36:26
Message-ID: Y8evii08IzWo3dKC () localhost
[Download RAW message or body]
On Tue, Jan 17, 2023 at 05:00:50PM +0100, Denys Vlasenko wrote:
> > On Fri, Sep 16, 2022 at 3:07 PM Miroslav Lichvar <mlichvar@redhat.com> wrote:
> > > The 32-bit integer part of the NTP timestamp overflows in year 2036,
> > > which starts the second NTP era.
> >
> > > + /* Shift timestamps before 1970 to the second NTP era (2036-2106) */
> > > + if (lfp.int_partl < OFFSET_1900_1970)
> > > + ret += (double)UINT_MAX + 1.0;
> >
> > Shouldn't this be 0xffffffff instead of UINT_MAX?
> >
> > What you are doing here is treating 0...OFFSET_1900_1970
> > as if there is a carry bit in int_partl, right?
> > And int_partl is not unit_t. It's uint32_t. Thus you need to add
> > (1<<32).
Right, that was the intention, but I didn't realize it needs to work on
systems where int is not 32-bit. Thanks for fixing it.
> Speaking of this... these are bugs, no?
Yes.
> ret = (double)lfp.int_partl + ((double)lfp.fractionl / UINT_MAX);
In this case it probably didn't matter as the values are too large to
contain the lowest bits of the fraction in the double format.
> ...
> ret = (double)sfp.int_parts + ((double)sfp.fractions / USHRT_MAX);
--
Miroslav Lichvar
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic