This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Y2038: add struct __timespec64
- From: Albert ARIBAUD <albert dot aribaud at 3adev dot fr>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Wed, 17 Oct 2018 12:00:11 +0200
- Subject: Re: [PATCH] Y2038: add struct __timespec64
- References: <20180919072701.27535-1-albert.aribaud@3adev.fr> <alpine.DEB.2.21.1809191606290.26757@digraph.polyomino.org.uk> <20180926132408.7b64cb08@athena> <alpine.DEB.2.21.1809261626230.9033@digraph.polyomino.org.uk>
Hi Joseph,
On Wed, 26 Sep 2018 16:28:21 +0000, Joseph Myers
<joseph@codesourcery.com> wrote :
> On Wed, 26 Sep 2018, Albert ARIBAUD wrote:
>
> > I have just checked the Y2038 syscalls branch I am using currently, and
> > it seems to clear the 32 upper bits of tv_nsec when receiving it from
> > the userland, so yes, we actually don't need to clear it ourselves
> > (I'll have to update the design document, which still assumes
> > otherwise).
>
> 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.
If we consider this not to be a problem, then we can keep the 32-bit
tv_nsec plus anonymous padding in both the public and private struct
__timespec64 types.
Cordialement,
Albert ARIBAUD
3ADEV