effect of free()

[Anthony Scian]

In article <29624 at news.Think.COM> barmar at think.COM (Barry Margolin) writes:
>In article <1693 at levels.sait.edu.au> CCDN at levels.sait.edu.au (DAVID NEWALL) writes:
>>In article <11070 at smoke.BRL.MIL>, gwyn at smoke.BRL.MIL (Doug Gwyn) writes:
>>> In particular, there is a school of thought that says machine architecture
>>> should be designed to assist in program reliability.  That school
>>> occasionally influences computer architectures such that actions like
>>> merely continuing to shuffle around invalid pointers cause an error trap
>>> to be taken.
>>That is supposed to make programs reliable?
>
>Yes.  The idea is that a program that tries to manipulate invalid
>pointers is doing so inadvertently.  The hope is that the trap will be
>invoked while the program is being tested, and the bug will be fixed.
>And even if the trap isn't triggered during testing, it might be
>triggered by an end user, who should report that the program crashed
>under such-and-such a circumstance, which will permit the developers
>to fix the bug.  An architecture that doesn't trap is allowing the
>program to perform a presumably-unintended operation.

The "trap on load of a bad pointer" feature sounds good initially
but it can lead to severe problems with CORRECT code.
Here is an example that occurs with OS/2 on the 286:

; optimizer has ptr in ES:DI but never references ptr afterwards
push es
push di
call dealloc
... ; never reaches this point!

dealloc: ; dealloc needs ES,DI,CX so they are saved
push es
push di
push cx
; frees segment as it frees the memory
...
pop cx
pop di
pop es	<-- EXCEPTION OCCURS HERE!
ret 4

The generalization of this tells us that "trap on load of bad pointer"
is a bad feature. It is impossible to use a calling convention that
saves registers with this feature (say A0-A7 on the 68K).
This severly limits what an optimizer can do across calls
(i.e., all A0-A7 regs must be NULLified before calls).
The restrictions placed on optimizers effectively renders
them useless unless there are plenty of non-trapping data registers.
The shuffling and clearing of address registers before calls
would severely comprimise performance.

Address registers should trap on USE not LOAD!
--
Anthony
//// Anthony Scian afscian at violet.uwaterloo.ca afscian at violet.waterloo.edu ////
"I can't believe the news today, I can't close my eyes and make it go away" -U2