There’s no single definitive answer to your question.
- Firstly, the external behavior of a freed block will depend on whether it was released to the system or stored as a free block in the internal memory pool of the process or C runtime library. In modern OSes the memory “returned to the system” will become inaccessible to your program, which means that the question of whether it was zeroed-out or not is moot.
(The rest applies to the blocks retained in the internal memory pool.)
Secondly, there’s little sense in filling freed memory with any specific value (since you are not supposed to access it), while the performance cost of such operation might be considerable. Which is why most implementations don’t do anything to freed memory.
Thirdly, at debugging stage filling freed memory with some pre-determined garbage value can be useful in catching errors (like access to already freed memory), which is why many debug implementations of standard library will fill freed memory with some pre-determined value or pattern. (Zero, BTW, is not the best choice for such value. Something like
0xDEADBABEpattern makes a lot more sense.) But again, this is only done in debug versions of the library, where performance impact is not an issue.
Fourthly, many (most) popular implementations of heap memory management will use a portion of the freed block for its internal purposes, i.e. store some meaningful values there. Which means that that area of the block is modified by
free. But generally it is not “zeroed”.
And all this is, of course, heavily implementation-dependent.
In general, your original belief is perfectly correct: in the release version of the code a freed memory block is not subjected to any block-wide modifications.