Re: [PATCH v8 1/3] y2038: Introduce internal for glibc struct __timespec64

[Florian Weimer <fw@deneb.enyo.de>]

* 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.