Re: Fifth draft of the Y2038 design document

[Albert ARIBAUD <albert dot aribaud at 3adev dot fr>]

Hi Zack,

On Wed, 22 Feb 2017 14:49:01 -0500, Zack Weinberg <zackw@panix.com>
wrote :

> 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.

So that would not b an implementation-defined type (which would not be
affected by GLIBC-related defines), that would be a variably- and
GLIBC-defined symbol. Not that I mind (that's what I'm aiming at with
'time_t'), it's just that the Posix and C standards could not really
be involved.

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).

> > 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

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).

As long as we run a kernel and user code which have the same time bit
size, we (can manage to) have no problem; and in heterogeneous
situations, paddings will happen in many other places, so it's not like
it's going to be a show-stopper (but granted, that would be a pain).

> 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.

Ugh. :)

> zw

Cordialement,
Albert ARIBAUD
3ADEV