How is the memory allocated while casting?

Question

We can create an object through casting a contiguous memory block into object. If we create an object with little memory, it's not crashing while accessing it. But it's crashing while going out of scope. Why?

class A
{
    public:
        int i;
};
void main(int argc, char * argv[])
{
    {
        vector<BYTE> v(1);
        A* a = (A*)v.data();
        a->i = 70000;          // a's memory can't hold 4 bytes (int). Why no crash?
        cout << a->i << endl;  // Printed value - 70000. Why not crash here
    }                          // Crashed here with heap corruption detected
    cout << "End of scope\n";
}

Answer 1

On a formal point of view, you are just invoking Undefined Behaviour because you are trying to access a BYTE * as a A *. Per the strict aliasing rule, it is enough for the compiler to to anything it wants.

In the real world, it will depend on the implementation, and it is likely to give correct results. Under the hood, common implementations for vector use allocated memory for their data member. That means that:

• it will be correctly aligned for any type
• the actual allocated memory is likely to be at least enough for an int (because of the alignment, it is at least 4 bytes on a 32 bits system and 8 on a 64 one)
• you can safely change the type of the allocated memory

That means that it is not surprising that this code does not crash, even if it is plain Undefined Behaviour.

Note: except in very special cases, and with notices in red flashing font, you should never rely on implementation detail for your code, because it can crash with next version of your compiler, or simply if you change build options.

The heap corruption is only a warning, because your implementation has put a mark after the last byte that it has given to you, and has found that mark overwritten. But on a low level point of view you have not erased anything of major importance - assuming your implementation is like mine :-)

Answer 2

Assuming that BYTE is some type or typedef such that sizeof(int) > sizeof(BYTE), and your real code had some #include and using directives that you forgot to paste, then your program causes undefined behaviour in several ways:

1. An expression of type int is used to write to storage of type BYTE, this violates the strict aliasing rule.
2. Even if we ignore (1) for a moment, it attempts to write past the end of the storage for the vector.
3. The program violates the rule that main must have a return type of int. Violating a diagnosable rule means that any executable generated has completely undefined behaviour.

When undefined behaviour occurs, anything can happen. This includes, but is not limited to, crashing and not crashing. You should not expect any particular events or lack thereof.

Answer 3

The vector you're using allocates its internal buffer on heap.

You make a buffer overflow writing 4 bytes on the 1 byte buffer, thus corrupting the heap.

When the scope is closed, the vector's destructor deallocate its internal buffer, the heap corruption is detected.

Answer 4

Welcome in Undefined Behavior land.

a->i = 70000; is totally undefined => you write an int inside something that have only one byte. So you can't know what will happen:

• Works fine
• Segmentation fault
• Works fine but break something in background (seams to be your case)
• another unpredictable behavior

Just by guessing, I suspect that the line a->i = 70000; will produce a buffer overflow which will overwrite some internal variables from vector. So during assignment, no visible trouble because enough memory has been allocated. But when vector is destroyed, internal variables produce incorrect behavior which produce a "crash".

Once again, it's just guessing, because it's undefined behavior. Only with a debugger you can observe what's happen just before crashing.

Answer 5

Your program does not crash. The heap corruption is an extra warning added by the compiler.

Now when the object gets destroyed it checks whether the memory is still "OK". Because you put a bigger object into the memory than intended, the memory past the object was overwritten. The implicit runtime checks by the compiler trigger and give you this error to tell you "something is wrong with the memory".

When this happens is compiler dependent and of the kind of memory checks. You can turn of the memory checks, then you wont get the error there but you have still corrupt memory and maybe have some strange (undefined) behavior later on.

There are several methods for this checks. Usually by adding extra special bytes at the end (sometimes also front) of allocated memory an on "delete" check if they are still there.