The value of out-of-bounds element of an array - should it change on each execution or stay the same?

For the actual question, jump to question part. For an interesting real-world example of undefined behavior, keep reading :)

There was this enumeration:

struct EnumStruct 
{
   enum Enum
   {
       val0 = 0,
       val1,
       val2,
       val3,
    开发者_C百科   val4
   };
};

and in some function we had this:

const int arrayCount = 6;
int arr[] = {
        EnumStruct::val0,
        EnumStruct::val1,
        EnumStruct::val2,
        EnumStruct::val3,
        EnumStruct::val4
        InvalidValue
      };    

Then there was a loop that put arrayCount elements of the arr into a file. This was the Prepare() routine for the unit tests. And the unit test was supposed to check for the presence of the InvalidValue in the file. I was assigned a defect stating that the unit test fails. It worked perfect on my machine though. After a couple of hours of debugging I noticed that InvalidValue is actually #defined as -1, and there is a missing comma after val4. You can only imagine the swearwords that came out of my mouth in the address of whoever wrote that code (which worked perfectly for more than 3 years, actually).

Now, as you can see, the array is actually comprised of 5 values - 0, 1, 2, 3, 3 but the loop writes to the file the 6th element as well, which is of course Undefined Behavior. Now, while technically it is undefined, on Windows with MSVC no crashes happen - it just writes the garbage that is at that memory location. The thing is that if the garbage happens to be anything but 0, 1, 2, 3, or 4, the unit tests will succeed.

Question: It appears that the .vcproj file of the UT's is somehow patched before the UT's are built. I don't know how they do it, but with their build out-of-bounds array elements are always 0. It seems to me that the whole virtual memory is set to 0 before program execution. What project setting is that? Or am I imagining things? I mean, if it was just luck that there was a 0 sitting out-of-bound of an array, then upon multiple executions my luck would fail, wouldn't it? But it is always 0... I am confused. By the way, when I build the same project the out-of-bounds element always has different values on each execution. Can you please explain this? Thanks.

To the actual question of is memory always 0 at the start? Well, it might depend. In general, when the OS provides you with a page of memory it will be cleared (as a security measure, so that you cannot read the values that any other process had in their memory), so in many cases you will find that uninitialized can look like 0, until memory is being reused in your own process, where you will get whatever you wrote before.

There are also some compiler flags that can affect it. To detect uninitialized memory issues, sometimes debug builds will write patterns to memory after allocation from the OS and before handling it to the program, and a different pattern after releasing the memory in the program before reallocating (to detect access to freed memory), so that it is simpler to identify what happened (if you see in a debugger that the value is 0xDEADBEEF, you will know that the memory has already been released by the program. You will have to read the compiler/IDE documentation for more precise information.

As you say, it's undefined, so the implementor is free to do whatever they like. I can't speak for Visual C++ at all, but I am aware of other products that do things like zero out memory when running debug builds so that things like invalid pointer dereferences will fail at the site of the fault. It's possible that Microsoft is doing something similar I guess.