Re: [PATCH v9] y2038: Introduce the __ASSUME_TIME64_SYSCALLS define

[Rich Felker <dalias at libc dot org>]

On Fri, Aug 30, 2019 at 02:59:05PM -0400, Zack Weinberg wrote:
> On Fri, Aug 30, 2019 at 2:26 PM Rich Felker <dalias@libc.org> wrote:
> > > I think ignoring the padding bits has to be the kernel's
> > > responsibility, because the C library can't assume that these pointers
> > > refer to writable storage, nor can it assume that it is safe (or
> > > acceptably efficient) to copy the data structure.
> >
> > You don't patch them up. You copy them. E.g. instead of passing ts,
> > pass ts?(struct timespec[]){*ts}:0.
> 
> We can't assume we can do that: the structure might be too large, or
> its address might be significant.  In fact, I distinctly remember we
> tried that for some other kernel/user ABI mismatch a couple years ago
> and it broke stuff and we had to back it out.

timespecs passed to the kernel do not appear in any large (or even
largeish) structures except timex, which is very special-purpose and
modified by the syscall anyway. So this is not an issue.

The other case was msghdr and cmsghdr for sockets which is much more
of a problem, especially when they occur in arrays for the Linux
"mmsg" extensions.

> > > (Do we still have to pretend that using bare 'long' for the type of
> > > tv_nsec isn't a defect in the relevant standards?)
> >
> > It's not a defect. There's no reason for a special typedef for this
> > field because long can necessarily represent the range of nanoseconds,
> > [0,999999999].
> 
> It's a defect! It's literally the only thing stopping us from making
> the user space definition of struct timespec agree with the kernel
> definition, which would make this entire problem vanish! Why am I the
> only person who sees this! I feel like I'm taking crazy pills!
> </mugatu>

A defect in the kernel, not the standard. And one that's been fixed,
but the fix seems to have been too late to depend on it. :( And it was
too late for x32 anyway.

Rich