[Moved to DR at the November, 2014 meeting.]

Proposed resolution (February, 2014):

1. Change 7.3.9 [conv.integral] paragraph 3 as follows:

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.

2. Change 7.6.1.6 [expr.post.incr] paragraph 1 as follows:

...The result is a prvalue. The type of the result is the cv-unqualified version of the type of the operand. If the operand is a bit-field that cannot represent the incremented value, the resulting value of the bit-field is implementation-defined. See also 7.6.6 [expr.add] and 7.6.19 [expr.ass].

3. Change 7.6.19 [expr.ass] paragraph 6 as follows:

When the left operand of an assignment operator denotes a reference to T, the operation assigns to the object of type T denoted by the reference is a bit-field that cannot represent the value of the expression, the resulting value of the bit-field is implementation-defined..

4. Change the final bullet of 9.4 [dcl.init] paragraph 17 as follows:

The semantics of initializers are as follows...

• ...

• ...no user-defined conversions are considered. If the conversion cannot be done, the initialization is ill-formed. When initializing a bit-field with a value that it cannot represent, the resulting value of the bit-field is implementation-defined. [Note: An expression of type...

7.3.9 [conv.integral] paragraph 3 says, regarding integral conversions,

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.

The values that can be represented in a bit-field are not well specified, except for the correspondence with the values of an enumeration in 9.7.1 [dcl.enum]. In particular, it is not clear whether a bit-field has a sign bit and whether bit-fields may have padding bits.

Another point to note in this wording: paragraph 1 describes the context as

A prvalue of an integer type can be converted to a prvalue of another integer type.

However, prvalues cannot be bit-fields, so the applicability of the mention of “bit-field width” in paragraph 3 is unclear.