This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Y2038: add struct __timespec64
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Albert ARIBAUD <albert dot aribaud at 3adev dot fr>
- Cc: <libc-alpha at sourceware dot org>
- Date: Wed, 17 Oct 2018 12:05:40 +0000
- 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> <20181017120011.1c946925@athena>
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