0xdeadbeef vs 0xdeadbeefL

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...

-dte

IIRC it should have the L [probably UL instead] since numerical constants are of type ``int'' by default.

Normally this isn't a problem since int == long on most platforms that run Linux. However, by the standard 0xdeadbeef is not a valid unsigned long constant.

Consider the following...

#include <stdio.h>
int main(void)
{
unsigned int x;
x = 4;
if (x < 0xdeadbeef) printf("hello");
return 0;
}

If you run splint on that you get

---
Splint 3.1.1 --- 13 Jun 2004

test2.c: (in function main)
test2.c:7:7: Operands of < have incompatible types (unsigned int, int):

                x < 0xdeadbeef

To ignore signs in type comparisons use +ignoresigns

Finished checking --- 1 code warning
---

As far as I know splint follows C99 which means that it thinks the constant is "int".

Tom

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail

... and that would be your F for C101. Suggested remedial reading before you take the test again: any textbook on C, section describing integer constants; alternatively, you can look it up in any revision of C standard. Pay attention to difference in the set of acceptable types for decimal and heaxdecimal constants.

You're f'ing kidding me right? Dude, I write portable ISO C source code for a living. My code has been built on dozens and dozens of platforms **WITHOUT** changes. I know what I'm talking about.

0x01, 1 are 01 all **int** constants.

On some platforms 0xdeadbeef may be a valid int, in most cases the compiler won't diagnostic it. splint thought it was worth mentioning which is why I replied.

In fact GCC has odd behaviour. It will diagnostic

char x = 0xFF;

and

int x = 0xFFFFFFFFULL;

But not

int x = 0xFFFFFFFF;

[with --std=c99 -pedantic -O2 -Wall -W]

So I'd say it thinks that all of the constants are "int". In this case 0xFF is greater than 127 [max for char] and 0xFFFFFFFFFFULL is larger than max for int. in the 3rd case the expression is converted implicitly to int before the assignment is performed which is why there is no warning.

Before you step down to belittle others I'd suggest you actually make sure you're right.

Tom

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail

Tom is correct. A literal constant defaults to 'int'.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
Note 96.31% of all statistics are fiction.

I did a bit more messing around with GCC and it seems in

int x = 4;
if (x == 0xDEADBEEF) { ... }

It will warn that 0xDEADBEEF is unsigned (which it isn't). Either there is an obscure clause in the C standard [I personally don't have a copy of C99 nor do I plan on reading it for this] or GCC cause an incorrect diagnostic [which isn't in violation of the standards...]

Really GCC should just warn that 0xDEADBEEF is not a valid int constant
[for portability sake...]. It's simple, any constant > 16-bits should
have a UL/L or ULL/LL suffix.

Tom

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail

It is certainly not obscure.
ISO C99 6.4.4.1#5 says:
The type of an integer constant is the first of the corresponding list in which its value can be represented.

For Octal or Hexadecimal Constant and no suffix, the table lists:
int
unsigned int
long int
unsigned long int
long long int
unsigned long long int

Assuming 32-bit int, 0xdeadbeef has unsigned int type.

For Decimal Constant and no suffix, the table lists only:
int
long int
long long int
and thus assuming 32-bit int and 64-bit long, 3735928559 has long int type, assuming 32-bit int, 32-bit long and 64-bit long long, 3735928559 has long int type.

Jakub

Hi!

Did you mean "long long int" at the end of last sentence?

64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Obviously, that was a pasto.

Jakub

Anyway, I think it's a good idea to put L wherever a constant is meant to be 'long' and U wherever it's meant to be 'unsigned' etc., because it may be useful in debigging, eg.:

1) identifying wrong types being used (eg. int vs long, int vs unsigned, long vs unsigned long),
2) identifying typos (eg. 0x100000000 vs 0x10000000)

Yours,
rjw

Rafael J. Wysocki
----------------------------
For a successful technology, reality must take precedence over public 
relations, for nature cannot be fooled.
					-- Richard P. Feynman

Correct. And irrelevant.

Correct, but incomplete.

Always do.

Exercise:
1) what type does an integer constant 0xdeadbeef have on a platform
with INT_MAX equal to 0x7fffffff and UINT_MAX equal to 0xffffffff?
2) when does the situation differ for integer constant 3735928559?

Oh, and do read the part of C standard in question. Hint: extra restrictions are placed on decimal constants, not on the octals and hexadecimals.

That may be true but what does it hurt to imply the dimensions ahead of time? You meant an unsigned long constant so add the UL suffix.

