[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
- Re: ✘64-bit time_t on glibc 2.34 and up, (continued)
Message not available
Re: ✘64-bit time_t on glibc 2.34 and up, Hal Murray, 2023/01/13
Message not availableRe: ✘64-bit time_t on glibc 2.34 and up, Gary E. Miller, 2023/01/13
Re: ✘64-bit time_t on glibc 2.34 and up, Hal Murray, 2023/01/14
Re: ✘64-bit time_t on glibc 2.34 and up, Miroslav Lichvar, 2023/01/16