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

[Paul Davis]

>> So, if we replace malloc, we then need a table of pointers and their
>> size. Worth it?
>
>If we're going to be using it for anything substantial, I tend to
>think this would be *extremely* unwise.  Writing a good allocator is
>*hard*.

as someone coming back to the internals of ltdl after a year or two, i
have to say that this seems to me to have gotten *way* out of hand. i
don't know if you've had people commenting on the current design who
haven't let it slowly creep up on them, but at first view, its
horribly, horribly broken.

no individual library like this should be replacing malloc. even the
C++ STL, which does all kinds of funky things with customized
allocators, and even glib, which does similar stuff in the C domain,
doesn't replace malloc. you simply don't do that. a program that needs
a customized allocator doesn't need it just in one library. 

most of my applications are linked against libhoard, which provides a
blindingly fast multithreaded allocator (my programs are just about
all multithreaded). libhoard simply replaces the libc malloc with its
own (along with free and realloc).

what on earth is ltdl.c doing providing stubs for library-local
allocation in the first place? ltdl is not an object, its a set of
wrappers for existing functions on each supported platform. 

--p