Re: Fifth draft of the Y2038 design document

[Joseph Myers <joseph at codesourcery dot com>]

On Thu, 23 Feb 2017, Arnd Bergmann wrote:

> > You could declare the padding as an unnamed bit-field "int : 32;" to avoid
> > it affecting initialization.  But that complicated zeroing it (in cases
> > where you're zeroing the original struct - when it's a read/write
> > parameter passed to the kernel - rather than a copy), as you can no longer
> > refer to it by name to assign zero to it; maybe you'd need to arrange for
> > it to be named inside glibc but unnamed for user code.
> 
> I had thought of that as well, but wasn't sure if we could rely on bitfields
> to do the right thing across C standard versions and non-gcc compilers.
> I experimentally found that gcc-4.9 and higher accept that version without
> a -Wpedantic warning when using --std=c99 or --std=c11, but they warn
> about it with --std=c89 or --std=gnu89. Older gcc versions as far back as
> gcc-3.4 (the oldest I could try) always warn about anonymous bitfields
> with -pedantic, but I could still silence that warning using the
> __extension__ keyword. I think that's good enough.

What's the warning you see, with what exact testcase?  Unnamed bit-fields 
(provided the declared type is int / signed int / unsigned int, not any 
other integer or enum type), and initializers ignoring them, date back at 
least to the third public review draft of C89 (13 May 1988), which is the 
oldest version I have to hand.

(Of course 64-bit time_t on 32-bit systems requires long long, but glibc 
headers already rely on that C99 feature anyway.)

> Pro glibc:
> - IIRC already have code to do this for x32, and could do it the same
>   way on all 32-bit architectures. (I could not find where this is done
>   though, maybe I dreamed it up?)

glibc doesn't have code for it; I think musl does.

-- 
Joseph S. Myers
joseph@codesourcery.com