Is calloc better than malloc?

Question

I have just learned about the C calloc() function the other day. Having read its description and how it differs from malloc (1, 2), I get the idea that, as a non-embedded programmer, I should always use calloc(). But is that really the case?

One reservation I have is the extra delay for accessing the calloc()-ed memory, but I also wonder if there are cases when switching from malloc() to calloc() will break the program in some more serious way.

P. S. The zero-initializing aspect of calloc() is quite clear to me. What I'm interested in learning about is the other difference between calloc() and malloc() - lazy memory allocation provided by calloc(). Please don't post an answer if you're going to focus purely on the memory initialization aspect.

C or C++? In C++ manual memory allocations, espcially the *alloc functions are frowned upon. — NathanOliver, Dec 21 '16 at 13:06
The general rule is that if you have a problem P you use a solution X that solves P, and not Y that happens to solve P as a side effect. There's no substitute for critical thinking; programming by recipe book rarely works. — Kerrek SB, Dec 21 '16 at 13:07
If it's for memory you don't need zero-initialized, why even chance paying extra for it? — StoryTeller - Unslander Monica, Dec 21 '16 at 13:08
How should `calloc` break any program that works fine with `malloc`? Everyone who uses `malloc` should be aware that he cannot rely on the content of the buffer. If it happens to be all zeroes that is just one possible result of random content. — Gerhardh, Dec 21 '16 at 13:09
@NathanOliver: I'm a C++ programmer, thought I'd also add the `C` tag because the question is about `C` functions. I'm well aware of C++ memory management best practices, but there's one case when I feel `malloc` is the best way to allocate memory: when I need to allocate a buffer of a fixed size that's encapsulated in one of my classes. — Violet Giraffe, Dec 21 '16 at 13:09
@VioletGiraffe - You'll have to run that by me to see the merit of `malloc`. I'll just use `::operator new` if I really have to. — StoryTeller - Unslander Monica, Dec 21 '16 at 13:10
@VioletGiraffe If you need a fixed sized buffer `std::unique_ptr` is the way I would go. Now you have built in memory management. — NathanOliver, Dec 21 '16 at 13:10
@NathanOliver: and runtime overhead. But yeah, I get the point. — Violet Giraffe, Dec 21 '16 at 13:15
@VioletGiraffe What run time overhead? If you have a manually allocated pointer you still have to delete it at some point. `std::unique_ptr` just binds that deletion to the pointers scope so you do not have to remember about it. a `std::unique_ptr` with a default deleter should be just as efficient as doing it yourself with the benefit of not really being able to get it wrong. — NathanOliver, Dec 21 '16 at 13:18
@NathanOliver: Is there no additional overhead in the unique pointer? No service structures, no thread-safety mechanisms? I have a hard time believing it's merely `class unique_ptr {T* _ptr};` — Violet Giraffe, Dec 21 '16 at 13:27
@NathanOliver: In the interest of full disclosure, it's worth looking at the actual runtime cost that unique_ptr has over raw pointers: The facility for dynamic ownership transfer has a dynamic cost, namely something like `p = make_unique<...>(...);` needs to perform a null check on `p` first, even if you statically know already that it is null. Moreover, passing unique pointers across function calls in inferior on the Itanium ABI, because the object has to go on the stack, while a raw pointer is passed in a register. (That's an implementation mistake, not a design mistake, but still.) — Kerrek SB, Dec 21 '16 at 13:31
@VioletGiraffe It pretty much is like you have it. There is no thread safety, no atomic reference counting, no null checks, It is meant to be as light weight as possible. It does store the deleter in the structure but thanks to empty base class optimization if it is just a empty deleter like a call to `delete[]` then that doesn't even make the size of the pointer bigger. In gcc `sizeof(std::unique_ptr)` is `8` which is the same size as a single pointer(64 bit). — NathanOliver, Dec 21 '16 at 13:32
@NathanOliver: Of course all this is very rarely significant compared to the enormous conceptual advantage that type-based ownership semantics afford us. — Kerrek SB, Dec 21 '16 at 13:32
You don't care about performance until you know where your bottleneck is. — n. m. could be an AI, Dec 21 '16 at 14:05
@n.m.: that approach often results in a program that's one large bottleneck as a whole, possibly with no clearly defined hot spots. Having said that - yes, early optimization is evil. — Violet Giraffe, Dec 21 '16 at 14:20

Sourav Ghosh · Answer 1 · 2016-12-21T13:37:06.477

This is really a situation-dependent decision. Rule of thumb is

If you're first writing into the allocated memory, malloc() is better (less possible overhead).

Example: Consider the following scenario
```
char * pointer = NULL;

//allocation

strcpy(pointer, source);
```
here, allocation can be very well using malloc().
If there's a possibility of read-before-write with the allocated memory, go for calloc(), as it initializes memory. This way you can avoid the problem with unitialized memory read-before-write scenario which invokes undefined behavior.

Example:
```
char * pointer = NULL;

//allocation

strcat(pointer, source);
```
Here, strcat() needs the first argument to be a string already, and using malloc() to allocate cannot guarantee that. As calloc() zero-initializes the memory, it will serve the purpose here and thus, calloc() is the way to go for this case.

To elaborate the second scenario, quoting from C11, chapter §7.24.3.1 (follow my emphasis)

The strcat() function appends a copy of the string pointed to by s2 (including the terminating null character) to the end of the string pointed to by s1. The initial character of s2 overwrites the null character at the end of s1. [....]

