[PATCH] Y2038: add struct __timespec64

[Joseph Myers]

On Wed, 17 Oct 2018, Albert ARIBAUD wrote:

> > In that case, is there any reason for the contents of the internal type to 
> > differ at all from the contents of the public type?  Or would it be best 
> > for both to use the anonymous padding when building for 32-bit long?
> 
> The only reason for a difference between an internal (64-bit tv_nsec)
> and public (32-bit tv_nsec) type is that we want application source code
> to build and run the same for 32-bit and 64-bit time, and Posix defines
> tv_nsec as a long (for 32-bit time), so application source code /might/
> expect it to be a long for 64-bit time too. However, the worse I can
> foresee if we make tv_nsec 64-bit is that some application source code
> might copy it into a long, which /may/ trigger gcc to warn if the
> compiler options include -Wconversion.

I agree that the user-visible type should be long in all cases.  My 
question was why the internal tv_nsec should be 64-bit for the case of 
32-bit long, rather than making the internal type work the same as the 
POSIX one (long tv_nsec, anonymous padding when needed), if there is never 
any need to zero the padding explicitly.

-- 
Joseph S. Myers
joseph@codesourcery.com