*This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD Editorial status.*

**Section:** 6.7.1 [basic.fundamental] **Status:** NAD Editorial
**Submitter:** Travis Vitek **Opened:** 2008-06-30 **Last modified:** 2016-02-10

**Priority: **Not Prioritized

**View all issues with** NAD Editorial status.

**Discussion:**

Neither the term "signed integral type" nor the term "unsigned
integral type" is defined in the core language section of the
standard, therefore the library section should avoid its use. The
terms *signed integer type* and *unsigned integer type* are
indeed defined (in 6.7.1 [basic.fundamental]), thus the usages should be
replaced accordingly.

Note that the key issue here is that "signed" + "integral type" !=
"signed integral type".
The types `bool`

, `char`

, `char16_t`

,
`char32_t`

and `wchar_t`

are all listed as
integral types, but are neither of *signed integer type* or
*unsigned integer type*. According to 6.7 [basic.types] p7, a synonym for
integral type is *integer type*.
Given this, one may choose to assume that an *integral type* that
can represent values less than zero is a *signed integral type*.
Unfortunately this can cause ambiguities.
As an example, if `T`

is `unsigned char`

, the
expression `make_signed<T>::type`

, is supposed to
name a signed integral type. There are potentially two types that
satisfy this requirement, namely `signed char`

and
`char`

(assuming `CHAR_MIN < 0`

).

*[
San Francisco:
]*

Plum, Sebor to review.

*[
Post Summit Daniel adds:
]*

The proposed resolution needs to be "conceptualized". Currently we have in [concept.support] only concept

IntegralTypefor all "integral types", thus indeed the currentContainerconcept and Iterator concepts are sufficiently satisfied with "integral types". If the changes are applied, we might ask core for conceptBilateralIntegerTypeand add proper restrictions to the library concepts.

**Proposed resolution:**

I propose to use the terms "signed integer type" and "unsigned integer type" in place of "signed integral type" and "unsigned integral type" to eliminate such ambiguities.

The proposed change makes it absolutely clear that the difference
between two pointers cannot be `char` or `wchar_t`,
but could be any of the signed integer types.
7.6.6 [expr.add] paragraph 6...

- When two pointers to elements of the same array object are subtracted, the result is the difference of the subscripts of the two array elements. The type of the result is an implementation-defined
~~signed integral type~~signed integer type; this type shall be the same type that is defined as`std::ptrdiff_t`

in the`<cstdint>`

header (18.1)...

The proposed change makes it clear that `X::size_type` and
`X::difference_type` cannot be `char` or
`wchar_t`, but could be one of the signed or unsigned integer
types as appropriate.
15.5.3.5 [allocator.requirements] table 40...

Table 40: Allocator requirements

expression return type assertion/note/pre/post-condition X::size_type~~unsigned integral type~~unsigned integer typea type that can represent the size of the largest object in the allocation model. X::difference_type~~signed integral type~~signed integer typea type that can represent the difference between any two pointers in the allocation model.

The proposed change makes it clear that `make_signed<T>::type`
must be one of the signed integer types as defined in 3.9.1. Ditto for
`make_unsigned<T>type` and unsigned integer types.
19.15.7.3 [meta.trans.sign] table 48...

Table 48: Sign modifications

Template Comments template <class T> struct make_signed;If `T`

names a (possibly cv-qualified)~~signed integral type~~signed integer type (3.9.1) then the member typedef`type`

shall name the type`T`

; otherwise, if`T`

names a (possibly cv-qualified)~~unsigned integral type~~unsigned integer type then`type`

shall name the corresponding~~signed integral type~~signed integer type, with the same cv-qualifiers as`T`

; otherwise,`type`

shall name the~~signed integral type~~signed integer type with the smallest rank (4.13) for which`sizeof(T) == sizeof(type)`

, with the same cv-qualifiers as`T`

.Requires:`T`

shall be a (possibly cv-qualified) integral type or enumeration but not a`bool`

type.template <class T> struct make_unsigned;If `T`

names a (possibly cv-qualified)~~unsigned integral type~~unsigned integer type (3.9.1) then the member typedef`type`

shall name the type`T`

; otherwise, if`T`

names a (possibly cv-qualified)~~signed integral type~~signed integer type then`type`

shall name the corresponding~~unsigned integral type~~unsigned integer type, with the same cv-qualifiers as`T`

