SC22/WG14 N775    J11/97-139

Relationships between unsigned types
Clive D.W. Feather
clive@demon.net
1997-09-23


Abstract
========

The existing Standard allows perverse relationships between unsigned
types. This proposal attempts to fix it.


Definitions
===========

The terms (taken from N765) /precision/ and /width/ of a type are used
in this paper to mean the number of value bits in that type, ignoring any
padding bits and respectively excluding and including the sign bit.
Thus if the precision of the type is P, the maximum value is 2**P-1.
For unsigned types the two terms are equivalent; for signed types the
width is 1 greater than the precision.


Discussion
==========

The Standard requires that standard signed types each have a range of
values that is a subrange of the next standard type in order, and that
both standard and extended signed types have a range of nonnegative
values that is a subrange of the corresponding unsigned type.

Using "P(T)" to mean the precision of T, this means that the complete
rules are:

    P(signed long long)   >= P(signed long)
    P(signed long)        >= P(signed int)
    P(signed int)         >= P(signed short)
    P(signed short)       >= P(signed char)

    P(unsigned long long) >= P(signed long long)
    P(unsigned long)      >= P(signed long)
    P(unsigned int)       >= P(signed int)
    P(unsigned short)     >= P(signed short)
    P(unsigned char)      >= P(signed char)

    P(signed long long)   >= 63
    P(signed long)        >= 31
    P(signed int)         >= 15
    P(signed short)       >= 15
    P(signed char)        >=  7

    P(unsigned long long) >= 64
    P(unsigned long)      >= 32
    P(unsigned int)       >= 16
    P(unsigned short)     >= 16
    P(unsigned char)      >=  8

However, there is no requirement that (say):

    P(unsigned int)       >= P(unsigned short)

and it is possible to construct an implementation which obeys the above
rules but for which this is not true. It is also the case that extended
integer types might behave in perverse ways. This proposal solves these
issues by adding a requirement that types with higher rank have a larger
range of values.


Proposal
========

In 6.1.2.5, delete the last sentence of paragraph 4:

    In the list of signed integer types above, the range of values of
    each type is a subrange of the values of the next type in the list.

Add a new paragraph between paragraphs 6 and 7:

    For any two types with the same signedness and different integer
    conversion rank, the range of values of the type with smaller integer
    conversion rank is a subrange of the values of the other type.

Add a forward reference to 6.2.1.1.