🚀 go-pugleaf

In article <43uq94INNpbl@keats.ugrad.cs.ubc.ca>, c2a192@ugrad.cs.ubc.ca
(Kazimir Kylheku) wrote:

> Right, that's obvious, because your properly written program always takes
> care to dereference through the handle.

Yup.  That pretty much comes from the definition of properly written
programs; they have to do the right thing.  Those that don't, tend to
crash.  They crash on Unix machines, Macs, PCs, Amigas, etc.

> I wouldn't do that at all. If a program requires that the size of an allocated
> unit change, I would have it go through a function that's similar to the
> standard C realloc().

And how would you magically fix all the references (aliases) that point to
that data structure?  Or is that just another problem which you'll ignore
in your quest for elegance over practical functionality?

> I wouldn't do either of these things, needless to say. I do use the technique
> of inserting dummy pages between allocated data in order to use the hardware
> to detect instructions that would normally corrupt the heap but only for
> debugging purposes.

Actually, this is a pretty good way to implement fast double buffering
schemes, as you don't have to explicitly test every reference to see if
you are past the end of the buffer.

> I was thinking purely of a machine without an MMU
> the entire time. In fact a 68K board with about 512K RAM or even less
> was what I precisely had in mind.

But you have yet to post any solution to the problem.  All you do is
assert without proof that it isn't a problem.  I can show you real Mac
applications that prove this situation occurs regularly.  I'll ask you
again, what do you do when there isn't enough contiguous space left in the
heap, after you've already coalaesed the blocks together when freeing
them, if you can't do compaction, besides just quitting the application?
-- 
        Nevin ":-)" Liber       nevin@CS.Arizona.EDU    (520) 293-2799