; otherwise,`type`

shall name the~~unsigned integral type~~unsigned integer type with the smallest rank (4.13) for which`sizeof(T) == sizeof(type)`

, with the same cv-qualifiers as`T`

.Requires:`T`

shall be a (possibly cv-qualified) integral type or enumeration but not a`bool`

type.

Note: I believe that the basefield values should probably be
prefixed with `ios_base::` as they are in 26.4.2.2.2 [facet.num.put.virtuals]
The listed virtuals are all overloaded on signed and unsigned integer
types, the new wording just maintains consistency.
26.4.2.1.2 [facet.num.get.virtuals] table 78...

Table 78: Integer Conversions

State stdioequivalentbasefield == oct%obasefield == hex%Xbasefield == 0%i~~signed integral type~~signed integer type%d~~unsigned integral type~~unsigned integer type%u

Rationale is same as above. 26.4.2.2.2 [facet.num.put.virtuals] table 80...

Table 80: Integer Conversions

State stdioequivalentbasefield == ios_base::oct%o(basefield == ios_base::hex) && !uppercase%x(basefield == ios_base::hex)%Xbasefield == 0%ifor a ~~signed integral type~~signed integer type%dfor a ~~unsigned integral type~~unsigned integer type%u

21.2 [container.requirements] table 80...

Table 89: Container requirements

expression return type operational semantics assertion/note/pre/post-condition complexity X::difference_type~~signed integral type~~signed integer typeis identical to the difference type of X::iteratorandX::const_iteratorcompile time X::size_type~~unsigned integral type~~unsigned integer typesize_typecan represent any non-negative value ofdifference_typecompile time

99 [iterator.concepts] paragraph 1...

Iterators are a generalization of pointers that allow a C++ program to work with different data structures (containers) in a uniform manner. To be able to construct template algorithms that work correctly and efficiently on different types of data structures, the library formalizes not just the interfaces but also the semantics and complexity assumptions of iterators. All input iterators

`i`

support the expression`*i`

, resulting in a value of some class, enumeration, or built-in type`T`

, called thevalue typeof the iterator. All output iterators support the expression`*i = o`

where`o`

is a value of some type that is in the set of types that arewritableto the particular iterator type of`i`

. All iterators`i`

for which the expression`(*i).m`

is well-defined, support the expression`i->m`

with the same semantics as`(*i).m`

. For every iterator type`X`

for which equality is defined, there is a corresponding~~signed integral type~~signed integer type called thedifference typeof the iterator.

I'm a little unsure of this change. Previously this paragraph would
allow instantiations of `linear_congruential_engine` on
`char`, `wchar_t`, `bool`, and other types. The
new wording prohibits this.
24.7.3.1 [rand.eng.lcong] paragraph 2...

The template parameter

`UIntType`

shall denote an~~unsigned integral type~~unsigned integer type large enough to store values as large as`m - 1`

. If the template parameter`m`

is 0, the modulus`m`

used throughout this section 26.4.3.1 is`numeric_limits<result_type>::max()`

plus 1. [Note: The result need not be representable as a value of type`result_type`

. --end note] Otherwise, the following relations shall hold:`a < m`

and`c < m`

.

Same rationale as the previous change. 99 [rand.adapt.xor] paragraph 6...

Both

`Engine1::result_type`

and`Engine2::result_type`

shall denote (possibly different)~~unsigned integral types~~unsigned integer types. The memberresult_typeshall denote either the typeEngine1::result_typeor the typeEngine2::result_type, whichever provides the most storage according to clause 3.9.1.

24.7.7.1 [rand.util.seedseq] paragraph 7...

Requires:`RandomAccessIterator`

shall meet the requirements of a random access iterator (24.1.5) such that`iterator_traits<RandomAccessIterator>::value_type`

shall denote an~~unsigned integral type~~unsigned integer type capable of accomodating 32-bit quantities.

By making this change, integral types that happen to have a signed representation, but are not signed integer types, would no longer be required to use a two's complement representation. This may go against the original intent, and should be reviewed. 29.7.1 [atomics.types.operations] paragraph 24...

Remark:For~~signed integral types~~signed integer types, arithmetic is defined using two's complement representation. There are no undefined results. For address types, the result may be an undefined address, but the operations otherwise have no undefined behavior.