[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Gary E. Miller
Subject: Re: ✘64-bit time_t on glibc 2.34 and up
Date: Fri, 13 Jan 2023 17:44:39 -0800

Yo Richard!

On Fri, 13 Jan 2023 19:08:10 -0600
Richard Laager via devel <> 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.

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

Yeah.  Missed that.

    time_t clockTimeStampSec;


    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.

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

Attachment: pgpgwG6jsdS01.pgp
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]