effect of free()

[T. William Wells]

In article <154 at bbxsda.UUCP> scott at bbxsda.UUCP (Scott Amspoker) writes:
:  >: It's not very hard to factor in the notion that a pointer is "poison"
:  >: when it no longer points to valid storage.  One would think that
:  >: "well-written code" would already follow that model, which is
:  >: compatible with a wider range of environments.

I do sort of object to the sequence you imply here: first, you did
not properly attribute it. Second, you made it appear that I said that
my code never dealt properly with freed pointers. I doubt that your
intent was malicious, but I'd appreciate more care in the future.

:  >Mine always did. Even before I learned to think about portability. It
:   ^^^^^^^^^^^^^^^
:  >just never occured to me that a freed pointer was anything but
:  >nonsense.
:
: How do you know?  Although a bad example using the free() call was
: what started all of this the discussion has turned to the more general
: problems of handling pointers.  I don't doubt that your calls to
: free() are clean.  What about every other place that pointers are
: used?  How many other programmers are working on your project with
: you?  If you did handle a bad pointer at one point (even though
: program logic would not deference that pointer under those conditions)
: how would you know (without personally examining every line of code)?
: Chances are your machine is allowing it so there would be no trap
: generated.

You missed the point. I did *not* say that my programs never
referenced a pointer after it was freed. Don't I wish. What I'm saying
is that I never *designed* a program to do that. And it never would
have occured to me to even try. A freed pointer is *gone*.

---
Bill                    { uunet | novavax | ankh | sunvice } !twwells!bill
bill at twwells.com