JTC1/SC22/WG14
N765
SC22/WG14 N765 J11/97/129
Issues with representation of values
Clive D.W. Feather
clive@demon.net
1997-09-22
Abstract
--------
In preparing draft 11 a number of major changes were made to the text
concerning the representation of values. Now that these have been merged
into the text, some tidying up is worthwhile.
Part A suggests improved wording in 6.1.2.8.1, restricting the use of
"padding bits" to integer types. Part B cleans up the use of "precision"
to make it easier to use elsewhere.
Part C is possibily more contentious. On all systems except those with
indefinitely extensible arithmetic, there is a largest integral type.
Furthermore, such an indefinitely extensible type would not fit in well
with the rest of C, because it has no maximum value and so could not
have the correct semantics for converting negative values to the unsigned
form (e.g. "(uintmax_t) (-1)"). Therefore it is proposed that such types
be declared not to be "integer types", and therefore [u]intmax_t must
exist.
Detailed proposals
------------------
Part A
------
Change the last paragraph of subclause 6.1.2.8.1:
Where an operator is applied to a value whose object representation
includes padding bits but which is not a trap representation, the
operator shall ignore those bits for the purpose of determining the
value of the result. If the result is stored in an object that has
padding bits, it is unspecified how those padding bits are generated -
they might not be related to the padding bits of the operands - but
a trap representation shall not be generated.
to:
Where an operator is applied to a value which has more than one object
representation, which object representation is used shall not affect
the value of the result. Where a value is stored in an object that has
more than one object representation for that value, it is unspecified
which representation is used, but a trap representation shall not be
generated.
Add to the end of footnote 41 (the first footnote in 6.1.2.8.2):
All other combinations of padding bits are alternative object
representations of the value specified by the value bits.
Part B
------
In 6.1.2.5, delete the following words from paragraph 19:
The representation of integral types shall define values by use of
a pure binary numeration system. The /precision/ of an integral type
is the number of bits it uses to represent values excluding any sign
and padding bits. The representations of real floating types are
unspecified.
[This text shouldn't have been there anyway.]
In 6.1.2.8.2, delete the following words from paragraph 1:
The /precision/ of an integer type is the number of bits it uses to
represent values excluding any sign and padding bits.
Replace paragraph 4:
Bit field types shall have no padding bits; an N-bit bitfield shall
have N value bits if treated as unsigned, and N-1 value bits plus a
sign bit if treated as signed.
with:
The /precision/ of an integer type is the number of bits it uses to
represent values, excluding any sign and padding bits. The /width/
of an integer type is the same but including any sign bit; thus for
unsigned types the two values are the same, while for signed types the
width is one greater than the precision.
Part C
------
In subclause 6.8.1 paragraph 4, replace the text:
The resulting tokens compose the controlling constant expression, which
is evaluated according to the rules of 6.4, except that all signed
integer types and all unsigned integer types act as if they have the
same representation as, respectively, a single signed integer type and
its corresponding unsigned integer type. If the <inttypes.h> header
defines /intmax_t/ and /uintmax_t/, the single signed integer type and
corresponding unsigned integer type shall be able to represent the
values of, respectively, /intmax_t/ and /uintmax_t/. Otherwise, the
single signed integer type and corresponding unsigned integer type
shall be able to represent the the values of, respectively, /long long
int/ and /unsigned long long int/.
with:
The resulting tokens compose the controlling constant expression, which
is evaluated according to the rules of 6.4, except that all signed
integer types and all unsigned integer types act as if they have the
same representation as, respectively, the types /intmax_t/ and
/uintmax_t/ defined in the header <inttypes.h>.
In the rewritten <inttypes.h>, require [u]intmax_t to exist.
==== ENDS ====