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