Unexpected result of ++((unsigned)x), x is uint8_t? - c

Question

Why doesn't this piece of code result in y == 0x100?
uint8_t x = 0xff;
unsigned y = ++((unsigned)x);
Check it out for yourself here: http://codepad.org/dmsmrtsg

Answer 1

The code you posted is invalid form the point of view of C language. The result of any cast in C is an rvalue. It cannot be used as an argument of ++. Operator ++ requires an lvalue argument. I.e. expression ++((unsigned) x) is non-compilable in standard C language.
What you actually observe in this case is GCC's "generalized lvalues" extension
http://gcc.gnu.org/onlinedocs/gcc-3.4.4/gcc/Lvalues.html
Per that extension (and contrary to the standard C), a cast applied to an lvalue produces an lvalue. When you attempt to write something into the resultant "generalized" lvalue, the value being written is converted twice: it is first converted to the type specified by the explicit cast, and then the intermediate result is converted again to the type of recipient object. The final result is placed into the recipient object.
For example, if with your x you do
(unsigned) x = 0x100;
it will be actually interpreted by GCC as
x = (uint8_t) (unsigned) 0x100;
and the final value of x will be 0.
And this is exactly what happens in your example. In GCC your
++((unsigned) x)
is equivalent to
(unsigned) x = (unsigned) x + 1;
which is in turn interpreted by GCC as
x = (uint8_t) (unsigned) ((unsigned) x + 1);
This is why you get 0 in x as the result, and that is the 0 that then gets assigned to your y.
This extension is referred to as deprecated by GCC docs.

Answer 2

To start this is not valid C code, I don't know how you got it to compile, but your link does show an output, so I'll try to explain what's happening based on this one major assumption:
I guess with this line unsigned y = ++((unsigned x)); the second unsigned is being dropped by your compiler, hence why you're able to build.
So, Assuming that...
uint8_t x = 0xff; // 8 bit value, max is 255(10) or 0xFF(16)
unsigned y = ++((unsigned)x);
Now x has the max value already for its type. You want to know why if we +1 via ++, y doesn't get value of 0x100.
x is 8 bit, typecasting it doesn't change the fact that it's 8 bit. So when we say:
++x
We're incrementing x (x=x+1). So we have an unsigned 8 bit value, at the max and add 1 to it, now it's wrapped around to 0. So y will get 0.
If you wanted this to work you could do something like:
int main(void)
{
unsigned char x = 0xFF; //I'm using char because it's 8 bit too
unsigned int y = 1+x; //no need to typecast, we're already unsigned
printf("%#x %#x\n", x, y);
return 0;
}
Now you'll get the expected values (x==0xFF and y==0x100)

Answer 3

Try this:
uint8_t x = 0xff;
unsigned y = ((unsigned)x) + 1;
It will come out as you expect, because (unsigned) x is now the two-byte value 0x0100.
Now try this:
uint8_t x = 0xff;
++x;
The value of 0xff wraps around to 0x00.

Answer 4

I put in some little transparency code into your excerpt and it explains everything.
#include <stdio.h>
#include <stdint.h> // not needed
int main(void) {
uint8_t x = 0xff;
printf("%d\n", sizeof(x));
unsigned y = ++((unsigned)x);
printf("%d\n", sizeof(y));
printf("0x%x\n", y);
printf("%d\n", sizeof(y));
return 0;
}
and the output is
1 // size of x
4 // size of y before computation
0x100 // computed value of y from your code
4 // size of y after computation
First thing to notice is that the sizeof(y) stays constant across computation.
From the outputs,
uint8_t = 1 byte
unsigned = 4 bytes
When you do a cast in C, think of it as an implicit call to realloc which says: "take this data I have from its block, increase (or decrease) its size in memory to the size I want to cast it to, then return the same data in a new block.
And from our sizes, unsigned will have enough space to fit the result of the computation from a one-byte operation.
Re-explainng your code in byte-level detail,
x = 11111111 = 0xff (in a byte)
(unsigned)x = 00000000000000000000000011111111 = 0xff (in a word)
++((unsigned)x) = 00000000000000000000000100000000 = 0x100