This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v9] y2038: Introduce the __ASSUME_TIME64_SYSCALLS define
- From: Florian Weimer <fweimer at redhat dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: Zack Weinberg <zackw at panix dot com>, Joseph Myers <joseph at codesourcery dot com>, Alistair Francis <alistair dot francis at wdc dot com>, GNU C Library <libc-alpha at sourceware dot org>, Lukasz Majewski <lukma at denx dot de>, Alistair Francis <alistair23 at gmail dot com>
- Date: Wed, 04 Sep 2019 16:56:45 +0200
- Subject: Re: [PATCH v9] y2038: Introduce the __ASSUME_TIME64_SYSCALLS define
- References: <20190827173015.24370-1-alistair.francis@wdc.com> <CAKCAbMiYinyQ_Gdcu94rPCm6PNw6hdq+H_dhzeADa89v2z13-A@mail.gmail.com> <alpine.DEB.2.21.1908271926030.31674@digraph.polyomino.org.uk> <20190830133818.GI9017@brightrain.aerifal.cx> <alpine.DEB.2.21.1908301630420.5568@digraph.polyomino.org.uk> <CAKCAbMjHbcM=8MvLd2CXA=EyT_iDanzsATMLuiMC=wtgTqOr+A@mail.gmail.com> <20190830170940.GL9017@brightrain.aerifal.cx> <CAKCAbMjVG9=wPr-U-Hac3R0j_1Ks8ueRe+sBabjROfNnXSQ8JA@mail.gmail.com> <20190830182650.GM9017@brightrain.aerifal.cx> <871rwwp7dm.fsf@oldenburg2.str.redhat.com> <20190904125015.GB9017@brightrain.aerifal.cx>
* Rich Felker:
>> If we give the padding a name, this will not work on big-endian targets
>>
>> ts?(struct timespec[]){ts->tv_sec, ts->tv_nsec}:0
>>
>> because the padding is in the middle, and ts->tv_nsec is copied into the
>> padding.
>
> While it may be desirable for compatibility with wrong code for this
> sort of initializer to work, there is no specification on the order or
> lack of other named members in timespec. Correct initialization has to
> use designated initializers. I tried to sidestep the problem by using
> *ts, but indeed I botched that; it would not zero the padding.
Wrong initializers are fairly common, unfortunately:
<https://codesearch.debian.net/search?q=struct+timespec.*+%3D+%5C%7B%5Cs*%5B%5E+.0%5D&literal=0&perpkg=1>
>> If we do not give the padding a name, the expression leaves the padding
>> uninitialized (C11: “Unnamed members of structure objects have
>> indeterminate value even after initialization.”).
>>
>> And who should do this? I think for pselect, glibc has to do it, but
>> what about ioctls and socket options?
>
> These need translation logic anyway or post-time64 software won't run
> on pre-time64 kernels. See
>
> https://git.musl-libc.org/cgit/musl/commit/?id=51fd67fcbfa598e2fe1885b517451b84c0bfe3b7
>
> So it's not a big deal to also zero the padding if needed.
That's not in the patch, right?
Is the set of emulations required fixed? In the sense that there will
be no new kernel features which are 32-bit only?
Only in that case, I think userspace emulation is feasible. Getting
full coverage for ioctls will still be difficult, I think.
I wonder if we should define a proper type (with long long int members)
for applications to use with ioctls. That would enable concise syntax
and documenting intent.
Or we could work with WG14 and POSIX and introduce a snseconds_t type,
formally blessing what x32 and the kernel already do. If we can get
this changed, I'm not sure if supporting older C and POSIX standards
(which mandate long) is worth the cost.
> Ideally though the kernel should handle this right, especially for new
> ioctls/sockopts added post-time64 where there's no need for fallback
> translation.
Let's hope so.
Thanks,
Florian