Re: ltdl.c thinks it's psychic (another SEGFAULT bug).

[Paul Davis]

>> > > what is any of this for in the first place?
>> >
>> >You mean why do we allos someone to define lt_dlmalloc, lt_dlrealloc,
>> >and lt_dlfree? I don't know :)
>>
>> yes, thats precisely what i mean. what problem is this attempting to
>> solve? some bizarre platform where ltdl.c can't call malloc()?
>
>Personally I consider this to be a good thing for libraries.  It is useful
>if you want to use a different (underlying) memory allocation API.
>Imagine you want to pass part of a shared memory arena (IRIX uses such)
>and libltdl.so tries to free() it with the standard libc call, this might 
>fail and crash the program.  Also M$-Windows knows different
>memory allocator APIs.

i have no problem with that. the issue is: why is there any support
for this on a per-library basis? i may have mentioned before that most
of my programs use libhoard, which completely replaces malloc,free and
realloc with ultra-fast-for-SMP-multithreaded equivalents. why on
earth do i want to tell ltdl (or any other particular library) to be
using a version of malloc/free/realloc that's any different from the
one used by the rest of the libraries linked to my progam? replacing
malloc() is often a good idea. but replacing malloc on a per-library
basis? why?

and besides, if you pass an acquired resource to an API, then you
either have to specify that its not the API's job to release it, or
provide the API with a way to do so. Since lt_dlmalloc() and
lt_dlfree() are intended for use entirely *within* the library, they
do not cover this condition, as far as i can see.

--p