bpo-39943: Use calloc-based functions, not malloc+memset

[petdance]

This consolidates a number of malloc+memset function calls to use their calloc-based equivalents.

https://bugs.python.org/issue39943

[vstinner]

Once I ran some microbenchmarks and it wasn't clear if calloc() was faster than malloc()+memset(0). It should, but I failed to measure such speedup. Well, the change is correct ;-)

https://bugs.python.org/issue21233#msg217253

Sadly, pymalloc allocator has no efficient of calloc yet: it's just malloc+memset(0) in internally. But it should help for allocations larger than 512 bytes (not using pymalloc).

[petdance]

My concern wasn't speed, but in DRY and minimization of code. Still, a speedup would be nice if it happens.

[benjaminp]

If the compiler sees the memset, it may be able to generate more efficient zeroing instructions inline. I imagine it would be hard to prove any different in CPython, though.

I like calloc because it provides a way to avoid some integer overflows.

[petdance]

The memsets are still there. They're just inside the *calloc functions.

[vstinner]

The memsets are still there. They're just inside the *calloc functions.

For memory allocations larger than 512 bytes, libc malloc() is used and the libc is free to avoid memset if it knows that the memory is already initialized with zeros. I expect that memory allocated by mmap() doesn't provide uninitialized memory for example.

This change should not make slower, but it's ok if it doesn't make Python faster neither. I expect that in some cases, it may be faster. But I don't bother enough to run exhaustive microbenchmarks ;-)

I like calloc because it provides a way to avoid some integer overflows.

Sure, that's a cool enhancement since we had many security issues related to integer overflow in the past :-/