Shift operators.

[deepak]

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.

 

[Marc Boyer]

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

 

[tomstdenis]

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

 

[Chris Dollin]

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.

 

[Marc Boyer]

What compiler is giving you that output? I know GCC will happily
oblige you with the desired zeroes.

Sure ?
-------------------- shift.c -------------------------
#include <limits.h>
#include <assert.h>
#include <stdio.h>

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

 

[Chris Dollin]

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.

 

[pete]

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.

 

[deepak]

main()
{
int a = 1;
int count ;

printf ("Count:");
scanf ("%d", &count);

printf ("\no/p:%d ", a<<count);
}

/users/dejose->uname
SunOS
4 acura /users/dejose->./a.out
Count:32
o/p:1

 

[Chris Dollin]

Was this (that deepak wrote):

main()
{
int a = 1;
int count ;

printf ("Count:");
scanf ("%d", &count);

printf ("\no/p:%d ", a<<count);
}

/users/dejose->uname
SunOS
4 acura /users/dejose->./a.out
Count:32
o/p:1

Supposed to be an answer to my:

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.]

 

[Tim Prince]

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.