ISO/ IEC 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 ====