A Chess forum. ChessBanter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » ChessBanter forum » Chess Newsgroups » rec.games.chess.computer (Computer Chess)
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

Horrible Visual C Bug!



 
 
Thread Tools Display Modes
  #1  
Old July 20th 03, 07:14 PM
Oliver Brausch
external usenet poster
 
Posts: n/a
Default Horrible Visual C Bug!

Hello,

have you ever heard about this MS-visual c compiler bug?
look at the small prog:


static int x=0;
int bit32() {
return ++x;
}

int bit64() {
return bit32() + (bit32() 1);
}

void main(int argc, char **argv) {
int i;
for (i = 0; i 5; i++) printf("%d. %d\n", i, bit64());
}


Ok, the (correct) result is:

0. 2
1. 8
2. 14
3. 20
4. 26

This is what every compiled progam says. Inclusive MSVisualC Compiler
with Debug options or /Ot fast-option.

But do not dare to switch to the the /O2 option of MSVisualC Compiler.
Then once your computer cannot calculate anymo

0. 1
1. 7
2. 13
3. 19
4. 25

So, up to Microsoft, 0 + 2 = 1 ?????. That's why their OS is so stable....
Try to increase the " 1". It even gets worse.

Ever seen this? I costed me hours of debugging. Can I
sue Microsoft for this?

- Oliver Brausch

http://home.arcor.de/dreamlike
  #2  
Old July 20th 03, 07:23 PM
Jakob Bieling
external usenet poster
 
Posts: n/a
Default Horrible Visual C Bug!

"Oliver Brausch" wrote in message
m...

have you ever heard about this MS-visual c compiler bug?
look at the small prog:


It is not a compiler bug. It is a bug in your code.

static int x=0;
int bit32() {
return ++x;
}

int bit64() {
return bit32() + (bit32() 1);
}


You try to change a variable twice, which is invalid, ie. undefined
behaviour. Microsoft's compiler is absolutely right.

void main(int argc, char **argv) {


'void main' is illegal. It is *always* 'int main'.

int i;
for (i = 0; i 5; i++) printf("%d. %d\n", i, bit64());
}


This is what every compiled progam says. Inclusive MSVisualC Compiler
with Debug options or /Ot fast-option.


So? Just because many compiled programs say this should be the result
does not mean that they are right.

Ever seen this? I costed me hours of debugging. Can I
sue Microsoft for this?


No, but your boss could fire you for such C code, since it is invalid.
--
jb

(replace y with x if you want to reply by e-mail)


  #3  
Old July 20th 03, 07:28 PM
Joona I Palaste
external usenet poster
 
Posts: n/a
Default Horrible Visual C Bug!

Oliver Brausch scribbled the following
on comp.lang.c:
Hello,


have you ever heard about this MS-visual c compiler bug?
look at the small prog:



static int x=0;
int bit32() {
return ++x;
}


int bit64() {
return bit32() + (bit32() 1);


These two bit32() calls can be evaluated in either order, and the
implementation doesn't even have to be consistent about it.

Assume x==0. The first way:
bit32() + (bit32() 1) ==
1 + (bit32() 1) ==
1 + (2 1) ==
1 + (4) ==
5
The second way:
bit32() + (1 1) ==
bit32() + (2) ==
2 + (2) ==
4

}


void main(int argc, char **argv) {


You have induced undefined behaviour by using void main() and lost all
right to expect any kind of specific behaviour at all.

int i;
for (i = 0; i 5; i++) printf("%d. %d\n", i, bit64());
}



Ok, the (correct) result is:


Anything. Any result is correct, because of the void main().

0. 2
1. 8
2. 14
3. 20
4. 26


This is what every compiled progam says. Inclusive MSVisualC Compiler
with Debug options or /Ot fast-option.


But do not dare to switch to the the /O2 option of MSVisualC Compiler.
Then once your computer cannot calculate anymo


0. 1
1. 7
2. 13
3. 19
4. 25


You'll have to read up on undefined behaviour (void main()) and
unspecified behaviour (bit32() + (bit32() 1)).

So, up to Microsoft, 0 + 2 = 1 ?????. That's why their OS is so stable....
Try to increase the " 1". It even gets worse.


Ever seen this? I costed me hours of debugging. Can I
sue Microsoft for this?


No. It's neither their or C's fault. It's yours.

--
/-- Joona Palaste ) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"There's no business like slow business."
- Tailgunner
  #4  
Old July 20th 03, 07:29 PM
Artie Gold
external usenet poster
 
Posts: n/a
Default Horrible Visual C Bug!

Oliver Brausch wrote:
Hello,

have you ever heard about this MS-visual c compiler bug?


Nope.

look at the small prog:

OK...

static int x=0;
int bit32() {
return ++x;
}

int bit64() {
return bit32() + (bit32() 1);
}

