Controling CRT memory initialization

Answer 1

I'm not following - having uninitialized memory set to something like 0xcdcdcdcd instead of 0 is better for flushing out bugs, because code is more likely get 'in range' arithmetic or specially handle 0. With the wildly invalid value, bugs are more likely to 'fail fast' so they can be fixed instead of hidden.

The values that the debug build of MSVC uses are specifically designed to help cause failures that can be easily detected:

• they aren't 0, so NULL pointer checks against uninitialized memory won't hide the bug
• they aren't valid pointers, so dereferencing uninitialized pointers will cause an access violation
• they aren't 'usual' integer values, so calculations involving uninitialized data will usually result in wildly incorrect results that will tend to cause noticeable failures (I think be negative when handled as signed data also helps a bit with this, but not as much as simply being unusual numbers).

Also, they're easy to recognize in data displays in the debugger. Zero doesn't stand out nearly as much.

All that said, MSVC provides a number of debug hooks/APIs that you might be able to use to do something along the lines of what you want:

• http://msdn.microsoft.com/en-us/library/1666sb98.aspx

Some additional information in response to your updated question:

You might be able to use a 3rd party debug allocation library like Dmalloc (http://dmalloc.com/) but I honestly don't know how easy those libraries are to integrate into an MSVC project, especially 'real world' ones.

Also, note that these obviously will only deal with dynamic allocations (and might not integrate well with MSVC's default new implementation).

You can use a global override of operator new() to deal with allocations that occur using new in C++ - there's not a problem with overwriting any valid constructor initializations - the new allocation occurs before the constructor performs any initialization (if you think about it for a moment it should be clear why that is).

Also, you might want to consider moving to Visual Studio 2010 - it will break into the debugger when you use an uninitialized local variable - doing nothing special other than running the Debug build under the debugger. Of course, MSCV has warned about many of these situations for a while, but VS2010 will catch the following in the debugger, which produces no warnings (at least with my current compiler settings):

int main(  )
{
    unsigned int x;
    volatile bool a = false;

    if (a) {
        x = 0;
    }

    printf( "Hello world %u\n", x); // VS2010 will break here because x is uninitialized

    return 0;
}

Even the Express version of VC++ 2010 supports this.

Answer 2

Just a suggestion: can you use the static code analysis tool in your compiler? /analyze will give you a C6001 warning that you're using uninitialized memory. And it's somewhat systematic, which is what your asking for.

Answer 3

Stepping into the CRT shows the magic numbers are used in _heap_alloc_dbg and realloc_help, and the value itself is encoded as

static unsigned char _bCleanLandFill  = 0xCD;   /* fill new objects with this */

Knowing what to search for often helps. The linked thread does have a nice suggestion: set a watch on _bCleanLandFill and modify it from the debugger.

It does work, but I'll keep this question open for a while - I still hope someone has a better idea... I was hoping to run automated tests with controlled initializations, and not have to do it manually (and only with a debugger available).