Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!unmvax!bbx!bbxsda!scott
From: scott@bbxsda.UUCP (Scott Amspoker)
Newsgroups: comp.lang.c
Subject: Re: The free() thing and function names
Message-ID: <131@bbxsda.UUCP>
Date: 20 Sep 89 20:17:32 GMT
References: <1989Sep14.022055.5961@twwells.com> <841@uniol.UUCP> <11073@smoke.BRL.MIL> <902@skye.ed.ac.uk> <11117@smoke.BRL.MIL>
Reply-To: scott@bbxsda.UUCP (Scott Amspoker)
Organization: Basis International
Lines: 21

In article <11117@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
>
>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.

We have done something similar to what the original poster was talking
about.  We have had our own routines that our software calls to do
malloc() and free().  These routines normally just pass on the arguments
to the real malloc() and free().  However, in a debugging situation
these routines will keep track of malloc'ed and free'ed areas to help
figure out what it going on if pointers are being trashed.  But, no,
we don't call them malloc() and free().  Of course, now we're being
told that we're not allowed to do our own pointer checking.

-- 
Scott Amspoker
Basis International, Albuquerque, NM
(505) 345-5232