Re: [Code] Brainteaser

From: Mike Breuer (
Date: 11/21/01

----- Original Message -----
From: "John" <witpens@OPTUSHOME.COM.AU>

> I initially thought that there were no differences between the two
> cases. However, when I first broached this subject to several
> programmers asking them why the heck the compiler tells me the mud
> crashes at this very spot all the time, their first reply was to
> separate the OR statement...

And now you have one telling you that is irrelevant.  You decide.

> although I dont understand why MSVC++ does not opt for "lazy evaluation"
> as its default.

It does...I once used MSVC quite extensively, and it would have been quite
obvious to me if it were not behaving correctly in that regard.  I'm not
even aware of any way that this could be turned off in MSVC, or any other
compiler for that matter.  Not that I've ever looked.

> The debugger actually says something like:-
> (+) str:    0xCC00000 ""
>               value cannot be determined
> So, I am guessing that the pointer has a NULL string and yet for some
> strange reason, it is trying to evaluate *str (I am also guessing that
> the memory address is really just part of the freestack) and hence, it
> crashes since *str is invalid.

Well, the only reason that particular line of code would crash would be if
str pointed to an invalid memory address (such as one which had been freed).
So it is obviously crashing on the !*str.  Changing the conditions around
would not fix that since, str would still be nonzero, and still invalid.

All that being said, I DID have a problem a few years back with MSVC.  As I
stepped through the code, I was able to watch one of my pointers changing
between two line of assembly code!  Neither line had anything to do with
that pointer, and there were no function calls, or other tricks going on.
It turned out to be an issue with the incremental linker.  If I did a
"rebuild all", the problem went away.  I'm not suggesting that this is the
problem...but it might be worth a try.


   | FAQ: |
   | Archives: |

This archive was generated by hypermail 2b30 : 12/06/01 PST