Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!kim
From: kim@kim.misemi (Kim Letkeman)
Newsgroups: comp.lang.c
Subject: Re: effect of free()
Summary: You can't test every variable every time you use it.
Message-ID: <985@kim.misemi>
Date: 19 Sep 89 14:51:23 GMT
References: <319@cubmol.BIO.COLUMBIA.EDU> <3756@buengc.BU.EDU> <1693@levels.sait.edu.au>
Organization: MITEL Corporation, Kanata, Ontario, Canada.
Lines: 36

In article <1693@levels.sait.edu.au>, CCDN@levels.sait.edu.au (DAVID NEWALL) writes:
> In article <11070@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
> > In particular, there is a school of thought that says machine architecture
> > should be designed to assist in program reliability.  That school
> > occasionally influences computer architectures such that actions like
> > merely continuing to shuffle around invalid pointers cause an error trap
> > to be taken.
> That is supposed to make programs reliable?
> Testing parameters for "correctness", rather than blindly hoping that they
> are "correct", is one way to make programs more reliable.  Does that school
> of yours suggest that it's OK to believe all (non-null) pointers?
> 
I think Doug was alluding to a situation where the compiler and
hardware cooperate to attempt to eliminate bugs very early in the
development cycle.

As an example, the hardware architecture might be designed to trap an
out of range pointer (e.g. bus error on a 68000) and the compiler (or,
more correctly, run time library) could cooperate by stuffing
$FFFFFFFF into a pointer when free() has been called. This would have
the effect of trapping use of the (now) invalid pointer.

This can be of critical importance in an environment where many tens
of software designers are pouring code into a single software load for
a real-time telecommunications system (as just one example).
Eliminating stupid bugs (like using pointers after they have been
discarded) right up front pays huge dividends in field reliability.







-- 
Kim Letkeman    uunet!mitel!spock!kim