effect of free()

Antti Louko alo at kampi.hut.fi
Sun Aug 20 00:45:00 AEST 1989


In article <14343 at haddock.ima.isc.com> karl at haddock.ima.isc.com (Karl Heuer) writes:
<<In article <1989Aug17.005548.745 at twwells.com> bill at twwells.com (T. William Wells) writes:
<<<	free(ptr);
<<<	if (ptr == 0) ...
<<<The if might cause a trap when the value of ptr is accessed.

<The issue is not whether the value of ptr has changed.  Some architectures
<distinguish between arithmetic registers and address registers, and refuse to
<allow arbitrary garbage to be loaded into an address register.  If free()
<actually releases the segment to the operating system (I don't know of any
<implementations that do, but the possibility is there), then the value of ptr,
<although unchanged, could now be unloadable.  In other words, not only *ptr
<but also ptr itself are unusable.

It would be interesting to see a C implementation like this in a
multitasking operating system. Let's consider this fragment of code:

p = malloc(..);
free(p);
.
. What if there happens a context switch here ??
.
p = malloc(..);

There might happen a context switch somewhere between free(p) and when
p is assigned a new legal value. Task switching code should check all
saved register values so that they wouldn't cause a trep. I think that
it would be much easier to just ignore this kind of traps than
identify just the legal traps.

	Antti Louko



More information about the Comp.lang.c mailing list