It still does, because it future proofs you against a change in the future that separates the allocation from completely filling the memory, and saves you from future programmers who don&#x27;t realize that only half-filling the memory could have catastrophic security or correctness consequences. It also harmonizes the programmer&#x27;s mental model (which has generally always assumed that newly-allocated memory is &quot;clean&quot; even when on some level we theoretically know better [1]) with the execution model, which is also a good thing.<p>I&#x27;d very much recommend that advice; use it all the time, remove it only when it proves to be a problem, and then, as always when optimizing, bear in mind that you&#x27;ve chosen to juggle lit sticks of dynamite and prepare accordingly.<p>[1]: I hypothesize that this is because what &quot;really&quot; comes back from a malloc is basically too impossibly complicated to model by a human. Even calling it &quot;random&quot; isn&#x27;t correct; it&#x27;s not random, but what it is is very hard to characterize.