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: gwyn@arl.mil 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 and possibly typedef-names could be associated with integer types other than the standard types defined in the current C standard. In rewriting the specification for , 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 headers. 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 {} 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 6.1.2.5 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}. to: 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 types*. 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 6.2.1.7 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]; after: {long} add new line: *extended-signed-integer-type* Optionally, but recommended, add new Syntax rule: *extended-signed-integer-type*: *identifier* 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 {unsigned} 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 (6.2.1.7) 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.1.2.5, 6.2.1.7, 6.5.2 (6.1.2.5 should be emboldened.) In the Rationale document, add a new paragraph to 6.1.2.5 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 {} and {}. 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.