Re: [Code] Brainteaser

From: Henrik Stuart (
Date: 11/21/01


On Wednesday, November 21, 2001 4:38:28 PM you wrote:
> 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. Martijn's explanation sounds plausible,
> although I dont understand why MSVC++ does not opt for "lazy evaluation"
> as its default.

> 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.

   MSVC++ does indeed use lazy evaluation - I cannot think of many
   compilers that do not, particularly as it is required by the C++
   standard, but also the C standard that evaluation is lazy.
   Makes the language constructs a bit more interesting to manipulate,
   but that's another story. :o)

   Now, I'll wager that you are using MSVC++ to do a debug build of
   your source and this will result in some unexpected behaviour if
   you do not know of it.

   The debug heap functions in vc++ is managed radically different
   than debug heap in most other compilers (forcing you to actually
   write the stuff "correctly").  Let's ponder a C++ example for a
   while (works the same way for C allocations).

   int* ptr;
   ptr = new int(37);
   delete ptr;

   Now, you might think that ptr is 0x00000000 per default, but the
   debug heap initialises it to 0xcdcdcdcd (some strange bogus value
   like this).

   The call to new, however, makes it point to a valid place in memory
   where we have stored the number 37. After the call to delete
   however, it has been changed to 0xdddddddd (your milage may vary).
   Now, if you try to dereference this pointer your program will...
   crash, yes. :o)  Because 0xdddddddd is an invalid address.

   So now I hear you linux people *mutter* Microsoft can never do
   anything right */mutter*. However, this is a benefit in most cases
   when you are doing actual debugging, because you do not want in all
   cases to set your pointer to 0 when you deallocate the contents it
   points to - examples are irrelevant to why your mud is crashing,
   but you can investigate Microsoft Developers Journal or the MSDN
   magazines if this stuff interests you and how it aids in your
   debugging - a particularly nice section in one of their magazines
   is called BugSlayer and works with debugging in many different ways
   written one of the gurus in the field.

   Ok, with this in mind, insert a breakpoint at the mentioned line
   (f9) and hit f5 to run a debug run. Now, each time it hits that
   line investigate str in the quick debug window and see whether it
   is actually 0x00000000 or whatever string you are currently

   So, unless the corruption took place in some other place you
   commented out while poking for the bug, I cannot explain why it is
   crashing. There is no difference between the two statements in how
   they are executed, so I find it highly improbable that that should
   be the cause of your crashes.

   Of course, eventually you want to remember to clean out all the
   object-files and do a clean rebuild - just in case. :o) And do
   remember to set up your precompiled headers correctly. (Read: If
   you have no clue about what they do, disable them!).

   Offnote to the latest arrivals in the thread that came in while I
   was writing by Martijn Schoemaker:

>>Well, we're talking MSVC++ here ... if gcc does not work, I start
>>worrying, if MSVC++ does not work, I silently shake my head ;)

   Compiler are a religious question. GNU insist they read the
   standard right about how to handle templates, Microsoft disagrees,
   Borland went the safe way and did both cases... Are any of them
   wrong? Is VC++ better than g++ or bc++ or vice versa? Hardly
   likely. The best compiler is the one you are most versatile in
   using and the one that gives you the best possibilities for solving
   your problems and debugging. And in my opinion debugging in
   particular, as that is one of the most problematic areas about
   programming - most people just don't get it right the first time
   unless they are copying the source for hello world and even then
   the majority of tries goes wrong. :o)  So really, pointless matter
   to bring up in a thread pertaining to a bug. :o)

Yours truly,
  Henrik Stuart (

   | FAQ: |
   | Archives: |

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