This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Fifth draft of the Y2038 design document
On Wed, Feb 22, 2017 at 3:17 PM, Albert ARIBAUD <albert.aribaud@3adev.fr> wrote:
>
> Besides, what you're hinting at is basically struct timeval with
> nanoseconds, and from what I understand, struct timeval is being phased
> out from Posix, so I suspect that trying to bring it back disguised as a
> struct timespec might be met with resistance (btw, it would be really
> interesting to know what led to phasing struct timeval out).
As far as I know - and I could be wrong - the *only* reason struct
timeval is being phased out by POSIX is that microsecond resolution is
no longer considered good enough.
> We do not necessarily need to worry about padding unless we try to map
> a 64bit+32bit struct timespec and another struct timespec which would
> happen to be be 2x64bits -- such as running 32-bit user code with
> 64-bit time over a full 64-bit kernel (disclaimer: I don't expect that
> use case for my purposes).
I'm most concerned about breaking code that does
struct timespec timeout = { 0, 200 * 1e6 }; /* 200ms */
myself.
zw