"vi***@gmail.com" <bh**************@gmail.com> writes:
hi all,
Out of sheer curosity, I decided to initialize an integer with a number
bigger than INT_MAX, however I still am not able to justify its output.
Here is the program :
#include<stdio.h>
int main(void)
{
int t=0xFFFFFFFFFFFFFFFFDABC;
printf("t is : %x\n",t);
getchar();
return 0;
}
[snip] The output was
t is : ffffdabc
[snip]
Strictly speaking, the "%x" specifier expects an unsigned int. You
can almost certainly get away with passing an int, but I still prefer
to use an explicit cast (one of the few cases where casts are useful):
printf("t is : %x\n", (unsigned)t);
The literal 0xFFFFFFFFFFFFFFFFDABC requires 80 bits, which is probably
(but not certainly) larger than any integer type.
An unsuffixed hexadecimal integer constant's type is the first type
from this list:
int
unsigned int
long int
unsigned long int
long long int (C99 only)
unsigned long long int (C99 only)
in which the value can be represented. If it can't be represented in
any of those types, it may have an extended integer type (if the
implementation has extended integer types; I don't know of any that
do). If there is no type that can represent the value, the standard
doesn't say what its type is; I believe this means it invokes
undefined behavior by omission (i.e., the behavior is undefined not
because the standard says so, but because it fails to define the
behavior).
I'd be happier if the standard said something explicit about integer
constants that can't be represented in any type.
On the other hand, suppose you use a literal that fits in some integer
type, but not in int. For example, assuming 32-bit int and long, and
64-bit long long:
int t = 0xFFFFFFFFFFFFDABC; /* 64 bits */
the constant is of type unsigned long long. The value is implicitly
converted to type int before being used to initialize t. An
overflowing conversion to a signed integer type doesn't invoke
undefined behavior; it merely yields an implementation-defined result
or raises an implementation-defined signal. (In C90, it yields an
undefined result; there's no mention of raising a signal.)
Having said all that, on every implementation I know of a conversion
from a larger to a smaller integer type simply discards the high-order
bits. You shouldn't depend on this behavior in portable code.
--
Keith Thompson (The_Other_Keith)
ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
