Author: Miguel A. Ballicora
Date: 08:46:45 11/28/01
Go up one level in this thread
On November 27, 2001 at 17:19:21, Scott Gasch wrote:
>On November 27, 2001 at 16:12:24, Miguel A. Ballicora wrote:
>
>>Has anybody experienced bugs from MS Visual C 6.0 when programming in C?
>
>Yes, once.
Thanks Scott, Dann and Wylie for your answers.
>>A couple of times I have observed weird behaviors that after a lot of debugging
>>I had to conclude that there was something weird with the compiler or optimizer.
>>For instance, I include a printf() to debug part of the program and that was
>>never printed. It just skipped that instruction. I had no idea what it was
>>because I just rewrote the function to make it work.
>
>Did you try dumping the assembly generated for your function in a debugger and
>sanity checking it? The presence of absence of a "call _printf" should be easy
>to verify. Such blatant code generation bugs are rare, I think.
This time, this problem happen again. It is in the same file I had problems
before, so something wrong is there ticking.
I checked what you say and _printf is there. The annoying thing is that
the debug session reports no error, printf is executed and everything looks
normal.
Trying different things I found (I think) what causes printf not to print.
String constants are not what they are suppose to be. For instance
This assert fires up:
ASSERT( "Message"[0] != '\0' );
Looks like "Message" is a pointer to char that is not initialized to 'M' as it
should be.
Another try that fail is
char tmp[256];
strcpy(tmp, "Another Message\n");
ASSERT(tmp[0]!='\0');
That is why if I try to do this simple line:
printf("Another Message\n");
I got the same as
printf("\0");
Similar behavior is I use fprintf, sprintf etc. It is the string that
is messed up and initilized as an empty string!
That might be related to the original problem. I had an array initialized
that returned me zeros. What the heck am I doing wrong? I have no idea.
Not having the chance to use printf as a debugging tool drives me nuts.
When I do a debugging session everything is normal (at least with printf,
I did not go further).
Is it me or an expression like
do_1();
printf("Print this for goodness sake\n");
fflush(stdout);
do_2();
should work no matter what if I see that do_1 and do_2 are executed?
Regards,
Miguel
>
>>Most of the time I think
>>that I am wrong (most of the time I am wrong) but there are some things that do
>>not make sense. Now I am facing a problem that probably is me, but it look very
>>suspicious. I'll comment on that when I am sure I spent enough time on it.
>[snip]
>
>Would be curious to hear about it.
>
>I've found that most of the time it's a bug in my code... I have a bad habit of
>blaming the compiler and then digging in and finding its my own bug.
>
>That said, once I found a glaring code gen bug in MSVC once and was forced to
>work around it. It took me a full day of tedious debugging but the problem was
>in my pawn evaluation function where MSVC had generated code that used the wrong
>register. I was or-ing a flag into the a member of one struct and the compiler
>generated code using a register containing a pointer to an entirely different
>struct. This caused garbage in my position (board) that later caused a crash in
>the SEE. The problem only repeated with full optimization turned on. I ran
>into this when I first ported from gcc to MSVC6.0 (SP4, I think).
>
>I then took my code in to work with me where we use development versions of
>MSVC7.0 and the problem seems to be fixed in the newer (forthcoming) compilers.
>
>Scott
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.