The free() thing

[Marcus Hall]

In article <1989Sep16.224730.9733 at twwells.com> bill at twwells.com (T. William Wells) writes:
>I will judge compilers on compliance to the standard first, and
>quality of implementation second. Speed is an important consideration
>and, since *I* won't do stupid things like look at pointers when I'm
>not supposed to, go ahead and trash freed pointers. Now, I'll admit
>that I'd like a compiler option that turns off this optimization, but
>I won't insist.

Re-use of registers and/or memory locations is something that the compiler
should be capable of determining without resorting to knowing that a free'd
pointer shouldn't be used anymore.  If your program doesn't use the pointer
after calling free(), the compiler should be able to determine that the
register can be re-used.  If you do use it again, there may be a problem on
some machines; certainly referencing what it points to could cause problems,
but it seems rather out of place for the compiler to just assume that you
won't use it again -- especially if the compiler could determine whether or
not your code actually does.

There are some cases where it may be desirable for the compiler to make
assumptions about the actions of recognized library calls (for instance, if
a routine ends with a call to exit(), what is the point of producing code
to do stack cleanup and subroutine return?  I would have preferred it if the
compiler were to recognize something like __exit and for exit() to be #defined
to __exit() or some such, but this apparently isn't required.

Anyhow, this case shouldn't really be anything special.  If the last use of
a veriable is in a call to printf(), I wouldn't be upset if the compiler
re-used the register or memory location for some other variable.  It would
still be correct code and other than efficiency (or using the 2nd variable
without initializing it) the optimization should be invisible.  This does
not matter whether the function is printf(), free(), or anything else.

marcus hall