Mail Archives: djgpp/2000/02/29/17:11:05
Marcus <mesthlm AT hem DOT passagen DOT se> wrote:
> "Hans-Bernhard Broeker" <broeker AT acp3bf DOT physik DOT rwth-aachen DOT de> wrote:
>> Essentially, yes, it is. Anyway, it is none of your function's...
> Hehe.... maybe it is... maybe it is...
It *may* be. But you've yet to show any argument why it would be, in
your particular case.
> I know exactly what I'm doing.
You may know that, today, on this particular platform. But what about
the next user of your library, a year later, possibly trying to do the
same on a different platform? You're asking us for a gun to shoot
yourself in the foot.
> Can't you just tell me how? Please!
No, I won't. The whole idea is flawed, from the very beginning. You
cannot determine if a pointer is free()able or not, without risking to
run into the very same crash that free() itself would have
caused. Just to give an example: of course you could check if the
pointer is inside the memory region controlled by malloc(), or not.
But then, your code would utterly crash as soon as you, or some other
user of your library does this:
char * p = malloc(20);
strcpy (p, "blablablabla");
your_func(p+5);
You said this was code in a library you're writing. I assume that
means that the particular function you're talking about is a
user-callable one. If so, it should most definitely not change its
behaviour (call free() on the pointer or not) just because the user
passed in a pointer to an malloc()ed string, rather than a string
constant. From the point of view of the routine getting passed a 'char
*' argument, there is no noticeable difference between these cases,
originally, and it's a bad idea to try and introduce one,
artificially.
The distinction between the two cases is untractably hard inside your
routine, whereas the same information is directly available to the
author of the calling routine. He can see, by looking at the source
code of that routine, what that 'char *' really is --- why not let
*him* use that information, and spare your routine the hard,
unportable work of digging through the heap to find and use it?
You should choose one behaviour, and stick to it:
1) always call free(), and put this fact prominently in the
documentation of the function.
2) don't call free(), ever, but let the caller take care of it.
This is the usual solution, so you could even neglect documenting
this.
Method 1) has two problems. First, incorrect usage of the routine will
cause crashes, instead of a more easily bearable memory leak. Second,
it changes the validity state of the pointer variable held by the
calling function, i.e. the caller would have to remember to always do
your_function(p);
p = NULL; /* p is invalid, now! */
in order to be sure he doesn't inadvertantly use 'p', later, or call
free() on it, himself. Given that this kind of postprocessing is
needed, anyway, there's IMHO no good reason not to let the caller do
the free(), too, while being at it.
All in all, I still gather the impression you're trying to solve the
wrong end of the problem. You fight the symptoms (crashes from illegal
calls to free()), instead of properly diagnosing and curing the
disease (memory leakage).
--
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.
- Raw text -