473,320 Members | 2,193 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

about shifting

lak
i know left and right shift normally,but i cant know what happens if
it is negative.
for example
int x=-2;
x<<=1;//what happens here

Sep 20 '07 #1
16 1519
lak wrote:
i know left and right shift normally,but i cant know what happens if
it is negative.
for example
int x=-2;
x<<=1;//what happens here
nothing different from usual.. the bit representation of -2 is shifted
one bit to the left...
cat test_shift.c
#include <stdio.h>
int main(void)
{

int k = -1;
printf("k is %d (%x)\n", k, k);
k<<=4;
printf("k is %d (%x)\n", k, k);

return (0);
}
gcc -Wall -o test_shift test_shift.c && ./test_shift
k is -1 (ffffffff)
k is -16 (fffffff0)

Pietro Cerutti
Sep 20 '07 #2
lak <la********@gmail.comwrote:
i know left and right shift normally,but i cant know what happens if
it is negative.
for example
int x=-2;
x<<=1;//what happens here
That is correct: you cannot know that.

From paragraph 6.5.7 in the ISO C Standard:

# 4 The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated
# bits are filled with zeros. If E1 has an unsigned type, the value of
# the result is E1 x 2 E2 ,reduced modulo one more than the maximum
# value representable in the result type. If E1 has a signed type and
# nonnegative value, and E1 x 2 E2 is representable in the result
# type, then that is the resulting value; otherwise, the behavior is
# undefined. ^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^

Note the under^^^lined bit. Since in your case x is neither an unsigned
integer, nor a signed integer with a positive value, the behaviour of
your code is undefined; and this means that, as far as ISO C is
concerned, you cannot know what happens. (It may be possible to discover
what happens on a particular computer using a particular compiler with
particular compilation settings, but I advise against it; on the next
system, or even on the next level of optimisation, the result can easily
be different.)

Richard
Sep 20 '07 #3
"Richard Bos" <rl*@hoekstra-uitgeverij.nla écrit dans le message de news:
46*****************@news.xs4all.nl...
lak <la********@gmail.comwrote:
>i know left and right shift normally,but i cant know what happens if
it is negative.
for example
int x=-2;
x<<=1;//what happens here

That is correct: you cannot know that.

From paragraph 6.5.7 in the ISO C Standard:

# 4 The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated
# bits are filled with zeros. If E1 has an unsigned type, the value of
# the result is E1 x 2 E2 ,reduced modulo one more than the maximum
# value representable in the result type. If E1 has a signed type and
# nonnegative value, and E1 x 2 E2 is representable in the result
# type, then that is the resulting value; otherwise, the behavior is
# undefined. ^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^

Note the under^^^lined bit. Since in your case x is neither an unsigned
integer, nor a signed integer with a positive value, the behaviour of
your code is undefined; and this means that, as far as ISO C is
concerned, you cannot know what happens. (It may be possible to discover
what happens on a particular computer using a particular compiler with
particular compilation settings, but I advise against it; on the next
system, or even on the next level of optimisation, the result can easily
be different.)
Richard is correct.
However, if you expected x <<= 1 to be equivalent to x += x, as would
"normally" be the case on regular 2s-complement machines, you might as well
write the latter.

--
Chqrlie.
Sep 20 '07 #4
Pietro Cerutti wrote:
lak wrote:
>i know left and right shift normally,but i cant know what happens if
it is negative.
for example
int x=-2;
x<<=1;//what happens here

nothing different from usual.. the bit representation of -2 is shifted
one bit to the left...
Umh, I have to apologize.. my sentence is actually incorrect. That's
true for right-shifting, while for left-shifting a negative left-hand
operand invokes UB

--
Pietro Cerutti
Sep 20 '07 #5
Pietro Cerutti wrote, On 20/09/07 14:45:
Pietro Cerutti wrote:
>lak wrote:
>>i know left and right shift normally,but i cant know what happens if
it is negative.
for example
int x=-2;
x<<=1;//what happens here
nothing different from usual.. the bit representation of -2 is shifted
one bit to the left...

