effect of free()

[Richard O'Keefe]

In article <2054 at munnari.oz.au> ok at cs.mu.oz.au I wrote
>So what's so special about other (pointer values that may not be
>dereferenced)?
In article <10976 at smoke.BRL.MIL>, gwyn at smoke.BRL.MIL (Doug Gwyn) writes:

> You'll never grasp what we're trying to say so long as you try to interpret
> it in terms of conventional architectures, because we're talking about a
> hardware trap that occurs NOT when an invalid pointer is used to REFERENCE
> an object, by when the invalid pointer itself is merely INSPECTED.

Don't try to guess how I'm interpreting things, because you guess wrong.
I understand the source of the problem perfectly well.  The problem is
that some machines have *some* ways of inspecting pointers which cause
traps when given an invalid pointer.  I was mistaken about NULL, that's
true:  NULL has to be a value that can't point to a valid C object,
but that doesn't mean that it has to be an invalid address.  Having a
special "null_obj" in the library that NULL points to will work fine on
those machines without requiring any special magic, so my argument fails.
The point remains that on those machines it is not *NECESSARY* to do a
pointer comparison using load-into-address-register-and-maybe-trap.
Barry Margolin explained lucidly why it may be *CONVENIENT*.

Even a machine like the B6700 (Unisys A series) with its tags provided
means of inspecting tagged words without causing the tags to be interpreted.
(Implementing BCPL on those machines was sufficient of a nightmare -- not
mine, thank goodness -- that you'd have to be crazy to try to implement C.)

Can a capability-based machine support a C implementation at all?
Might that provide an example where a pointer can't be accessed as data
(thus making pointer-comparison-via-trapping-methods obligatory)?
What would that do to pointer subtraction, pointers in unions, and so on?