effect of free()

[Scott Amspoker]

 >: 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.

 >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.

This isn't a flame.  :-)  :-)  <- see, I'm smiling

It's just that there is a lot more at issue here than a call to free().
There is a comment above about being compatible with a "wider range
of environments".  Since nobody has yet given a real world example
of "pointer poison", just how much "wider" a range are we talking about?

-- 
Scott Amspoker
Basis International, Albuquerque, NM
(505) 345-5232