Re: dynamically allocated memory

Gordon Burditt wrote:
> >> > Can i replace gnu libc malloc without recompiling libc?
> >>
> >> There is no one, right, portable way to do it except to '#define malloc
> >> mymalloc' (or never call 'malloc') and compile all your code that way. Many
> >> libraries have their own way to replace the memory allocation functions. For
> >> example, OpenSSL has CRYPTO_set_mem_functions. There is, of course, also
> >> non-portable linker magic.
> >
> >I'm surprised to read that.
> >
> >Is not placing your own object with malloc/free before libc in the
> >linker object list the portable way to do this at link time? Or using
> >LD_PRELOAD at run time?
> You are not guaranteed that the linker can drag in individual symbols
> separately from libc (especially if it's static-linked). You might
> end up with malloc() and free() from your own object, and one object
> module from libc.a containing exit(), malloc(), free(), and fflush().
> Since you've got TWO malloc()s and TWO free()s, the link dies on a
> multiply defined symbol.

This is false for Linux at least. All imported symbols no matter how
objects were linked are subject to dynamic linking. So, there is no way
a process accidentally uses two different malloc/free, all the
references will be resolved by to the only implementation.

> This is less likely to be a problem with dynamic-linked libraries.
> However, with dynamic-linked libraries, you are likely to have the
> problem that fopen() calls the malloc() in the libc library, not
> the one you supplied.

This is also wrong since malloc is an exported symbol, rather than

Refer to