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!)