(I mean, let’s be honest: if we really cared about security we wouldn’t be writing in C.)
Forgive me for not taking your word for that.
The author doesn’t answer his own question. At last V3 had salloc(3) for strings. Then again in V6. Finally, in V7, we have malloc(3). And to answer the author’s question:
Needless to say, grave disorder will result if the space assigned by malloc is overrun…
So it would appear, from the manpage, that calloc(3) existed (as well as for the obvious reason of zeroing) to address this shortcoming.
This homework thanks to the UNIX tree.
Edit: as noted by Theo, overflow detection in openbsd happened in 2002 (rev 1.6), followed later by the usual stragglers. The original implementation, calloc.c, just did the multiply. So much for “grave” disorder.
It’s not clear in the article but this isn’t required behaviour of calloc() - really it’s just an implementation choice. The standard merely says “The calloc function allocates space for an array of nmemb objects, each of whose size
is size. The space is initialized to all bits zero.”
I think this is an important point. Choosing a particular implementation of calloc to reap the benefits described in the article is a good idea. However, one needs to keep in mind it may change in the future and may not be supported on other platforms.
This is probably related to a recent bug reported against the requests library on MacOS. Summarized here: https://lobste.rs/s/irigao