On 32 bit linux with gcc 4.2 I get unexpected results with this code:
main()
{
int bits = 32;
printf("%d\n",(int)1 << (int)32);
printf("%d\n",(int)1 << bits);
}
The first printf gives a result of 0, the second gives 1. I checked
with sizeof() and ints are definately 32 bits in size.
I'm sure I'm missing something obvious but can someone tell me what?
Thanks
B2003 9 2237
Boltar wrote:
On 32 bit linux with gcc 4.2 I get unexpected results with this code:
main()
{
int bits = 32;
printf("%d\n",(int)1 << (int)32);
printf("%d\n",(int)1 << bits);
}
The first printf gives a result of 0, the second gives 1. I checked
with sizeof() and ints are definately 32 bits in size.
I'm sure I'm missing something obvious but can someone tell me what?
Thanks
B2003
When I compile tyour code with lcc-win I get:
Warning tshift.c: 2 no type specified. Defaulting to int
The prototype for main is:
int main(void)
Warning tshift.c: 5 missing prototype for printf
You did not include <stdio.h>
Warning tshift.c: 5 shift by 32 is undefined
The number of bits shifted is greater than sizeof(int)*CHAR_BIT
This is undefined!
The result of running the program is:
16777216
1
If I turn optimizations ON I get:
16777216
1024
The result of shifting more than sizeof(int)*CHAR_BIT positions
is NOT defined by the language. It is an illegal expression.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
Boltar wrote:
On 30 Mar, 21:37, jacob navia <ja...@nospam.comwrote:
>The result of shifting more than sizeof(int)*CHAR_BIT positions is NOT defined by the language. It is an illegal expression.
It isn't? Thats bloody annoying since that means i'll have to do a
specific check for the bit shift count being than the size of the
type being shifted.
Actually, you need to check for >=, not just >. And
with signed integers, you need to be sure the value being
shifted is non-negative and small enough that no 1's are
propagated into the sign position.
--
Eric Sosman es*****@ieee-dot-org.invalid
"jacob navia" <ja***@nospam.comwrote in message
news:fs**********@aioe.org...
Boltar wrote:
>On 32 bit linux with gcc 4.2 I get unexpected results with this code:
main() { int bits = 32; printf("%d\n",(int)1 << (int)32); printf("%d\n",(int)1 << bits); }
The first printf gives a result of 0, the second gives 1. I checked with sizeof() and ints are definately 32 bits in size.
I'm sure I'm missing something obvious but can someone tell me what?
When I compile tyour code with lcc-win I get:
Warning tshift.c: 5 shift by 32 is undefined
The number of bits shifted is greater than sizeof(int)*CHAR_BIT
This is undefined!
OK, but the following code from lccwin does not appear to set up the shift
count in cl register. So you don't even attempt to shift by 32, but by an
unknown value in cl (presumably 24)?
; 6 printf("%d\n",(int)1 << (int)32);
.line 6
movl $1,%edi
movl $32,%esi
sall %cl,%edi
On the x86 at least, shifting a 32-bit register left by 32 is anyway a
no-operation (the register is unchanged).
So the OP should not rely on 32+ bit left-shifts working as he expects.
--
Bart
Bartc wrote:
OK, but the following code from lccwin does not appear to set up the shift
count in cl register. So you don't even attempt to shift by 32, but by an
unknown value in cl (presumably 24)?
; 6 printf("%d\n",(int)1 << (int)32);
.line 6
movl $1,%edi
movl $32,%esi
sall %cl,%edi
On the x86 at least, shifting a 32-bit register left by 32 is anyway a
no-operation (the register is unchanged).
So the OP should not rely on 32+ bit left-shifts working as he expects.
Surely not. Things go as follows:
lcc-win discovers that we have a shift operation with
two immediate constants. This should be done at
compile time to make the generated program more efficient.
Then it discovers that one of the constants is too big
and generates a warning. Apparently, when making this
optimizations it doesn't set cl.
If you change the program to
5 printf("%d\n",(int)1 << (int)31);
.line 5
pushl $-2147483648 // Shift done at compile time
pushl $_$2
call _printf
addl $8,%esp
You see?
Now, it can be argued that this is a bug. True.
I have changed this now so that it will do the shift at compile time,
returning whatever the result is at compile time (1) anyway.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
Boltar <bo********@yahoo.co.ukwrote:
On 32 bit linux with gcc 4.2 I get unexpected results with this code:
main()
{
int bits = 32;
printf("%d\n",(int)1 << (int)32);
printf("%d\n",(int)1 << bits);
}
The first printf gives a result of 0, the second gives 1. I checked
with sizeof() and ints are definately 32 bits in size.
I'm sure I'm missing something obvious but can someone tell me what?
That the shift count must be *less than* the number of bits in the
operand or you get undefined behavior.
-Larry Jones
Please tell me I'm adopted. -- Calvin
Boltar <bo********@yahoo.co.ukwrote:
>
It isn't? Thats bloody annoying since that means i'll have to do a
specific check for the bit shift count being than the size of the
type being shifted.
The theory is it's better to have to have an explicit check for the
relatively small amount of code that needs it than to have the compiler
always generate for the vast majority of code that doesn't need it.
-Larry Jones
OK, what's the NEXT amendment say? I know it's in here someplace. -- Calvin
Bartc <bc@freeuk.comwrote:
>
On the x86 at least, shifting a 32-bit register left by 32 is anyway a
no-operation (the register is unchanged).
On the contrary, different processors in the x86 family behave
differently. Some only look at the bottom 5 bits of the count (so a
shift count of 32 is interpreted as 0 and 33 as 1) but others look at
the entire value (so a shift count of 32 or greater zeros the register).
-Larry Jones
You're just trying to get RID of me, aren't you? -- Calvin
>OK, but the following code from lccwin does not appear to set up the shift
>count in cl register. So you don't even attempt to shift by 32, but by an unknown value in cl (presumably 24)?
; 6 printf("%d\n",(int)1 << (int)32); .line 6 movl $1,%edi movl $32,%esi sall %cl,%edi
On the x86 at least, shifting a 32-bit register left by 32 is anyway a no-operation (the register is unchanged).
So the OP should not rely on 32+ bit left-shifts working as he expects. Surely not. Things go as follows:
lcc-win discovers that we have a shift operation with two immediate constants. This should be done at compile time to make the generated program more efficient.
Then it discovers that one of the constants is too big and generates a warning. Apparently, when making this optimizations it doesn't set cl.
This is not a bug. 1 << 32 invokes the wrath of undefined behavior.
Since no possible answers are wrong, you might as well get one
quickly, even if it's random crap.
>If you change the program to
5 printf("%d\n",(int)1 << (int)31);
.line 5
pushl $-2147483648 // Shift done at compile time
pushl $_$2
call _printf
addl $8,%esp
You see?
Now, it can be argued that this is a bug. True.
I'll argue that the wording of the error message is a
quality-of-implementation issue.
>I have changed this now so that it will do the shift at compile time, returning whatever the result is at compile time (1) anyway.
jacob navia:
The number of bits shifted is greater than sizeof(int)*CHAR_BIT
This is undefined!
Don't forget about systems that have padding bits within their integer
types. On such systems, sizeof(some int type)*CHAR_BIT will yield a
value which is larger than the amount of value representational bits
in that type. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics |
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...
|
by: vj |
last post by:
Hello group,
I am working on a compression tool and saw this puzzling bit shit
behaviour on a VC++6.0 compiler.
#include <iostream>
using namespace std;
typedef unsigned char uchar;
#define...
|
by: richard_l |
last post by:
Hello All,
I am writing an application which receives a word which is a bitmap. I
have created a word typedef which contains a bitfield defining each
bit. however, I was wondering however if it...
|
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;
|
by: Charles Sullivan |
last post by:
I understand different processor hardware may store the bits in a
byte in different order. Does it make a difference in C insofar
as bit-shifting unsigned char variables is concerned?
E.g, if I...
| |
by: Dave |
last post by:
Hi guys,
I have just set up a duplicate server running:
apache 2.54, mysql 5.04 and php 5.04
This is the same setup as as the server we are using now, apart from
the hardware inside. I have...
|
by: lak |
last post by:
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
|
by: Madhur |
last post by:
I would like to know the best efficient way to shift a flat buffer by
say 4bits.
for exaple if the flat buffer is
0x62 0x48 0x23 ....
then the result should be
0x06 0x24 0x82 0x3.....
|
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...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
| |
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| |
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| |