Issue
I init a uint32 variable by shifting two uint8 variables.
uint32_t test = ((first_uint8 << 16) | second_uint8);
In my test, the value of test should be 0x00170001 (0x17<<16|0x01)
Then it runs into a switch case
switch(test) {
case 0x00170001:
//do sth
break;
default:
//printf invalid
break;
}
It should go to the first case, however, it always run into default.
Then I printf("%x", test), the result is 0x170001, which is equal to 0x00170001.
At last I try to modify it like this:
switch(test) {
case 0x170001:
//do sth
break;
default:
//printf invalid
break;
}
Then it works well.
So I'm curious about the result.
- for a uint32_t variable, why 0x170001 does not equal to 0x00170001?
- if it is caused by I didn't memset
testby 0, thentestshould also not be equal to 0x170001, it should be 0x11170001 or something with a garbage first byte.? - is it caused by the compiler ignores the
0in the front of hex value? I'm using Android NDK to compile my c code.
Solution
- for a uint32_t variable, why 0x170001 does not equal to 0x00170001?
It does. 0x170001, 0x0170001 and 0x00170001 are all equal.
2.if it is caused by I didn't memset test by 0, then test should also not be equal to 0x170001, it should be 0x11170001 or something with a garbage first byte.?
It is not caused by a missing memset. Any assignment test = X will set all bits in test.
3.is it caused by the compiler ignores the 0 in the front of hex value? I'm using Android NDK to compile my c code.
That could explain it but I doubt it. I think it is more likely that your being tricked by something else. Perhaps you are not actually running the code, you think. If it really turns out that it makes a difference whether you write 0x170001 or 0x00170001, you should report it as a compiler bug - but be really sure before doing that.
See here for a working example compiled with gcc : http://ideone.com/UR566Q
Answered By - 4386427
0 comments:
Post a Comment
Note: Only a member of this blog may post a comment.