Re: [avr-libc-dev] [bug #13106] wrong handle of union definitions in bitfields

[Joerg Wunsch]

As Markus Königshaus wrote:

> typedef struct
> {
>   uint8_t b_bit0 : 1;
>   uint8_t b_bit1 : 1;
>   uint8_t b_bit2 : 1;
>   union
>    { 
>     uint8_t b_union0 : 1;
>     uint8_t b_union1 : 1;
>    };
>   uint8_t reserve : 4;
> } _T_bitfield;

> _T_bitfield bitfield;
> bitfield.b_union1 = 1;
> // does not work! Bit number 4 will not be set to 1.
> The asm - code initialise the worng Byteadress.

First of all, if at all, that's a compiler bug, not a library bug.
For that reason, I have to close that bug report here, there's nothing
the avr-libc folks could ever do about that.

Second, what you're writing is not standards-compliant C code.  The
union following b_bit2 inside your _T_bitfield structure does not have
a name, and thus is not accessible within the terms of ISO C.  The
namespace of the b_union0 and b_union1 identifiers is the union
containing these names, but as these union doesn't have a name by
itself, you cannot access it using any of the methods supported by the
standard.  Consequently, if you add -pedantic to your GCC options, GCC
will warn you about it.  Also, if you reduce the language
compatibility option from -std=gnu99 to -std=c99, it will yield a
syntax error.  (Besides, declaring a name starting with an underscore
[_T_bitfield] is nothing of your concern, as these names are reserved
for the compiler and library.  Better avoid that.)

So you're using a GCC extension, and are at the mercy of GCC anyway.
As the standard doesn't make any guarantees about the order of bits
within a bit-field, I think you've got not much chances convincing a
GCC developer they were doing wrong here.

Btw., the actual problem appears to me that the nested union will be
aligned to the next 8-bit boundary, which is not really what you want.
As not even __attribute__((__packed__)) avoid this, you're simply far
enough in implementation-defined land here to be out of luck.  As nice
as bit-fields might appear at a first glance, they are barely usable
in a portable way, alas.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)