On Thu, 2007-03-22 at 12:22 +0100, Jim Meyering wrote:
David Edmondson <dme(a)sun.com> wrote:
> On Wed, Mar 21, 2007 at 04:38:00PM +0100, Jim Meyering wrote:
>> I interpret "wrappers", above, to mean more than just a calloc-like
wrapper.
>>
>> A malloc (not calloc, of course) wrapper that always initializes can
>> mask what would have otherwise been a used-uninitialised error, and what
>> would still be a logical U.I. error.
>
> That seems silly. If the wrapper is defined as zero-initalising then
> it cannot be an error to assume that it zero-initalises.
What seems silly? A malloc() wrapper that initializes the
memory it allocates? That's the case in which errors can be masked.
A function intended to be used as a malloc or realloc replacement should
not initialize its memory -- at least not by default. A calloc-wrapper
_must_ do that. Not the others.
Wow, this is a weird little side-track :-)
I think the confusion is just around what the term "malloc() wrapper"
means. I mean it purely as "a memory allocation function", you seem to
interpret it as "a function which overrides the malloc() symbol and has
the same semantics as malloc()".
e.g. I would define g_malloc(), g_malloc0(), g_new() and g_new0()
etc.[1] as malloc() wrappers ... but you wouldn't? They have different
semantics from malloc() and some of them have the semantic "zero
initialise the newly allocated memory".
So, sure, a zero-initialising replacement for the malloc(3) symbol
would be stupid.
Cheers,
Mark.
[1] -
http://developer.gnome.org/doc/API/2.0/glib/glib-Memory-Allocation.html