Visual C++ 6.0 problem ?

Started by
18 comments, last by wack 16 years, 11 months ago
Please try to compile this code under Visual C++ 6.0, console application, RELEASE mode. #include <stdio.h> int fonc1() { return 11; } int main() { char c[255]; int size; int i; size = fonc1() ; for(i=0;i<size;i++) { printf("arf %d\t",size); c=0; } return 0; } Strangely, the program write me "arf 11" millions times !!! It should write it 11th times only... Any explaination ? Can you get the same problem ? Can you explain me ? Is this a known troubleshooting of Visual C++ 6.0 ? (it works under .net 2005) Thx !!
Advertisement
I actually did reproduce this.

It works fine in debug mode and it works fine if you take out the line:

c = 0

but, in release mode, with that code in, it loops infinitely (or enough to get me to shut it off before it stopped).

Since size is printed out every time at 11 the only way that this loop should continue is if i is somehow getting reset (which is not in the code), BUT, when I print out i with the following line:

printf("arf %d\t %d\t",i, size);

and leave everything else unchanged the loop works fine.

Very odd problem, I'd call it a bug but I hate to blame things on the compiler. Someone else here might have a better explanation.

Quote:Very odd problem, I'd call it a bug but I hate to blame things on the compiler. Someone else here might have a better explanation.


I dont have VC6.0 to test it but VC6.0 is known to be extremly bugy so if you both observed the behaviour then i wouldnt be to worried about blaming the compiler.
Its hard to know for sure with VC++6 (Though that looks like C code to me so it shouldn't be a problem iirc)
[size="1"]I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!
Thx all :)
Yes, seems to be Visual C++ 6.0 problem, but I look for the page explaining this bug (if this is a bug) to know exactly in whish case this bug appear !

If someone can help !
If you want further help, you should obtain dumps of the disassembly of both the broken (buggy) case and the working case, and post them here.

However, the fix is to not use Visual C++ 6, which is so old that it isn't even a proper C++ compiler (it was written before C++ was standardized). There's no reason to use it any more.
Quote:Original post by jpetrie
However, the fix is to not use Visual C++ 6, which is so old that it isn't even a proper C++ compiler (it was written before C++ was standardized). There's no reason to use it any more.
Quoted for emphisis.
Quote:Original post by jpetrie
If you want further help, you should obtain dumps of the disassembly of both the broken (buggy) case and the working case, and post them here.

However, the fix is to not use Visual C++ 6, which is so old that it isn't even a proper C++ compiler (it was written before C++ was standardized). There's no reason to use it any more.


Not to mention the fact that there are many free compilers out there that are way better than VC++ 6.0...
Problem is :

I'm a professionnal programmer, we work under several IDE, and some of our customers ask us libs for Visual C++ 6.0. (some others .Net 2005, Linux, etc...)
We have to use it, and make our code work under this system too.

That's why I am looking for the bug report page about this page to know exactly what we have to avoid in our code :)
Note that this is the first time we have this error, we program (me and my collegues) under Visual C++ 6.0 for years, and we never had this problem.
You could try turning off optimizations for the translation unit that's causing you problems.

This topic is closed to new replies.

Advertisement