In both cases, you get uninitialized memory, and you can't make any assumptions about its contents.

When the OS has to apportion a new page to your process (whether that's for its stack or for the arena used by malloc()), it guarantees that it won't expose data from other processes; the usual way to ensure that is to fill it with zeros (but it's equally valid to overwrite with anything else, including even a page worth of /dev/urandom - in fact some debugging malloc() implementations write non-zero patterns, to catch mistaken assumptions such as yours).

If malloc() can satisfy the request from memory already used and released by this process, its contents won't be cleared (in fact, the clearing is nothing to do with malloc() and it can't be - it has to happen before the memory is mapped into your address space). You may get memory that has previously been written by your process/program (e.g. before main()).

In your example program, you're seeing a malloc() region that hasn't yet been written by this process (i.e. it's direct from a new page) and a stack that has been written to (by pre-main() code in your program). If you examine more of the stack, you'll find it's zero-filled further down (in its direction of growth).

In both cases, you get uninitialized memory, and you can't make any assumptions about its contents.

When the OS has to apportion a new page to your process (whether that's for its stack or for the arena used by malloc()), it guarantees that it won't expose data from other processes; the usual way to ensure that is to fill it with zeros (but it's equally valid to overwrite with anything else, including even a page worth of /dev/urandom - in fact some debugging malloc() implementations write non-zero patterns, to catch mistaken assumptions such as yours).

If malloc() can satisfy the request from memory already used and released by this process, its contents won't be cleared (in fact, the clearing is nothing to do with malloc() and it can't be - it has to happen before the memory is mapped into your address space). You may get memory that has previously been written by your process/program (e.g. before main()).

In your example program, you're seeing a malloc() region that hasn't yet been written by this process (i.e. it's direct from a new page) and a stack that has been written to (by pre-main() code in your program). If you examine more of the stack, you'll find it's zero-filled further down (in its direction of growth).

If you really want to understand what's happening at the OS level, I recommend that you bypass the C Library layer and interact using system calls such as brk() and mmap() instead.

In both cases, you get uninitialized memory, and you can't make any assumptions about its contents.

When the OS has to apportion a new page to your process, it guarantees that it won't expose data from other processes; the usual way to ensure that is to fill it with zeros (but it's equally valid to overwrite with anything else, including even a page worth of /dev/urandom - in fact some debugging malloc() implementations write non-zero patterns, to catch mistaken assumptions such as yours).

If malloc() can satisfy the request from memory already used in this process, its contents won't be cleared (in fact, the clearing is nothing to do with malloc() and it can't be - it has to happen before the memory is mapped into your address space). You may get memory that has previously been written by your process/program (e.g. before main()).

In both cases, you get uninitialized memory, and you can't make any assumptions about its contents.

When the OS has to apportion a new page to your process (whether that's for its stack or for the arena used by malloc()), it guarantees that it won't expose data from other processes; the usual way to ensure that is to fill it with zeros (but it's equally valid to overwrite with anything else, including even a page worth of /dev/urandom - in fact some debugging malloc() implementations write non-zero patterns, to catch mistaken assumptions such as yours).

If malloc() can satisfy the request from memory already used and released by this process, its contents won't be cleared (in fact, the clearing is nothing to do with malloc() and it can't be - it has to happen before the memory is mapped into your address space). You may get memory that has previously been written by your process/program (e.g. before main()).

In your example program, you're seeing a malloc() region that hasn't yet been written by this process (i.e. it's direct from a new page) and a stack that has been written to (by pre-main() code in your program). If you examine more of the stack, you'll find it's zero-filled further down (in its direction of growth).