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

[Richard Laager]

On 1/13/23 18:33, Gary E. Miller via devel wrote:
> Yo All!
> 
> Looks like there are four cases to support with shmTime:
> 
> 1: 64-bit time_t with 64-bit ints:
>        All known 64-bit distros (?)
>        Works after 2038
>        No change required.
> 
> 2: 64-bit time_t with 32-bit ints:
>        All *BSD (?)
>        Works after 2038
>        No change required.
> 
> 3: 32-bit time_t with 32-bit ints,  No #define to get 64-bit time_t
>        glibc version 2.33 and before
>        Fails in 2038
>        No change possible
> 
> 4: Optional 64-bit time_t with 32-bit ints. #define to get 64-bit time_t
>        glibc version 2.34 and later
>        Works after 2038
>        Incompatible with unmodified chrinyd, ntpd, htpshmmon, etc.
>        Fix possible.
> 
> So, looking only at option 4.  The one that we can improve.

I think you have captured the options correctly.

> I had over looked the "int dummy[8]" in shmTime that Richard pointed out.
> CUrrently gpsd has set those fields to 0.
> 
> In that case, and only that case, change shmTime as follows:
> 
> From:
> 
> struct shmTime
> {
>      [...]
>      time_t receiveTimeStampSec;
>      [...]
>      int             dummy[8];
> };
> 
> To:
> 
> struct shmTime
> {
>      [...]
>      // because we use 64-bit time_t, but ntpd expects 32-bits
>      // ignore the sign bit
>      int receiveTimeStampSec;    // lower 31-bits of 64-bit time_t
>      [...]
>      // use the first dummy, previously zero
>      int             top_time_t;  // upper bits of 64-bit time_t
>      int             dummy[7];
> };
> 
> Before 2038, top_time_t will always be zero.
> After 2038, until 2106, top_time_t will be always one.
> 
> 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?

Should top_time_t be unsigned? 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.

-- 
Richard