Re: Fifth draft of the Y2038 design document

[Zack Weinberg <zackw at panix dot com>]

On Wed, Feb 22, 2017 at 2:33 PM, Albert ARIBAUD <albert.aribaud@3adev.fr> wrote:
> On Wed, 22 Feb 2017 13:51:12 -0500, Zack Weinberg <zackw@panix.com>
> wrote :
>
>> Speaking of struct timespec, though, why does this spec not consider
>> the possibility of changing the type of 'tv_nsec' to a new typedef,
>> say nsec_t, which can vary between 32- and 64-bit modes?  Yes, this
>> requires a change in POSIX (and ISO C as well now, unfortunately), but
>> one that would be a good idea *anyway*.
>
> Honestly, I think I have enough on my plate right now with GLIBC Y2038.
> I don't think I'd be able to add talking to the Posix and C standards
> folks about a change which may break existing code in subtle ways.

Well, that's fair, although since I see the status quo as a
straight-up bug in C and POSIX, I don't see any particular need for
you to bother.  We can go ahead and fix the bug and they can catch up
later.

> But I'm curious about replacing the implementation-defined 'long' which
> an equally implementation-defined nsec_t: what would be the incentive
> for C implementers to choose a definition for nsec_t other than
> 'typedef long nsec_t;'?

Well, for one thing, precisely the situation we are discussing! On
platforms with 32-bit 'long', nsec_t could be defined as int32_t when
_TIME_BITS=32 and int64_t when _TIME_BITS=64, and then there would be
no need to worry about padding in the =64 case

A related problem happens in "x32" configurations, where long is 64
bits wide but pointers are 32 bits wide; the kernel wants to reuse as
much of the ILP32 userspace interface as possible for IP32L64, and
trips over tv_nsec, which the ILP32 kernel side treats as 32 bits
wide, but userspace is expecting 64 bits.  If you look at the glibc
definition of struct timespec for x86-64, I believe you will discover
that it's _not_ a bare long, it's actually something like
__syscall_slong_t, for this reason.

zw