Hi, the following is compiled in 9.3, glibc-2.3.4-23.4, and gcc-3.3.5-5. The result is: mask=0 mask1=4294967295 I would expect mask = mask1 = 0? Regards, Verdi =========================================================== #include <stdio.h> int main() { unsigned int mask = (unsigned int) -1 >> 32; int i = 0; unsigned int mask1 = ((unsigned int) -1) >> (32 - i); printf("mask=%u mask1=%u\n", mask, mask1); return 0; } =========================================================== -- GMX DSL = Maximale Leistung zum minimalen Preis! 2000 MB nur 2,99, Flatrate ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl
On Wed, Jul 20, 2005 at 11:57:51AM +0200, Verdi March wrote:
Hi, the following is compiled in 9.3, glibc-2.3.4-23.4, and gcc-3.3.5-5. The result is: mask=0 mask1=4294967295
I would expect mask = mask1 = 0?
Regards, Verdi
=========================================================== #include <stdio.h>
int main() { unsigned int mask = (unsigned int) -1 >> 32;
int i = 0; unsigned int mask1 = ((unsigned int) -1) >> (32 - i);
printf("mask=%u mask1=%u\n", mask, mask1); return 0; } ===========================================================
A shift count exceeding the width of the entity is undefined. Aka, shiftcount >= 32 is undefined. $ gcc -Wall -O2 -c xx.c xx.c: In function #main#: xx.c:4: warning: right shift count >= width of type $ The second time you are tricking the compiler, but its similar. Ciao, Marcus
On Wednesday 20 July 2005 5:57 am, Verdi March wrote:
Hi, the following is compiled in 9.3, glibc-2.3.4-23.4, and gcc-3.3.5-5. The result is: mask=0 mask1=4294967295
I would expect mask = mask1 = 0?
Regards, Verdi
=========================================================== #include <stdio.h>
int main() { unsigned int mask = (unsigned int) -1 >> 32;
int i = 0; unsigned int mask1 = ((unsigned int) -1) >> (32 - i);
printf("mask=%u mask1=%u\n", mask, mask1); return 0; } =========================================================== Marcus' comment that this is an undefined behavior is absolutely correct (ISO C90 6.5.7), so if your code relies on mask1 (or mask) resulting in 0 is probably a bad assumption and the code should be corrected.
Apparently what is happening in the second case is that ((unsigned int) -1) is being changed to a signed int, and the sign bit is getting propagated. BTW: On a 64-bit system (Itanium) the values are both 0. -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
Jerry Feldman <gaf@blu.org> [Wed, 20 Jul 2005 10:29:44 -0400]:
On Wednesday 20 July 2005 5:57 am, Verdi March wrote:
BTW: On a 64-bit system (Itanium) the values are both 0.
Of cause! You'd obviously have to use unsigned int mask = (unsigned int) -1 >> 64; and unsigned int mask1 = ((unsigned int) -1) >> (64 - i); To get the same effect. Just shows why it's a very good idea to always compile with -Wall. Philipp
On Thursday 21 July 2005 4:46 pm, Philipp Thomas wrote:
Jerry Feldman <gaf@blu.org> [Wed, 20 Jul 2005 10:29:44 -0400]:
On Wednesday 20 July 2005 5:57 am, Verdi March wrote:
BTW: On a 64-bit system (Itanium) the values are both 0.
Of cause! You'd obviously have to use
unsigned int mask = (unsigned int) -1 >> 64; and unsigned int mask1 = ((unsigned int) -1) >> (64 - i); True since on a 64-bit system (unsigned int) -1 might be promoted to an unsigned long, but I'm too lazy to look at the promotion rules in the standard right now. -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
participants (4)
-
Jerry Feldman -
Marcus Meissner -
Philipp Thomas -
Verdi March