[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: Gary E. Miller
Subject: Re: ✘64-bit time_t on glibc 2.34 and up
Date: Sat, 14 Jan 2023 12:58:23 -0800

Yo Greg!

On Sat, 14 Jan 2023 09:32:03 -0500
Greg Troxel <> wrote:

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

Yes.  From /usr/include/sys/time.h:

#ifndef __USE_TIME_BITS64
extern int gettimeofday (struct timeval *__restrict __tv,
                         void *__restrict __tz) __THROW __nonnull ((1));
# ifdef __REDIRECT_NTH
extern int __REDIRECT_NTH (gettimeofday, (struct timeval *__restrict __tv,
                                          void *__restrict __tz),
                           __gettimeofday64) __nonnull ((1));
# else
#  define gettimeofday __gettimeofday64
# endif

> This is what has been unclear

Maybe to BSD people...

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

That is not how I use "versioned".  In Linux land "versioned" applis to the
version number on shared libraries.

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

You can always build bad .o.  But good practice is to build all .o
in a program or binary with the same setting.  Otherwise a huge number
of ways to fail.  That is why all gpsd c files start with:

#include "../include/gpsd_config.h"  // must be before all includes

> Are there then new and old libc?

Of course. glibs versions change with the days of the week.  When a
program is linked, it is matched to one and only one glibc version.

libc proliferate like bunnies.  Thus the need for them to be versioned.

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

Attachment: pgpMlxtWxTAWd.pgp
Description: OpenPGP digital signature

reply via email to

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