Date: Tue, 22 Oct 2002 21:27:35 +0300 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: djgpp-workers AT delorie DOT com Message-Id: <9003-Tue22Oct2002212734+0200-eliz@is.elta.co.il> X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 1.8.9 In-reply-to: <3DB3D5D9.F1DA8C95@yahoo.com> (message from CBFalconer on Mon, 21 Oct 2002 06:24:25 -0400) Subject: Re: CBFalconer's malloc References: <3DB3D5D9 DOT F1DA8C95 AT yahoo DOT com> Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > Date: Mon, 21 Oct 2002 06:24:25 -0400 > From: CBFalconer > > > > The point to me is that > > > any such interfaces are done through header files, and leave the > > > malloc code itself free to do what it needs. > > > > I'm not sure I understand. The debugging hooks are called by malloc at > > strategic places, provided that they are non-NULL (each hook is a pointer > > to a function, by default set to NULL). malloc is free to do what it > > needs, but it must call the hooks while it's doing that. > > Why do it within malloc? Isn't it easier to define say > > void * xmalloc(size_t sz) > { > void *p; > > xmentryhook(sz); > p = malloc(sz); > xmexithook(p); > return p; > } > > in the users space. Because the hooks don't just tell you when malloc is called. They tell you something about the inner workings of malloc, so a program which hooked into malloc can gather information about memory allocation. For example, __malloc_get_freelist returns the free list of memory blocks, an otherwise internal structure. An application can then examine the free list for whatever it needs, like count the size of the free memory pool. Another example is __libc_malloc_fail_hook, which, if points to something non-NULL, is called by malloc when it is about to fail the call. An application that sets up such a hook can later print how many allocations failed. __libc_malloc_hook is called whenever a block is returned to an application, and the info about that block is passed as arguments to the hook; this can be used to gather statistics about memory allocations. Etc., etc. malldbg.c uses these hooks to implement a simple malloc debugging and memory reporting package. > Incorporating such pointers in the module will mean they > have to be NULL initialized and tested True. I don't think a test against NULL is a significant overhead in normal usage. > and non-standard routines will have to be present to set and reset > them. Well, messing with internals of a library implementation is inherently non-standard. Those hooks are meant to be used by memory allocation debuggers and various malloc extensions, so standardization of the internal names is not the issue. For example, malldbg.c implements several fairly-standard functions using these facilities. > It also means that > such routines as "free(NULL)" cannot simply do an early return, > but must use the single return point. I don't see why. `free' simply does this: if (ptr == 0) { if (__libc_free_hook) __libc_free_hook(); return; } So you again pay the price of a single comparison. > Or is name changing the operational problem? It's mainly a back compatibility problem. > At any rate, if you can ease my getting the descriptions of the > interfaces, I can think about things much better, rather than > making wild guesses. I'll happily help you understand teh current implementation. Just ask questions here if the docs is not enough. > Just looking at the names above realloc_fail_hook seems to be > missing. realloc fails if malloc fails, and the latter has a fail hook. But I don't have anything against adding a reall-c-specific fail hook, if that's what people want. > And what about calls that > are rejected because the memory has been corrupted or free/realloc > is passed an invalid pointer (some of which I detect and do a > signal). If these are detected, we probably want additional hooks for these specific failures.