Is calloc(4, 6) the same as calloc(6, 4) ?

Question

I'm a beginner C programmer, and I assumed that this would be the case, but would like some affirmation if possible.

If they are the same, why not just take one argument instead?

Answer 1

It is the same. The reason is because most of the time you want to use a sizeof operator as one of the arguments. If passing two parameters bother you, call malloc() which has a single argument.

Answer 2

People mostly use allocation routines to allocate space for a set number of items, so calloc() allows that to be specified nicely. So, for example, if you want space for 100 integers or 20 of your own structure:

int *pInt = calloc (100, sizeof(int));
tMyStruct *pMyStruct = calloc (20, sizeof(tMyStruct));

This code actually looks slightly "nicer" than the equivalent malloc() calls:

int *pInt = malloc (100 * sizeof(int));
tMyStruct *pMyStruct = malloc (20 * sizeof(tMyStruct));

although, to seasoned C coders, there's no real distinction (other than the zero initialization of course).

I have to say I have never used calloc in the wild, since I'm almost always creating a struct where zero's don't make sense. I prefer to initialize all the fields manually to ensure I get the values I want.

Answer 3

There is a slight distinction: Calloc can decide to zero-out the memory only as it is needed and then there's the advantage of knowing the size of the elements.

I can't name any implementations doing this, but it was thought for this.

As an example:

One callocates 4GB of memory, but the system has only 2GB: it wouldn't make sense to write 2GBs of zero into the virtual memory, therefore the system could set a dirty-flag on this memory to zero it out as it gets loaded into memory.

Answer 4

Despite the accepted answer (which I believe to be correct), there seems to be confusions about how many bytes are allocated due to alignment. So here's a little test on my 32-bit Linux with gcc-4.3:

#include <stdio.h>
#include <stdlib.h>

int main()
{
  char* p1 = calloc(6, 4);
  char* p2 = calloc(4, 6);
  char* p3 = calloc(1,1);
  printf("%p, %p, %p\n", p1, p2, p3);
  return 0;
}

The result is:

0x826b008, 0x826b028, 0x826b048

which shows that both calloc(6,4) and calloc(4,6) allocate the same amount of memory, which is rounded to 32 bytes on my system. Changing the numbers to calloc(3,4) and calloc(4,3) will give the following result:

0x95d2008, 0x95d2018, 0x95d2028

which shows that 16 bytes are reserved when 12 are requested and allocated to the program. In either case, both calloc(a,b) and calloc(b,a) calls have the same effect on the memory usage.

---

Added by Jonathan Leffler because 300 characters is never going to be enough.

Consider this program, which leaks memory like a veritable sieve, but demonstrates a point:

#include <stdlib.h>
#include <stdio.h>

int main()
{
    int i, j, k;

    for (i = 1; i < 17; i++)
        for (j = 1; j < 9; j++)
            for (k = 0; k < 4; k++)
                printf("(%2d,%d)%d: 0x%08X\n", i, j, k, calloc(i, j));
    return(0);
}

On Windows, under Cygwin, this starts by allocating blocks that are 16 bytes apart (actually, the second block is 24 bytes after the first, but thereafter, they are 16 bytes apart). When allocating (2,7), the block addresses start incrementing by 24 bytes; likewise, (3,4) allocates blocks 16 bytes apart, but (3,5) allocates blocks 24 bytes apart. And, for the record, both (4,6) and (6,4) return pointers 32 bytes apart.

This simply demonstrates that there is some overhead associated with an allocation call. If you look at the archetypal implementation of malloc() et al in K&R, you will see that the size of the block is stored ahead of the memory that you're entitled to use. Different implementations do these things differently; those worried about memory trampling will avoid storing control data near where the user can wreak havoc.

When you calloc(4,6), you only have reliable access to 24 bytes of data. Even if your implementation gives you return values that are 32 bytes apart, you may not safely use any more than the 24 bytes you requested. And debugging versions of malloc() will observe if you write out of the bounds you requested.

Answer 5

To the excellent responses posted, I want to add one more point of difference between using calloc(nelem, elsize) versus malloc(nelem * elsize): quality implementations of calloc will ensure that if your nelem and elsize were big enough to cause an integer overflow when multiplied together, it will fail rather than cause an undersized allocation, as a naive malloc invocation would.

Just this feature alone would be enough for me to prefer calloc to malloc. Background reading.