[PATCH v9] y2038: Introduce the __ASSUME_TIME64_SYSCALLS define

Zack Weinberg zackw@panix.com
Fri Aug 30 18:59:00 GMT 2019


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.

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

zw



More information about the Libc-alpha mailing list