ISO/ IEC JTC1/SC22/WG14 N713

                       Document Number:  WG14 N713/J11 97-076

                        C9X Revision Proposal

Title: Allow implementations to use extended integers
Author: Douglas A. Gwyn
Author Affiliation: United States Army Research Laboratory
Postal Address: 6449 Tauler Ct., Columbia, MD 21045-4530, US
E-mail Address:
Telephone Number: +1-301-394-2287
Fax Number: +1-410-278-2934
Sponsor: J11
Date: 1997-06-06
Document History:  There have been many previous Committee
        and e-mail discussions concerning extended integer
        types and their possible use in implementing types
        defined by standard headers.  The consensus seems
        to be that <inttypes.h> and possibly <stddef.h>
        typedef-names could be associated with integer types
        other than the standard types defined in the current
        C standard.
        In rewriting the specification for <inttypes.h>, I
        found it necessary to revisit this issue and devise
        a solution for it, which also resolves similar
        issues for other integer types defined in standard
Proposal Category:
   __ Editorial change/non-normative contribution
   x_ Correction
   __ New feature
   __ Addition to obsolescent feature list
   __ Addition to Future Directions
   __ Other (please specify)
Area of Standard Affected:
   __ Environment
   x_ Language
   __ Preprocessor
   __ Library
      __ Macro/typedef/tag name
      __ Function
      __ Header
   __ Other (please specify)  ______________________________
Prior Art: implementations with extended integer types
Target Audience: C implementers requiring more integer types
Related Documents (if any):
Proposal Attached: x_ Yes __ No, but what's your interest?
Abstract: Currently, the C standard (C89) defines integer
        types in terms of standard keywords in certain
        allowed combinations, and only those combinations.
        The inadequacy of this limitation can be seen in the
        fact that the Committee has approved the addition of
        {long long} (and related combinations) as a new
        integer type for the next C standard (C9x).  However,
        there is no general mechanism for making conforming
        extensions as new needs arise, for example 128-bit
        integers when a 64-bit representation for {long long}
        has already been chosen for compatibility reasons.
        There are also problems choosing a suitable integer
        type for {prtdiff_t} on some architectures, where for
        example the native word size may be 32 bits and an
        object may have a size of more than 2^31 bytes, which
        would require 33 bits to represent the difference of
        two arbitrary byte pointers within the object.
        The new standard header {<inttypes.h>} was largely
        motivated by the desire to support implementation-
        defined extended integer types, but without necessary
        changes in the language section of the standard, it
        does not achieve this goal.  Also, the {ptrdiff_t}
        issue cannot be properly addressed without changes to
        allow implementations to, at least in controlled
        contexts, introduce extended integer types.
        This proposal details the changes that I believe are
        necessary and sufficient to address these issues
        without causing any other problems.

