The free() thing and function names

[Doug Gwyn]

In article <902 at skye.ed.ac.uk> richard at aiai.UUCP (Richard Tobin) writes:
>This is a real pain for programs (like interpreters for other languages)
>that need to keep track of just what memory is in use.  A helpful
>implementation would at least provide a way of producing code that
>relied only on the advertised semantics of malloc(), etc, perhaps by
>means of a compiler flag.
[...]
>I hope that this will be treated as a "quality of implementation"
>issue.

I don't understand your concern.  malloc()/realloc()/free() are
provided by the (hosted) C implementation and must meet the
specifications.  Details of the way these and other functions are
implemented are, and must be, left up to the implementor's discretion.
Because a strictly conforming program cannot take cognizance of
implementation-specific details, they needn't be of concern.

A program can wrap the system-provided malloc()/realloc()/free() with
its own bookkeeping module, if desired, but strict standard
conformance (or maximal portability) requires that it not attempt to
supplant malloc()/realloc()/free() with its own functions of the same
name.

The hardest part of the job when I port our version of the Bourne
shell to a new UNIX environment is untangling the shell's memory
manager, which attempts to replace the normal C library version,
often failing to meet the actual C implementation's constraints.
It was simply a design botch for the shell to have taken that approach.