Re: Fifth draft of the Y2038 design document

[Joseph Myers <joseph at codesourcery dot com>]

On Wed, 1 Mar 2017, Albert ARIBAUD wrote:

> This means the GLIBC implementation of clock_gettime64 needs to know
> not only the GLIBC 'struct timespec', but also the two Linux 'struct
> timespec' and 'struct timespec64'.
> 
> I've looked at how GLIBC solves this for 'struct stat' / 'struct
> stat64', but there, the variant chosen depends on the word size, i.e.
> it's *either* the 32-bit off_t *or* the 64-bit off64_t, not both at the
> same time.

Where necessary, glibc has kernel_stat.h files defining struct 
kernel_stat.  For the timespec work, glibc would simply have an internal 
header defining struct kernel_timespec / struct kernel_timespec64.  Then 
the implementation would have the usual

#ifdef __ASSUME_TIME64
  /* Implementation that knows the 64-bit syscalls are available at 
     runtime.  */
#else
  /* Implementation that tries a 64-bit syscall then falls back to a 
     32-bit one if the 64-bit one isn't available, using a static 
     variable (probably shared between all 64-bit time syscalls) to store 
     the results after the first attempt.  */
#endif

(on architectures that have had 64-bit time_t all along, there wouldn't be 
an __clock_gettime64 function defined at all, so the case for such 
architectures would just disable building this code completely).

That is, no need to use the kernel headers for these types and it may be 
simpler not to do so.  There will be very few different definitions 
needed.

-- 
Joseph S. Myers
joseph@codesourcery.com