[PATCH v2] ntpd: make NTP client and server Y2036/2038-ready

Denys Vlasenko vda.linux at googlemail.com
Tue Jan 17 16:00:50 UTC 2023


On Tue, Jan 17, 2023 at 4:47 PM Denys Vlasenko <vda.linux at googlemail.com> wrote:
> Apologies for a very late reply.
>
> On Fri, Sep 16, 2022 at 3:07 PM Miroslav Lichvar <mlichvar at 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).

Speaking of this... these are bugs, no?

       ret = (double)lfp.int_partl + ((double)lfp.fractionl / UINT_MAX);
...
       ret = (double)sfp.int_parts + ((double)sfp.fractions / USHRT_MAX);

because fractionl of 0xffffffff is not 1 second (as the above code thinks),
it is less than that: 0xffffffff / (1<<32) seconds


More information about the busybox mailing list