cas

There's no problem as far as C (C99, specifically) is concerned. Integer constants in your program are by default int; but if an integer constant can't fit into an int, then it's a long; if it can't fit into a long int, then it's long long. So since your 18232323232322 doesn't fit into an int or a long on your system, it has the type long long int. That's fine and dandy, but your compiler is (perhaps helpfully) letting you know that it's too large to be a long.

I don't know about your compiler, but on gcc 4.3.3, I get that warning when I'm not explicitly in C99 mode. The C89 standard did not have long long, and thus of course did not have long long constants. So my compiler is helpfully letting me know that what I'm doing might have issues. If I ask for C99 support (with -std=c99) the warning goes away.

If you're unaware, C is an internationally standardized language with two major version: C89 and C99. C99 is newer, and contains things that C89 does not have, one of those being the long long type. So your compiler, even if it accepts long long, is probably not fully C99 conformant. As such, it's letting you know that your code, while being correct C99, is not necessarily portable to other implementations.

As for 251 vs -5: when a negative integer is converted to an unsigned type, the resulting value is necessarily positive; and how it is converted is defined: -1 is the largest possible value in the unsigned type, -2 is the next largest, and so on.

Assuming a typical desktop, an unsigned char is 8 bits. Thus the largest value it can take is 255. -1 converted to unsigned char is 255. An unsigned int is 32 bits. -1 converted to unsigned int is 4294967295.

When you pass values to printf(), something called the "integer promotions" happens. C won't allow you to pass an integer smaller than an int to printf(). That means char (and short) need to get converted to a larger type. Assume our unsigned char and unsigned int above take the values -1 (which means their largest value). When the unsigned char is passed to printf(), it's converted to int. That means 255 is converted to int, which results in the value 255. So %d, which expects an int, received an int with the value 255, and printed that out.

However, you're lying to the compiler when you pass the unsigned int and use %d. %d expects an int, not an unsigned int. This means that %d can not print out a value larger than the largest int. The unsigned int you passed is much larger than the largest int type (about twice as large). %d must then interpret the bit pattern as an int (that's its job: it has no choice in the matter). It so happens that what you passed (4294967295) looks like -1 when interpreted as an int, which is what %d does. 255 does not look like -1 when interpreted as an int, so that's why 255 printed in the first part.

Perhaps this helps:

Elysia

There is no C89 international standard. There is only C90 and C99.
C89 is an American standard.

__________________
Using: Microsoft Windows™ 7 Professional (x64), Microsoft Visual Studio™ 2008 Team System
I dedicated my life to helping others. This is only a small sample of what they said:
"Thanks Elysia. You're a programming master! How the hell do you know every thing?"
Quoted... at least once.

BlaX

"It cannot be stored in 32 bits" , but im already declaring it as a long long integer and .. why should it post a warning ?

why %I64d .. why isn't %lld working ?

@cas : ... thank you.im graceful for your explanation

though i have some other questions

1) if all chars and shorts are changed the same way to ints ... then how would a signed char like

cause a negative to print out ?

2) when we are saying unsigned int x = -5
and knowing its ranging is 0 to 4.......

how come -5 is getting stored, it is not in the range ? ... can we say declaring it unsigned is useless while using the %d format specifier ?

3)And why is

printing -5 ... im explicitly changing -5 to an unsigned value ...

Damn im confused ..
Thank you.

tabstop

Because for, ooh, about two-thirds of its lifetime the C language didn't have anything longer than 32 bits. (Also hint: 1823232323232322 is not explicitly typed -- you most certainly have not declared it as a long long integer.)

Ditto. MinGW uses the Microsoft runtime, 'cause it's their operating system, and Microsoft hasn't gotten past 1989 in terms of C (when there was no such thing as "long long").
... Because it's changed to an int? If it wasn't converted to an int, you'd get the equivalent of 0x000000FB, also known as 251. It is converted to an int, that is we get an int with the same value, not with the same bits.
What?
You are explicitly changing -5 to an unsigned value ... and then explicitly changing it right back again by printing with %d.

BEN10

1). Considering the char to be of 8bits, The range of signed char is -128 to 127. Now if you give a signed char any value in this range, it'll print it as it is. But if you give the signed char a value which is not in it's range for eg. 255, then it'll print any appropriate number from the other side. In your case you are printing -5 which is in the range of -128 to 127 that's why it prints -5, but try your hands on any number not in this range then you'll get to know what's happening. Let me give you another example.
As I said here x is not in range of -128 to 127, now what happens is that it takes the appropriate number from the other side of the range which is -128, if x would have been 129, output then would be -127 and so on. Try doing this
It'll result in an indefinite loop because of the same reason that x is never going above 127. As it increments to 129 it goes to the negative side and thus process gets repeated.

2) Same as 1. It'll take appropriate value from it's range which is 0-4.
3)Just change %d to %u and you'll get an appropriate value from the other side.

__________________
HOPE YOU UNDERSTAND.......

for( ; ; )
printf("If you can't make it good, at least make it look good");

PC specifications- 512MB RAM, Windows XP sp3, 2.79 GHz pentium D.
IDE- Microsoft Visual Studio 2008 Express Edition

Elysia

No, you are not declaring it as long long!
You are declaring the variable x as long long. But the integer constant itself, you are declaring as an int (by omitting any type of postfix)!
In later code, when you added LL after it, you got no warning, did you?

You can also see it this way:
How do we assign that number to the variable x (in machine code)?
First, we must have some place to store it.

mov eax, my_integer_constant; // <--- If your number can't fit into 32 bits, you will get a WARNING!
lea ecx, x; // Put address of x into ecx
mov [ecx], eax; // Store eax in *ecx.

Does this make any sense? You have TWO parts of the expression, and both have different types!
The first is the variable x which has type long long, and the second is the number which has type int (or long).

__________________
Using: Microsoft Windows™ 7 Professional (x64), Microsoft Visual Studio™ 2008 Team System
I dedicated my life to helping others. This is only a small sample of what they said:
"Thanks Elysia. You're a programming master! How the hell do you know every thing?"
Quoted... at least once.

cas

If the compiler follows C99 at all, then the constant is not an int or a long, but a long long, assuming it doesn't fit into an int or a long. There's nothing wrong with explicitly making it long long with LL, especially if your compiler is, as the OP's appears to be, in C89 mode with extensions. But the type of the constant is not int or long.