Author: Scott Gasch
Date: 13:40:22 11/28/01
Go up one level in this thread
On November 28, 2001 at 11:46:45, Miguel A. Ballicora wrote:
>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');
Something is utterly broken here and I really doubt it's the compiler. Such
simple cases almost certainly work. Here's my advice to you: get rid of your
assert macro (could you have written it incorrectly?) and do a simple
if-statement... then put a breakpoint at the strcpy and single step the code
watching the memory at &tmp. Another thought: are you building this test in
retail mode (and therefore the ASSERT is not in the code gen)? Also beware of
smart compilers simply removing identifiers you don't need. I don't think this
is relevant here though.
>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).
You have to be somehow zeroing out your memory buffer by accident. My advice to
you is to either put a watch on that buffer or single step your program keeping
an eye on that buffer as you do. I bet you'll find you're somehow klobbering
it. If your problem doesn't reproduce in a debugger you can try memory
protection to catch this problem... but the odds are that allocating your buffer
from the heap or with VirtualAlloc will cause your layout in virtual memory to
change and therefore probably hide the problem. Speaking of which, does the
problem go away when you change the order of identifier declarations? If so its
almost certain that you are overrunning a buffer and zeroing something else.
Triple check any ZeroMemory calls or memset calls you make... are you absolutely
sure you are only hitting what you want?
Here's a trick that MSVC does with some new flag in order to catch buffer
overflows... but you can expand it alittle and use it on your own... add a DWORD
between every local identifier in around your buffer and initialize them. Like
this:
int myfunction(void)
{
DWORD dwBefore = 0xffffffff;
char szMyBuffer[1024];
DWORD dwAfter = 0xffffffff;
...
do_1
ASSERT(dwAfter == dwBefore == 0xffffffff);
...
do_2
ASSERT(dwAfter == dwBefore == 0xffffffff);
...
// about to leave the function!
ASSERT(dwAfter == dwBefore == 0xffffffff);
return(1);
}
>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
Good luck. I know this is frustraiting but keep after it. And let us know what
you found (even if its a dumb mistake). That way we can learn from your
experience! I'd much rather learn from yours than my own, less work that way.
If you really have a compiler bug and can reproduce it with a small bit of code,
post it up here and I'll try it on my MSVC6.0 (and newer MSVCs) and report the
results. I bet Eugene might be interested in this sort of thing too.
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.