Hi Arnd,
On Thu, 23 Feb 2017 21:24:22 +0100, Arnd Bergmann arnd@arndb.de wrote :
On Thu, Feb 23, 2017 at 6:31 PM, Joseph Myers joseph@codesourcery.com wrote:
On Thu, 23 Feb 2017, Arnd Bergmann wrote:
[...]
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.
So IIUC (and assuming we keep tv_nsec a long in APIs) we /could/ pad struct timespec with an anonymous bitfield and still be compatible with (most) existing user source code, and it is considered acceptable (but should be duly documented). Added this in rev. 122of the design doc.
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.
So that's one 'pro GLIBC' less, right?
Arnd
Cordialement, Albert ARIBAUD 3ADEV