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.