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

[Greg Troxel]

"Gary E. Miller" <gem@rellim.com> writes:

> 1: 64-bit time_t with 64-bit ints:
>       All known 64-bit distros (?)
>       Works after 2038
>       No change required.

Do you mean "int64_t"?

Are there really Linux systems where "int" is 64 bits?, on x86_64?   I
have only seen "int" be 64 bit on Alpha.

are there actual systems like this?

> 2: 64-bit time_t with 32-bit ints:
>       All *BSD (?)
>       Works after 2038
>       No change required.

I suspect most BSD.  Certainly NetBSD has "int64_t" as time_t, on all
CPU types, i386, x86_64, alpha (as the three representatives).

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

Sure, but isn't this pretty much all Linux computers, except on Alpha?

> So, looking only at option 4.  The one that we can improve.
>
> 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];
> };

int is not guaranteed to be 32 bits.  It is 64 bits on Alpha.

So this is guarded on "time_t is the same type as int32_t"?  And also
"time_t is int64_t, but it's Linux with a define"?

And NOT for "the system time_t type is int64_t, with no funny business?"


I lean to favoring a non-icky post-transition state.