effect of free()

[Kim Letkeman]

The original poster asked (essentially) what effect there would be if
he freed a block of memory and then tested the pointer.

This prompted a lively and interesting discussion filled with
speculation as to the possible effects under various hardware
architectures, especially those that treat pointers as "special
animals". 

No real consensus was reached, although most people seemed to feel
that it was unreasonable for C language to do anything as nasty as
trap the process because it "should not know anything about the
pointer's current status."

A couple of people asserted (correctly, as far as I am concerned) that
the run-time implementation was free to make assertions that a pointer
when accessed must be valid or a trap will occur. This is likely to
happen on architectures where pointers really are special, and not
just glorified integers.

Through all the smoke and gunfire I feel that the original poster's
intent was never clearly answered.

It is bad practise to release a block of memory back to the os and
then attempt to do anything at all with the pointer or the memory. Any
behaviour that is not totally random is implementation dependant and
is therefore not worth the risk.

Take a look at "The Elements of Progamming Style" and "Software Tools"
for a very clear explanation of good coding style as it pertains to
taking risks in code and/or sloppiness and/or laziness and/or anything
else that reduces code quality.

Kim

By the way ... anyone out there have any ideas as to how many
programmers have read these classics? I have asked a number of people
who make their living as software designers and the numbers are quite
shocking. I would say that less than 5 percent of programmers have
even heard of these two books. And well under 10 percent ever read a
software engineering book at all.

Kim Letkeman       uunet!mitel!spock!kim

-- 

Kim Letkeman         ...uunet!mitel!spock!kim