malloc vs calloc

[David Hill]

Is there a difference between:

/* code 1 */
struct sample test;
test = malloc(sizeof(s truct sample));
memset(&test, 0, sizeof(test));

/* code 2 */
struct sample test;
test = calloc(1, sizeof(struct sample));

Why would code 1 be chosen over code 2? I tend to see many instances of
code 1 in source code and hardly any instances of code 2.

Thanks
David

[Tom St Denis]

"David Hill" <da***@wmol.com > wrote in message
news:GnEpb.7407 1$275.194415@at tbi_s53...

Is there a difference between:

Troll. Didn't you just ask this?

Tom

[Arthur J. O'Dwyer]

On Tue, 4 Nov 2003, David Hill wrote:

Is there a difference between:

/* code 1 */
struct sample test;
test = malloc(sizeof(s truct sample));
Whoops! Corrected the obvious typos below:

/* code 1 */
struct sample *test;
test = malloc(sizeof *test);
memset(test, 0, sizeof *test);
/* code 2 */
struct sample *test;
test = calloc(1, sizeof *test);

Why would code 1 be chosen over code 2? I tend to see many instances of
code 1 in source code and hardly any instances of code 2.

OMMV, but I personally avoid 'calloc', along with some library
functions such as 'memmove', because I think their *exact* effects
are obscure, and I don't ever feel like reading manpages when I
don't have to.

In particular for your example, 'calloc' takes two arguments whose
order matters -- so I'd have to get that right, where with 'malloc'
I don't. Ease of use.

Secondly, 'calloc' tries to set all the newly allocated bytes to zero.
That generally takes O(n) time. Now C in general has a very close
correspondence between C-language statements and machine-level
instructions, and I feel that if I'm going to be performing a very
expensive setup step like "set this whole block to zero," that's
something that should *not* be hidden away inside a library function
call. The 'malloc'/'memset' idiom makes the cost of setting '*test'
to zero slightly more noticeable.

Those are the two big reasons I don't use 'calloc', but there's
one more: it is rarely the right tool for the job.

In fact, *neither* of those fragments is going to do what you want,
in the general case: setting a struct's bytes to all zero isn't the
same as setting each member of that struct to zero, especially when
it comes to pointers and floating-point numbers. There's no easy
way to set each member of a dynamically allocated 'struct' to zero,
though -- you have to do it one-by-one.

HTH,
-Arthur

[Ben Pfaff]

"David Hill" <da***@wmol.com > writes:

Is there a difference between:

/* code 1 */
struct sample test;
test = malloc(sizeof(s truct sample));
`test' is not a pointer, so this assignment is invalid. I will
assume you meant to declare `test' as type `struct sample *'.

When calling malloc(), I recommend using the sizeof operator on
the object you are allocating, not on the type. For instance,
*don't* write this:

int *x = malloc (sizeof (int) * 128); /* Don't do this! */

Instead, write it this way:

int *x = malloc (sizeof *x * 128);

There's a few reasons to do it this way:

* If you ever change the type that `x' points to, it's not
necessary to change the malloc() call as well.

This is more of a problem in a large program, but it's still
convenient in a small one.

* Taking the size of an object makes writing the statement
less error-prone. You can verify that the sizeof syntax is
correct without having to look at the declaration.
memset(&test, 0, sizeof(test));
`&test' would be correct if `test' didn't have a pointer type,
but since you meant it to have a pointer type (or why would you
assign it the result of malloc()) this should be changed to
memset(test, 0, sizeof *test);
/* code 2 */
struct sample test;
test = calloc(1, sizeof(struct sample));
Again, `test' needs to have a pointer type for this to be
reasonable.
Why would code 1 be chosen over code 2? I tend to see many instances of
code 1 in source code and hardly any instances of code 2.

The latter is more straightforward . It might even be faster if
the implementation has a source of pre-zeroed storage.

Often neither is portably correct, because pointer and
floating-point types, among others, need not have a null pointer
or zero value when set to all-bits-zero.
--
"I hope, some day, to learn to read.
It seems to be even harder than writing."
--Richard Heathfield

[Artie Gold]

David Hill wrote:

Is there a difference between:

/* code 1 */
struct sample test;
test = malloc(sizeof(s truct sample));
memset(&test, 0, sizeof(test));
Well, the above is just plain wrong! ITYM:

struct sample * test;
test = malloc(sizeof *test);
if (test == NULL) {
/* take appropriate action */
}
memset(test, 0, sizeof *test);

/* code 2 */
struct sample test;
test = calloc(1, sizeof(struct sample));
Same problem. ITYM:

struct sample * test;
test = calloc(1, sizeof *test);
/* appropriate test for calloc failure */


Why would code 1 be chosen over code 2? I tend to see many instances of
code 1 in source code and hardly any instances of code 2.

Considering the fact that it's wrong [;-)], I doubt it.

Once corrected, however, they are equivalent.

HTH,
--ag

--
Artie Gold -- Austin, Texas
Oh, for the good old days of regular old SPAM.

[Jack Klein]

On Mon, 3 Nov 2003 22:02:50 -0500 (EST), "Arthur J. O'Dwyer"
<aj*@nospam.and rew.cmu.edu> wrote in comp.lang.c:

On Tue, 4 Nov 2003, David Hill wrote:

Is there a difference between:

/* code 1 */
struct sample test;
test = malloc(sizeof(s truct sample));
Whoops! Corrected the obvious typos below:

/* code 1 */
struct sample *test;
test = malloc(sizeof *test);
memset(test, 0, sizeof *test);
/* code 2 */
struct sample *test;
test = calloc(1, sizeof *test);

Why would code 1 be chosen over code 2? I tend to see many instances of
code 1 in source code and hardly any instances of code 2.

OMMV, but I personally avoid 'calloc', along with some library
functions such as 'memmove', because I think their *exact* effects
are obscure, and I don't ever feel like reading manpages when I
don't have to.

You think right about calloc(), wrong about memmove(). The effects of
the latter are perfectly defined.
In particular for your example, 'calloc' takes two arguments whose
order matters -- so I'd have to get that right, where with 'malloc'
I don't. Ease of use.

The order of the arguments to calloc() does NOT matter. Nor do the
exact values. ONLY the product of the two values matters.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

[Al Bowers]

Arthur J. O'Dwyer wrote:

On Tue, 4 Nov 2003, David Hill wrote:

Is there a difference between:

/* code 1 */
struct sample test;
test = malloc(sizeof(s truct sample));

Whoops! Corrected the obvious typos below:

/* code 1 */
struct sample *test;
test = malloc(sizeof *test);
memset(test, 0, sizeof *test);
/* code 2 */
struct sample *test;
test = calloc(1, sizeof *test);

Why would code 1 be chosen over code 2? I tend to see many instances of
code 1 in source code and hardly any instances of code 2.

.....snip...... ..

In fact, *neither* of those fragments is going to do what you want,
in the general case: setting a struct's bytes to all zero isn't the
same as setting each member of that struct to zero, especially when
it comes to pointers and floating-point numbers. There's no easy
way to set each member of a dynamically allocated 'struct' to zero,
though -- you have to do it one-by-one.

You can assign a struct object the value of a static struct object.
I'm not sure if this is included in your reference of one-by-one.

#include <stdio.h>

struct test
{
int i;
double d;
int *ip;
} init;

int main(void)
{
struct test a = init;

printf("a.i = %d\na.d = %f\na.ip is%s a null pointer\n",
a.i,a.d,(a.ip== NULL)?"":" not");
return 0;
}

--
Al Bowers
Tampa, Fl USA
mailto: xa******@myrapi dsys.com (remove the x to send email)
http://www.geocities.com/abowers822/

[Robert Stankowic]

"David Hill" <da***@wmol.com > schrieb im Newsbeitrag
news:GnEpb.7407 1$275.194415@at tbi_s53...

Is there a difference between:

/* code 1 */
struct sample test;
test = malloc(sizeof(s truct sample));
memset(&test, 0, sizeof(test));

/* code 2 */
struct sample test;
test = calloc(1, sizeof(struct sample));

Why would code 1 be chosen over code 2? I tend to see many instances of
code 1 in source code and hardly any instances of code 2.

I think, zeroing a struct with either calloc() or malloc()/memset() is a Bad
Idea :). If you need just one struct, use

struct sample test = {0};

Which is guaranteed to fill all the members with the appropriate zero values
(NULL for pointers, 0.0 for floating point values etc).
And if you have to malloc() an array of structs and zero them it's better to
write something like
(snippet only, headers, #defines etc omitted)

size_t i;
struct sample empty = {0};
struct sample *test = malloc(NUMBER_O F_STRUCTS_WANTE D * sizeof *test);
if(test)
{
for(i = 0; i < NUMBER_OF_STRUC TS_WANTED; i++)
{
test[i] = empty;
}
/*do something with test*/
free(test);
}

Using an initializer gives you also the possibility to initialize your
structs to non-zero values:

struct tag_test
{
size_t size;
int available;
char some_text[SOME_SIZE];
}init_struct = {sizeof init_struct, 1, "Item"};
Robert

[Irrwahn Grausewitz]

"Tom St Denis" <to********@iah u.ca> wrote:

"David Hill" <da***@wmol.com > wrote:

Is there a difference between:
Troll.

I don't think so.
Didn't you just ask this?

No, he didn't. It was somebody else:

# From: rihad <ri***@mail.r u>
# Newsgroups: comp.lang.c
# Subject: calloc(1,1) vs. *malloc(1)=0
# Date: Thu, 30 Oct 2003 00:12:16 +0400
# Message-ID: <ai************ *************** *****@4ax.com>

Regards
--
Irrwahn
(ir*******@free net.de)

[Dan Pop]

In <Pi************ *************** ********@unix41 .andrew.cmu.edu > "Arthur J. O'Dwyer" <aj*@nospam.and rew.cmu.edu> writes:

In particular for your example, 'calloc' takes two arguments whose
order matters -- so I'd have to get that right, where with 'malloc'
I don't.
Please elaborate. What happens if you get the calloc argument order
"wrong"?
Secondly, 'calloc' tries to set all the newly allocated bytes to zero.
That generally takes O(n) time. Now C in general has a very close
corresponden ce between C-language statements and machine-level
instructions , and I feel that if I'm going to be performing a very
expensive setup step like "set this whole block to zero," that's
something that should *not* be hidden away inside a library function
call. The 'malloc'/'memset' idiom makes the cost of setting '*test'
to zero slightly more noticeable.
Isn't it still hidden away inside a library function call?
Those are the two big reasons I don't use 'calloc', but there's
one more: it is rarely the right tool for the job.

It's not that exotic to initialise an object to all zeroes at the very
point you bring it into existence. calloc can achieve this for quite a
wide range of objects (only floating point and pointers can't be
*portably* set to zero this way, but, if your code is already
non-portable, this is the least of your worries: conforming
implementations where all bits zero don't work as expected for floating
point and pointers are few and far between).

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de