Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!kim
From: kim@kim.misemi (Kim Letkeman)
Newsgroups: comp.lang.c
Subject: Re: effect of free()
Message-ID: <990@kim.misemi>
Date: 20 Sep 89 18:36:44 GMT
References: <319@cubmol.BIO.COLUMBIA.EDU> <3756@buengc.BU.EDU> <16507@watdragon.waterloo.edu>
Organization: MITEL Corporation, Kanata, Ontario, Canada.
Lines: 50

In article <16507@watdragon.waterloo.edu>, 
   afscian@violet.waterloo.edu (Anthony Scian) writes:
>[Deleted several stacked articles discussing]
>[trap on invalid pointer issues             ]
> 
> 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:
> 
>[Deleted example where free() breaks because it has]
>[to reference es register just one more time on    ]
>[exit but the RAM has already been freed.          ]
> 
> 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!

Can you tell me how you would go about causing an 80286 to trap on
load of a "bad" value in the ES That's? This register is internal to
the CPU and I doubt that there are any values that would cause a trap
to be raised simply by loading them.

Ditto for the 68000. A0-A7 can handle values up to $FFFFFFFF (which is
well outside of the M68000's 16mb address space) without trapping on
load. (Mind you, you can't reference the RAM, but you can load the
value into the address register.)

You cannot create an example using existing architectures that behave
a certain way and then say "but if they did this other thing ..."

If they actually did that other thing, they would not be using your
general purpose compiler.

The point I am making is that your example is narrow of focus and has
no basis in any practical reality. These chips do not do what you are
worried about. Chips that do would require a specific compiler (or at
last run time library) implementation anyway.

I prefer my sweeping generalities with a little reality thrown in.

-- 
Kim Letkeman    uunet!mitel!spock!kim