Tom

__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail

You are aware that this statement is plainly and simply wrong, aren't you?

On many platforms a "plain" char is unsigned. You can't write portable code without knowing this.

Ditto.

Gabriel

That goes right up there with, um nope. The only reason why the compiler doesn't error about it is because it's not an error. Doesn't mean it's right.

Um, actually "char" like "int" and "long" in C99 is signed. So while you can write

signed int x = -3;

You don't have to. in fact if you "have" to then your compiler is broken. Now I know that GCC offers "unsigned chars" but that's an EXTENSION not part of the actual standard.

You ought to distinguish "what my compiler does" with "what the standard actually says". If you want unsigned chars don't be lazy, just write "unsigned char".

As for writing portable code, um, jacka#!, BitKeeper, you know, that thingy that hosts the Linux kernel? Yeah it uses LibTomCrypt. Why not goto http://libtomcrypt.org and find out who the author is. Oh yeah, that would be me. Why not email Wayne Scott [who has code in LibTomCrypt btw...] and ask him about it?

Who elses uses LibTomCrypt? Oh yeah, Sony, Gracenote, IBM [um Joy Latten can chip in about that], Intel, various schools including Harvard, Stanford, MIT, BYU, ...

I write code that builds on basically any box with GCC which includes regular PCs, Macs, Gameboys, PS2, Suns, etc, etc, etc. All without changes....

Tom

__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo

------------------------------ snip -----------------------------
[#15] The three types char, signed char, and unsigned char
are collectively called the character types. The
implementation shall define char to have the same range, representation, and behavior as either signed char or unsigned char.35)
------------------------------ snip -----------------------------

Tons of people use windows aswell. You just showed that you don't know C well enough, so maybe someone should better do an audit for your code ;-)

Right. Didn't know that. Whoa. So in essence "char" is not a safe type.

To be honest I didn't know that above. That's why I'm always explicit.
[btw my code builds in MSVC, BCC and ICC as well].

You don't need to know such details to be able to develop in C. I'm sure if you walked into [say] Redhat and gave an "on the spot C quiz" about obscure rules they would fail. You have to use some common sense and apply the more relevant rules.

Point is 0xDEADBEEFUL is just as simple to type and avoids any sort of ambiguitity. It means unsigned long. No question about it. No having to refer to subsection 12 of paragraph 15 of section 23 of chapter 9 to figure that out.

Why people are fighting over this is beyond me. Fine, write it as 0xDEADBEEF see what the hell I care. Honestly. Open debate or what?

And I don't need mr. Viro coming down off his mountain saying "oh you fail it" because I don't know some obscure typing rule that I wouldn't come accross because *** I AM NOT LAZY ***. Hey mr. Viro what have you contributed to the public domain lately? Anything I can harp on in public and abuse?

Asshat.

Tom

__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

If people write either 0XdeadbeefUL or 0xDEADBEEFul, fine. But this is a place where character case really makes a difference in readibility-

I think you will find that mr. Viro has contributed quite a lot :-)

Hilsen Harald.

On Wed, Jul 07, 2004 at 11:53:40AM -0700, tom st denis wrote:
[snip]

Well, look at it this way... Alexander Viro is one of very few persons in the world that I'd trust enough to take unaudited code from and apply to my own projects.

Oh, and you're using his works every day I suppose; he's behind most of the VFS of the kernel. Read the bloody changelogs for the kernel instead of whining.

Regards: David Weinehall

 /) David Weinehall <[email protected]> /) Northern lights wander      (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/    (/   Full colour fire           (/

It depends what you use it for, but it typically is not.

The _very_ common mistake is assigning the result of fgetc/getc/getchar (which are defined to return an _unsigned_ char cast to an int or EOF) to a plain char and then comparing it with -1 to check for EOF:

1) it will never detect the EOF if the char is unsigned (PPC)

2) it will stop on a ÿ (that's an y with a diaeresis) on Intel. This character is infrequent in the languages I use but it occasionally happens.

Of course people who only use plain 7 bit ASCII never hit the bug, but as soon as you go into Latin-$n encodings you may hit them (I'm only restricting myself to character sets based on the Latin alphabet).

And no the solution is not to use -fsigned-char or -funsigned char as an optin to GCC. Most of the time it only changes the kind of bugs that are hidden in the code, and 2) above is statistically harder to hit than 1).

Yes, I know and I use BK. But given the fact that you insult me for better knowing C rules than you, I'm seriously considering switch to subversion or arch instead.

Argh, I've mentioned BK. There should be a Goldwin's law equivalent for BitKeeper on lkml ;-)