Umh, I have to apologize.. my sentence is actually incorrect. That's
true for right-shifting, while for left-shifting a negative left-hand
operand invokes UB
For right shifting it is implementation defined, so you were just wrong.
--
Flash Gordon
Sep 20 '07 #6
Charlie Gordon wrote, On 20/09/07 13:51:
"Richard Bos" <rl*@hoekstra-uitgeverij.nla écrit dans le message de news:
46*****************@news.xs4all.nl...
>lak <la********@gmail.comwrote:
>>i know left and right shift normally,but i cant know what happens if
it is negative.
for example
int x=-2;
x<<=1;//what happens here
That is correct: you cannot know that.
<snip>
Richard is correct.
However, if you expected x <<= 1 to be equivalent to x += x, as would
"normally" be the case on regular 2s-complement machines, you might as well
write the latter.
Personally I would write it as x *= 2.
--
Flash Gordon
Sep 20 '07 #7
Charlie Gordon wrote:
[... bit-shifting negative numbers ...]
However, if you expected x <<= 1 to be equivalent to x += x, as would
"normally" be the case on regular 2s-complement machines, you might
as well write the latter.
Okay, nit-pick time related to UB.

Why doesn't the statement:

x += x;

violate 6.5p2:

Between the previous and next sequence point an object shall
have its stored value modified at most once by the evaluation
of an expression. Furthermore, the prior value shall be read
only to determine the value to be stored.

Yes, I see that footnote 71 says that "i = i + 1" is allowed by the
paragraph, but why is the "x" on the right of "+=" not violating the
"shall be read only to determine the value to be stored"? How is
this different from "y = x + x++;" in the use of "x"?

Obviously, something like "x += x;" must be allowed, but what is it
about 6.5p2 that allows it?

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>
Sep 20 '07 #8
Pietro Cerutti wrote:
Pietro Cerutti wrote:
>lak wrote:
>>i know left and right shift normally,but i cant know what
happens if it is negative. for example
int x=-2;
x<<=1;//what happens here

nothing different from usual.. the bit representation of -2 is
shifted one bit to the left...

Umh, I have to apologize.. my sentence is actually incorrect.
That's true for right-shifting, while for left-shifting a
negative left-hand operand invokes UB
Since lak appears to be a newbie, explain that UB means "undefined
behaviour". In other words, don't do that. Also for positive
operands that overflow.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Sep 20 '07 #9
On Sep 20, 10:33 am, Kenneth Brody <kenbr...@spamcop.netwrote:
Charlie Gordon wrote:

[... bit-shifting negative numbers ...]
However, if you expected x <<= 1 to be equivalent to x += x, as would
"normally" be the case on regular 2s-complement machines, you might
as well write the latter.

Okay, nit-pick time related to UB.

Why doesn't the statement:

x += x;

violate 6.5p2:

Between the previous and next sequence point an object shall
have its stored value modified at most once by the evaluation
of an expression. Furthermore, the prior value shall be read
only to determine the value to be stored.

Yes, I see that footnote 71 says that "i = i + 1" is allowed by the
paragraph, but why is the "x" on the right of "+=" not violating the
"shall be read only to determine the value to be stored"? How is
this different from "y = x + x++;" in the use of "x"?

Obviously, something like "x += x;" must be allowed, but what is it
about 6.5p2 that allows it?
"Furthermore, the prior value shall be read only to determine the
value to be stored."

Quite frankly, in this case, I simply don't see how it would be
possible for the compiler to get it wrong.

For an instance like:

i = ++i;

there are two modifications of i, so it's right out.

But how is:
x += x;
more dangerous than (for instance):
x = x;
Both of which have to examine the contents of x use those contents to
modify x (though this second instance can be thrown out by the
compiler if it chooses because of the 'as if' rule.)

For the instance of:
y = x + x++;
We don't even need the y. This is also undefined behavior:

