Document Number: WG14 N629/X3J11 96-093 C9X Revision Proposal ===================== Title: ____Type rules for decimal integer constants_________ Author: ___David Prosser____________________________________ Author Affiliation: __SCO, Inc._____________________________ Postal Address: 430 Mountain Ave.; P.O. Box 4; Murray Hill, NJ 07974 E-mail Address: ______dfp@sco.com___________________________ Telephone Number: ____(908)790-2358_________________________ Fax Number: __________(908)790-2426_________________________ Sponsor: __Larry Jones______________________________________ Date: ________________13 November 1996______________________ Proposal Category: __ Editorial change/non-normative contribution x_ Correction x_ 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: _________________________________________________ Target Audience: _C Programmers_____________________________ ____________________________________________________________ ____________________________________________________________ Related Documents (if any): ________________________________ ____________________________________________________________ ____________________________________________________________ Proposal Attached: x_ Yes __ No, but what's your interest? Abstract: The addition of a new integer data type (long long) permits a change to the rules regarding types for decimal integer constants that fixes some inconsistencies, primarily regarding signedness. This proposal strongly suggests that decimal integer constants should only have signed integer type choices, unless suffixed by a "u" or "U". Proposal: The rules for decimal integer constants in the current ISO C standard reflect the notion that a long is the biggest type and, having predated the "u" and "U" suffix addition, had decimal integer constants whose value was in the range [LONG_MAX+1,ULONG_MAX] taken to have type unsigned long. Otherwise, an unsuffixed decimal constant must be a signed type. For the other bases (octal and hexadecimal), all the signed and unsigned integer types from int and up are sequentially stepped through. When long long was added, integer constants had to be accepted with values beyond that representable by long or unsigned long. With octal and hexadecimal, adding long long and then unsigned long long is straightforward and obvious. The technical committee now had to wrestle with the problem of these decimal constants. The two choices where either to similarly tack on long long and then unsigned long long, or first to remove the unsigned long choice and then tack on the same two new types. My understanding is that there is existing practice in both of these camps. I know that SCO's C compiler took the latter choice (and emits a warning when a decimal integer constant without a "u" or "U" suffix falls in the above range). What came out of a discussion partially seen on the sc22wg14 reflector is a different choice--one that we probably would have strongly considered back in the 80's when we were first codifying C (even though there we had no long long type) if we had seen the expressiveness of our "u" and "U" suffix addition. This choice is simply not to include ANY unsigned integer types for decimal integer constants without a "u" or "U" suffix. In other words, a constraint violation (ISO C 6.1.3) would be triggered if such a constant had a value greater than LLONG_MAX. [N.B.: I've assumed that has LLONG_MIN, LLONG_MAX and ULLONG_MAX as its spelling of the new end point values. These are the spellings used in SCO's implementation.] The reworded ISO C 6.1.3.2 "semantics" second paragraph would read: The type of an integer constant is the first of the corresponding list in which its value can be represented. Unsuffixed decimal: int, long int, long long int; unsuffixed octal or hexadecimal: int, unsigned int, long int, unsigned long int, long long int, unsigned long long int; suffixed by the letter "u" or "U": unsigned int, unsigned long int, unsigned long long int; decimal suffixed by the letter "l" or "L": long int, long long int; octal or hexadecimal suffixed by the letter "l" or "L": long int, unsigned long int, long long int, unsigned long long int; suffixed by both the letters "u" or "U" and "l" or "L": unsigned long int, unsigned long long int; decimal suffixed by two letters "l" or "L": long long int; octal or hexadecimal suffixed by two letters "l" or "L": long long int, unsigned long long int; suffixed by both "u" or "U" and two letters "l" or "L": unsigned long long int. (I would suggest that this can be much more easily presented now that long long exists by a table!)