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?
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.
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
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.
calloc(4, 6) and calloc(6, 4) are NOT the same:
On a typical 32bit/64bit system the first would allocate 32 bytes and the second 24 bytes.
void *calloc(size_t nelem, size_t elsize);
The key point is that calloc must return the memory as if it was correctly aligned as an array. It is meant to allocate an array and be used as follows:
A *p = (A*)calloc(count, sizeof(A));
for (int i = 0; i < count; ++i)
// f(p + i) is also valid
A *p = (A*)calloc(count, sizeof(A));
for (A *q = p; q != p + count; ++q)
calloc is supposed to allocate the array taking into account padding and other operating requirements of the target system. So on most 32bit machines, where a 6 byte structure would need to be padded to 8 bytes, it would allocate 4 lots of 8 bytes.
calloc where the first argument is a sizeof() is most likely a bug and should be investigated.
calloc where the second argument is not sizeof(atype) is undefined. It reeks of hidden assumptions and is dangerous to port.
Clarification: On a typical 32bit/64bit system, a structure is likely to be padded and aligned to a multiple of 32bits. As such on these systems sizeof would not return 6 bytes. In fact there is no guarantee that the compiler would not pad and align to some multiple of 16 bytes if that is what the compiler/platform requires.
My answer is based on the fact you should not make assumptions about structure size. They can change with compiler options, or target platform. Just make sure that your second argument is a sizeof expression and don't make assumptions.
The calloc() function shall allocate unused space for an array of nelem elements each of whose size in bytes is elsize. The space shall be initialized to all bits 0.
The pointer returned if the allocation succeeds shall be suitably aligned so that it may be assigned to a pointer to any type of object and then used to access such an object or an array of such objects in the space allocated (until the space is explicitly freed or reallocated). Each such allocation shall yield a pointer to an object disjoint from any other object. The pointer returned shall point to the start (lowest byte address) of the allocated space.
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
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
malloc. Background reading.
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:
char* p1 = calloc(6, 4);
char* p2 = calloc(4, 6);
char* p3 = calloc(1,1);
printf("%p, %p, %p\n", p1, p2, p3);
The result is:
0x826b008, 0x826b028, 0x826b048
which shows that both
calloc(4,6) allocate the same amount of memory, which is rounded to 32 bytes on my system. Changing the numbers to
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(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:
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: %p\n", i, j, k, calloc(i, j));
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.
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.