#include <stdlib.h>
int t(void)
{
int x = rand();
return x + x++;
}

We are adding x + <something>
We are also incrementing x.
There is no sequence point.

Sep 20 '07 #10
"Kenneth Brody" <ke******@spamcop.neta écrit dans le message de news:
46***************@spamcop.net...
Charlie Gordon wrote:
[... bit-shifting negative numbers ...]
>However, if you expected x <<= 1 to be equivalent to x += x, as would
"normally" be the case on regular 2s-complement machines, you might
as well write the latter.

Okay, nit-pick time related to UB.

Why doesn't the statement:

x += x;

violate 6.5p2:

Between the previous and next sequence point an object shall
have its stored value modified at most once by the evaluation
of an expression. Furthermore, the prior value shall be read
only to determine the value to be stored.

Yes, I see that footnote 71 says that "i = i + 1" is allowed by the
paragraph, but why is the "x" on the right of "+=" not violating the
"shall be read only to determine the value to be stored"? How is
this different from "y = x + x++;" in the use of "x"?

Obviously, something like "x += x;" must be allowed, but what is it
about 6.5p2 that allows it?
x is modified only once, and its value is read only to determine the value
to be stored, once or twice depending on quality of implementation or
presence of volatile qualifier on x's definition.

Change x <<= N into x *= 1 << N to get rid of the problem with negative x,
as long as the multiplication does not overflow. Also note that *all*
current architectures use two's complement representation for integers, and
implement left shifting on negative numbers consistently.

--
Chqrlie.
Sep 20 '07 #11
Richard Bos wrote:
lak <la********@gmail.comwrote:
>i know left and right shift normally,but i cant know what happens if
it is negative.
for example
int x=-2;
x<<=1;//what happens here

That is correct: you cannot know that.

From paragraph 6.5.7 in the ISO C Standard:

# 4 The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated
# bits are filled with zeros. If E1 has an unsigned type, the value of
# the result is E1 x 2 E2 ,reduced modulo one more than the maximum
# value representable in the result type. If E1 has a signed type and
# nonnegative value, and E1 x 2 E2 is representable in the result
# type, then that is the resulting value; otherwise, the behavior is
# undefined. ^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^

Note the under^^^lined bit. Since in your case x is neither an unsigned
integer, nor a signed integer with a positive value, the behaviour of
your code is undefined; and this means that, as far as ISO C is
concerned, you cannot know what happens. (It may be possible to discover
what happens on a particular computer using a particular compiler with
particular compilation settings, but I advise against it; on the next
system, or even on the next level of optimisation, the result can easily
be different.)

