On Wed, Feb 24, 2016 at 3:38 PM, Joseph Myers <jos...@codesourcery.com> wrote: > On Wed, 24 Feb 2016, Wink Saville wrote: > >> > (c) nothing defines semantics of conversion of out-of-range values to >> > bit-fields other than treating the width as part of the type (or in the >> > case of _Bool bit-fields, having the special wording to make it explicit >> > that those have the semantics of _Bool not the semantics of an ordinary >> > unsigned integer type with the specified number of bits). >> >> >> I don't see where in the standard it says the width of a bit field is >> part of the type. >> I see In Section 6.7.2.1 paragraphs 9, 10, 11, 12 requires the compiler to >> know >> the width, but I don't see where the width is part of the type. >> >> Could you point me to the appropriate paragraph(s)? > > If you look at the London 2007 minutes > <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1267.pdf> you'll see > that at that time this was intended to be deliberately ambiguous, to > support both C++ practice and the longstanding C intent as expressed in > the responses to various C90 DRs (the difference, at that time, only > mattering for implementation-defined bit-field types). > > The "interpreted as having a signed or unsigned integer type consisting of > the specified number of bits" (paragraph 10), if applied for the purposes > of interpreting other references to types in C11, has consequences > including: (i) conversions to store a value in a bit-field follow the same > rules as conversions to a normal integer type, (ii) a bit-field with width > less than that of int also has integer conversion rank less than that of > int, and so promotes to int under the integer promotions (even if the > declared type is wider than int).
I found this very surprising, but the standard does seem to require this. > (It also has the less intuitive > consequences regarding bit-field types escaping from their bit-field > context, as discussed in the present thread and elsewhere.) > > Without it being part of the type, making long:1 promote to int (as in > C++) not long would require changes to the wording on promotions, and > separate wording would be needed to make the results of assignments clear > (and I'm not convinced that C++ has such wording in all cases where it is > needed). Clang doesn't seem to need to have the width as part of the type. And by not having it as part of the type _Generic works as expected on clang but doesn't work on gcc. Further more things like printing of "big" bit fields such as unsigned long long int b:33 doesn't issue any warnings with -Wall on clang but does on gcc. Also, the shifting weirdness doesn't occur on clang. >From my perspective, as a user, I think these behaviors are gcc bugs. If someone were to supply a patch that changed the behavior to match what clang and apparently other compilers are doing, would you be likely to accept it? -- Wink > -- > Joseph S. Myers > jos...@codesourcery.com
