Difference between {0} and calloc? - c

Question

As this answer on another question covers, using an aggregate initialization
struct foo {
size_t a;
size_t b;
};
struct foo bar = {0};
results in built-in types being initialized to zero.
Is there any difference between using the above and using
struct foo * bar2 = calloc(1, sizeof(struct foo));
leaving aside the fact that one variable is a pointer.
Looking at the debugger we can see that both a and b are indeed set to zero for both of the above examples.
What's the difference between two above examples, are there any gotchas or hidden issues?

Answer 1

Yes, there is a crucial difference (aside from storage-class of your object of type struct foo):
struct foo bar = {0};
struct foo * bar2 = calloc(1, sizeof *bar2);
Every member of bar is zero-initialized (and the padding is zeroed out for sub-object without initializer, or if bar is of static or thread_local storage-class),
while all of *bar2 is zeroed out, which might have completely different results:
Neither null-pointers (T*)0 nor floating-point-numbers with value 0 are guaranteed to be all-bits-0.
(Actually, only for char, unsigned char and signed char (as well as some of the optional exact-size-types from <stdint.h>) it is guaranteed that all-bits-0 matches value-0 till some time after C99. A later technical corrigenda guaranteed it for all integral types.)
The floating-point-format might not be IEEE754.
(On most modern systems you can ignore that possibility though.)
Cite from c-faq (Thanks to Jim Balter for linking it):
The Prime 50 series used segment 07777, offset 0 for the null pointer, at least for PL/I.

Answer 2

struct foo bar = {0};
This defines an object of type struct foo named bar, and initializes it to zero.
"Zero" is defined recursively. All integer subobjects are initialized to 0, all floating-point subobjects to 0.0, and all pointers to NULL.
struct foo * bar2 = calloc(1, sizeof(struct foo));
IMHO this is better (but equivalently) written as:
struct foo *bar2 = calloc(1, sizeof *bar2);
By not repeating the type name, we avoid the risk of a mismatch when the code is changed later on.
This dynamically allocates an object of type struct foo (on the heap), initializes that object to all-bits-zero, and initializes bar2 to point to it.
calloc can fail to allocate memory. If it does, it returns a null pointer. You should always check for that. (The declaration of bar also allocates memory, but if it fails it's a stack overflow, and there's no good way to handle it.)
And all-bits-zero is not guaranteed to be the same as "zero". For integer types (including size_t), it's very nearly guaranteed. For floating-point and pointer types, it's entirely legal for 0.0 or NULL to have some internal representation other than all-bits-zero. You're unlikely to run into this, and since all the members of your structure are integer you probably don't need to worry about it.

Answer 3

calloc gives you a heap dynamically allocated zeroed memory zone (into your bar2). But an automatic variable (like bar, assuming its declaration is inside a function) is allocated on the call stack. See also calloc(3)
In C, you need to explicitly free heap allocated memory zone. But stack allocated data is popped when its function is returning.
Rerad also wikipage on C dynamic memory allocation, and on garbage collection. Reference counting is a widely used technique in C and in C++, and could be viewed as a form of GC. Think about circular references, they are hard to handle.
The Boehm conservative GC can be used in C programs.
Notice that the liveness of a memory zone is a global program-wide property. You generally cannot claim that a give zone belongs to a particular function (or library). But you could adopt conventions about that.
When you code a function returning a heap-allocated pointer (i.e. some pointer to dynamic storage) you should document that fact and decide who is in charge of freeing it.
About initialization: a calloc pointer is zeroed (when calloc succeeds). An automatic variable initialized as {0} is also zeroed. In practice, some implementations may calloc differently big objects (by asking whole zeroed pages from the kernel for them, e.g. with mmap(2)) and small objects (by reusing, if available, a previously free-d zone and zeroing it). zero-ing a zone is using a fast equivalent of memset(3)
PS. I am ignoring the weird machines on which an all zero-bit memory zone is not a cleared data for the C standard, i.e. like {0}. I don't know such machines in practice, even if I know they are in principle possible (and in theory the NULL pointer might not be an all-zero-bit word)
BTW, the compiler may optimize an all-zero local structure (and perhaps not allocate it at all on the stack, since it would fit in registers).

Answer 4

(This answer focuses on the differences in initialization, in the case of a struct only containing integral types)
Both forms set a and b to 0. This is because the Standard defines that all-bits-zero for an integral type must represent a value of 0.
If there is structure padding, then the calloc version sets that but the zero-initialization may not. For example:
struct foo a = { 0 }, b = { 0 };
struct foo c, d; memset(&c, 0, sizeof c); memset(&d, 0, sizeof d);
if ( memcmp(&a, &b, sizeof a) )
printf("This line may appear.\n");
if ( memcmp(&c, &d, sizeof c) )
printf("This line must not appear.\n");
A technique you will sometimes see (especially in code designed to fit on systems with small amounts of storage) is that of using memcmp to compare two structs for equality. When there is padding between structure members, this is unreliable as the padding may be different even though the structure members are the same.
The programmer didn't want to compare structure members individually as that is too much code size, so instead, he will copy structs around using memcpy, initialize them using memset; in order to preserve the ability to use memcmp to check for equality.
In modern programming I'd strongly advise to not do this; and to always use the { 0 } form of initailization. Another benefit of the latter is that there is no chance of making a mistake with the size argument and accidentally setting too much memory or too little memory.

Answer 5

There is a serious difference: allocation of automatic variables is done at compile-time and comes for free (when the stack frame is reserved, the room is there.) On the opposite, dynamic allocation is done at run-time and has an unpredictible and non neglectible cost.
As regards initialization, the compiler has opportunities for optimization with automatic variables (for instance by not clearing if unnecessary); this is not possible with a call of calloc.
If you like the calloc style, you also have the option of performing memset on the automatic variable.
memset(&bar, 0, sizeof bar);
UPDATE: allocation of automatic variables is quasi-done at compile-time.