gpsd-dev
[Top][All Lists]
Advanced

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

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


From: Greg Troxel
Subject: Re: ✘64-bit time_t on glibc 2.34 and up
Date: Sat, 14 Jan 2023 09:00:58 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (berkeley-unix)

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

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) and in BSD was int on some ILP32 and all LP64
machines, or at least that is how it is in NetBSD 5.  In NetBSD 6 it is
uniformly int64_t.

It seems time_t is in Linux on i386 and arm.  Checking a Debian x86_64
system, it lacks the POSIX-required sys/types.h (not sure what's up with
that) and 


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

Yes, but one needs to build the entire system that way.  I assume there
are no distributions like this, because they wouldn't be ABI compatible.

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

I meant in the standard, normal, ABI that is generally in use.

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

That needs a prior ifdef linux and/or if defined(_TIME_SIZE_BITS).  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



reply via email to

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