[Y2038] Replacement of struct timespec with struct __timespec64 in glibc internal code
Wed Jun 24 12:26:03 GMT 2020
> On Wed, 3 Jun 2020, Lukasz Majewski wrote:
> > To do it I could:
> > - Replace its occurences in relevant directories - like ./nptl or
> > ./sysdeps/pthread - i.e. rename all occurrences in a single
> > directory
> > - Replace them in functions (tests) and use explicit conversion
> > functions - like valid_timespec_to_timespec64() before passing
> > struct __timespec64 arguments (like ones for futex_time64 for nptl).
> > - Replace _all_ occurrences in glibc tree of struct timespec with
> > struct __timespec64 at once with using sed on the glibc tree.
> Using sed obviously won't work, since external interfaces need
> different handling from purely internal uses. I think you need to
> change things bit by bit, in sufficiently small patches for
> convenient review.
> Regarding tests, I expect many tests of time-related interfaces
> should end up being built and run twice on systems that currently use
> 32-bit time, once to test the interfaces with 32-bit time and once to
> test the interfaces with 64-bit time.
Does it mean that I shall NOT make the struct timespec to struct
__timespec64 conversion in glibc tests (e.g.
./sysdeps/pthread/tst-mutex5.c). Would those tests build infrastructure
be changed to build them w/ _TIME_BITS=64 support?
One thing puzzles me though - it seems like xclock_gettime, xclock_now,
timespec_add, timespec_sub are used by glibc tests (#include
Am I correct that those functions are not exported and used solely
The problem is that I do need to convert them to support 64 bit time as
pthreads use them (sysdeps/pthread/timer_settime.c). This also means
that I would need to update tests (otherwise I would experience
build/tests errors), which you don't recommend before the _TIME_BITS=64
support is added.
How to proceed in this case? Two big parts of Y2038 support are still
- One is stat and friends (which may be simplified when we move forward
with minimal kernel version supported)
- And second are pthreads (nptl).
Pthreads are important for user space applications - so they shall be
converted sooner than latter IMHO.
> Also, tests can't generally
> use 64-bit time interfaces from libc until _TIME_BITS=64 support is
> actually implemented.
Does it mean that tests - like sysdeps/pthread/tst-mutex5.c - will
always use exported struct timespec? (aliased to 64 bit struct
__timespec64 when needed)?
> So I think tests would be one of the last
> places to change (and similarly installed executables).
> Whereas any
> internal use of time in a function in the libraries that does not
> involve time in its interface can be updated more or less
> independently of any other such use, provided the relevant internal
> interfaces using 64-bit time are now available.
As I stated above - e.g. timespec_sub() helper function (from /support)
is used by both pthreats and tests.
Despite it is internal function - shall I follow the pattern and
rewrite it as:
__timespec_add64(... struct __timespec64)
#if __TIMESIZE != 64
__timespec_add(... struct timespec64)
However, the above approach seems to me like an overkill to do this for
internally used support function.
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: firstname.lastname@example.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 488 bytes
Desc: OpenPGP digital signature
More information about the Libc-alpha