Re: [PATCH] manual: memory: document support custom allocators

[Mike Frysinger <vapier at gentoo dot org>]

On 13 Feb 2016 11:38, Florian Weimer wrote:
> On 02/13/2016 03:46 AM, Mike Frysinger wrote:
> > +@node Function Replacements
> > +@subsection API for custom allocators
> > +
> > +Your replacement must implement all of these functions.  If you omit any of
> > +them, correct behavior cannot be guaranteed.  This is because some functions
> > +might not internally call the others.  E.g. @code{calloc} might not call
> > +@code{malloc}, so passing the returned pointer to @code{free} can confuse the
> > +allocator.
> > +
> > +@itemize @bullet
> > +@item @code{malloc} @xref{Basic Allocation}
> > +@item @code{free} @xref{Freeing after Malloc}
> > +@item @code{realloc} @xref{Changing Block Size}
> > +@item @code{calloc} @xref{Allocating Cleared Space}
> > +@item @code{memalign} @xref{Aligned Memory Blocks}
> > +@end itemize
> >  
> > +All other memory functions that the @glibcadj{} provides will utilize the
> > +ones listed above.  You may replace them, but the @glibcadj{} will not call
> > +them directly, only through the aforementioned list.
> 
> I think this should note that other system libraries may call the other
> functions, and that for full compatibility. an interposed malloc should
> override these functions as well.

i don't think that's what we want.  even if another library (be it part of
glibc or otherwise) calls a function not overridden, those will eventually
call into malloc().  the funcs i listed where the only ones that show up
in a `readelf -r` listing of libc.so.
-mike

Attachment: signature.asc
Description: Digital signature