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

[Miroslav Lichvar]

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 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).

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