Defect Report #171

Submission Date: 16 Oct 95
Submittor: BSI
Source: Clive D.W. Feather
Question
Submitted to BSI by Clive D.W. Feather clive@sco.com .
In this Defect Report, identifiers lexically identical to those declared in standard headers refer to the identifiers declared in those standard headers, whether or not the header is explicitly mentioned.
This Defect Report has been prepared with considerable help from Mark Brader, Jutta Degener, Ronald Guilmette, and a person whose employment conditions require anonymity. However, except where stated, opinions expressed or implied should not be assumed to be those of any person other than myself.
Defect Report UK 019: Ranges of integral types
It appears to be possible to create implementations with unreasonable arrangements of integral types.
Subclause 6.1.2.5 states various rules which allow the following deductions to be made:
SCHAR_MAX = SHRT_MAX
SHRT_MAX = INT_MAX
INT_MAX = LONG_MAX
SCHAR_MIN = SHRT_MIN
SHRT_MIN = INT_MIN
INT_MIN = LONG_MIN
SCHAR_MAX = UCHAR_MAX
SHRT_MAX = USHRT_MAX
INT_MAX = UINT_MAX
LONG_MAX = ULONG_MAX
and, depending on the interpretation of the term the same amount of storage:
sizeof (unsigned short) == sizeof (short)
sizeof (unsigned int) == sizeof (int)
sizeof (unsigned long) == sizeof (long)
However, (based on the preliminary discussions of Defect Report #069, which allow padding bits in integral types) there does not appear to be any requirement for the following:
UCHAR_MAX = USHRT_MAX
USHRT_MAX = UINT_MAX
UINT_MAX = ULONG_MAX
sizeof (short) = sizeof (int)
sizeof (int) = sizeof (long)
UCHAR_MAX = INT_MAX
The first five of these are necessary to allow reasonable deductions to be made about the behavior of types in the presence of padding bits (for example, that unsigned long can hold any value representable in any integral type). The sixth is necessary to allow the <ctype.h> functions to behave sensibly (it is also assumed by example 2 of subclause 5.1.2.3).
Suggested Technical Corrigendum
In subclause 6.1.2.5, change in the fourth paragraph:
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
. to:
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, and the size of an object of each type is not greater than the size of an object of the next type in the list.
Add to the fifth paragraph:
The range of values of each unsigned integer type is a subrange of the next type (in the list unsigned char, unsigned short, unsigned int, unsigned long).
Add to the fifth or eighth paragraph:
The range of values of the type unsigned char is a subrange of the values of the type int.
Response
This is a work in progress item.
Summary: Explicit statements are not made about ranges for all types. It can be argued that you can derive this information from the C Standard.
Does the Commitee want to make explicit statements about all relationships, specifically the unsigned types?
Previous Defect Report < - > Next Defect Report