Issue 0171: Is it possible to create implementations with unreasonable arrangements of integral types?

This issue has been automatically converted from the original issue lists and some formatting may not have been preserved.

Authors: Clive D.W. Feather, BSI
Date: 1995-10-16
Submitted against: C90
Status: Fixed
Fixed in: C99
Cross-references: 0069
Converted from: dr.htm, dr_171.html

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.

Comment from WG14 on 1997-09-23:

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 Committee want to make explicit statements about all relationships, specifically the unsigned types?