effect of free()

[T. William Wells]

In article <165 at bbxsda.UUCP> scott at bbxsda.UUCP (Scott Amspoker) writes:
: Someone whose name I keep losing writes:

Me. Bill Wells.

:                                             For some reason, everytime
: I try to followup one of your postings my 'rn' program aborts back to
: the shell.  This happens only with your postings (???).

I doubt it. The problem is probably with the long References: line.
My system, since I'm running C news, generates these looooong message
ids which quickly result in an oversized References: line. I'm going
to edit that line in this message, I'll bet you can follow up now.

: >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.
:
: Then we are in agreement.  How would you feel, then, if your ported
: your code to some machine that wasn't so forgiving; and when you
: complained, someone told you that you were lazy and shouldn't have
: written the code that way in the first place?  None of us want to
: pay so dearly for something so trivial whether we intended it or
: not.  Remember, we're talking about more than free() calls here.

I'm not sure what you are talking about. The original posting in this
thread (mine) said that the C standard permits the compiler writer to
assume that you don't use a pointer after a free, and thus he can
have the compiler generate code that trashed the pointer value after
the free.

If I write the program so that it is not designed to reference
pointers after they are freed, assuming I get it right, it doesn't
matter whether the generated code trashes the pointer. If I get it
wrong, I have a bug, which I should assume will show up sooner or
later (a day later after the cost of fixing it goes astronomical :-),
and it still doesn't matter whether the compiler does this.

Actually, it does, a little: if in the compiler's C model freed
pointers still have valid values, my error won't cause the program to
violate that model immediately. But if the code does trash the
pointer, my error makes the program violate its model, such programs
are generally harder to debug. That is one of the reasons why, if I
do have a compiler that generates this kind of code, I'd like to be
able to turn it off. Of course, turning off optimizations is often a
good idea when debugging, anyway.

On the other hand, if I write my code assuming that the value of a
freed pointer doesn't get trashed, I'm OK on "normal" compilers (if
I'm reasonably careful, there are still things that will break even
on those), but I've a big loser if I port the program to one that
does this optimization.

The conclusion is that I should avoid referencing the pointer after
it is freed, so that this perfectly legit optimization won't break my
code.

Also, as I've implied elsewhere, there is a much better reason than
this for not touching the pointer after it is freed: *conceptually*,
once a pointer is freed, its value is meaningless. Pointers (other
than null pointers) have meaning only insofar as they have an object
at the other end.

: BTW: Since I am having so much trouble with your postings (not
: me personally :-) but 'rn' is having trouble.) I will have to
: avoid further followups.  If we have more to discuss let's try
: e-mail.

Let's see if this fixes the problem.

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