# Thread: why is int 0xFFFFFFFF is -1 ?

1. ## why is int 0xFFFFFFFF is -1 ?

can someone make it clear for me please ?

if i say
Code:
```int a = 0xFFFFFFFF;
unsigned int b = 0xFFFFFFFF;

printf("a = %d, b = %u" , a,b);```
the output will be :
a = -1 , b = 4294967295

// now . FFFF FFFF is 1111 1111 and 'int a' has the first 1 as the flag for negetive number .
. how its works. someone can figure it out for me ? 2. Simply put, 0xFF = 1111 1111 is the 2s complement for -1. Look up 2s complement. It's an encoding scheme used in computers. 3. Note, also, that C implementations are not required to use 2s-complement encoding - and there are certainly implementations that don't. The result could therefore be different with different implementations (compiler, host system, etc). 4. Originally Posted by Elysia Look up 2s complement. It's an encoding scheme used in computers.
Also be aware that true 2s-complement has a representation for negative zero, which is distinct from positive zero. The modified 2s-complement used in most systems you're likely to encounter does not. 5. Also be aware that true 2s-complement has a representation for negative zero, which is distinct from positive zero.
O_o

I think you are looking for "One's Complement" where "Two's Complement" is the one without the negative zero.

Soma 6. You're right. My mistake. 7. To be clear, 0xffffffff is not -1, it is 4294967295. This value may or may not be representable by an int or an unsigned int (see 5.2.4.2.1p1). When the value cannot be represented by an int, converting it to an int has implementation-defined behaviour (see 6.3.1.3p3). 8. Originally Posted by zyxwvuts To be clear, 0xffffffff is not -1, it is 4294967295...
No, it's not. A number is a string of bits. What number those string of bits represents depends on how you interpret them.
If you interpret it as an unsigned number, then it's 4..294..967..295.
If you interpret it as a two's complement number, then it's -1. 9. The point I was trying to convey is that C will interpret the integer constant (not the representation) 0xffffffff as having the value that is commonly written as 4294967295. (See 6.4.4.1p4.) 10. Originally Posted by zyxwvuts The point I was trying to convey is that C will interpret the integer constant (not the representation) 0xffffffff as having the value that is commonly written as 4294967295. (See 6.4.4.1p4.)
That's just it though, it doesn't because int's are signed.
0xffffffffU does though. 11. That's just it though, it doesn't because int's are signed.
O_o

The "signedness" of `int' has nothing to do with the comment zyxwvuts posted.

Integer literals are not necessarily `int'; they are "first fit" according to a few rules.

If the compiler supports larger--such as 64bit--values, the value `0xffffffff' as an `int' is naturally 4294967295 decimal.

When a compiler is limited smaller--such as 32bit--values, the value `0xffffffff' may be too large for a `int'--which is signed. A conforming compiler will then try `unsigned int', `long', and so on until an appropriate type is found. If one of the unsigned types "first fit", the value of `0xffffffff' would be treated as unsigned thus still being 4294967295 decimal.

Tried to clear up some awkward wording...
[/Edit]

Soma Popular pages Recent additions 