🚀 go-pugleaf

In article <681@stag.UUCP>, to_stdnet@stag.UUCP writes:
> [peter@sugar.uu.net (Peter da Silva) writes...]
> > TOS, of course, doesn't let you do this... its memory management has a fatal
> > bug that forces everyone to roll their own. but I'll wager that if you free
> > something twice in a complex 'C' program and let it run long enough it'll
> > crash.

>   You'd loose the wager if the C program used the dLibs (public domain) C
> librarys for the ST....  You can free memory blocks at random locations
> from here to doomsday and the machine will fall apart from old age before
> the program will crash...

Well, Hackercorp has a library front end that does much the same thing.
However, I hope that you don't depend on the behaviour of dLibs... or if you
do I hope you don't ever port your program to another machine.

Hackercorp's memory management routines are machine-independent, and when
they detect an error they inform you. That way you can fix your bugs (freeing
memory twice is a bug) instead of hiding them. I hope dLibs does as well.

>   (When/where can I collect on your wager?  :^)

Third-party hacks don't count.
-- 
Peter "Have you hugged your wolf today" da Silva  `-_-'  Hackercorp.
...texbell!sugar!peter, or peter@sugar.uu.net      'U`