This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: How to use _Generic with bit-fields
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Wink Saville <wink at saville dot com>
- Cc: Martin Sebor <msebor at gmail dot com>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Wed, 24 Feb 2016 23:38:59 +0000
- Subject: Re: How to use _Generic with bit-fields
- Authentication-results: sourceware.org; auth=none
- References: <CAKk8iso7KLotY1WGwaO8FBvp27nFORAWdShqVGth=0Hrc+WVbQ at mail dot gmail dot com> <56C78A87 dot 4090601 at gmail dot com> <CAKk8isoF4gT_z9sscYmnetMZOCkaZUO0Gr9_sj7WQB86PEQxZg at mail dot gmail dot com> <56CBA6CC dot 8080709 at gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1602230041500 dot 26576 at digraph dot polyomino dot org dot uk> <56CE03F4 dot 4040108 at gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1602242103550 dot 23205 at digraph dot polyomino dot org dot uk> <CAKk8isri9vRzNGWUmWPqiFYnMpk_nPYMKoTJAa6BfKmYCFwggg at mail dot gmail dot com>
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). (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).
--
Joseph S. Myers
joseph@codesourcery.com