Question

malloc is not guaranteed to return 0’ed memory. The conventional wisdom is not only that, but that the contents of the memory malloc returns are actually non-deterministic, e.g. openssl used them for extra randomness.

However, as far as I know, malloc is built on top of brk/sbrk, which do “return” 0’ed memory. I can see why the contents of what malloc returns may be non-0, e.g. from previously free‘d memory, but why would they be non-deterministic in “normal” single-threaded software?

1. Is the conventional wisdom really true (assuming the same binary and libraries)
2. If so, Why?

Edit Several people answered explaining why the memory can be non-0, which I already explained in the question above. What I’m asking is why the program using the contents of what malloc returns may be non-deterministic, i.e. why it could have different behavior every time it’s run (assuming the same binary and libraries). Non-deterministic behavior is not implied by non-0’s. To put it differently: why it could have different contents every time the binary is run.

Answer 1

I think that the assumption that it is non-deterministic is plain wrong, particularly as you ask for a non-threaded context. (In a threaded context due to scheduling alea you could have some non-determinism).

Just try it out. Create a sequential, deterministic application that

• does a whole bunch of allocations
• fills the memory with some pattern, eg fill it with the value of a counter
• free every second of these allocations
• newly allocate the same amount
• run through these new allocations and register the value of the first byte in a file (as textual numbers one per line)

run this program twice and register the result in two different files. My idea is that these files will be identical.