malloc() and free()

[Pegboy]

I need three buffers and am going to allocate memory for them, is it legal
to allocate and free the required memory with one call to malloc and free?

unsigned char *b1, *b2, *b3;

if( (b1 = (unsigned char *)malloc( 30000 )) != NULL )
{
b2 = b1 + 10000;
b3 = b2 + 10000;

/* use b1, b2 and b3 here */

free( b1 );
}

Thanks for any assistance.

 

[Ben Pfaff]

I need three buffers and am going to allocate memory for them, is it legal
to allocate and free the required memory with one call to malloc and free?

Sure. Most of the time, calls to malloc() and free() should be
balanced--one malloc(), one free().

unsigned char *b1, *b2, *b3;

if( (b1 = (unsigned char *)malloc( 30000 )) != NULL )

I don't recommend casting the return value of malloc():

* The cast is not required in ANSI C.

* Casting its return value can mask a failure to #include
<stdlib.h>, which leads to undefined behavior.

* If you cast to the wrong type by accident, odd failures can
result.

{
b2 = b1 + 10000;
b3 = b2 + 10000;

/* use b1, b2 and b3 here */

free( b1 );
}

This code looks fine.

 

[Pegboy]

Thanks for your reply.

 

[Mac]

Sure. Most of the time, calls to malloc() and free() should be
balanced--one malloc(), one free().


I don't recommend casting the return value of malloc():

* The cast is not required in ANSI C.

* Casting its return value can mask a failure to #include
<stdlib.h>, which leads to undefined behavior.

* If you cast to the wrong type by accident, odd failures can
result.


This code looks fine.

Well, the devil is in the details, as they say. If your (the OP's)
definition of using b1 involves changing its value (that is, making it
point anywhere else) then you can no longer call free with it. In fact,
you would have a memory leak at that point. (I know Ben already knows
this. He was just assuming that the OP wouldn't modify b1.)

But if you never use b1 on the left side of an assignment, or otherwise
change where it points, then you are OK.

Mac
--

 

[Barry Schwarz]

I need three buffers and am going to allocate memory for them, is it legal
to allocate and free the required memory with one call to malloc and free?

unsigned char *b1, *b2, *b3;

if( (b1 = (unsigned char *)malloc( 30000 )) != NULL )
{
b2 = b1 + 10000;
b3 = b2 + 10000;

/* use b1, b2 and b3 here */

free( b1 );
}

Absolutely. Of course you must test b1 after the malloc before using
it any computation.


<<Remove the del for email>>

 

[Scott Fluhrer]

Absolutely. Of course you must test b1 after the malloc before using
it any computation.

Maybe that's why he put the malloc within an if condition

 

[Malcolm]

I need three buffers and am going to allocate memory for them, is it
legal to allocate and free the required memory with one call to malloc
and free?

Yes, though it is generally not a good idea, since a maintaining programmer
will be puzzled that some dynamic buffers don't seem to be being freed. If
the buffers are large you will also use memory less efficiently due to the
requirement for bigger chunks.

If the buffers are not of the same type you also need to be careful about
alignment.

However if you have a large number of small arrays, maybe stored in the same
structure, then this is legal and might improve efficiency.

 

[Pegboy]

Thanks to all, all good points.

Yes, though it is generally not a good idea, since a maintaining programmer
will be puzzled that some dynamic buffers don't seem to be being freed. If
the buffers are large you will also use memory less efficiently due to the
requirement for bigger chunks.

If the buffers are not of the same type you also need to be careful about
alignment.

However if you have a large number of small arrays, maybe stored in the same
structure, then this is legal and might improve efficiency.

 

[Peter Shaggy Haywood]

Groovy hepcat Barry Schwarz was jivin' on 23 Nov 2003 02:39:47 GMT in
comp.lang.c.
Re: malloc() and free()'s a cool scene! Dig it!
^^^ ^^ ^^ ^^^^ ^

Absolutely. Of course you must test b1 after the malloc before using
it any computation.

Wakey wakey, Bazza!

--

Dig the even newer still, yet more improved, sig!

http://alphalink.com.au/~phaywood/
"Ain't I'm a dog?" - Ronny Self, Ain't I'm a Dog, written by G. Sherry & W. Walker.
I know it's not "technically correct" English; but since when was rock & roll "technically correct"?

 

[Peter Shaggy Haywood]

Groovy hepcat Malcolm was jivin' on Sun, 23 Nov 2003 09:47:48 -0000 in
comp.lang.c.
Re: malloc() and free()'s a cool scene! Dig it!

Yes, though it is generally not a good idea, since a maintaining programmer
will be puzzled that some dynamic buffers don't seem to be being freed. If
the buffers are large you will also use memory less efficiently due to the
requirement for bigger chunks.

That's usually more efficient, because it cuts down on allocation
overhead (both time and RAM).

If the buffers are not of the same type you also need to be careful about
alignment.

Even if they are of the same type. But what he's actually doing is
fine.

However if you have a large number of small arrays, maybe stored in the same
structure, then this is legal and might improve efficiency.

How would that improve efficiency when each small buffer has to be
allocated, taking time and space to do so for each one?

--

Dig the even newer still, yet more improved, sig!

http://alphalink.com.au/~phaywood/
"Ain't I'm a dog?" - Ronny Self, Ain't I'm a Dog, written by G. Sherry & W. Walker.
I know it's not "technically correct" English; but since when was rock & roll "technically correct"?