Well, I consider the rules about plain char to be among the most relevant, since I've been hit by them _way_ _more_ than about any other badly known C rule.

And finally, I'd personnaly prefer the char to be unsigned, for several reasons:
- its name which suggests that it is an enumeration of symbols.
- strcmp and friends do the comparisons using _unsigned_ char, despite the fact that the prototype declare plain char parameters
- the aforementioned fgetc/getc/getchar issues.

BTW, this signed/unsigned mess is a reason for some weirdness like tables with 384 entries in libc/ctype/ctype.h:

/* These are defined in ctype-info.c.
The declarations here must match those in localeinfo.h.

In the thread-specific locale model (see `uselocale' in <locale.h>) we cannot use global variables for these as was done in the past. Instead, the following accessor functions return the address of each variable, which is local to the current thread if multithreaded.

These point into arrays of 384, so they can be indexed by any unsigned char' value [0,255]; by EOF (-1); or by any signed char' value [-128,-1). ISO C requires that the ctype functions work for unsigned char' values and for EOF; we also support negative signed char' values for broken old programs.

[snipped]

Not specifying the signedness of the char types is one of C's original mistakes, and the one that statistically mostly affects me.

Gabriel (the only good char is the unsigned char)

Godwin, surely?

Anyway, if you think that suckversion authors knew C... Try to read their decoder/parser/whatever you call the code handling the data stream obtained from other end of connection. _Especially_ when it comes to signedness (of integers, mostly).

... have nothing to do with char; getc() has more legitimate return values than char can represent. No matter whether it's signed or unsigned, if you have

	... char c;
	...
	c = getc();

you have a bug - Dirichlet Principle bites you anyway.

Right, should have looked the name up.

I did not read it, neither did I read BitKeeper's code for obvious reasons.

Only one more, unless I missed something.

Indeed, but unfortunately you don't hit the problem with pure ASCII on x86. That's one of the reasons for which a lot of code ported to archs where char is unsigned by default is simply compiled with -fsigned-char instead of correcting the bugs.

The remaining case (char 0xff) is infrequent, at least for Latin-[19] encodings in the languages I know, and never happens with UTF-8 AFAICT.

Heck, even the 2.4 ppc kernel is compiled with -fsigned-char, for $DEITY's sake.

Regards,
Gabriel

Ah, it took me a few seconds to reconstruct what principle you are referring to.

I am used to seeing "Dirichlet Principle" in a context where one wants to solve a boundary value problem for certain elliptic partial differential equations. (Then the principle states, roughly, that the unique solution is found by minimizing some integral.)

You invoke what I am used to call the pigeonhole principle.

Andries

I'm sure that Al meant "Dirichlet's Box Principle" here, as you say.

http://mathworld.wolfram.com/DirichletsBoxPrinciple.html
vs.
http://mathworld.wolfram.com/DirichletsPrinciple.html

Michael Driscoll, [email protected]
"A noble spirit embiggens the smallest man" -- J. Springfield

[...]

Nope. char is either an unsigned char or a signed char, which one is up to the implementation, and the three types are distinct. The signed keyword was introduced exactly for the corner case of an explicitly signed (not unsigned, and not maybe signed) char.

Not an extension, in C for ever and ever.

Right. Look at the standard, and then go back and rewrite to agree with C99 all the "standard conforming" C you have written. Should keep you away from LKML for a while...

Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

<posted & mailed>

Thought the name looked familiar, now I figure out why. Ladies and gentlemen, the Al Viro of sci.crypt has met the Al Viro of... Al Viro.

Well if you put the 'name' so we could search for the reason..... It probably is used for magic to initialize long-words. Without the L, you may get a 'C' warning error because numbers default to 'int'.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
Note 96.31% of all statistics are fiction.

The reason I ask is that I'm going on a cleaning spree of

include/video/radeon.h

I was trying to debug my code figuring out which flags we were setting in GMC_GUI_MASTER_CNTL. Now radeon.h does have lots of #defines for what the bits mean, but they're all mixed up, e.g.:

#define GMC_DP_CONVERSION_TEMP_6500                0x00000000
#define GMC_DP_SRC_RECT                            0x02000000
#define GMC_DP_SRC_HOST                            0x03000000
#define GMC_DP_SRC_HOST_BYTEALIGN                  0x04000000
#define GMC_3D_FCN_EN_CLR                          0x00000000
#define GMC_3D_FCN_EN_SET                          0x08000000
#define GMC_DST_CLR_CMP_FCN_LEAVE                  0x00000000
#define GMC_DST_CLR_CMP_FCN_CLEAR                  0x10000000
#define GMC_AUX_CLIP_LEAVE                         0x00000000
#define GMC_AUX_CLIP_CLEAR                         0x20000000
#define GMC_WRITE_MASK_LEAVE                       0x00000000
#define GMC_WRITE_MASK_SET                         0x40000000
#define GMC_CLR_CMP_CNTL_DIS                       (1 << 28)
#define GMC_SRC_DATATYPE_COLOR                     (3 << 12)
#define ROP3_S                                     0x00cc0000
#define ROP3_SRCCOPY                               0x00cc0000
#define ROP3_P                                     0x00f00000
#define ROP3_PATCOPY                               0x00f00000
#define DP_SRC_SOURCE_MASK                         (7    << 24)
#define GMC_BRUSH_NONE                             (15   <<  4)
#define DP_SRC_SOURCE_MEMORY                       (2    << 24)
#define GMC_BRUSH_SOLIDCOLOR                       0x000000d0

This mish-mash makes it impossible to grep for '0x00f0' or '0x000000f0' and get the answer I want, as GMC_BRUSH_NONE isn't listed in such a form. So I wrote a little script to standardize the file, and I noticed that in other sections, we have #defines like these:

// CLK_PIN_CNTL

#define CLK_PIN_CNTL__OSC_EN_MASK                          0x00000001L
#define CLK_PIN_CNTL__OSC_EN                               0x00000001L
#define CLK_PIN_CNTL__XTL_LOW_GAIN_MASK                    0x00000004L
#define CLK_PIN_CNTL__XTL_LOW_GAIN                         0x00000004L
#define CLK_PIN_CNTL__DONT_USE_XTALIN_MASK                 0x00000010L
#define CLK_PIN_CNTL__DONT_USE_XTALIN                      0x00000010L

As part of the standardization, my script strips the 'L' off of the constant. (It's the output of 'eval()'ing the #define in Python.) I was really just wondering if this would break anyone's code.

Invocation goes like this:

$ (stdlbdef.py | upsidedown.py | stdlbdef.py | upsidedown.py ) < radeon.h > radeon.h.2

Then all of the simple arithmetic #define's are aligned to a uniform width of hex value within each block of #define's.

-dte

#!/usr/bin/python
#
# stdlbdef.py
#
# Got a header file where someone has mixed up their constants # willy-nilly, like this?
#

#define GMC_AUX_CLIP_LEAVE                         0x00000000
#define GMC_AUX_CLIP_CLEAR                         0x20000000
#define GMC_WRITE_MASK_LEAVE                       0x00000000
#define GMC_WRITE_MASK_SET                         0x40000000
#define GMC_CLR_CMP_CNTL_DIS                       (1 << 28)
#define GMC_SRC_DATATYPE_COLOR                     (3 << 12)

#
# This script will make them all nice constants... mmmm..

import string
import re
import sys

linesplitter = re.compile("^(?P<a>#define\s+[a-zA-Z0-9_]+\s+)(?P<b>.*)") hexnum = re.compile("^0[xX][0-9a-fA-F]+$")

l = sys.stdin.readline()
lastsize = 2

while l:
ma = linesplitter.search(l,0)
if ma and ma.group("b"):
exp = ma.group("b").rstrip()
# process the line
if hexnum.match(exp,0) and len(exp) >= lastsize:
lastsize = len(exp)
sys.stdout.write( l )
else:
try:
num = eval(exp)
q = '0x%x' % num
if len(q) < lastsize:
fs = '0x%%0%dx' % (lastsize - 2) q = fs % num
lastsize = len(q)
sys.stdout.write( '%s%s\n' % (ma.group("a"), q))
except:
sys.stdout.write( l )
else:
sys.stdout.write( l )
lastsize = 2
l = sys.stdin.readline()

#!/usr/bin/python
#

# upsidedown.py
#
#   prints out a file, line by line, starting with the last line, 
#    going to the first

import sys
l = sys.stdin.readlines()
l.reverse()
for i in l:
sys.stdout.write(i)

[SNIPPED...]

Yes, they are not pretty. I would suggest puting them in order, but nothing else. As you can tell by the response, you have tripped on a hornet's nest and they are attacking anything in the area. I certainly would not remove 'L' from any of those constants. The code will be exactly the same when compiled, but there may be some diagnostic messages and nasty-grams from kernel hackers.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
Note 96.31% of all statistics are fiction.