shift right operator

[DeepaK K C]

main()
{
int a =100;
a = a>>32;
printf(" %d", a);
}

it prints "a" as 100 only....but I am expecting a = 0.....
can some one tell me the reason?

bye
Deepak\

 

[Chris Dollin]

main()
{
int a =100;
a = a>>32;
printf(" %d", a);
}

it prints "a" as 100 only....but I am expecting a = 0.....
can some one tell me the reason?

It's a manifestation of undefined behaviour. (Some machines
only have a 5-bit shift count, for example.)

What happens if you turn your compiler warnings up?

 

[David Resnick]

main()
{
int a =100;
a = a>>32;
printf(" %d", a);
}

it prints "a" as 100 only....but I am expecting a = 0.....
can some one tell me the reason?

bye
Deepak\

Fixed version of your program:
#include <stdio.h>
int main(void)
{
int a = 100;
a = a>>32;
printf(" %d\n", a);
return 0;
}

temp(558)$ gcc -Wall -o foo foo.c
foo.c: In function `main':
foo.c:6: warning: right shift count >= width of type
temp(559)$ foo
100

Do you compile with warnings on? Unless int is 64 bits, you
are invoking undefined behavior. Once you do that, what you
get is up to the vagaries of fate, in gcc apparently it does
nothing for shifts >= to the size, at least for the version
I am using. Here is what the standard says:

The integer promotions are performed on each of the
operands. The type of the result is that of the promoted
left operand. If the value of the right operand is negative
or is greater than or equal to the width of the promoted
left operand, the behavior is undefined.

-David

 

[CBFalconer]

main()
{
int a =100;
a = a>>32;
printf(" %d", a);
}

it prints "a" as 100 only....but I am expecting a = 0.....
can some one tell me the reason?

probably because (32 % 32 == 0). Other errors in your program:

int main(void)

main returns an int, say so. If you're not using any arguments,
say so.

failure to #include <stdio.h>

The call to printf is invalid, and leads to undefined behavior.

failure to return anything from main. return 0 needed.

failure to indent properly.

 

[Eric Sosman]

probably because (32 % 32 == 0).

That's just (off-topic) speculation. Chris Dollin
has already provided the correct answer.

Other errors in your program:

int main(void)

main returns an int, say so. If you're not using any arguments,
say so.

failure to #include <stdio.h>

The call to printf is invalid, and leads to undefined behavior.

It's only invalid in the absence of <stdio.h>, so I
think you're double-counting. (And I'm surprised you didn't
note the missing newline; it doesn't lead to U.B. but it's
an error nonetheless.)

failure to return anything from main. return 0 needed.

failure to indent properly.

Oh, come on. How about "uninformative identifiers"
or "inconsistent use of white space" or "lack of comments"
or "failure to use `>>=' when the opportunity arose?"
Not to mention "posting questions on a Wednesday" and
"running afoul of someone who arose on the wrong side
of bed?" Ease up a little.

 

[Peter Nilsson]

It's a manifestation of undefined behaviour. (Some machines
only have a 5-bit shift count, for example.)

More precisely, shifting by the full width of an integer, or
more, invokes undefined behaviour.

A 32-bit shift of a (non-negative) int can be performed in a
conforming way though...

a = a >> 15 >> 15 >> 2;

 

[Christian Bau]

More precisely, shifting by the full width of an integer, or
more, invokes undefined behaviour.

A 32-bit shift of a (non-negative) int can be performed in a
conforming way though...

a = a >> 15 >> 15 >> 2;

Much better to write:

a = (a >> 15) >> 15) >> 2;

Would you bet your life that you got your precedences right? Didn't
think so. Would I bet your life that you get your precedences right?
Absolutely.

 

[Eric Sosman]

[...]
A 32-bit shift of a (non-negative) int can be performed in a
conforming way though...

a = a >> 15 >> 15 >> 2;

Much better to write:

a = (a >> 15) >> 15) >> 2;

Ah, this is obviously some strange use of the phrase
"much better" that I wasn't previously aware of ...

 

[Peter Nilsson]

Much better to write:

a = (a >> 15) >> 15) >> 2;

Goes to show: "If it ain't broken, don't fix it."

Would you bet your life that you got your precedences right?

Yes. Assignment operators have always had lower precedence than
shift operators.

Obviously, you meant association rather than precedence, but even
there, yes! Why? Because in C++ I exploit the same left to right
association of shift operators all the time.

Ironic that C++ should make me a better C programmer, isn't it?

 

[Christian Bau]

[...]
A 32-bit shift of a (non-negative) int can be performed in a
conforming way though...

a = a >> 15 >> 15 >> 2;

Much better to write:

a = (a >> 15) >> 15) >> 2;

Ah, this is obviously some strange use of the phrase
"much better" that I wasn't previously aware of ...

Maintainability. It is obvious to everybody what the intention of the
second version is, and what it does. It is impossible to determine what
the intention of the first version is (without additional comments in
the code), and I really have more important things to remember than
associativity of shift operators.

 

[Keith Thompson]

[...]
A 32-bit shift of a (non-negative) int can be performed in a
conforming way though...

a = a >> 15 >> 15 >> 2;


Much better to write:

a = (a >> 15) >> 15) >> 2;

Ah, this is obviously some strange use of the phrase
"much better" that I wasn't previously aware of ...

Maintainability. It is obvious to everybody what the intention of the
second version is, and what it does. It is impossible to determine what
the intention of the first version is (without additional comments in
the code), and I really have more important things to remember than
associativity of shift operators.

Um, you might want to count the parentheses in the second version.

 

[CBFalconer]

[...]
A 32-bit shift of a (non-negative) int can be performed in a
conforming way though...

a = a >> 15 >> 15 >> 2;

Much better to write:

a = (a >> 15) >> 15) >> 2;

Ah, this is obviously some strange use of the phrase
"much better" that I wasn't previously aware of ...

For any int size up to and including 32 bits, it is considerably
simpler, and even more efficient, to write:

a = 0;

 

[Lawrence Kirby]

On Thu, 17 Feb 2005 00:24:13 +0000, Christian Bau wrote:

....

Maintainability. It is obvious to everybody what the intention of the
second version is, and what it does. It is impossible to determine what
the intention of the first version is (without additional comments in
the code), and I really have more important things to remember than
associativity of shift operators.

I don't bother to remember all the precedence levels but associativity is
easy: all operators are left associative except unary, ternary and
assignment operators which are all right associative (according to the K&R
model). The only oddity is the function call operator which doesn't have a
fixed arity. That is left associative and still fits reasonably in the
rule (it isn't specifically a unary or ternary operator).

Lawrence