Why programmers don't always use calloc: good question.

Firstly, anyone who does mallocs a block, and then immediately does a memset(block, 0, size) on that block almost certainly should be using calloc. The Linux kernel has kzalloc for this purpose as an alternative to kmalloc and it's fairly widely used.

Sometimes it is inefficient to set something to zero, when that is not the true initial value (some or all of the zeros will be overwritten with the true initial value before the object is used). If you malloc some structure and then painstakingly initialize every member, then calloc is wasteful.

If you malloc some structure, and then forget to initialize some of the members, calloc will hide that bug by initializing them to all zero bits. This might not be the correct value. If the uninitialized parts of the structure aren't clobbered from zeros, you can get an accurate diagnostic about that from a tool like Valgrind. On the other hand, if you aren't using that tool, the behavior with zeros is more deterministic. E.g. if a pointer is not initialized, but overwritten with zeros, on most mainstream platforms that will be a null pointer whose dereferencing uses are detected. If you don't have such a tool available, having the uninitialized bits be all zero is arguably better.

Much of this reasoning mirrors reasoning about whether to initialize a local variable to zero, if its true initialization actually happens later.

In my experience using malloc over calloc make it much harder to find subtle bugs that result from off by one under set errors (i.e. you malloc 100 bytes, only set 99, and then you later read 100 bytes). When you use malloc the 100th byte is filled with random garbage, while with calloc you get something consistent.

Finding bugs where you write 101 bytes are easy to find with tools like Valgrind, but finding bugs where you malloc and don’t initialise the data structure correctly are a real pain.

Valgrind will tell you about reading that 100th uninitialized byte.

Probably the best reason to hate it is if you didn't include the right headers and malloc is therefore implicitly defined to return int. That creates a bug on most 64-bit compilers where int is 32 bits. The cast will mask the bug.

But more stylistically, let's be honest, something like this is way too verbose:

    struct foo *bar = (struct foo*)malloc(sizeof(struct foo));

I see code like this often, and I think the only explanation I can think of is that people don't know the language well enough to write:

    struct foo *bar = malloc(sizeof(*bar));

> A related question is why do people use malloc if calloc is available?

Seems like a very different question... calloc multiplies, calls malloc, and zeros. I guess if you don't want to multiply, don't want to zero, don't want to bother specifying another parameter, some combination of these, then malloc might be a better choice. Though I do recall a few years back the OpenBSD folks (possibly others too?) focusing on making sure calloc checks for overflow when it multiplies. [See also: reallocarray]

Any decent C compiler has a warning for the situation that an external function is called without a prototype declaration having been seen.

GCC also has diagnostics for when a function definition occurs without a declaration.

From GCC man page:

       -Wmissing-prototypes (C and Objective-C only)
           Warn if a global function is defined without a previous prototype
           declaration.  This warning is issued even if the definition itself
           provides a prototype.  The aim is to detect global functions that
           fail to be declared in header files.

       -Wstrict-prototypes (C and Objective-C only)
           Warn if a function is declared or defined without specifying the
           argument types.  (An old-style function definition is permitted
           without a warning if preceded by a declaration which specifies the
           argument types.)

       -Wimplicit-function-declaration (C and Objective-C only)
           Give a warning whenever a function is used before being declared.
           In C99 mode (-std=c99 or -std=gnu99), this warning is enabled by
           default and it is made into an error by -pedantic-errors. This
           warning is also enabled by -Wall.

If you turn on wall you should be warned that you didn’t include the right headers?

I was under the impression that lots of implementations of malloc actually call calloc under the hood. Unless you are calling malloc in a tight loop I can’t see the extra step of zeroing being a issue. In one of my programs where performance is critical I changed over all my mallocs to calloc and couldn’t measure the time change - I did find I had fewer difficult-to-duplicate bugs though.

Edit. Interestingly CERT recommends casting [1]. Seems to solve a much worse issue than forgetting to include stdlib.h

1. https://www.securecoding.cert.org/confluence/display/c/MEM02...