leo@philmds.UUCP (Leo de Wit) (08/26/88)
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.