Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: The free() thing and function names
Message-ID: <11117@smoke.BRL.MIL>
Date: 20 Sep 89 14:44:06 GMT
References: <1989Sep14.022055.5961@twwells.com> <841@uniol.UUCP> <11073@smoke.BRL.MIL> <902@skye.ed.ac.uk>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 28

In article <902@skye.ed.ac.uk> richard@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.