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

[Greg Troxel]

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

>> Which magically changes references to syscalls that use time_t, in the
>> entire binary, to the new ones?
>
> Uh, once again, no.  No "versioning".  No syscalls are changed.
>
> Every existing syscall that uses 32-bit time_t now has a 64_bit twin.

And the new ones have new codepoints?  New names that are user-facing?

Does one have to ifdef _TIME_SIZE_BITS in source code and call
gettimeofday64?

Or in a program with _TIME_SIZE_BITS there is some #define so that
gettimeofday in the sources maps to the int64_t version?

This is what has been unclear

> So old and new binaries just work.

That has to mean that the old syscall number leads to a syscall with the
old behavior and the new syscall has a new number.  That's what I meant
by versioned.

>> What happens if a library defines D_TIME_BITS 64 and makes syscalls,
>> and a program which is unaware of this defines 32 and also makes
>> sycalls? Or is the syscall switch per .o because the names are
>> #defined?
>
> That can never happen.

I don't see how different .o files are prohibited from having different
_TIME_SIZE_BITS, unless it leads to a link failure.

Are there then new and old libc?