[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Devel] Off topic? Signed versus unsigned for hexadecimal constants.
From: |
Antoine Leca |
Subject: |
Re: [Devel] Off topic? Signed versus unsigned for hexadecimal constants. |
Date: |
Tue, 27 Mar 2001 17:45:33 +0200 |
Tom Kacvinsky wrote:
>
> Based on the email earlier today about hexadecimal constants,
Note that I have *not* read the entire discussion with full attention...
> I have found the following (no qualifiers such as U or UL or L on the
> constant):
<snip>
> I don't have my ANSI C99 spec. in front of me (its at work, I'm at home), but
> based on
> the above, I'd have to say its the ANSI specification that hexadecimal
> constants should
> be treated as signed unless the U qualifier is given.
Nope. The rule is quite a bit more complex. Here they are:
For *decimal* integer constants:
0 <= x <= INT_MAX signed int
INT_MAX < x <= LONG_MAX signed long (if it matters)
LONG_MAX < x <= ULONG_MAX unsigned long
(and obviously, with C99 and the added types like long long, things are still
more complex, but detailing them is not worth the trouble)
For *octal* and *hexadecimal* integer constants:
0 <= x <= INT_MAX signed int
INT_MAX < x <= UINT_MAX unsigned int
UINT_MAX < x <= LONG_MAX signed long (if it matters)
LONG_MAX < x <= ULONG_MAX unsigned long (if it matters)
You can easily notice that with decimal constants, you cannot create a
"unsigned int"-typed value, so the "u" suffix is required. OTOH, with
octal and hexadecimal constants, you always have the "tallest" available
type with the correct value.
Now (assuming 32-bit ints) if 0xFFFFFFFF is signed (being int or long,
BTW), I would call it a bug.
(in ANSI mode, of course; things are quite different when one use non
conforming modes, for example because previous versions did not have these
rules, and preserving backward compatibility were and is considered more
important).
Antoine