Why is malloc( ) initializing the value of a newly allocated block of memory?

Question

I'm starting to learn about dynamic memory allocation in C and so far everywhere I've read the malloc() function does NOT initialize the value of the newly allocated block.

Has this been changed in newer versions of C? C99 and C11?

I'm executing the following using Xcode and all values are being initialized with 0.

double *p = (double *) malloc(5 * sizeof(double));

printf("Address of p0 = %p | Valoe of p0 = %f\n", p, *p);
printf("Address of p1 = %p | Valoe of p1 = %f\n", p+1, *(p+1));
printf("Address of p2 = %p | Valoe of p2 = %f\n", p+2, *(p+2));
printf("Address of p3 = %p | Valoe of p3 = %f\n", p+3, *(p+3));
printf("Address of p4 = %p | Valoe of p4 = %f\n", p+4, *(p+4));

I thought this was true only for the function calloc().

Answer 1

Seems to be implementation defined behavior. On Visual Studio 2012, C compiler, I see no such initializations.

More importantly, read the "catch" of the selected answer in this question:

Why does malloc initialize the values to 0 in gcc?

Says, that the OS might "give" you zeroed values due to security reasons. As it seems, this is an implementation defined behavior.

Piece of advice: its not standard behavior and breaks portability of the code. Make sure you initialize the values and not depend on the data given by the OS .

Answer 2

You got lucky(or unlucky if you trust this). Malloc does not have such thing inside(but it asks to OS to get allocation and I dont know OS behavior). Then there could be some performance decrease when you repeatedly malloc some areas. Those zeroes are from untouched forest.

First malloc, then initialize to random numbers/chars then repeat this many times, then you will start getting non-zero elements just after malloc.

Dont forget to free() between random sized mallocs.

Answer 3

You've assumed that "I get 0" always means "the value 0 was deliberately placed here", which is not the case.

There is no initialisation in your code.

Answer 4

First, the fact that malloc does not initialize the returned memory block (this has not changed) as per the standard does not mean that it must not do it, but rather that it is not required to do so.

It is very well allowable for malloc to initialize the memory block anyway. It is even conceivable (but unwise) for a debug build to zero-initialize all allocated blocks. A better solution would be to fill them with a recognizable pattern, however.

On top of that, new pages obtained from the operating system are always zeroed. This is done for security reasons, with no exceptions (some embedded systems may be the rare exception, but no "mainstream" system will give you an uninitialized page, ever). Therefore, in some cases, memory may be zero-initialized, but you have no way of knowing whether it was malloc doing it or someone else.

Answer 5

The content of the allocated block is not defined and so it is implementation specific.

Some implementations (like this one you are using) set it to zero, others to 0xdeadbeef or some other magic number (msvc++ compiled malloc fills it with 0xCC but not everything).

It is implementation specific and so undefined, do not depend on it.

And do never reallocate memory inside memory just because it is dangerous.

Answer 6

In multi-user operating systems, when memory is given to a process by the operating system, the operating system will typically clear the memory so that it does not reveal data that was previously there from other processes. (Of course, the system does not have to zero this memory; to protect privacy, it merely has to set the memory to any values that do not contain private data. Zero is usually used.)

This implies that when malloc returns memory that is freshly obtained from the operating system, which of course happens when the pool of memory malloc had previously is insufficient to satisfy your request, that memory will contain zeros. However, when malloc returns memory that was previously used by your process, it may contain other data. (Some of this data may be from parts of your program that are not normally visible to you, such as the C run-time initialization code or dynamic loaders and linkers.)

Since this behavior is a result of your operating system and not of the C specification, you may not rely on it when basing software only on the C specification. When you do not have assurance that this behavior will occur, you must write software as if every malloc could return uninitialized data, even if experience or examinations often show otherwise.