[392] in Hesiod
Re: hesiod 3.x
daemon@ATHENA.MIT.EDU (Bill Sommerfeld)
Tue Jan 4 22:47:35 2000
Message-Id: <200001050347.DAA11436@orchard.arlington.ma.us>
To: Greg Hudson <ghudson@MIT.EDU>
Cc: "Danilo Almeida" <dalmeida@MIT.EDU>, hesiod@MIT.EDU
In-Reply-To: Message from Greg Hudson <ghudson@MIT.EDU>
of "Tue, 04 Jan 2000 21:54:22 EST." <200001050254.VAA12618@small-gods.mit.edu>
Date: Tue, 04 Jan 2000 22:47:13 -0500
From: Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us>
Greg,
I've run into implementation problems of this form in shared-library
environments on unix in the past (particularly when they involved
threading libraries and macro-wrapped malloc/free -- i.e., some code
might be built with malloc #defined to cma_malloc, and some wouldn't
be), as well as in other implementation environments were
ultraportable code was called for.
in general, most C library functions which allocate memory (e.g.,
fopen) provide a corresponding function which, as a side effect, frees
it (e.g., fclose); it seems to me that it's perfectly reasonable to
mirror this in the hesiod API.
- Bill
