effect of free()

[Guy Shaw]

In article <11008 at smoke.BRL.MIL>, gwyn at smoke.BRL.MIL (Doug Gwyn) writes:
> In article <9278 at attctc.Dallas.TX.US> chasm at attctc.Dallas.TX.US (Charles Marslett) writes:

> >Why don't we just say is it lousy looking code that does this sort of thing --
> >so don't do it (even though it will work 99999 times out of 10000, or whatever
> >the fraction really is.
> 
> Good advice; since it is not necessary to rely on the nonportable
> ability to continue to play with a pointer after it is free()d,
> it is best to simply avoid doing so.

Do any of the C development/run-time environments, such as Sabre-C,
have run-time pointer checking code that is as strict as the kinds
of hardware that has been discussed here recently?  I know there are
C interpreters or run-time environments that will check array bounds
and will take care of dereferencing bad pointers, even when the usual
run-time code would just keep slashing away and surprise you later,
on many machines.  But, are there any that can simulate the the kind
of hardware that says, "don't even think about bad pointers"?

I don't have any objection to coding safely, but I don't trust myself
to catch every potential portability problem, by hand.  I don't think
lint could catch this.  As a matter of fact, I can't think of a way
to make some new version of lint catch this in ALL cases.  Offhand,
it seems that generating code to do this at run time is the only way
to get that kind of enforcement.  Perhaps, another cc switch.
Yes, I know, that does not prove your program doesn't have bugs
in unexercised parts of your program, but neither does running it on
strict hardware.

I don't want to buy a Unisys A-series machine (or whatever) just
to run my code to make sure it is maximally portable.  But if I
had the option handy in software, I would use it to supplement lint.

Thanks in advance.
-- 
Guy Shaw
Paralogics
paralogics!shaw at uunet.uu.net  or  uunet!paralogics!shaw