Bit-field width is a separate attribute from type and is applicable only
to class members [class.bit]/1; by implication it is not applicable to
rvalues.

However, [conv.prom]/3 says:

  "An rvalue for an integral bit-field (9.6) can be converted to an rvalue
  of type int if int can represent all the values of the bit-field;
  otherwise, it can be converted to unsigned int if unsigned int can
  represent all the values of the bit-field.  If the bit-field is larger
  yet, no integral promotion applies to it.  If the bit-field has an
  enumerated type, it is treated as any other value of that type for
  promotion purposes."

This implies that either
(1) the lvalue-to-rvalue conversion carries over the bit-field attribute
    as well as the type of the lvalue, or
(2) the result of an lvalue-to-rvalue conversion can have a different
    type from the source type if the source is a bit-field, as described.
Whichever is the case, I think this should be specified explicitly in
[conv.lval].  In case (2) this paragraph could be deleted; in case (1) it
would need to be re-worded to refer to "a bit-field rvalue".

Also, [conv.integral] says:

  "An rvalue of an integer type can be converted to an rvalue of another
  integer type. An rvalue of an enumeration type can be converted to an
  rvalue of an integer type.
  [...]
  "If the destination type is signed, the value is unchanged if it can be
  represented in the destination type (and bit-field width); otherwise,
  the value is implementation-defined."

But nothing says how the destination bit-field width is determined!
[expr.ass]/3 should specify that the right-hand expression is converted
to the bit-field width of the left-hand expression, where applicable,
not just its type.

I'm not sure whether the application of bit-widths to rvalues has any
effect outside these paragraphs.  Can they be safely ignored?

Ben.

--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
                                                              - Albert Camus

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]