[Top][All Lists]

[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:32:03 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (berkeley-unix)

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

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?

reply via email to

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