>> > > 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 _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
