0xdeadbeef vs 0xdeadbeefL
tom st denis quoted David Eger saying:
Quoted 8 lines
Quoted 2 lines
Is there a reason to add the 'L' to such a 32-bit constant like this? There doesn't seem a great rhyme to it in the headers...
IIRC it should have the L [probably UL instead] since numerical constants are of type ``int'' by default.
[...]
However, by the standard0xdeadbeefis not a valid unsigned long constant.
I think you have a different standard than I do [1]. According to K&R, 2nd ed, section A2.5.1 (Integer Constants):
The type of an integer depends on its form, value and suffix. [...] If it is unsuffixed octal or hexadecimal, it has the first possible of these types ["in which its value can be represented" -- from omitted]: int, unsigned int, long int, unsigned long int.
Which means 0xdeadbeef is a perfectly valid literal for an unsigned int.
Ray
[1] "The great thing about standards is that there are so many of them to choose from." Wish I could remember who said that.
Quoted 3 lines · Ray Lee
[1] "The great thing about standards is that there are so many of them to choose from." Wish I could remember who said that.
AST and in this case it actually doesn't apply - everything from K&R to C99 is in agreement here.
Quoted 7 lines · On Jul 7, 2004, [email protected] wrote:
Quoted 3 lines · Ray Lee
[1] "The great thing about standards is that there are so many of them to choose from." Wish I could remember who said that.
AST and in this case it actually doesn't apply - everything from K&R to C99 is in agreement here.
Are you sure? I've seen K&R C compilers for 32-bit platforms in which 0xdeadbeef had type *signed* int, as opposed to unsigned int. I thought the preference for an unsigned type in this case was introduced in ISO C90, but it might as well have been a bug in that compiler. Although I'm told other compilers display similar behavior.
Signature · 3 lines
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}Quoted 2 lines · Alexandre Oliva
Are you sure? I've seen K&R C compilers for 32-bit platforms in which
0xdeadbeefhad type *signed* int, as opposed to unsigned int.
K&R pre-ANSI (i.e., K&R first edition) allowed this. K&R second edition, a.k.a. ANSI C clarifies this substantially, as per my previous two messages on the topic.
Quoted 3 lines
I thought the preference for an unsigned type in this case was introduced in ISO C90, but it might as well have been a bug in that compiler. Although I'm told other compilers display similar behavior.
File a bug.
Ray
Quoted 1 line · Ray Lee
Which means
0xdeadbeefis a perfectly valid literal for an unsigned int.
Assuming ints are 32-bits wide. They don't have to be. They could be as narrow as 16 bits, in which case the constant will have type long or unsigned long (because long must be at least 32 bits), or they could be wider than 32 bits, in which case the constant will be signed int instead of unsigned int. You might lose either way. It's probably safer to make it explicitly UL, except perhaps in machine-specific files where the width of types is well-known.
Signature · 3 lines
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}Quoted 5 lines · Alexandre Oliva
Quoted 1 line · Ray Lee
Which means
0xdeadbeefis a perfectly valid literal for an unsigned int.Assuming ints are 32-bits wide. They don't have to be.
In which case the rest of that line that read:
it has the first possible of these types ["in which its value can be represented" -- from omitted]: int, unsigned int, long int, unsigned long int.
...kicks in.
Quoted 2 lines
or they could be wider than 32 bits, in which case the constant will be signed int instead of unsigned int.
Read that line again. This would only happen if the platform has no unsigned 32 bit integer whatsoever. If you can point out one of those to me that Linux runs on, then I'll concede the point. On any other platform, the constant oct/hex int promotion rules will walk it up to a 32-bit unsigned before it hits the larger types.
Ray
Quoted 5 lines · Alexandre Oliva
Quoted 1 line · Ray Lee
Which means
0xdeadbeefis a perfectly valid literal for an unsigned int.Assuming ints are 32-bits wide.
ITYM "at least 32-bits wide".
Quoted 2 lines
They don't have to be. They could be
as narrow as 16 bits, in which case
... you would have no fscking chance to build Linux kernel on such platform for $BIGNUM reasons.
Quoted 8 lines · On Jul 7, 2004, [email protected] wrote:
Quoted 5 lines · Alexandre Oliva
Quoted 1 line · Ray Lee
Which means
0xdeadbeefis a perfectly valid literal for an unsigned int.Assuming ints are 32-bits wide.
ITYM "at least 32-bits wide".
No, exactly 32-bits wide. If they're wider, it's going to be signed int. If they're narrower, it's going to be long or unsigned long, depending on how wide long is.
Signature · 3 lines
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}Followup to: <[email protected]> By author: Alexandre Oliva <[email protected]> In newsgroup: linux.dev.kernel
Quoted 13 lines · Ray Lee
Quoted 2 lines
Which means
0xdeadbeefis a perfectly valid literal for an unsigned int.Assuming ints are 32-bits wide. They don't have to be. They could be as narrow as 16 bits, in which case the constant will have type long or unsigned long (because long must be at least 32 bits), or they could be wider than 32 bits, in which case the constant will be signed int instead of unsigned int. You might lose either way. It's probably safer to make it explicitly UL, except perhaps in machine-specific files where the width of types is well-known.
If it runs Linux:
CHAR_BIT == 8 sizeof(int) == 4 sizeof(void(*)()) == sizeof(void *) sizeof(long) == sizeof(void *) sizeof(long long) == 8 (long)NULL == 0L
These assumptions are pretty ingrained in the Linux kernel.
-hpa
Quoted 7 lines · On Jul-06 2004, Tue, 19:05 -0700 Ray Lee <[email protected]> wrote:
According to K&R, 2nd ed, section A2.5.1 (Integer Constants):
The type of an integer depends on its form, value and suffix. [...] If it is unsuffixed octal or hexadecimal, it has the first possible of these types ["in which its value can be represented" -- from omitted]: int, unsigned int, long int, unsigned long int.
Is it safe to assume that C99 compilers append "..., long long int, unsigned long long int" to the list?
Signature · 1 line
Tomas Szepe <[email protected]>
On Wed, 2004-07-07 09:30:59 +0200, Tomas Szepe <[email protected]> wrote in message <[email protected]>:
Quoted 4 lines
Quoted 2 lines · On Jul-06 2004, Tue, 19:05 -0700 Ray Lee <[email protected]> wrote:
According to K&R, 2nd ed, section A2.5.1 (Integer Constants):
Quoted 8 lines
Quoted 5 lines
The type of an integer depends on its form, value and suffix. [...] If it is unsuffixed octal or hexadecimal, it has the first possible of these types ["in which its value can be represented" -- from omitted]: int, unsigned int, long int, unsigned long int.
Is it safe to assume that C99 compilers append "..., long long int, unsigned long long int" to the list?
It is.
MfG, JBG
Signature · 4 lines
Jan-Benedict Glaw [email protected] . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Followup to: <[email protected]> By author: Tomas Szepe <[email protected]> In newsgroup: linux.dev.kernel
Quoted 6 lines
Quoted 2 lines · On Jul-06 2004, Tue, 19:05 -0700 Ray Lee <[email protected]> wrote:
According to K&R, 2nd ed, section A2.5.1 (Integer Constants):
Quoted 9 lines
Quoted 5 lines
The type of an integer depends on its form, value and suffix. [...] If it is unsuffixed octal or hexadecimal, it has the first possible of these types ["in which its value can be represented" -- from omitted]: int, unsigned int, long int, unsigned long int.
Is it safe to assume that C99 compilers append "..., long long int, unsigned long long int" to the list?
Yes.
-hpa