[Y2038] Replacement of struct timespec with struct __timespec64 in glibc internal code

[Lukasz Majewski]

Dear Community,

I would like to bring up one relevant Y2038 support issue  - to be more
specific - the conversion/replacement of struct timespec to struct
__timespec64 in glibc internal code (source tree).

For example - I would like to convert nptl and pthreads to be Y2038
safe. To do that the timespec_* helpers and some functions, which use
futex_time64 syscall, (from 5.1+) need to use struct __timespec64. 

The problem is with instant replacement of struct timespec with
struct __timespec64 in glibc internal code (and tests). 


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.

The last option seems to be the most appealing as we already use
__timespec64 (with its aliasing) for some core system syscalls (like
clock_gettime). 
However, such patch shall be applied just after the release of new
stable glibc version (August 2020?) to have time for potential fixes.


Which options shall we use?



A few more related questions:
- Shall tests in ./nptl and ./sysdeps/pthread [*] use struct
  __timespec64 or struct timespec? 
  From my understanding tests (like ./nptl/tst-*) use exported headers
  so struct timespec for them is struct __timespec64 anyway for archs
  with __WORDSIZE == 32 and __TIMESIZE !=64.

- Other time related structures needs to be converted as well - like
  struct itimerspec. 


[*] - from running scripts/build-many-glibcs.py it looks like only
i686-gnu port (HURD) is using code in ./sysdeps/pthread. Will
./sysdeps/pthread be replaced by nptl in some near time in the future
(and removed)? 



Best regards,

Lukasz Majewski

--

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: lukma@denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20200603/0e6ed006/attachment-0001.sig>