What is the advantage of malloc over calloc

[deepu]

Please reply...

 

[Jack Klein]

Please reply...

Please define "better".

 

[deepu]

What is the advantage of malloc over calloc. i.e. since malloc exists
to perform the memory operations why calloc is needed. Asked in an
interview.

 

[pete]

What is the advantage of malloc over calloc.

It's possible that malloc might be smaller and faster.

i.e. since malloc exists
to perform the memory operations why calloc is needed.

Because calloc does something that malloc doesn't do.

Asked in an interview.

The two questions are non sequitors.

 

[Ian Collins]

What is the advantage of malloc over calloc. i.e. since malloc exists
to perform the memory operations why calloc is needed. Asked in an
interview.

Do you know the difference between the two? Hint, one zeros the
allocated memory, which may or may not be an advantage.

 

[Keith Thompson]

Do you know the difference between the two? Hint, one zeros the
allocated memory, which may or may not be an advantage.

Keep in mind that zeroing memory won't necessarily do anything useful
for pointers or floating-point objects. (Worse yet, it very commonly
will set them to NULL and 0.0, respectively, which can make certain
bugs very difficult to find.)

 

[Chris McDonald]

Keep in mind that zeroing memory won't necessarily do anything useful
for pointers or floating-point objects. (Worse yet, it very commonly
will set them to NULL and 0.0, respectively, which can make certain
bugs very difficult to find.)

Sorry, I'm confused as to why you've described this as potentially not
useful. (without restarting the discussion thread of whether NULL is
always zero) surely by calling calloc() the allocated space is provided
in an initialized state? Yes, your program may not *want* NULLs and
0.0s, but knowing what they are, and why they were set to that value,
must be better than the uninitialized contents provided by malloc(). ?

 

[Richard Tobin]

Yes, your program may not *want* NULLs and
0.0s, but knowing what they are, and why they were set to that value,
must be better than the uninitialized contents provided by malloc(). ?

Why? If your program has no bugs, then you will not use these values,
so it makes no difference what they are. If your program does have
bugs, then random values may well cause the error to be spotted sooner
than null pointers and 0.0 floats.

A real example: when shared libraries were added to SunOS, several
programs (standard unix commands) were found that had been unwittingly
relying on automatic variables being initialised to zero. This showed
up because the dynamic loading used the stack before main() was
called.

Some malloc implementations have an option to "scribble" over memory
before mallocing and after freeing, to increase the likelihood of
errors being detected.

-- Richard

 

[Richard G. Riley]

Keep in mind that zeroing memory won't necessarily do anything useful
for pointers or floating-point objects. (Worse yet, it very commonly
will set them to NULL and 0.0, respectively, which can make certain
bugs very difficult to find.)

Could you expand on this a little. How on earth can it not be useful
to zero a block of memory if that is the intent? What do you mean by
"it will commonly set then to NULL"? of course it would : its zeroing
memory (e.g zeroing a block of char **).

 

[Richard G. Riley]

Why? If your program has no bugs, then you will not use these

values,

Unless of course the zeroed memory was to hold a set of pointers and a
non null value indicates a valid pointer.

so it makes no difference what they are. If your program does have
bugs, then random values may well cause the error to be spotted sooner
than null pointers and 0.0 floats.

A real example: when shared libraries were added to SunOS, several
programs (standard unix commands) were found that had been unwittingly
relying on automatic variables being initialised to zero. This showed
up because the dynamic loading used the stack before main() was
called.

But this does not in any way invalidate the need/requirement for auto
zeroing in a memory allocation call.

 

[Chris McDonald]

Why? If your program has no bugs, then you will not use these values,
so it makes no difference what they are. If your program does have
bugs, then random values may well cause the error to be spotted sooner
than null pointers and 0.0 floats.

A real example: when shared libraries were added to SunOS, several
programs (standard unix commands) were found that had been unwittingly
relying on automatic variables being initialised to zero. This showed
up because the dynamic loading used the stack before main() was
called.

Some malloc implementations have an option to "scribble" over memory
before mallocing and after freeing, to increase the likelihood of
errors being detected.

Thanks for the reply Richard (and an interesting SunOS example).

I'm not comfortable with the approach that assuming, or relying upon,
random values *may* trigger bugs in code. I understand why this may
be effective, as you've described, but surely calling calloc() could
be more effective in helping to isolate one of those bugs in the first
place, by provided a known state from which to start that debugging.

One could also argue that setting pointers to NULL values is more likely
to trigger unknown pointer bugs, than if they just had random values
where 1 in 4, or 1 in 8, may just work.

 

[Chris Dollin]

Could you expand on this a little. How on earth can it not be useful
to zero a block of memory if that is the intent?

Because it's not /guaranteed/ to do so for non-integer types.

What do you mean by
"it will commonly set then to NULL"? of course it would : its zeroing
memory (e.g zeroing a block of char **).

