LWN: Comments on "kzalloc()"

calloc idiocy

chad.netzer — 2005-08-14T23:03:55+00:00

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.

calloc idiocy

giraffedata — 2005-08-14T02:50:57+00:00

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:


  struct foo * arrayOfFooStructs;
  MALLOCARRAY(arrayOfFooStructs, 4);

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

chad.netzer — 2005-08-14T02:26:34+00:00

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

giraffedata — 2005-08-12T21:33:56+00:00

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:


    t * arrayOfT;
    MALLOCARRAY(arrayOfT, 4);

calloc idiocy

chad.netzer — 2005-08-12T06:21:23+00:00

You, of course, meant to say "malloc(4 * sizeof(t))", but we get your point.

However, what happens when n * sizeof(t) is greater than size_t? Then the request can succeed, due to overflow making a small number out of a very large number. You get a pointer to the memory you requested, but you got a much smaller amount than you expected. calloc() detects these errors and returns NULL.

Of course, you may expect that these cases are rare, and modern OSes will simply memory fault when accessing unallocated memory. However, on embedded systems, or kernel code, such memory protection may not exist, and this error can be much more problematic. If a user can somehow trick the system into generating this allocation (ie. without checking every array memory request that a user might be able to influence for overflow), you have a potential security bug. calloc() does exactly that, so it has its uses.

See this lkml post for more info:

http://marc.theaimsgroup.com/?l=linux-kernel&m=112324...

calloc()

brettlevin — 2005-08-11T22:17:28+00:00

I found a libc guru to ask.

In 4.1BSD the args to malloc and calloc were unsigned ints. There were at least some machines who had 16-bit ints, but which had more than 2^16 worth of addressable memory. In such an environment it might be useful to allocate more than 64Kb in one call.

Then POSIX changed these args to size_t, easing the size restriction.

calloc()

brettlevin — 2005-08-11T19:32:58+00:00

Does anyone know the story behind the count parameter in libc's calloc()?

kzalloc()

nathan — 2005-08-11T15:01:43+00:00

Let's not lose sight of the fact that the original two calls would still have been larger than the single kcalloc call --even with its useless parameter.

calloc idiocy

bronson — 2005-08-11T13:53:45+00:00

I have always thought that calloc/fwrite/etc's use of "nmemb" parameters was idiotic. Which is easier to read?
calloc(4, sizeof(t))
or
calloc(4 * sizeof(t))
For me, the latter. Especially with fwrite. And it's smaller and more general too.

Abolish nmemb!!