Proposal: The intent is allow implementations to use extended
        integer types in standard headers, without granting
        strictly conforming programs any license to use them
        directly (only through types defined in the standard
        headers).  This is tricky to get right, due to the
        open-ended nature of potential extended types, which
        need to be genuine types for use as function arguments
        and so forth, interoperate with other integer types,
        and have sufficiently well-defined behavior that a
        program runs no risk of becoming not strictly
        conforming merely because it might use these types.
        The nature of these requirements makes it evident that
        the solution must be to incorporate these types into
        the appropriate parts of the C language itself;
        however, if care is not taken, we run the risk of
        allowing a strictly conforming program to contain
        implementation-specific identifiers, which of course
        is not our intent (strict conformance is supposed to
        approximate maximal portability).  The key to
        addressing this latter concern is to limit the names
        for extended integers to those identifiers reserved
        "for any use" by the implementation in 7.1.3, which
        further reserves them only in the context of standard
        headers.  Finally, if these types are explicitly made
        implementation-defined, then a strictly conforming
        program may not use them directly, but only through
        the types defined in standard headers (which we have
        previously agreed need not expand to segments of
        strictly-conforming source code).

        Subsection and page numbers in this proposal refer to
        Draft 8 of the C9x standard; they may need to be
        adjusted to track later drafts.  Text surrounded by
        *asterisks* should be italicized, while text
        surrounded by {braces} should be set in Courier font.

        Change Types, p. 30, para. [3], from:
                There are five *signed integer
                types*, designated as {signed char}, {short
                int}, {int}, {long int}, and {long long int}.
                There are five *standard signed integer
                types*, designated as {signed char}, {short
                int}, {int}, {long int}, and {long long int}.
                There may also be implementation-defined
                *extended signed integer types*.  The
                standard and extended signed integer types
                are collectively called just *signed integer

        Note:  The above change adds extended types to the
        category of "integer types" throughout the standard.
        Because the extended types are implementation-defined,
        strictly conforming programs cannot directly use them.
        Unsigned and general extended integer types fall
        naturally out of subsequent existing wording.

        Change in Usual arithmetic conversions, p. 49;
        immediately after
                Otherwise, the integral promotions are
                performed on both operands.  Then the
                following rules are applied:
        insert the following new first rule:
                        If either operand has an extended
                        integer type, both operands are
                        converted to an implementation-defined
                        common integer type.

        Note:  This allows the common type to differ from both
        operand types, which is compatible with the behavior
        for some combinations of standard integer types.
        Presumably the required implementation definition will
        be "reasonable"; we don't want to try to specify the
        details ourselves.  (Frank Farance and others have
        attempted to devise uniform conversion rules for
        general integer types.  Unfortunately, there are warts
        in the conversion rules for standard types which may
        affect their interactions with extended types.)

        Notice also that there is no need to force extended
        integer types shorter than {int} to undergo change
        under "integral promotions"; the only real use of that
        property is in variable-argument functions, but
        strictly conforming use of (ptrdiff_t} etc. will have
        to explicitly convert such an argument to some known
        standard type anyway and would not be able to rely on
        integral promotion always producing type {int}.

        Change in 6.5.2 Type specifiers, p. 81, Syntax [1];
        add new line:

        Optionally, but recommended, add new Syntax rule:

        Corresponding changes should be made in B.2.2, p.352.

        Change in 6.5.2 Type specifiers, p. 81, Constraints
        [2]; after:
                        -- {unsigned long long} or
                           {unsigned long long int}
        add two new lines:
                        -- an identifier reserved for any use
                           in 7.1.3 that designates an
                           implementation-defined extended
                           signed integer type, or the same
                           identifier preceded by {signed}
                        -- the same identifier preceded by

        Change in 6.5.2 Type specifiers, p. 82, Forward
        references; add to the end of the reference list:
                , reserved identifiers (7.1.3)

        Note:  I regret having these identifiers show up in
        the grammar, but it seems to be logically necessary in
        order to provide a way for a typedef to invoke an
        extended integer type.  Since the only way a strictly
        conforming program can access one of these identifiers
        is via a typedef name defined in a standard header,
        which in effect hides the use of a reserved
        identifier, no harm is done.  *If the Committee
        prefers to leave 6.5.2 unchanged, I can go along with
        that, although I am concerned that it would allow a
        "reasonable reader" to misinterpret our intent.*

        The following should be inserted in I.3.5
        (Implementation-defined behavior/Integers), p. 417:
                -- Conversion rules involving extended integer
                types (

        Note:  I see no need to require the reserved
        identifiers to be documented, and it is probably best
        to allow implementations flexibility in this regard.

        Add to the Index on p. 428:
                extended integer type,,, 6.5.2
        ( should be emboldened.)

        In the Rationale document, add a new paragraph to Types, just after any discussion of the new
        type {long long}:
                Even with the addition of {long long}, the
                Committee recognized the need to support other
                implementation-defined *extended integer
                types*.  Rather than introducing a standard
                parameterized type or introducing detailed
                rules for non-standard types, the use of such
                extensions in strictly conforming programs has
                been limited to types defined in standard
                headers such as {<stddef.h>} and
                {<inttypes.h>}.  To ensure that extended types
                interact properly with standard types, they
                were explicitly added to the category of
                *integer types*.  Conforming implementations
                may make use of such types in standard headers,
                but since extended types are designated by
                reserved identifiers, strictly conforming
                programs can use them only through typedef
                names defined in those headers.