> As long as Apple's allocator continues to zero freed memory, programs accidentally depending on that behavior will only be a problem for other operating systems.

As I mentioned, only until that freed block is reused for a new allocation, which means it will no longer be all-zeros; or until the memory allocator decides it's time to unmap that region, which means it will trap (SIGSEGV or similar).

Memory allocators generally don't unmap anything, because the performance hit on any other threads running is severe.

When memory is unmapped, caches of memory mappings of other threads are discarded, via inter-core interrupts. Then they get misses until their cache is restored.

In what might be a multi-thread program, you don't fool with the memory map without very good reasons. Mapping new pages, or marking a page r/o or r/w is OK; anything else, probably not.

> When memory is unmapped, caches of memory mappings of other threads are discarded, via inter-core interrupts.

ARM architecture does not need to interrupt for TLB shootdown.

> which means it will trap

Is it really a problem? Failing harder and earlier is a good thing if it means the bug has more chances of being detected and fixed.

Possibly but there's the potential reverse problems where Apple programs start depending on newly allocated memory being zero .... and those programs start failing elsewhere ...

Well the change is to zero out memory on deallocation. So on allocation it may or may not be zero depending on whether it was previously freed, right?

not necessarily, even if was freed there might be defragged free blocks that still contain heap metadata by the time it gets reallocated

Might fail there, too, but only sometimes, if the memory gets allocated again.

Or until the particular allocation moves to a custom/separate heap or other non-system-malloc allocator. That sort of tuning is very common in big apps.