The free() thing and function names
Doug Gwyn
gwyn at smoke.BRL.MIL
Thu Sep 21 00:44:06 AEST 1989
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.
More information about the Comp.lang.c
mailing list