Re: malloc/free aimple question!
Hello David,
Thanks for getting back!
That is fine, (ish) but only one of them can "own" the data.
My original post doesn't show p and x as members in structures as done in
the real program, but to keep things simple lets continue basing our
discussion on the original sample code of this post. So, therefore, doing
this would be okay?
========================
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main()
{
int a;
long *p, *x;
p = malloc(10 * sizeof(long));
x = p;
// do stuff with x ...
x = NULL;
// do stuff with p ...
free(p);
// other code here...
return 0;
}
===========================
So if I understand right, and this was how I always saw it:
a) declare a local pointer
b) malloc the pointer right a way or assign it to null until I am ready to
assign an address to it or an address from malloc.
c) once we finished with it, if its a pointer that was assigned from malloc,
then free it OR if its a pointer variable.... then null it!
d) Another altenative for a pointer variable once we finished with it, let
the pointer destroy itself by exiting the function... (in this case don't
need to null it)!
Sometimes keeping track of an owner of data and other objects which only
contain access to it, is a useful approach, but it has to be done with care.
Unfortunately, I have no choice of having p as the owner and x as one that
only has access to the data. Unfortunately, its just because it is the way I
went about things!
Anyhow, David, the bug I had was not related to a malloc/free situation, it
was something wierd with enums being used as the parameter for a "case" in a
switch case statement with the PIC compiler. Something like this:
PS: The code below has not been tested is only intended to get an idea of
the type of code that caused the crash in another module completely unrelated
to this code.
Go figure!
============================
enum s{abc=1, def,ghi,jkl};
void f1(s i)
{
switch(i)
{
case abc: // does stuff
break;
case def: // do stuff
break;
default:
break;
}
}
int main()
{
f1(abc);
return 0;
}
==========================
So I replced it with this:
=========================
#define abc 1
#define def 2
#define ghi 3
#define jkl 4
void f1(s i)
{
switch(i)
{
case abc: // does stuff
break;
case def: // do stuff
break;
default:
break;
}
}
int main()
{
f1(abc);
return 0;
}
=============================
And then there was no more bugs.
David, thankyou for helping me! I appreciated it!
--
Best regards
Roberto
"David Webber" wrote:
"Robby" <Robby@discussions.microsoft.com> wrote in message
news:022436AD-0CC0-4B21-B5DB-8A0CCD00A9DB@microsoft.com...
I am freeing p and leaving x alone. I was also tempted toset x to null,
but
thats dangerous too... no!
No :-) If you have a pointer which is non-NULL pointing to a piece of
memory you don't own, then it is very dangerous. A NULL pointer p can
cause problems if you do p->.... but sprinkling your debug code with
ASSERT(p); will usually soon force you to fix it before you release your
code to the world. An illegal non-NULL pointer can wreak much more havoc.
For this reason I usually set p=NULL; immediately after freeing the memory.
Danger yes, but a more controlled danger.
It can be useful to use blocks when doing this sort of thing:
{
long *p = malloc(....);
....
....
free(p);
}
Note that p has no existence before the line which mallocs, and none after
the line which frees. The { } block is used to protect the following code
from p by throwing it out of scope. You don't have to wait for an if, loop,
or function when using them.
Its just that in my real program, x and p are members of two different
structures which are typedefed in a header.
...
That is fine, (ish) but only one of them can "own" the data.
If we're doing C++ here, rather than C, the one which owns the data should
call malloc() in its constructor, (or at least set p to NULL if it is only
to be allocated later) and free() in its destructor. The other one
should take a copy of the pointer and have comments at regular intervals: I
DON'T OWN THIS DATA. DO NOT DESTROY THE OWNER WHILE I AM STILL AROUND.
Sometimes keeping track of an owner of data and other objects which only
contain access to it, is a useful approach, but it has to be done with care.
Alternatively, a more object oriented approach, is to malloc both of them,
and give them independent copies of the data, and then free them both.
(For malloc/free substitute new/delete in C++).
Dave
--
David Webber
Author of 'Mozart the Music Processor'
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mozartists/mailinglist.htm