On Thu, 2007-03-22 at 12:22 +0100, Jim Meyering wrote: > David Edmondson <dme@xxxxxxx> 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