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