Re: [PATCH v2] linux: Use 'long int' for timespec tv_nsec on x32 (BZ #16437)

[Rich Felker <dalias@libc.org>]

On Fri, Dec 10, 2021 at 04:44:46PM +0100, Florian Weimer via Libc-alpha wrote:
> * H. J. Lu via Libc-alpha:
> 
> > On Fri, Dec 10, 2021 at 3:03 AM Adhemerval Zanella via Libc-alpha
> > <libc-alpha@sourceware.org> wrote:
> >>
> >> Although the kernel ABI uses 64-bit (so it can re-use the syscall
> >> logic from x86_64), POSIX states the type to be 'long int'.  It
> >> requires to explicit signal extend the value on syscalls that
> >> take the value to avoid requiring bumping the minimum kernel version
> >> (ea2ce8f3514e ("time: Fix get_timespec64() for y2038 safe compat
> >> interfaces") got merged into v4.18, futex and recvmsg followed in v5.1,
> >> but v5.6 is considered 'complete').
> >>
> >> The fix uses 'long long int' array to represent 'struct timespec',
> >> since it allows a simpler code than define a kernel specific timespec.
> >>
> >> There is no need to compat symbol, the now high-bits are not used
> >> to represent the nanoseconds and for some syscalls it only issues
> >> an error (which hardly indicates the need of compat symbol).
> >>
> >> Checked on x86_64-linux-gnu-x32 with kernel 4.4.0 and 5.13.
> >
> > Isn't it an ABI change for x32?
> 
> I agree.  I said so repeatedly.

Can you clarify the sense in which it's an "ABI change"? I don't think
it's a change at all in the "mechanical" ABI linkage between libc and
the libc consumer. Of course it is a change in the types at the high
level language level.

If this were just an enhancement request, I'd be inclined to say just
drop it, but this is a bug fix for a serious conformance problem
that's going to have people writing wacky code to work around x32 (if
anyone even actually cares about x32) and that keeps coming up in
messy ways like the request to change tv_nsec to snseconds_t. From my
perspective there is very high value in getting rid of this exception
to the specification so that stuff doesn't get built around it. On top
of that, to my knowledge there are no binary distros for x32, and very
few users at all (so few that "remove x32" has been proposed multiple
times). I don't think any minor "ABI change" is going to have an
impact on them; glibc has probably made more-breaking changes of this
class before, even.

Rich