Re: How to use _Generic with bit-fields

[Wink Saville <wink at saville dot com>]

On Wed, Feb 24, 2016 at 3:38 PM, Joseph Myers <joseph@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
> joseph@codesourcery.com