#266 Unnamed bit-field initialization

closed
None
5
2008-11-15
2008-11-15
No

I found a inconsistency between sdcc and gcc regarding unnamed bit-field initialization:

struct {
int a : 2;
char : 2;
int b : 2;
} s = {1, 2, 3};

- in sdcc it means: s.a = 1; s.b = 3;
- in gcc it means: s.a = 1; s.b = 2; and gcc throws a warning:
t.c:6: warning: excess elements in struct initializer
t.c:6: warning: (near initialization for `s')
- msvc behaves in the same way as gcc

I haven't found the explanation in the ISO/IEC 9899:1999 standard how
the compiler should handle unnamed bit-field initialization. Maybe it is implicitly specified somewhere.

I propose to change unnamed bit-field initialization to be gcc compatible.

Borut

Discussion

  • Borut Ražem

    Borut Ražem - 2008-11-15

    Fixed in svn revision #5267.

    Borut

     
  • Borut Ražem

    Borut Ražem - 2008-11-15
    • status: open --> closed
     
  • Raphael Neider

    Raphael Neider - 2008-11-15

    For informational purposes: The GCC-like behaviour seems to be correct. The ISO/IEC 9899:1999 Committee Draft WG14/N1124 states in Section 6.7.8. (Initialization), clause 9:

    "Except where explicitly stated otherwise, for the purposes of this subclause unnamed
    members of objects of structure and union type do not participate in initialization.
    Unnamed members of structure objects have indeterminate value even after initialization."

    Unnamed members must be skipped and do not consume any initializers.

    Similar conclusions can be drawn from the footnote 106 to Section 6.7.2.1 Structure and union specifiers, clause 11:

    "An unnamed bit-field structure member is useful for padding to conform to externally imposed layouts."

    If unnamed fields consumed initializers, this usecase would be unfeasible.

    Thanks for fixing this!

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks