effect of free()
T. William Wells
bill at twwells.com
Sat Sep 23 19:22:16 AEST 1989
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
More information about the Comp.lang.c
mailing list