Richard
I am afraid I don't understand shifts anymore. I suppose(d) that on
32-bit machine
insigned x, y;
y = 32U; //where the compiler doesn't see it
(x<<y)==0U && (x>>y)==0U
All ARM compilers I've seen, the effective calculation is
x << (y & 31U) and x << (y & 31U)
(because that's how the CPU instructions work)
Is this compliant?

-- Ark
Sep 21 '07 #12
"Ark Khasin" <ak*****@macroexpressions.coma écrit dans le message de news:
4sEIi.6556$Yb2.2730@trndny08...
Richard Bos wrote:
>lak <la********@gmail.comwrote:
>>i know left and right shift normally,but i cant know what happens if
it is negative.
for example
int x=-2;
x<<=1;//what happens here

That is correct: you cannot know that. From paragraph 6.5.7 in the ISO C
Standard:

# 4 The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated
# bits are filled with zeros. If E1 has an unsigned type, the value of
# the result is E1 x 2 E2 ,reduced modulo one more than the maximum
# value representable in the result type. If E1 has a signed type and
# nonnegative value, and E1 x 2 E2 is representable in the result
# type, then that is the resulting value; otherwise, the behavior is
# undefined. ^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^

Note the under^^^lined bit. Since in your case x is neither an unsigned
integer, nor a signed integer with a positive value, the behaviour of
your code is undefined; and this means that, as far as ISO C is
concerned, you cannot know what happens. (It may be possible to discover
what happens on a particular computer using a particular compiler with
particular compilation settings, but I advise against it; on the next
system, or even on the next level of optimisation, the result can easily
be different.)

Richard
I am afraid I don't understand shifts anymore. I suppose(d) that on 32-bit
machine
insigned x, y;
y = 32U; //where the compiler doesn't see it
(x<<y)==0U && (x>>y)==0U
All ARM compilers I've seen, the effective calculation is
x << (y & 31U) and x << (y & 31U)
(because that's how the CPU instructions work)

Is this compliant?
C99 6.5.7p3 also says: 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. So shifting a 32-bit integer by 32 invokes undefined
behaviour. That covers any harware behaviour whatsoever.

If you really want that, you need to split the operation:
(x << 16) << 16 == 0 && (x >16) >16 == 0

--
Chqrlie.
Sep 21 '07 #13
Charlie Gordon wrote:
"Ark Khasin" <ak*****@macroexpressions.coma écrit dans le message de news:
4sEIi.6556$Yb2.2730@trndny08...
>Richard Bos wrote:
>>lak <la********@gmail.comwrote:

i know left and right shift normally,but i cant know what happens if
it is negative.
for example
int x=-2;
x<<=1;//what happens here
That is correct: you cannot know that. From paragraph 6.5.7 in the ISO C
Standard:

# 4 The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated
# bits are filled with zeros. If E1 has an unsigned type, the valueof
# the result is E1 x 2 E2 ,reduced modulo one more than the maximum
# value representable in the result type. If E1 has a signed type and
# nonnegative value, and E1 x 2 E2 is representable in the result
# type, then that is the resulting value; otherwise, the behavior is
# undefined. ^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^

Note the under^^^lined bit. Since in your case x is neither an unsigned
integer, nor a signed integer with a positive value, the behaviour of
your code is undefined; and this means that, as far as ISO C is
concerned, you cannot know what happens. (It may be possible to discover
what happens on a particular computer using a particular compiler with
particular compilation settings, but I advise against it; on the next
system, or even on the next level of optimisation, the result can easily
be different.)

Richard
I am afraid I don't understand shifts anymore. I suppose(d) that on 32-bit
machine
insigned x, y;
y = 32U; //where the compiler doesn't see it
(x<<y)==0U && (x>>y)==0U
All ARM compilers I've seen, the effective calculation is
x << (y & 31U) and x << (y & 31U)
(because that's how the CPU instructions work)

Is this compliant?
C99 6.5.7p3 also says: 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. So shifting a 32-bit integer by 32 invokes undefined
behaviour. That covers any harware behaviour whatsoever.

If you really want that, you need to split the operation:
(x << 16) << 16 == 0 && (x >16) >16 == 0
Thanks. I should have known better indeed.
-- Ark

Sep 21 '07 #14
On Thu, 20 Sep 2007 13:33:21 -0400, Kenneth Brody wrote:
Why doesn't the statement:

x += x;

violate 6.5p2:

Between the previous and next sequence point an object shall
have its stored value modified at most once by the evaluation
of an expression. Furthermore, the prior value shall be read
only to determine the value to be stored.

Yes, I see that footnote 71 says that "i = i + 1" is allowed by the
paragraph, but why is the "x" on the right of "+=" not violating the
"shall be read only to determine the value to be stored"? How is
this different from "y = x + x++;" in the use of "x"?

Obviously, something like "x += x;" must be allowed, but what is it
about 6.5p2 that allows it?
x is modified only once, and it is only read to determine the
value to be stored. Right? I think the last sentence in that quote
is very mysterious. There have been endless discussions about
whether list = list->next = malloc(sizeof *list) causes UB. And a
sufficiently bizarre interpretation of that sentence would mean
that
x = 0 * x + rand() causes UB, and
x = 1 * x + abs(0) doesn't. I definitely think that this isn't the
intent. Anyway, I've developed a paranoia of not using the same
lvalue twice in an expression, e.g. I'd rather write i *= -1 than
i = -i, or u ^= UINT_MAX than u = ~u. (At least this helps to
write macros which evaluate its argument exactly once, but is it
*really* necessary when written directly in the code?)

--
Army1987 (Replace "NOSPAM" with "email")
If you're sending e-mail from a Windows machine, turn off Microsoft's
stupid “Smart Quotes†feature. This is so you'll avoid sprinkling garbage
characters through your mail. -- Eric S. Raymond and Rick Moen

Sep 21 '07 #15
Kenneth Brody <ke******@spamcop.netwrites:
Charlie Gordon wrote:
[... bit-shifting negative numbers ...]
>However, if you expected x <<= 1 to be equivalent to x += x, as would
"normally" be the case on regular 2s-complement machines, you might
as well write the latter.

Okay, nit-pick time related to UB.

Why doesn't the statement:

x += x;

violate 6.5p2:

Between the previous and next sequence point an object shall
have its stored value modified at most once by the evaluation
of an expression. Furthermore, the prior value shall be read
only to determine the value to be stored.

Yes, I see that footnote 71 says that "i = i + 1" is allowed by the
paragraph, but why is the "x" on the right of "+=" not violating the
"shall be read only to determine the value to be stored"? How is
this different from "y = x + x++;" in the use of "x"?
Why 'x += x;' is OK has been answered, but why 'y = x + x++;' is not
might need a bit more discussion. Here, the prior value is read to
determine both the value to be stored in x and the value of x for the
addition. The term "read" is important. If the standard had said
"used" then 'y = 1 + x++;' would be UB (x's prior value is used for a
purpose other than to determine the value to be stored).

The prohibition is on more than one part of the expression referring
to the value of an object whose value the expression modifies. I
doubt that that wording is any clearer (or I am sure the committee
would have used it) but it gives another way to look at it.

--
Ben.
Sep 21 '07 #16
lak wrote:
i know left and right shift normally,but i cant know what happens if
it is negative.
for example
int x=-2;
x<<=1;//what happens here

A simple rule of thumb, is to do bitwise operations on unsigned types.
--
Tor <torust [at] online [dot] no>
Sep 21 '07 #17

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

6
by: David Stockwell | last post by:
Hi, My background is c/c++ and java. I'm learning python at this point. My question is does python share java's peculiar mode of bit shifting, or does python adhere closer to c's bit shifting?...
77
by: nospam | last post by:
Reasons for a 3-tier achitecture for the WEB? (NOTE: I said, WEB, NOT WINDOWS. DON'T shoot your mouth off if you don't understand the difference.) I hear only one reason and that's to switch a...
3
by: Joe C | last post by:
I have some code that performs bitwise operations on files. I'm trying to make the code portable on different endian systems. This is not work/school related...just trying to learn/understand. ...
9
by: GGG | last post by:
Noticed something odd in the way bit shifting was working today. As far as I have ever heard, shifting will shift in zeros(signed ints aside) However I foudn something odd when I am shifting...
2
by: jagivens | last post by:
Hi, I have two identical programs that encrypt characters. One is written in C++, and it works, but the other one is written in C, and it does not work. I have copied the code below. There is...
2
by: salsipius | last post by:
Can someone please help me clarify the below code. I think the shifting has to do with converting datatypes and/or loss of data but am not really clear on the details, could you help shed some...
10
by: chanma | last post by:
code1:var x=0xf0000000; alert(x); output:4026531840 code2:var b=0xf<<28; alert(b); output:-268435456
10
by: krunalb | last post by:
Hi, I am trying to shift unsigned long long value by 64 bits and this is what i get #include <stdio.h> int main() { unsigned short shiftby= 64;
12
by: Boltar | last post by:
I seem to be having yet more wierd issue with bit shifting. It seems the following code doesnt do anything under gcc (ie it returns -1 as both results). Anyone know why? Is it another language...
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
0
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.