void main(int argc, char **argv) {

int main(int argc, char **argv) {

but since you're not making use of the command-line interface,

int main(void)

would do quite nicely...

int i;
for (i = 0; i 5; i++) printf("%d. %d\n", i, bit64());
}


Ok, the (correct) result is:

0. 2
1. 8
2. 14
3. 20
4. 26


Oh, really?

What if I told you that the correct result could be just about anything,
including demons flying out of your nose?


This is what every compiled progam says. Inclusive MSVisualC Compiler
with Debug options or /Ot fast-option.

But do not dare to switch to the the /O2 option of MSVisualC Compiler.
Then once your computer cannot calculate anymo

0. 1
1. 7
2. 13
3. 19
4. 25

So, up to Microsoft, 0 + 2 = 1 ?????. That's why their OS is so stable....
Try to increase the " 1". It even gets worse.


Well, as it turns out, the bug is on the other side of the keyboard in
this case.[1]

Please see: http://www.eskimo.com/~scs/C-faq/s3.html for an explanation.


Ever seen this? I costed me hours of debugging. Can I
sue Microsoft for this?


Actually, even if it had been their bug (which it isn't) you couldn't --
read the license.

HTH,
--ag

[1] Not that I would mind a bit had it been _their_ fault.

--
Artie Gold -- Austin, Texas

  #5  
Old July 20th 03, 07:47 PM
Brett Frankenberger
external usenet poster
 
Posts: n/a
Default Horrible Visual C Bug!

In article ,
Jakob Bieling wrote:
"Oliver Brausch" wrote in message
om...

static int x=0;
int bit32() {
return ++x;
}

int bit64() {
return bit32() + (bit32() 1);
}


You try to change a variable twice, which is invalid, ie. undefined
behaviour.


There is a sequence point between the two modifications of x, so
there's no undefined behavior here. The C language doesn't specify
which of the two bit32()'s will be invoked first, so there is
unspecified behavior here. But the first two calls to bit32() are
going to return 1 and 2 respectively, giving:
1 + (2 1) which is 5, or
2 + (1 1) which is 4
for the first return of bit64(). (If this were undefined behavior, the
compiler would be free to do whatever it wanted. That's not the case
here -- he can reliably assume he'll get 4 or 5 ... he just can't
assume which one he'll get.)

(The two outputs he shows (1 and 2 for the first call to bit64())
aren't possible from the code he posted ... but I assume his test code
actually had "x++" instead of "++x".)

-- Brett
  #6  
Old July 20th 03, 08:00 PM
Joona I Palaste
external usenet poster
 
Posts: n/a
Default Horrible Visual C Bug!

Brett Frankenberger scribbled the following
on comp.lang.c:
In article ,
Jakob Bieling wrote:
"Oliver Brausch" wrote in message
. com...
static int x=0;
int bit32() {
return ++x;
}

int bit64() {
return bit32() + (bit32() 1);
}


You try to change a variable twice, which is invalid, ie. undefined
behaviour.


There is a sequence point between the two modifications of x, so
there's no undefined behavior here. The C language doesn't specify
which of the two bit32()'s will be invoked first, so there is
unspecified behavior here. But the first two calls to bit32() are
going to return 1 and 2 respectively, giving:
1 + (2 1) which is 5, or
2 + (1 1) which is 4
for the first return of bit64(). (If this were undefined behavior, the
compiler would be free to do whatever it wanted. That's not the case
here -- he can reliably assume he'll get 4 or 5 ... he just can't
assume which one he'll get.)


(The two outputs he shows (1 and 2 for the first call to bit64())
aren't possible from the code he posted ... but I assume his test code
actually had "x++" instead of "++x".)


Actually, yes they are. He has undefined behaviour - void main(). 1 and
2 are as legal outputs as 4 and 5, and so is "your mother was a hamster
and your father smelt of elderberries".

--
/-- Joona Palaste ) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"Life without ostriches is like coffee with milk."
- Mika P. Nieminen
  #7  
Old July 20th 03, 08:19 PM
Brett Frankenberger
external usenet poster
 
Posts: n/a
Default Horrible Visual C Bug!

In article ,
Joona I Palaste wrote:
Brett Frankenberger scribbled the following
on comp.lang.c:
In article ,
Jakob Bieling wrote:
"Oliver Brausch" wrote in message
.com...
static int x=0;
int bit32() {
return ++x;
}

int bit64() {
return bit32() + (bit32() 1);
}

You try to change a variable twice, which is invalid, ie. undefined
behaviour.


There is a sequence point between the two modifications of x, so
there's no undefined behavior here.


Actually, yes they are. He has undefined behaviour - void main(). 1 and
2 are as legal outputs as 4 and 5, and so is "your mother was a hamster
and your father smelt of elderberries".


Yes, of course, but I wasn't responding to that. I was responding to
the claim that calling bit32() twice, as shown above, was undefined
behavior. And it's not. I specifically didn't show the void main()
part of the code.

As a practical matter, if he fixed the void main() thing, he's not
going to get a different result -- he'll still get one of the two
possible outcomes from bit64(). So he'll end up with a program that
has unspecified (but not undefined) behavior.

-- Brett

  #8  
Old July 20th 03, 08:44 PM
Jakob Bieling
external usenet poster
 
Posts: n/a
Default Horrible Visual C Bug!

"Falcon Kirtarania" wrote in message
. ca...

"Jakob Bieling" wrote in message
...
"Oliver Brausch" wrote in message
m...

have you ever heard about this MS-visual c compiler bug?
look at the small prog:


It is not a compiler bug. It is a bug in your code.

static int x=0;
int bit32() {
return ++x;
}

int bit64() {
return bit32() + (bit32() 1);
}


You try to change a variable twice, which is invalid, ie. undefined
behaviour. Microsoft's compiler is absolutely right.

void main(int argc, char **argv) {


'void main' is illegal. It is *always* 'int main'.


No, it is not. However, int main has always been considered MUCH better
practice, because it allows for escapes and return codes.


You might want to do a search on Google about why you should write 'int
main' instead of 'void main'. Do not want to start such a long discussion
again. ;o)

regards
--
jb

(replace y with x if you want to reply by e-mail)


 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 02:41 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.Content Relevant URLs by vBSEO 2.4.0
Copyright 2004-2017 ChessBanter.
The comments are property of their posters.