Re: ✘64-bit time_t on glibc 2.34 and up

[Gary E. Miller]

Yo Richard!

On Fri, 13 Jan 2023 19:08:10 -0600
Richard Laager via devel <devel@ntpsec.org> wrote:

> > So, looking only at option 4.  The one that we can improve.  
> 
> I think you have captured the options correctly.

Plus the corrections from Greg.

> > That maintains compatibility with existing SHM users.
> > That works with existing SHM users until 2038.
> > That works with modified SHM users until the end of 64 bit time.  
> 
> I like it! In broad strokes, this seems like the right solution. Way 
> better than my ideas about trying to use a magic and detect where it
> is.

Good.
 
> There is another time_t field in the struct. Does that also have to
> change?

Yeah.  Missed that.

    time_t clockTimeStampSec;

And:

    time_t receiveTimeStampSec;

> Should top_time_t be unsigned?

Either way.  The top bit is never set.  I would like to follow
the existing as much as possible (time_t is int).

> The original 64-bit time_t will be 
> signed, but you know that it is always positive. You put the lower 31 
> bits in the original field (which makes sense, as you don't want the 
> 32nd bit to go in the sign bit spot of the original field). That
> leaves 64 - 31 = 33 bits to save. One of those is the sign bit. Since
> we know it is positive, we can drop that. So top_time_t should be
> unsigned to make that clear.

I'll see what is easist to avoid compiler warnings with.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        gem@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

pgpgwG6jsdS01.pgp
Description: OpenPGP digital signature