So, in this case, the destination pointer should be a pointer to a string. Allocating via calloc() guarantees that while allocating using malloc() cannot guarantee that, as we know, from chapter §7.22.3.4

The malloc function allocates space for an object whose size is specified by size and whose value is indeterminate.

EDIT:

One possible scenario where malloc() is advised over calloc(), is writing test stubs used for unit / integration testing. In that case, use of calloc() can hide potential bugs which arrive with cases similar to the later one.

The zero-initialization aspect is quite clear. But what about lazy memory allocation that `calloc()` provides? — Violet Giraffe, Dec 21 '16 at 13:26
@VioletGiraffe AFAIK, that is the property of the memory allocator, and applicable equally with `malloc()` and /or `calloc()` for a particular platform. Can you elaborate? — Sourav Ghosh, Dec 21 '16 at 13:32
The links are in my question: http://stackoverflow.com/a/2688522/634821 and https://vorpus.org/blog/why-does-calloc-exist/ — Violet Giraffe, Dec 21 '16 at 13:42
If you need the first character in a `char` array to be `'\0'`, just do it. `calloc` is overkill for such a simple initialization. — Pete Becker, Dec 21 '16 at 13:42
@PeteBecker that was one example scenario, we can find more complex scenarios for sure where we need the whole memory to be initialized. :) — Sourav Ghosh, Dec 21 '16 at 13:44

score 3 · Answer 2 · answered Dec 21 '16 at 13:09

The main difference between malloc and calloc is that calloc will zero-initialize your buffer, and malloc will leave the memory uninitialized.

This gets to the common programming idiom of "don't pay for what you don't use". In other words, why zero-initialize something (which has a cost) if you don't necessarily need to (yet)?

As a side note since you tagged C++: manual memory usage using new/delete is frowned upon in modern C++ (except in rare cases of memory pools, etc). Use of malloc/free is even more rare and should be used very sparingly.

score 2 · Answer 3 · edited May 23 '17 at 12:32

Use calloc for zero-filled allocations, but only when the zero-filling is really needed.

You should always use calloc(count,size) instead of buff=malloc(total_size); memset(buff,0,total_size).

The call to zero-memset is the key. Both malloc and calloc are translated into OS calls which do lots of optimizations, use hardware tricks whenever possible, etc. But there is little that OS can do with memset.

On the other hand, when do you need to zero-fill the allocated memory? The only common use is for zero-ended arbitrary length elements, such as C-strings. If that's the case, sure, go with calloc.

But if you allocate the structures in which the elements are either fixed-length or carry the length of arbitrary-sized elements with them (such as C++ strings and vectors), zero-filling is not helpful at all, and if you try to rely on it, it can lead to tricky bugs.

Suppose you write your custom linked list, and decide to skip the zeroing of the pointer to the next node by allocating the memory for the node with calloc. It works fine, then someone uses it with custom placement new, which doesn't zero-fill. Trouble is, sometimes it will be zero-filled, and can pass all the usual testing, go in production, and there it will crash, crash sometimes, the dreaded unrepeatable bug.

For debug purposes, zero-filling is usually not that good, either. 0 is too common, you rarely can write something like assert(size); because it's usually a valid value, too, you handle it with if(!size), not with asserts. On the debugger it won't catch your eye, either, there are usually zeros everywhere in your memory. The best practice is to avoid unsigned types for the lengths (signed lengths can be useful for runtime error handling and some of the most common overflow checks, too). So, while buff=malloc(total_size); memset(buff,0,total_size) is to be avoided, the following is OK:

const signed char UNINIT_MEM=MY_SENTINEL_VALUE;
buff=malloc(total_size);
#if DEBUG_MEMORY
memset(buff,UNINIT_MEM,total_size);
#endif

In debug mode, runtime library or even OS do this for you sometimes, for example check this excellent post on VC++-specific sentinel values.

score 1 · Answer 4 · answered Dec 21 '16 at 13:07

1

It's all about what you want to do with the memory. malloc returns uninitialized (and possibly not even real yet) memory. calloc return real, zero'ed memory. If you need it zero'ed, then yes, calloc is your best option. If you don't, why pay for zero'ing with a latency hit when you don't need it?

answered Dec 21 '16 at 13:07

Paul Evans

27,315
3
37
54

I'm more interested in lazy allocation that `calloc()` provides. – Violet Giraffe Dec 21 '16 at 13:25
1

@VioletGiraffe Then you definitely want `malloc`. On Linux `malloc` returns a pointer not even pointing to real memory. The memory becomes real the first time the program accesses it. – Paul Evans Dec 21 '16 at 13:38
@VioletGiraffe calloc() doesn't do lazy allocation on any common platform as of yet. malloc() however does. – nos Dec 21 '16 at 13:42
@nos: I have links to two articles (well, an article and an SO answer) in my question that state otherwise. Are they false? – Violet Giraffe Dec 21 '16 at 13:43

score 1 · Answer 5 · answered Dec 22 '16 at 09:25

malloc() is far more common in C code than calloc().

A text search for "malloc" will miss the calloc() calls.

Replacement libraires will often have mymalloc(), myrealloc(), myfree() but not mycalloc().

Zero-initialisation of pointers and reals isn't actually guaranteed to have the expected effect, though on every major platform all bits zero is NULL for a pointer and 0.0 for a real.

calloc() tends to hide bugs. Debug malloc usually sets a fill pattern like DEADBEEF which evaluates to a large negative number and doesn't look like real data. So the program quickly crashes and, with a debugger, the error is flushed out.

Is calloc better than malloc?

5 Answers5