| Author |
Message |
|
Richard Chamberlai
#1 / 21
|
 dumb malloc free question Hi,
I'm using a fairly large struct in an application I'm writing and I'm using
malloc and a pointer to create an instance of it.
At some point I've done with it and therefore need to use free() to free up
the memory.
so the declaration is something like this:
struct mission *current;
so I used:
free(current);
That gave me an error which said it needed a void pointer. Ok so I cast it:
free((void *)current);
and that compiles and runs. But it kind of plays on my mind a bit :-( I may
be missing the point entirely but I don't understand how it knows the amount
of memory to free (in my struct's case 13 bytes) if free is only receiving a
void pointer. I kind of expect to have to pass the size as well.
Yours dumbly,
Richard
|
| Mon, 22 Sep 2003 16:38:02 GMT |
|
 |
|
Joona I Palast
#2 / 21
|
dumb malloc free question
Quote: > Hi,
> I'm using a fairly large struct in an application I'm writing and I'm using
> malloc and a pointer to create an instance of it.
> At some point I've done with it and therefore need to use free() to free up
> the memory.
> so the declaration is something like this:
> struct mission *current;
> so I used:
> free(current);
> That gave me an error which said it needed a void pointer. Ok so I cast it:
> free((void *)current);
> and that compiles and runs. But it kind of plays on my mind a bit :-( I may
> be missing the point entirely but I don't understand how it knows the amount
> of memory to free (in my struct's case 13 bytes) if free is only receiving a
> void pointer. I kind of expect to have to pass the size as well.
> Yours dumbly,
> Richard
The compiler most likely complained because you failed to put
#include <stdlib.h> at the top of your file, so the compiler made the
wrong assumption about the parameters for free().
About the sizes of the memory blocks - free() does indeed receive a void
pointer. It uses the value of the pointer rather than its type to find
out how much memory it should free. This information is kept in an OS-
internal lookup table you don't have to worry about. If you can ensure
every pointer you pass to free() is the result of a malloc() call,
free() will always free the correct amount of memory.
--
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"Ice cream sales somehow cause drownings: both happen in summer."
- Antti Voipio & Arto Wikla
|
| Mon, 22 Sep 2003 16:48:59 GMT |
|
|
|
Richard Chamberlai
#3 / 21
|
dumb malloc free question Thanks for the reply,
I hadn't added stdlib.h you were correct, but I still get an error if I just
pass the pointer without casting it. However from what you've said I guess I
don't need to be concerned with this and have faith that the correct amount
of memory is cleared?
One of the reasons for my concern is that the application is *supposed* to
be running for a year (it's an embedded system) and I'd hate to run out of
heap because I've not cleared my pointers correctly.
Richard
Quote:
> > Hi, > > I'm using a fairly large struct in an application I'm writing and I'm
using
> > malloc and a pointer to create an instance of it.
> > At some point I've done with it and therefore need to use free() to free
up
> > the memory.
> > so the declaration is something like this:
> > struct mission *current;
> > so I used:
> > free(current);
> > That gave me an error which said it needed a void pointer. Ok so I cast
it:
> > free((void *)current);
> > and that compiles and runs. But it kind of plays on my mind a bit :-( I
may
> > be missing the point entirely but I don't understand how it knows the
amount
> > of memory to free (in my struct's case 13 bytes) if free is only
receiving a
> > void pointer. I kind of expect to have to pass the size as well.
> > Yours dumbly,
> > Richard
> The compiler most likely complained because you failed to put
> #include <stdlib.h> at the top of your file, so the compiler made the
> wrong assumption about the parameters for free().
> About the sizes of the memory blocks - free() does indeed receive a void
> pointer. It uses the value of the pointer rather than its type to find
> out how much memory it should free. This information is kept in an OS-
> internal lookup table you don't have to worry about. If you can ensure
> every pointer you pass to free() is the result of a malloc() call,
> free() will always free the correct amount of memory.
> --
> | Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
> | http://www.helsinki.fi/~palaste W++ B OP+ |
> \----------------------------------------- Finland rules! ------------/
> "Ice cream sales somehow cause drownings: both happen in summer."
> - Antti Voipio & Arto Wikla
|
| Mon, 22 Sep 2003 17:25:14 GMT |
|
|
|
Eli Bendersk
#4 / 21
|
dumb malloc free question Quote: > Thanks for the reply, > I hadn't added stdlib.h you were correct, but I still get an error if I just
> pass the pointer without casting it. However from what you've said I guess I
> don't need to be concerned with this and have faith that the correct amount
> of memory is cleared?
> One of the reasons for my concern is that the application is *supposed* to
> be running for a year (it's an embedded system) and I'd hate to run out of
> heap because I've not cleared my pointers correctly.
it with other pointers without a cast shouldn't cause an error
IMHO. Maybe it is a problem with the compiler you're using
(so you might want to consult a NG specific to it). But you should
not worry, as the right amount of memory should be freed even
with a cast (after all, free expects void*...)
|
| Mon, 22 Sep 2003 17:34:49 GMT |
|
|
|
Nithyanandha
#5 / 21
|
dumb malloc free question Quote:
> Thanks for the reply, > I hadn't added stdlib.h you were correct, but I still get an error if I just
> pass the pointer without casting it. However from what you've said I guess I
> don't need to be concerned with this and have faith that the correct amount
> of memory is cleared?
free( ) will take care of everything...But if you are still not satisfied, try
using Purify tool( from Rational ) , to find the code where you get the issues
like memory leak, uninitialized memory read etc.
|
| Mon, 22 Sep 2003 18:02:52 GMT |
|
|
|
Richard Chamberlai
#6 / 21
|
dumb malloc free question Thanks for everyones replies.
Much appreciated,
Richard
Quote: > Hi, > I'm using a fairly large struct in an application I'm writing and I'm
using
> malloc and a pointer to create an instance of it.
> At some point I've done with it and therefore need to use free() to free
up
> the memory.
> so the declaration is something like this:
> struct mission *current;
> so I used:
> free(current);
> That gave me an error which said it needed a void pointer. Ok so I cast
it:
> free((void *)current);
> and that compiles and runs. But it kind of plays on my mind a bit :-( I
may
> be missing the point entirely but I don't understand how it knows the
amount
> of memory to free (in my struct's case 13 bytes) if free is only receiving
a
> void pointer. I kind of expect to have to pass the size as well.
> Yours dumbly,
> Richard
|
| Mon, 22 Sep 2003 18:17:57 GMT |
|
|
|
Mal Ka
#7 / 21
|
dumb malloc free question Quote:
> > Thanks for the reply,
> > I hadn't added stdlib.h you were correct, but I still get an error if I just
> > pass the pointer without casting it. However from what you've said I guess I
> > don't need to be concerned with this and have faith that the correct amount
> > of memory is cleared?
> > One of the reasons for my concern is that the application is *supposed* to
> > be running for a year (it's an embedded system) and I'd hate to run out of
> > heap because I've not cleared my pointers correctly.
> free is indeed declared to receive a void pointer, but supplying
> it with other pointers without a cast shouldn't cause an error
> IMHO. Maybe it is a problem with the compiler you're using
> (so you might want to consult a NG specific to it). But you should
> not worry, as the right amount of memory should be freed even
> with a cast (after all, free expects void*...)
Unless there is some strange coding error then the compiler is getting
it wrong. For an embedded system in a critical application I would be
very worried.
Malcolm Kay
|
| Mon, 22 Sep 2003 21:37:17 GMT |
|
|
|
Stew Murri
#8 / 21
|
dumb malloc free question As an aside, I'd be wary of dynamic memory allocation in embedded systems.
In my experience, a lot of embedded compilers don't have very robust memory
allocation schemes.
Stew
--
Stew Murrie
Quote: > Thanks for everyones replies. > Much appreciated,
> Richard
> > Hi,
> > I'm using a fairly large struct in an application I'm writing and I'm
> using
> > malloc and a pointer to create an instance of it.
> > At some point I've done with it and therefore need to use free() to free
> up
> > the memory.
> > so the declaration is something like this:
> > struct mission *current;
> > so I used:
> > free(current);
> > That gave me an error which said it needed a void pointer. Ok so I cast
> it:
> > free((void *)current);
> > and that compiles and runs. But it kind of plays on my mind a bit :-( I
> may
> > be missing the point entirely but I don't understand how it knows the
> amount
> > of memory to free (in my struct's case 13 bytes) if free is only
receiving
> a
> > void pointer. I kind of expect to have to pass the size as well.
> > Yours dumbly,
> > Richard
|
| Mon, 22 Sep 2003 19:30:08 GMT |
|
|
|
Stefan Hoehn
#9 / 21
|
dumb malloc free question Hi,
Quote:
> > > Thanks for the reply,
> > > I hadn't added stdlib.h you were correct, but I still get an error if I just
> > > pass the pointer without casting it. However from what you've said I guess I
> > > don't need to be concerned with this and have faith that the correct amount
> > > of memory is cleared?
> > > One of the reasons for my concern is that the application is *supposed* to
> > > be running for a year (it's an embedded system) and I'd hate to run out of
> > > heap because I've not cleared my pointers correctly.
> > free is indeed declared to receive a void pointer, but supplying
> > it with other pointers without a cast shouldn't cause an error
> > IMHO. Maybe it is a problem with the compiler you're using
> > (so you might want to consult a NG specific to it). But you should
> > not worry, as the right amount of memory should be freed even
> > with a cast (after all, free expects void*...)
> Unless there is some strange coding error then the compiler is getting
> it wrong. For an embedded system in a critical application I would be
> very worried.
I would agree on that. In C, implicit conversions between void* and other
pointers are valid and should not even cause a warning.
Might it be possible that he's actually using a C++-Compiler?
Stefan.
--
Never dived for a disc?
http://www.unix-ag.uni-kl.de/ultimate
|
| Mon, 22 Sep 2003 22:29:19 GMT |
|
|
|
Richard Chamberlai
#10 / 21
|
dumb malloc free question Hi,
Quote: > If you can ensure
> every pointer you pass to free() is the result of a malloc() call,
> free() will always free the correct amount of memory.
I'm not quite doing that.
My structs are used in a linked list. The function that frees the memory
creates a new struct pointer and runs throught the list finding data that is
longer required. So in effect I use this pointer in the free function rather
the pointer I originally used malloc against (that is long since pointing to
something new).
Thanks for any help,
Richard
|
| Mon, 22 Sep 2003 22:34:10 GMT |
|
|
|
Stefan Hoehn
#11 / 21
|
dumb malloc free question Hi,
Quote:
> > If you can ensure > > every pointer you pass to free() is the result of a malloc() call, > > free() will always free the correct amount of memory. > I'm not quite doing that.
> My structs are used in a linked list. The function that frees the memory
> creates a new struct pointer and runs throught the list finding data that is
> longer required. So in effect I use this pointer in the free function rather
> the pointer I originally used malloc against (that is long since pointing to
> something new).
but it points to the same place. Richard did not mean that the pointer you
call free() with has to be hold by the same variable, he has to hold just
the same value - in this case, same address - as the one which has been
returned by malloc.
E.g.
--
int * ip=malloc(sizeof *ip);
int * another_ip=ip;
free(another_ip);
--
will usually work fine.
And thats the same you do: you first assign the next-pointer of the
preceeding element in the list to be the pointer you just got from
malloc() in your insertion-routine. And you made a copy from this
next-pointer in the deletion-routine too, calling free() with it.
(Or something like that ... :-)
Still sure its nessesary to cast the return-value of malloc()? Can you
compile this without warning:
--
int main() {
int * ip;
ip=(void*)0;
return 0;
Quote: }
--
?
Stefan.
--
Never dived for a disc?
http://www.unix-ag.uni-kl.de/ultimate
|
| Mon, 22 Sep 2003 23:06:24 GMT |
|
|
|
-hs-
#12 / 21
|
dumb malloc free question Richard Chamberlain a crit dans le message ...
Quote: >I hadn't added stdlib.h you were correct, but I still get an error if I
just
>pass the pointer without casting it. However from what you've said I guess
I
Are you sure you are using a C compiler and not a C++ compiler? Is your
source file extension .c and not .C or .cpp?
Quote: >don't need to be concerned with this and have faith that the correct amount
>of memory is cleared?
Correct. The address is enough.
Quote: >One of the reasons for my concern is that the application is *supposed* to
>be running for a year (it's an embedded system) and I'd hate to run out of
>heap because I've not cleared my pointers correctly.
Working on telecom embedded systems supposed to be running during at last 10
years, I know exaclty what you mean. I suggest you test your code on a PC
with some wrapper around the malloc() / free() functions. You can implement
some trace or counter to check the malloc/free process. Not to mention
stuffs like Electric Fence, Purify or BoundCheckers.
--
-hs- "spaces, not tabs"
CLC-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
ISO-C Library: http://www.dinkum.com/htm_cl
FAQ de FCLC : http://www.isty-info.uvsq.fr/~rumeau/fclc
|
| Tue, 23 Sep 2003 04:31:34 GMT |
|
|
|
Zoran Cutur
#13 / 21
|
dumb malloc free question
.....
Quote: > As you can see from above I'm using gcc, BUT I'm not using stdlib.h but a
> malloc.h which has been supplied to us by the developer of the board. I
> guess there is a problem in their library and I've wasted everyone's time
> (it was very useful for me though) so sorry about that.
> Richard
was known to be char *. For that fact many people still use
char * as an allround argmuent for functions that don't
have to care about the type of an object, but only about
its size. You will find many implementations of malloc
and other functions that instead of using a generic pointer
still have a char-pointer.
--
"LISP is worth learning for the profound enlightenment experience
you will have when you finally get it; that experience will make you
a better programmer for the rest of your days." -- Eric S. Raymond
|
| Tue, 23 Sep 2003 15:14:58 GMT |
|
|
|
Richard Chamberlai
#14 / 21
|
dumb malloc free question That's correct in my header file is a char *.
so should I cast to a char * instead of my current (void *) instead?
Thanks,
Richard
Quote:
> ..... > > As you can see from above I'm using gcc, BUT I'm not using stdlib.h but
a
> > malloc.h which has been supplied to us by the developer of the board. I
> > guess there is a problem in their library and I've wasted everyone's
time
> > (it was very useful for me though) so sorry about that.
> > Richard
> In former (K&R C) times the generic pointer (today void *)
> was known to be char *. For that fact many people still use
> char * as an allround argmuent for functions that don't
> have to care about the type of an object, but only about
> its size. You will find many implementations of malloc
> and other functions that instead of using a generic pointer
> still have a char-pointer.
> --
> "LISP is worth learning for the profound enlightenment experience
> you will have when you finally get it; that experience will make you
> a better programmer for the rest of your days." -- Eric S. Raymond
|
| Tue, 23 Sep 2003 16:21:58 GMT |
|
| |
