Meaning behind memory surrounding array c++

Question

I've been lately experimenting with dynamically allocated arrays. I got to conclusion that they have to store their own size in order to free the memory.

So I dug a little in memory with pointers and found that 64 bytes directly before and 14 bytes directly after array don't change upon recompilation (aren't random garbage).

I represented these as unsigned int types and printed them out in win console:

Here's what I got: (array's content is between fdfdfdfd uints in representation)

So I figured out that third unsigned int directly before the array's first element is the size of allocated memory in bytes.

However I cannot find any information about rest of them.

Q: Does anyone know what the memory surrounding array's content means and care to share?

The code used in program:

#include <iostream>

void show(unsigned long val[], int n)
{
    using namespace std;

    cout << "Array length: " << n <<endl;
    cout << "hex: ";
    for (int i = -6; i < n + 1; i++)
    {
        cout << hex << (*(val + i)) << "|";
    }
    cout << endl << "dec: ";
    for (int i = -6; i < n + 1; i++)
    {
        cout << dec << (*(val + i)) << "|";
    }
    cout << endl;
}

int main()
{
    using namespace std;

    unsigned long *a = new unsigned long[15]{ 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14 };
    unsigned long *b = new unsigned long[15]{ 0 };
    unsigned long *c = new unsigned long[17]{ 0 };

    show(a, 15);
    cout << endl;
    show(b, 15);
    cout << endl;
    show(c, 17);
    cout << endl;

    cout << endl;
    system("PAUSE");

    delete[] a;
    delete[] b;
    delete[] c;
}

Answer 1

It typically means that you carried out your experiments using a debugging configuration of the project and debugging version of the standard library. That version of the library uses some pre-defined bit-patterns to mark the boundaries of each allocated memory block ("no man's land" areas). Later, it checks if these bit-patterns survived intact (e.g. at the moment of delete[]). If they did not, it implies that someone wrote beyond the boundaries of the memory block. Debug version of the library will issue a diagnostic message about the problem.

If you compile your test program in release (optimized) configuration with release (optimized) version of the standard library, these "no man's land" areas will not be created, these bit-patterns will disappear from memory and the associated memory checks will disappear from the code.

---

Note also the the memory layout you observed is typically specific for arrays of objects with no destructors or with trivial destructors (which is basically the same thing). In your case you were working with plain unsigned long.

Once you start allocating arrays of objects with non-trivial destructors, you will observe that it is not just the size of memory block (in bytes) that's stored by the implementation, but the exact size of the array (in elements) is typically stored there as well.

Answer 2

"I got to conclusion that they have to store their own size in order to free the memory." No they don't.

Array does not free it's memory. You never get an array from new/malloc. You get a pointer to memory under which you can store an array, but if you forget size you have requested you cannot get it back. The standard library often does depend on OS under the hood as well.

And even OS does not have to remember it. There are implementations with very simple memory management which basically returns you current pointer to the free memory, and move the pointer by the requested size. free does nothing and freed memory is forgotten.

Bottom line, memory management is implementation defined, and outside of what you get nothing is guaranteed. Compiler or OS can mess with it, so you need to look documentation specific for the environment.

Bit patterns that you talk about, are often used as safe guards, or used for debugging. E.g: When and why will an OS initialise memory to 0xCD, 0xDD, etc. on malloc/free/new/delete?