This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v8 1/3] y2038: Introduce internal for glibc struct __timespec64
- From: Florian Weimer <fw at deneb dot enyo dot de>
- To: Lukasz Majewski <lukma at denx dot de>
- Cc: Joseph Myers <joseph at codesourcery dot com>, Alistair Francis <alistair23 at gmail dot com>, Alistair Francis <alistair dot francis at wdc dot com>, Zack Weinberg <zackw at panix dot com>, Arnd Bergmann <arnd at arndb dot de>, GNU C Library <libc-alpha at sourceware dot org>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, Florian Weimer <fweimer at redhat dot com>, Carlos O'Donell <carlos at redhat dot com>, Stepan Golosunov <stepan at golosunov dot pp dot ru>
- Date: Wed, 25 Sep 2019 15:40:30 +0200
- Subject: Re: [PATCH v8 1/3] y2038: Introduce internal for glibc struct __timespec64
- References: <20190918211603.8444-1-lukma@denx.de> <20190918211603.8444-2-lukma@denx.de> <alpine.DEB.2.21.1909192014250.11875@digraph.polyomino.org.uk> <20190923232109.735f898b@jawa> <alpine.DEB.2.21.1909250035540.14213@digraph.polyomino.org.uk> <20190925094540.14be491d@jawa> <877e5wtu7y.fsf@mid.deneb.enyo.de> <20190925153402.060a686c@jawa>
* Lukasz Majewski:
>> Regarding the actual patch, I don't understand why tv_pad isn't an
>> *anonymous* bit field.
>
> The reason for this is that we may need to clear this padding if we
> plan to fix some issues - for example in kernel 5.1.0 - 5.1.4 there is
> a bug for x32 which may require explicit clearing the padding.
I think we cannot support those kernels with reasonable effort. So
cross-architecture source compatibility with existing practices is
more important.
Furthermore, I think the consensus for the public struct timespec64 is
that it should use an unnamed bitfield because of the prevalence of
incorrect (according to POSIX) initializers.
>> This seems to introduce unnecessary variance
>> between architectures and is incompatible with how glibc itself uses
>> struct timespec.
>
> The v3 of this patch had this field defined as anonymous padding.
> However, there was strong objection for such approach [1].
> Links:
> [1] - https://sourceware.org/ml/libc-alpha/2019-05/msg00151.html
The patch has a named bitfield:
+ int tv_pad: 32; /* Padding named for checking/setting */
As far as I can see, the discussion was about what was actually in the
patch, and not an unnamed bitfield.