Library dynamic allocation primitives
*************************************

   Libg++ contains versions of `malloc, free, realloc' that were
designed to be well-tuned to C++ applications. The source file
`malloc.c' contains some design and implementation details.  Here are
the major user-visible differences from most system malloc routines:

  1. These routines *overwrite* storage of freed space. This means that
     it is never permissible to use a `delete''d object in any way.
     Doing so will either result in trapped fatal errors or random
     aborts within malloc, free, or realloc.

  2. The routines tend to perform well when a large number of objects
     of the same size are allocated and freed. You may find that it is
     not worth it to create your own special allocation schemes in such
     cases.

  3. The library sets top-level `operator new()' to call malloc and
     `operator delete()' to call free. Of course, you may override these
     definitions in C++ programs by creating your own operators that
     will take precedence over the library versions. However, if you do
     so, be sure to define *both* `operator new()' and `operator
     delete()'.

  4. These routines do *not* support the odd convention, maintained by
     some versions of malloc, that you may call `realloc' with a pointer
     that has been `free''d.

  5. The routines automatically perform simple checks on `free''d
     pointers that can often determine whether users have accidentally
     written beyond the boundaries of allocated space, resulting in a
     fatal error.

  6. The function `malloc_usable_size(void* p)' returns the number of
     bytes actually allocated for `p'. For a valid pointer (i.e., one
     that has been `malloc''d or `realloc''d but not yet `free''d) this
     will return a number greater than or equal to the requested size,
     else it will normally return 0. Unfortunately, a non-zero return
     can not be an absolutely perfect indication of lack of error. If a
     chunk has been `free''d but then re-allocated for a different
     purpose somewhere elsewhere, then `malloc_usable_size' will return
     non-zero. Despite this, the function can be very valuable for
     performing run-time consistency checks.

  7. `malloc' requires 8 bytes of overhead per allocated chunk, plus a
     mmaximum alignment adjustment of 8 bytes. The number of bytes of
     usable space is exactly as requested, rounded to the nearest 8
     byte boundary.

  8. The routines do *not* contain any synchronization support for
     multiprocessing. If you perform global allocation on a shared
     memory multiprocessor, you should disable compilation and use of
     libg++ malloc in the distribution `Makefile' and use your system
     version of malloc.