Path: utzoo!utgpu!watmath!watdragon!violet!afscian
From: afscian@violet.waterloo.edu (Anthony Scian)
Newsgroups: comp.lang.c
Subject: Re: effect of free()
Message-ID: <16507@watdragon.waterloo.edu>
Date: 19 Sep 89 16:35:59 GMT
References: <319@cubmol.BIO.COLUMBIA.EDU> <3756@buengc.BU.EDU> <10988@smoke.BRL.MIL> <9339@attctc.Dallas.TX.US> <1641@levels.sait.edu.au> <11070@smoke.BRL.MIL> <1693@levels.sait.edu.au> <29624@news.Think.COM>
Sender: daemon@watdragon.waterloo.edu
Reply-To: afscian@violet.waterloo.edu (Anthony Scian)
Organization: U. of Waterloo, Ontario
Lines: 55

In article <29624@news.Think.COM> barmar@think.COM (Barry Margolin) writes:
>In article <1693@levels.sait.edu.au> CCDN@levels.sait.edu.au (DAVID NEWALL) writes:
>>In article <11070@smoke.BRL.MIL>, gwyn@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@violet.uwaterloo.ca afscian@violet.waterloo.edu ////
"I can't believe the news today, I can't close my eyes and make it go away" -U2