Movatterモバイル変換

This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 119a. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.

2025-12-20

739. Signedness of plain bit-fields

[Moved to DR at the October, 2012 meeting.]

11.4.10 [class.bit] paragraph 3 says,

It is implementation-defined whether a plain (neither explicitlysigned nor unsigned)char,short,int orlong bit-field is signed or unsigned.

The implications of this permission for an implementation thatchooses to treat plain bit-fields as unsigned are not clear. Doesthis mean that the type of such a bit-field is adjusted to theunsigned variant or simply that sign-extension is not performed whenthe value is fetched? C99 is explicit in specifying the former (6.7.2paragraph 5: “for bit-fields, it is implementation-definedwhether the specifierint designates the same type assigned int or the same type asunsignedint”), while C90 takes the latter approach (6.5.2.1:“Whether the high-order bit position of a (possibly qualified)'plain' int bit-field is treated as a sign bit isimplementation-defined”).

Additional note, May, 2009:

As an example of the implications of this question, consider thefollowing declaration:

    struct S {      int i: 2;      signed int si: 2;      unsigned int ui: 2;    } s;

Is it implementation-defined which expression,cond?s.i:s.si orcond?s.i:s.ui, is an lvalue (thelvalueness of the result depends on the second and third operandshaving the same type, per 7.6.16 [expr.cond] paragraph 4)?

Proposed resolution (August, 2011):

Change 11.4.10 [class.bit] paragraph 3 as follows:

A bit-field shall not be a static member. A bit-field shall haveintegral or enumeration type (6.9.2 [basic.fundamental]).It isimplementation-defined whether a plain (neither explicitly signed norunsigned)char,short,int,long,orlong long bit-field is signed or unsigned.For a bit-field with a non-dependent type (13.8.3.2 [temp.dep.type])that is specified to be plain (neither explicitly signed nor unsigned)short,int,long, orlong long or atypename-name that is so defined (possibly through multiplelevels oftypedefs), it is implementation-defined whether thetype of the bit-field is the corresponding signed or unsignedtype. [Example:

  struct B {    long x : 3;    typedef signed int si;    si y : 1;    typedef int i;    i z : 1;  };  template<class T>  struct A {    T x : 7;  };

It is implementation-defined whetherB::x has typesigned long orunsigned long.B::y hastypesigned int. It is implementation-defined whetherB::z has typesigned int orunsigned int.A<int>::x andA<signed int>::x designatethe same entity of typesigned int.A<unsignedint>::x has typeunsigned int. —endexample]

Abool value...

This resolution also resolvesissue 675.

Note, January, 2012:

Additional questions have been raised about the proposed resolution,so the status was returned to "review" to allow further discussion.

Proposed resolution (February, 2012):

1. Change 11.4.10 [class.bit] paragraph 3 as follows:

A bit-field shall not be a static member. A bit-field shall haveintegral or enumeration type (6.9.2 [basic.fundamental]).It isimplementation-defined whether a plain (neither explicitly signed norunsigned)char,short,int,long,orlong long bit-field is signed or unsigned. Abool value can successfully be stored...

2. Add the following as a new section in C.7.7 [diff.class]:

11.4.10 [class.bit]

Change: Bit-fields of type plainint are signed.

Rationale: Leaving the choice of signedness to implementationscould lead to inconsistent definitions of template specializations. Forconsistency, the implementation freedom was eliminated for non-dependenttypes, too.

Effect on original feature: The choice is implementation-definedin C, but not so in C++.

Difficulty of converting: Syntactic transformation.

How widely used: Seldom.

This resolution also resolvesissue 675.