Equivalent malloc with calloc

[lovecreatesbea...]

Do you prefer malloc or calloc?

p = malloc(size);

Which of the following two is right to get same storage same as the
above call?

p = calloc(1, size);
p = calloc(size, 1);

 

[Guest]

Do you prefer malloc or calloc?

That depends on whether the memory should be initialised to all bits
zero. Sometimes it should, sometimes it shouldn't.

p = malloc(size);

Which of the following two is right to get same storage same as the
above call?

p = calloc(1, size);

Here, you're requesting enough space to store an array with 1 element
of size [size].

p = calloc(size, 1);

Here, you're requesting enough space to store an array with [size]
elements of size 1.

In the end, both calls request exactly the same size. The difference
in meaning matters only to anyone reading the code, not to the
compiler or to the computer.

 

[santosh]

Do you prefer malloc or calloc?

Usually malloc, but I also use calloc occasionally, when it's
advantageous to do so.

p = malloc(size);

Which of the following two is right to get same storage same as the
above call?

p = calloc(1, size);
p = calloc(size, 1);

Both allocate the same _amount_ of storage as the malloc call, but the
manner in which you'd, presumably, access the storage, and the manner
in which the compiler would translate your source would definitely
differ. Of course, you can always access the storage as a sequence of
bytes, but that would, IMHO, defeat the purpose of using calloc in the
first place.

 

[Richard Heathfield]

(e-mail address removed) said:

Do you prefer malloc or calloc?

It depends.

p = malloc(size);

Which of the following two is right to get same storage same as the
above call?

p = calloc(1, size);
p = calloc(size, 1);

Either.

 

[Keith Thompson]

Do you prefer malloc or calloc?

It's not a matter of preference. Use whichever one is appropriate.
But calloc() is rarely useful. The main difference is that calloc()
initilizes the allocated memory to all-bits-zero, but that makes sense
only for purely integer data.

 

[Francine.Neary]

It's not a matter of preference. Use whichever one is appropriate.
But calloc() is rarely useful. The main difference is that calloc()
initilizes the allocated memory to all-bits-zero, but that makes sense
only for purely integer data.

What about bit-fields in a struct? Wouldn't they automatically be
zeroed correctly too?

 

[Ian Collins]

It's not a matter of preference. Use whichever one is appropriate.
But calloc() is rarely useful. The main difference is that calloc()
initilizes the allocated memory to all-bits-zero, but that makes sense
only for purely integer data.

What about bit-fields in a struct? Wouldn't they automatically be
zeroed correctly too?
Bitfields are integer data.

Please don't quote signatures.

 

[Ben Pfaff]

What about bit-fields in a struct? Wouldn't they automatically be
zeroed correctly too?

Bit-fields are integer data.

 

[ilan pillemer]

It's not a matter of preference. Use whichever one is appropriate.
But calloc() is rarely useful. The main difference is that calloc()
initilizes the allocated memory to all-bits-zero, but that makes sense
only for purely integer data.

I used it when creating bitmaps. I wanted all the bytes initialised to
zero. This meant the background was black. And then I just needed to
draw what I wanted. (Which was a Sierpinkski gasket.) Otherwise I
would have to write extra code to set all the bytes to zero.

 

[Chris Dollin]

I used it when creating bitmaps. I wanted all the bytes initialised to
zero.

"Purely integer data". (IE this is a case Keith covered.)

This meant the background was black. And then I just needed to
draw what I wanted. (Which was a Sierpinkski gasket.) Otherwise I
would have to write extra code to set all the bytes to zero.

Well, yes, one call to rule them all, one call to bind them -- sorry,
that's DNS. I mean, one call to `memset`. (And buried in your
assumed-by-me "makeMyBitmap" function, so written just once anyway.)

--
JUC 2007, submit: http://hpl.hp.com/conferences/juc2007/submission.html
"What I don't understand is this ..." Trevor Chaplin, /The Beiderbeck Affair/

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England

 

[J. Sommers]

It's not a matter of preference. Use whichever one is appropriate. But
calloc() is rarely useful. The main difference is that calloc()
initilizes the allocated memory to all-bits-zero, but that makes sense
only for purely integer data.

I don't know about that. I use it all the time e.g. to deal with
strings that must be NULL-terminated.

 

[Richard Heathfield]

J. Sommers said:

I don't know about that. I use it all the time e.g. to deal with
strings that must be NULL-terminated.

(a) Strings are sequences of char, and char is an integer type, so
you're not actually disagreeing with him;
(b) strings never need to be NULL-terminated, but they do always need to
be null-terminated.

 

[Ben Pfaff]

I don't know about that. I use it all the time e.g. to deal with
strings that must be NULL-terminated.

Isn't it a bit of a waste to initialize an entire allocated block
to all-zero-bits just to ensure that a string is null-terminated?

Generally, I ensure that my strings are null-terminated by
null-terminating them.

 

[Guest]

I don't know about that. I use it all the time e.g. to deal with
strings that must be NULL-terminated.

Strings cannot ever be NULL-terminated. NULL is a pointer value.
Strings are arrays of characters. And characters, at least in C, are
integer values.

 

[Default User]

I don't know about that. I use it all the time e.g. to deal with
strings that must be NULL-terminated.

Besides what the others said, this is fairly silly in general. Unless
you're poking individual characters into a char array, this will seldom
save you anything. Almost every string-handling function takes care of
the termination for you, so it's easier and clearer to handle the few
corner cases individually.




Brian

 

[Keith Thompson]

I used it when creating bitmaps. I wanted all the bytes initialised to
zero. This meant the background was black. And then I just needed to
draw what I wanted. (Which was a Sierpinkski gasket.) Otherwise I
would have to write extra code to set all the bytes to zero.

That's one of the (fairly rare) sensible uses of calloc().

But the "extra code to set all the bytes to zero" would be nothing
more than a single call to memset(). If calloc() didn't exist, I
wouldn't miss it.

There are also some subtle points involving very large allocations.
Given calloc(x, y), if the product of x and y won't fit in a size_t,
it's up to the calloc() implementation to handle the "overflow"
sanely. But enough real-world implementations get this wrong that you
can't depend on it.

 

[CBFalconer]

J. Sommers said:
.... snip ...


(a) Strings are sequences of char, and char is an integer type, so
you're not actually disagreeing with him;
(b) strings never need to be NULL-terminated, but they do always
need to be null-terminated.

Pick, pick, pick nits. nul is the standard name.

 

[pete]

nul is the standard name.

What do you mean?

The word "nul" isn't in the C standard.

 

[J. J. Farrell]

... snip ...



Pick, pick, pick nits. nul is the standard name.

Well, if we're getting picky:

- in C it's called the "null character"
- in a lot of character sets it's called "NUL"
- in other character sets it isn't a valid character so doesn't have a
name, and in others it represents a character with a different name -
but I don't think any of these happen to be valid C source or
execution character sets
- I'm not aware of it ever being officially called "nul" or "NULL".

 

[CBFalconer]

.... snip ...

Well, if we're getting picky:

- in C it's called the "null character"
- in a lot of character sets it's called "NUL"
- in other character sets it isn't a valid character so doesn't have a
name, and in others it represents a character with a different name -
but I don't think any of these happen to be valid C source or
execution character sets
- I'm not aware of it ever being officially called "nul" or "NULL".

Look in the char tables for the various possible standard sets.
Yes, it doesn't appear in the C standard.