✘64-bit time_t on glibc 2.34 and up

[Gary E. Miller]

Yo Greg!

On Fri, 13 Jan 2023 19:55:47 -0500
Greg Troxel <gdt at lexort.com> wrote:

Sorry, you correctly point out I was sloppy and mistakes in
nomenclature.

See below for more.

> "Gary E. Miller" <gem at 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"?

No, I meant, should have said, LP64: 32-bit ints, 64 bit pointers, as in
x86_64.

> Are there really Linux systems where "int" is 64 bits?, on x86_64?

Intel supports ILP64:
     https://www.intel.com/content/www/us/en/develop/documentation/mpi-developer-guide-linux/top/compiling-and-linking/ilp64-support.html

gcc also supports ILP64.

But let's ignore that for now.  Until someone complains...

> have only seen "int" be 64 bit on Alpha.

And now Intel.

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

My suspicion as well.  I don't care to nail it down exactly, the header
files "do the right thing".

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

I meant, should have said, ILP32, as in x86.  Thus all 32-bit linux
distros that use glibc prior to 2.34.

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

I don't care.  We need to match existing shmTime structure to the byte.
As in case 3, time_t is an int, so we need to be an int, whatever an
int is.

> 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"?

No.  Guarded by #ifdef _TIME_SIZE_BITS == 64

That is, the case where default time_t is int (int32_t), and overridden
time_t is int64_t.

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

Yes.

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

I all ears.

Then we have to solve chrony sockets.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20230113/6f9ac186/attachment.bin>