3 ms·
Even on a modern non-embedded system, you aren't going to benefit from the MMU when calling calloc(). Your pages are only going to be zero'd when you first get
by mcculley 11y ago
Even on a modern non-embedded system, you aren't going to benefit from the MMU when calling calloc(). Your pages are only going to be zero'd when you first get them from mmap() or brk()/sbrk().
If you're sitting in a loop calling malloc(), filling it with data, processing it, and calling free(), changing malloc() to calloc() is just wasting cycles.
- qb45 11y agoIn fact, brk and mmap aren't even really guaranteed to return zero filled memory. It just happens that kernels often zero everything to avoid the headache of tracking which pages contain data you aren't supposed to see. I guess one can rely on such behavior when writing a platform-specific libc. But in portable code? Yuck.
- mcculley 11y agoKernels have to provide cleared memory if they don't want to leak data between processes.
- qb45 11y ago1. There is nothing inherently wrong in "leaking" a page which used to cache some word-readable file or belonged to a process you'd be able to ptrace anyway. 2. One could imagine this being configurable for embedded or HPC systems which don't care about security, though I'm not aware of people actually doing that. 3. The memory could equally well be overwritten with 0xdeadbeef and you have no control over that. 4. I once heard that Windows may sometimes fault-in nonzero pages if it runs out of pre-zeroed ones, but I couldn't locate this in MS docs so I'm not quite sure.