The wording presented here also resolved the following core issues:
There are further cleanups in the area of integer types beyond requiring two's complement notation, not all of which Jean François Bastien may agree with. In particular, turning "Plain ints have the natural size suggested by the architecture of the execution environment" into a note in this paper appears contentious.
The semantics of bitwise operators are reformulated based on the base-2 representation of the operand values.
Bit-fields now consistently use the term "width" (instead of "length").
Change in [conv.integral] paragraphs 2-4:
Objects declared as characters (char) shall be large enough to store any member of the implementation's basic character set. If a character from this set is stored in a character object, the integral value of that character object is equal to the value of the single character literal form of that character. It is implementation-defined whether a char object can hold negative values. Characters can be explicitly declared unsigned or signed. Plain char, signed char, and unsigned char are three distinct types, collectively called narrow character types. A char, a signed char, and an unsigned char occupy the same amount of storage and have the same alignment requirements (6.6.5); that is, they have the same object representation. For narrow character types, all bits of the object representation participate in the value representation. [Note: A bit-field of narrow character type whose length is larger than the number of bits in the object representation of that type has padding bits; see 6.7. -- end note] For unsigned narrow character types, each possible bit pattern of the value representation represents a distinct number. These requirements do not hold for other types. In any particular implementation, a plain char object can take on either the same values as a signed char or an unsigned char; which one is implementation-defined. For each value i of type unsigned char in the range 0 to 255 inclusive, there exists a value j of type char such that the result of an integral conversion (7.3.8 [conv.integral]) from i to char is j, and the result of an integral conversion from j to
unsigned charis i.
There are five standard signed integer types: "signed char", "short int", "int", "long int", and "long long int". In this list, each type provides at least as much storage as those preceding it in the list. There may also be implementation-defined extended signed integer types. The standard and extended signed integer types are collectively called signed integer types. Plain
ints have the natural size suggested by the architecture of the execution environment
[ Footnote:; the other signed integer types are provided to meet special needs.
intmust also be large enough to contain any value in the range [INT_MIN, INT_MAX], as defined in the header <climits>. ]
For each of the standard signed integer types, there exists a corresponding (but different) standard unsigned integer type: "unsigned char", "unsigned short int", "unsigned int", "unsigned long int", and "unsigned long long int"
, each of which occupies the same amount of storage andhas the same
as the corresponding signed integer type
- alignment requirements (6.6.5 [basic.align])
type minimum range exponent N
64 [ Footnote: See 220.127.116.11 [dcl.type.simple] regarding the correspondence between types and the sequences of type-specifiers that designate them.]; that is, each signed integer type has the same object representation as its corresponding unsigned integer type. Likewise, for each of the extended signed integer types there exists a corresponding extended unsigned integer type with the same amount of storage and alignment requirements. The standard and extended unsigned integer types are collectively called unsigned integer types.
The range of non-negative values of a signed integer type is a subrange of the corresponding unsigned integer type, the representation of the same value in each of the two types is the same, and the value representation of each corresponding signed/unsigned type shall be the same.
The standard signed integer types and standard unsigned integer types are collectively called the standard integer types, and the extended signed integer types and extended unsigned integer types are collectively called the extended integer types.
The signed and unsigned integer types shall satisfy the constraints given in the C standard, subclause 18.104.22.168.1.
Unsigned integers shall obey the laws of arithmetic modulo 2n where n is the number of bits in the value representation of that particular size of integer. [ Footnote: This implies that unsigned arithmetic does not overflow because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting unsigned integer type. ]
wchar_tis a distinct type
whose valuescan represent distinct codes for all members of the largest extended character set specified among the supported locales (26.3.1 [locale]). TypeTypes
wchar_tshall have the same size, signedness, and alignment requirements (6.6.5 [basic.align]) as one of the other integral types, called its underlying type.
char32_tdenote distinct types
with the same size, signedness, and alignment as
uint_least32_t, respectively, in <cstdint>
, called the underlying types.
Values of type
boolare either true or false. [ Footnote: Using a bool value in ways described by this document as "undefined", such as by examining the value of an uninitialized automatic object, might cause it to behave as if it is neither true nor false. ] [Note: There are no signed, unsigned, short, or long bool types or values. -- end note] Values of type
boolparticipate in integral promotions (7.3.6 [conv.prom]).
wchar_t, and the signed and unsigned integer types are collectively called integral types.
[ Footnote: Therefore, enumerations (9.6 [dcl.enum]) are not integral; however, enumerations can be promoted to integral types as specified in 7.3.6 [conv.prom]. ]A synonym for integral type is integer type. The representations of integral types shall define values by use of a pure binary numeration system.[ Footnote: A positional representation for integers that uses the binary digits 0 and 1, in which the values represented by successive bits are additive, begin with 1, and are multiplied by successive integral power of 2, except perhaps for the bit with the highest position. (Adapted from the American National Dictionary for Information Processing Systems.) ] [Example: This document permits two's complement, ones' complement and signed magnitude representations for integral types. -- end example]
Change in 22.214.171.124 [expr.static.cast] paragraph 9:
If the destination type is unsigned, the resulting value is the least unsigned integer congruent to the source integer (modulo 2n where n is the number of bits used to represent the unsigned type). [Note: In a two's complement representation, this conversion is conceptual and there is no change in the bit pattern (if there is no truncation). -- end note]
If the destination type is signed, the value is unchanged if it can be represented in the destination type; otherwise, the value is implementation-defined.
If the destination type is
bool, see 7.3.14 [conv.bool]. If the source type is
bool, the value false is converted to zero and the value true is converted to one.
A value of a scoped enumeration type (9.6) can be explicitly converted to an integral typeChange in 7.6.7 [expr.shift] paragraphs 1-4:
. When that type is cv bool, the resulting value is false if the original value is zero and true for all other values. For the remaining integral types, the value is unchanged if the original value can be represented by the specified type. Otherwise, the resulting value is unspecified. A value of a scoped enumeration type can also be explicitly converted to a floating-point type; the result is the same as that of converting from the original value to the floating-point type.
The shift operators << and >> group left-to-right.Change in 7.6.11 [expr.bit.and]:shift-expression: additive-expression shift-expression << additive-expression shift-expression >> additive-expressionThe operands shall be of integral or unscoped enumeration type and integral promotions are performed. The type of the result is that of the promoted left operand. The behavior is undefined if the right operand is negative, or greater than or equal to the length in bits of the promoted left operand.
The value of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are zero-filled.
If E1 has an unsigned type, the value of the result is E1 x 2E2, reduced modulo one more than the maximum value representable in the result type. Otherwise, if E1 has a signed type and non-negative value, and E1 x 2E2 is representable in the corresponding unsigned type of the result type, then that value, converted to the result type, is the resulting value; otherwise, the behavior is undefined.
The value of E1 >> E2 is E1 right-shifted E2 bit positions.
If E1 has an unsigned type or if E1 has a signed type and a non-negative value, the value of the result is the integral part of the quotient of E1/2E2. If E1 has a signed type and a negative value, the resulting value is implementation-defined.
The expression E1 is sequenced before the expression E2.
Change in 7.6.12 [expr.bit.xor]:and-expression: equality-expression and-expression & equality-expressionThe usual arithmetic conversions (7.4 [expr.arith.conv]) are performed
; theresult is the bitwise AND function of the operands. The operator applies only to integral or unscoped enumeration operands.
Change in 7.6.13 [expr.or]:exclusive-or-expression: and-expression exclusive-or-expression ^ and-expressionThe usual arithmetic conversions (7.4 [expr.arith.conv]) are performed
; theresult is the bitwise exclusive OR function of the operands. The operator applies only to integral or unscoped enumeration operands.
Change in 9.6 [dcl.enum] paragraph 8:inclusive-or-expression: exclusive-or-expression inclusive-or-expression | exclusive-or-expressionThe usual arithmetic conversions (7.4 [expr.arith.conv]) are performed
; theresult is the bitwise inclusive OR function of its operands. The operator applies only to integral or unscoped enumeration operands.
For an enumeration whose underlying type is fixed, the values of the enumeration are the values of the underlying type. Otherwise, for an enumeration where emin is the smallest enumerator and emax is the largest, the values of the enumeration are the values in the range bmin to bmax, defined as follows:Change in 10.3.10 [class.bit] paragraph 1-4:
Let K be 1 for a two's complement representation and 0 for a ones' complement or sign-magnitude representation.bmax is the smallest value greater than or equal to max(|emin | - K, |emax |) and equal to 2M - 1, where M is a non-negative integer. bmin is zero if emin is non-negative and -(bmax + K) otherwise. The sizeof the smallest bit-field large enough to hold all the values of the enumeration type is max(M, 1) if bmin is zero and M + 1 otherwise. It is possible to define an enumeration that has values not defined by any of its enumerators. If the enumerator-list is empty, the values of the enumeration are as if the enumeration had a single enumerator with value 0. [ Footnote: ... ]
A member-declarator of the formChange in 126.96.36.199 [meta.unary.prop] paragraph 9:identifieropt attribute-specifier-seqopt : constant-expression brace-or-equal-initializeroptspecifies a bit-field
; its length is set off from the bit-field name by a colon. The optional attribute-specifier-seq appertains to the entity being declared. Thebit-field attribute is not part of the type of the class member. The constant-expression shall be an integral constant expression with a value greater than or equal to zero. The value of the integral constant expression may be larger than the number of bits in the object representation (6.7 [basic.types]) of the bit-field's type; in such casesthe extra bits are padding bits (6.7 [basic.types]). Allocation of bit-fields within a class object is implementation-defined. Alignment of bit-fields is implementation-defined. Bit-fields are packed into some addressable allocation unit. [Note: Bit-fields straddle allocation units on some machines and not on others. Bit-fields are assigned right-to-left on some machines, left-to-right on others. -- end note]
A declaration for a bit-field that omits the identifier declares an unnamed bit-field. Unnamed bit-fields are not members and cannot be initialized. An unnamed bit-field shall not be declared with a cv-qualified type. [Note: An unnamed bit-field is useful for padding to conform to externally-imposed layouts. -- end note] As a special case, an unnamed bit-field with a width of zero specifies alignment of the next bit-field at an allocation unit boundary. Only when declaring an unnamed bit-field may the
value of the constant-expressionbe equal tozero.
A bit-field shall not be a static member. A bit-field shall have integral or enumeration type (6.7.1). AThe address-of operator & shall not be applied to a bit-field, so there are no pointers to bit-fields. A non-const reference shall not be bound to a bit-field (9.3.3). [Note: If the initializer for a reference of type const T& is an lvalue that refers to a bit-field, the reference is bound to a temporary initialized to hold the value of the bit-field; the reference is not bound to the bit-field directly. See 9.3.3. -- end note]
boolvalue can successfully be stored in a bit-field of any nonzero size.
If the value
falseis stored into a bit-field of type
boolof any size (including a one bit bit-field), the original
boolvalue and the value of the bit-field
shallcompare equal. If the value of an enumerator is stored into a bit-field of the same enumeration type and the number of bits in the bit-fieldis large enough to hold all the values of that enumeration type (9.6 [dcl.enum]), the original enumerator value and the value of the bit-field shallcompare equal. [Example: ...]
... The set of scalar types for which this condition holds is implementation-defined. [Note: If a type has padding bits, the condition does not hold; otherwise, the condition holds true forChange in 19.16.3 [ratio.ratio] paragraph 1:
unsignedintegral types. -- end note]
If the template argument D is zero or the absolute values of either of the template arguments N and D is no representable by typeChange in 29.7.2 [atomics.types.int] paragraph 7:
intmax_t, the program is ill-formed. [Note: These rules ensure that infinite ratios are avoided and that for any negative input, there exists a representable value of its absolute value which is positive.
In a two's complement representation, thisexcludes the most negative value. -- end note]
Remarks: For signed integer types,Change in 29.7.2 [atomics.types.int] paragraph 8:
arithmetic is defined to use two's complement representation.There are no undefined results
T operator op=(T operand) volatile noexcept; T operator op=(T operand) noexcept;Effects: Equivalent to:
fetch_key (operand) op operand;static_cast<T>(static_cast<make_unsigned_t<T>>(fetch_key(operand)) op static_cast<make_unsigned_t<T>>(operand));