On Thu, Feb 23, 2017 at 6:31 PM, Joseph Myers joseph@codesourcery.com wrote:
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.
Sorry, my mistake, I used "long : 32", which causes "warning: type of bit-field '<anonymous>' is a GCC extension [-Wpedantic]". With 'int' it works fine.
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.
Ok, that explains what I was thinking.
Arnd