From: Hans-Bernhard Broeker <broeker AT acp3bf DOT physik DOT rwth-aachen DOT de>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Prevent crash on free()
Date: 29 Feb 2000 19:04:33 GMT
Organization: Aachen University of Technology (RWTH)
Lines: 78
Message-ID: <89h581$o79$1@nets3.rz.RWTH-Aachen.DE>
References: <89e5e3$8g1$1 AT cubacola DOT tninet DOT se> <89e72m$hpt$1 AT nets3 DOT rz DOT RWTH-Aachen DOT DE> <89e7oq$cmv$1 AT cubacola DOT tninet DOT se> <89ecto$jum$1 AT nets3 DOT rz DOT RWTH-Aachen DOT DE> <89ee3g$8pf$1 AT zingo DOT tninet DOT se> <89gqib$jah$1 AT nets3 DOT rz DOT RWTH-Aachen DOT DE> <89gvv0$j0h$1 AT cubacola DOT tninet DOT se>
NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de
X-Trace: nets3.rz.RWTH-Aachen.DE 951851073 24809 137.226.32.75 (29 Feb 2000 19:04:33 GMT)
X-Complaints-To: abuse AT rwth-aachen DOT de
NNTP-Posting-Date: 29 Feb 2000 19:04:33 GMT
User-Agent: tin/1.4-19991113 ("No Labels") (UNIX) (Linux/2.0.0 (i586))
Originator: broeker@
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

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.