| |||||||||||
|
| |||||||||||
calloc idiocycalloc idiocyPosted Aug 12, 2005 21:33 UTC (Fri) by giraffedata (subscriber, #1954)In reply to: calloc idiocy by chad.netzer Parent article: kzalloc()
You, of course, meant to say "malloc(4 * sizeof(t))", but we get your point. I'm pretty sure he meant what he wrote; it's what I would have written, anyway: an apples to apples comparison of two hypothetical designs for calloc(), one more readable than the other. I find calloc(4, sizeof(t)) easier to read. It says rather explicitly that you're allocating space for 4 array elements, whereas calloc(4 * sizeof(t)) requires an extra mental step to go backwards through the arithmetic and say, "Aha. He's calculating how much memory a 4 element array would take." I myself do even better. I use a macro thusly:
(Log in to post comments)
calloc idiocy Posted Aug 14, 2005 2:26 UTC (Sun) by chad.netzer (subscriber, #4257) [Link] Huh? What would be the semantics of a "hypothetical" calloc(4 * sizeof(t)), and how would they be different from the malloc(4 * sizeof(t))? Clearly bronson meant to compare malloc() to calloc()bronson's point was that if using malloc() and calloc() are almost equivalent, differing by just an internal multiplication, there would seem to be little need for calloc(). It is an explicit indication that you are allocating an array (as you stated), and he argued that this was less readable for him. But:
malloc(n * sizeof(t))
and
calloc(n, sizeof(t))are NOT equivalent. The calloc() is implemented as something like:
if (n && ((n*sizeof(t))/n == n))
p = malloc(n * sizeof(t));
else
p = NULL;
Assuming I haven't made an error, this protects against n being large enough to cause an overflow (or, for example, when n is an int, and it's a small negative number). The naive malloc() call could lead to serious complications, allocating a much smaller array than the caller expected.Your macro example got garbled, so I won't comment on it.
calloc idiocy Posted Aug 14, 2005 2:50 UTC (Sun) by giraffedata (subscriber, #1954) [Link] I think you missed the fundamental distinction of calloc() from malloc(). The difference in how you specify the size is incidental. The reason calloc() exists is that it allocates memory that is set to zero ("c" is for "clear"), whereas malloc() allocates memory with arbitrary contents.I'm not sure my macro example really did get garbled. It looks fine on my screen, but does look a little funny because I tried to be consistent with the earlier example that used a one-character type name. Let me try again:
It's supposed to be two lines. The first one declares an array variable (technically a pointer, but practically an array) and the second allocates space for a 4-element array and assigns its address to that pointer. I.e. it instantiates the array. I have seen people use special "multiply and malloc" routines in order to deal with the arithmetic overflow while not taking the time to clear the memory as with calloc(). Also, these routines sometimes multiply more than two numbers together to get the size.
calloc idiocy Posted Aug 14, 2005 23:03 UTC (Sun) by chad.netzer (subscriber, #4257) [Link] Ahh, I see. I did ignore the clearing aspect in my replies; I overlooked this as the the distinction that perhaps you (and bronson) were talking about. But I hope all this does illustrate to bronson (if he or she is reading) that calloc() requires the "nmemb" argument for a reason, and that the overflow protection is easy to overlook, but an important feature of calloc().
Ok, I understand your macro example now. A compact way of doing the array allocation without the clear, and safer than malloc(n * sizeof(struct foo)). Thanks for rewriting the declaration.
Cheers.
|
|||||||||||