446,191 Members | 787 Online
Need help? Post your question and get tips & solutions from a community of 446,191 IT Pros & Developers. It's quick & easy.

Shift operators.

 P: n/a If i'm shifting an integer 'n' times where n > sizeof(int), It's giving the same value as that of n-sizeof(n). Why is it behaving like this. I studied that the bit 'll be replaced by '0'. Example; int i = 1; printf ("%d\n", i<<32); o/p: 1. int i = 2; printf ("%d\n", i<<33); o/p: 2. Jun 14 '06 #1
9 Replies

 P: n/a deepak wrote: If i'm shifting an integer 'n' times where n > sizeof(int), It's giving the same value as that of n-sizeof(n). Why is it behaving like this. I studied that the bit 'll be replaced by '0'. Example; int i = 1; printf ("%d\n", i<<32); o/p: 1. int i = 2; printf ("%d\n", i<<33); o/p: 2. What compiler is giving you that output? I know GCC will happily oblige you with the desired zeroes. Tom Jun 14 '06 #2

 P: n/a Le 14-06-2006, deepak a écrit*: If i'm shifting an integer 'n' times where n > sizeof(int), It's giving the same value as that of n-sizeof(n). Why is it behaving like this. I studied that the bit 'll be replaced by '0'. Yes, shifting for more than the type size is an undefined behavior. I don't know why, but that is. Marc Boyer Jun 14 '06 #3

 P: n/a deepak wrote: If i'm shifting an integer 'n' times where n > sizeof(int), It's giving the same value as that of n-sizeof(n). Why is it behaving like this. Because it's allowed to, and its efficient on your implementation. If the shift amount isn't in the range 0..bitswidthOfPromotedLeftOperand-1, the result is undefined. I suspect your implementation's machine only looks at the low 5 bits of the shift amount. -- Chris "it's as daft as a brush" Dollin "Reaching out for mirrors hidden in the web." - Renaissance, /Running Hard/ Jun 14 '06 #4

 P: n/a Le 14-06-2006, to********@gmail.com a écrit*: deepak wrote: If i'm shifting an integer 'n' times where n > sizeof(int), It's giving the same value as that of n-sizeof(n). Why is it behaving like this. I studied that the bit 'll be replaced by '0'. Example; int i = 1; printf ("%d\n", i<<32); o/p: 1. int i = 2; printf ("%d\n", i<<33); o/p: 2. What compiler is giving you that output? I know GCC will happily oblige you with the desired zeroes. Sure ? -------------------- shift.c ------------------------- #include #include #include int main() { assert( sizeof(int) == 4 && CHAR_BIT == 8 ); unsigned int taille = 32; unsigned int r1 = 1u << taille; printf("** %u\n", r1); unsigned int r2 = 1u << 32; printf("** %u\n", r2); return 0; } -------------------- shift.c ------------------------- Run on a sparc pogo% uname -a SunOS pogo 5.9 Generic_118558-06 sun4u sparc SUNW,Sun-Blade-1000 pogo% gcc -v gcc version 3.4.5 pogo% gcc shift.c ; ./a.out shift.c: In function `main': shift.c:10: warning: left shift count >= width of type ** 1 ** 1 Run on intel ubu> uname -a Linux ubu 2.6.12-10-386 #1 Mon Feb 13 12:13:15 UTC 2006 i686 GNU/Linux ubu> gcc -v version gcc 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9) ubu> gcc shift.c ; ./a.out shift.c: In function 'main': shift.c:10: warning: left shift count >= width of type ** 1 ** 0 Marc Boyer Jun 14 '06 #5

 P: n/a Marc Boyer wrote: Le 14-06-2006, deepak a Ã©critÂ*: If i'm shifting an integer 'n' times where n > sizeof(int), It's giving the same value as that of n-sizeof(n). Why is it behaving like this. I studied that the bit 'll be replaced by '0'. Yes, shifting for more than the type size is an undefined behavior. I don't know why, but that is. Because the behaviour of the underlying machine shift instructions differs in these circumstances, and so rather than mandating some result and penalising machines with a different result, C allows the use of the presumably-efficient instructions and doesn't define what happens outside the "sensible" range. -- Chris "not my choice" Dollin "I'm still here and I'm holding the answers" - Karnataka, /Love and Affection/ Jun 14 '06 #6

 P: n/a Marc Boyer wrote: Yes, shifting for more than the type size is an undefined behavior. Shifting for greater than or equal to type width, is undefined behavior. -- pete Jun 14 '06 #7

 P: n/a main() { int a = 1; int count ; printf ("Count:"); scanf ("%d", &count); printf ("\no/p:%d ", a<uname SunOS 4 acura /users/dejose->./a.out Count:32 o/p:1 Chris Dollin wrote: deepak wrote: If i'm shifting an integer 'n' times where n > sizeof(int), It's giving the same value as that of n-sizeof(n). Why is it behaving like this. Because it's allowed to, and its efficient on your implementation. If the shift amount isn't in the range 0..bitswidthOfPromotedLeftOperand-1, the result is undefined. I suspect your implementation's machine only looks at the low 5 bits of the shift amount. -- Chris "it's as daft as a brush" Dollin "Reaching out for mirrors hidden in the web." - Renaissance, /Running Hard/ Jun 14 '06 #8

 P: n/a Was this (that deepak wrote): main() { int a = 1; int count ; printf ("Count:"); scanf ("%d", &count); printf ("\no/p:%d ", a<uname SunOS 4 acura /users/dejose->./a.out Count:32 o/p:1 Supposed to be an answer to my: I suspect your implementation's machine only looks at the low 5 bits of the shift amount. Because, if so, don't be so unkind as to top post, and actually /say/ something about the relationship. [It appears to me that your code/output is consistent with my hypothesis.] -- Chris "seeker" Dollin A rock is not a fact. A rock is a rock. Jun 14 '06 #9

 P: n/a Marc Boyer wrote: Le 14-06-2006, deepak a écrit : If i'm shifting an integer 'n' times where n > sizeof(int), It's giving the same value as that of n-sizeof(n). Why is it behaving like this. I studied that the bit 'll be replaced by '0'. Yes, shifting for more than the type size is an undefined behavior. I don't know why, but that is. The compiler is obliged only to supply code which works where the behavior is defined. The reason for the bigger shifts being undefined is that the effect of the simple instruction sequence varies between hardware implementations. It's likely the OP has found hardware where the shifter in effect masks off the high order out-of-range bits. Jun 14 '06 #10