✘64-bit time_t on glibc 2.34 and up

[Gary E. Miller]

Yo Greg!

On Sat, 14 Jan 2023 09:00:58 -0500
Greg Troxel <gdt at lexort.com> wrote:

> "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.  
> 
> The size of int isn't really the question.

Thus my correction above.

>  It's the size of the type
> used for time_t, which is an implementation choice.   POSIX requires
> only "time_t shall be an integer type.".

Yes.

> However, my memory was fuzzy.  Historically, time_t was "long".  On
> the PDP-11, int was 16 bits and long was 32 bits.  It remained long
> on most 32-bit machines (ILP32)

Uh, no.  time_t has been in t on Linux for decades.

But, I don't care how we got here.  I just care where we are and how to move
forward.  We already agreed we categorized all the common current cases,
and the way to move forward that breaks nothing is already in git head.

> >> have only seen "int" be 64 bit on Alpha.  
> >
> > And now Intel.  
> 
> I meant in the standard, normal, ABI that is generally in use.

I thought we were enumerating all likely cases, not just the "normal".
But, the recent gpsd patches handle that too, so no worries.

> > That is, the case where default time_t is int (int32_t), and
> > overridden time_t is int64_t.  
> 
> That needs a prior ifdef linux and/or if defined(_TIME_SIZE_BITS).

Which is exactly what the new code in git head does.  Except it cannot
ifdef linux since glibc runs on more than  linux.

> My
> point is that this whole thing is a workaround for the unusual feature
> of a dual API where it is normal for different programs to make
> different choices

Which is nack to exactly where this started:

https://gitlab.com/gpsd/gpsd/-/issues/152

And now completed.

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/20230114/1abc9bff/attachment.bin>