[PATCH] manual: memory: document support custom allocators

[Florian Weimer]

On 02/13/2016 12:07 PM, Mike Frysinger wrote:
> 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.

To be clear, I am talking about malloc_usable_size, valloc, pvalloc,
aligned_alloc, and posix_memalign.  Some system libraries do call some
of these functions, and if your interposed malloc library does not
override them as well, crashes are the result.

Florian