There is no requirement that the bytes of a null pointer be zeroes.
A program that assumes that there is - because it's been tried on
machines where null pointers have zero bytes - will likely break
when it encounters an implementation where null pointers have interesting
bit-patterns.

[Note that the standard /does/ require that a null pointer compare equal
to a literal 0; this is not the same case.]

 

[Richard G. Riley]

Because it's not /guaranteed/ to do so for non-integer types.

I have no idea how this came up : when I said "intent" clearly the
intent (with the example) was to zero banks of pointers. I agree that
for non integer types that 0s dont necessarily compute to 0..

To sum up : of course calloc is useful

 

[Richard G. Riley]

Thanks for the reply Richard (and an interesting SunOS example).

I'm not comfortable with the approach that assuming, or relying upon,
random values *may* trigger bugs in code. I understand why this may
be effective, as you've described, but surely calling calloc() could
be more effective in helping to isolate one of those bugs in the first
place, by provided a known state from which to start that debugging.

I would agree and was going to write the same.

One could also argue that setting pointers to NULL values is more likely
to trigger unknown pointer bugs, than if they just had random values
where 1 in 4, or 1 in 8, may just work.

Again : I agree.

The only issue being (and I'm not sure how it was raised since it
seemd a bit of a strawman to knock calloc) that zeroed memory isnt't
always what might be intended if real "0" values were intended :
although more theory than practice in real world IMO since one of the
only reasons I would use calloc would be to initialise pointer blocks.

 

[Chris Dollin]

I have no idea how this came up : when I said "intent" clearly the
intent (with the example) was to zero banks of pointers. I agree that
for non integer types that 0s dont necessarily compute to 0..

Pointers are not integer types. callocing memory which is then treated
as pointer values, without pointer values being assigned into it,
/doesn't/ guarantee that the memory reads as null pointers.

To sum up : of course calloc is useful

For some things. I don't believe I've ever had a use for it, but I
don't write /that/ much C code (nowadays): usually I wanted to put
non-zero things into my mallocated space.

 

[Richard G. Riley]

There is no requirement that the bytes of a null pointer be zeroes.
A program that assumes that there is - because it's been tried on
machines where null pointers have zero bytes - will likely break
when it encounters an implementation where null pointers have interesting
bit-patterns.

[Note that the standard /does/ require that a null pointer compare equal
to a literal 0; this is not the same case.]

I must say that in many years of programming it is the first time I
have come across this. I stand corrected. Makes me wonder about the
usefulness of calloc after all.

Do you know of a platform where "Null" pointers did not cast to zero?

 

[Chris McDonald]

The only issue being (and I'm not sure how it was raised since it
seemd a bit of a strawman to knock calloc) that zeroed memory isnt't
always what might be intended if real "0" values were intended :
although more theory than practice in real world IMO since one of the
only reasons I would use calloc would be to initialise pointer blocks.

(good to have a sensible discussion).

I know it's all about standard C here, and that history can't be changed,
but I'd suggest that much C programming may be 'easier' if the default
function of choice was calloc(), which always zeroes memory, and for those
that require it, a function named randalloc() be available which fills
memory with random, or hazardous, bytes (if memset() is insufficient).

 

[Richard G. Riley]

(good to have a sensible discussion).

I know it's all about standard C here, and that history can't be changed,
but I'd suggest that much C programming may be 'easier' if the default
function of choice was calloc(), which always zeroes memory, and for those
that require it, a function named randalloc() be available which fills
memory with random, or hazardous, bytes (if memset() is insufficient).

of course. And further more "relying" on malloc to provide "random
values" is pie in the sky. The mallocd memory may well already be 0s
or some continuous memory check pattern.

 

[pete]

Makes me wonder about the
usefulness of calloc after all.

The only time I've been tempted to use calloc,
is when working with strings.
But as the code evolved, it always turned out for me,
that using calloc wasn't necessary.

I have no examples of calloc use in my C code archives.

 

[Chris Dollin]

There is no requirement that the bytes of a null pointer be zeroes.
A program that assumes that there is - because it's been tried on
machines where null pointers have zero bytes - will likely break
when it encounters an implementation where null pointers have interesting
bit-patterns.

[Note that the standard /does/ require that a null pointer compare equal
to a literal 0; this is not the same case.]

I must say that in many years of programming it is the first time I
have come across this. I stand corrected. Makes me wonder about the
usefulness of calloc after all.

Do you know of a platform where "Null" pointers did not cast to zero?

Casting is something else again [1]: the issue above was about whether
a pointer with all bytes (or bits) zero was necessarily a null pointer.

If I remember Chris Torek's posts on this subject correctly, the Prime
series of computers had null pointers which had set bits in them (for
capabilities). Hence callocated memory treated as pointers would have
illegal values in, or values pointing /at/ something - but they would
not be /null/ ....