🚀 go-pugleaf

In article <467@uvicctr.UUCP> collinge@uvicctr.UUCP (Doug Collinge) writes:
   [some lines deleted]...
>Actually, I've always hated the way unix malloc works; too dangerous, you
>see, someone could easily write all over the links, then all hell breaks
>loose especially in a system with no protection.  Why not keep the block
>parameters in tables somewhere else?  Maybe even The Kernel could keep them
>in Protected Memory and thus have global memory allocation (and fragmentation).
>I digress...

I *LIKE* the Unix malloc(); it is a flexible and portable memory
allocator, and if you're not stuck with a too bad implementation it can
be pretty fast too (in my shell I use a malloc that resembles the BSD
malloc, it is much faster than the one that comes with my - Lattice C -
compiler, and it does not fragment memory too badly). Having links in
protected memory implies you have to use system calls (which generally
does not speed things up).

The chances of writing over a link in the heap are certainly not
greater than writing over a char array on the stack, which is probably
more dangerous (destroying return addresses & link pointers).

The incorrectness of a destroyed link in malloc *CAN* be checked by the
way; not 100% foolproof but much easier than checking a destroyed stack.

If you have chosen for a system without protection you should not complain
about some part being insecure while leaving the rest alone. I'd rather
have the FAT's and stuff in protected memory; if they get messed up you
really are in trouble (disks unreadable at least).

                         Leo.