static _int_malloc et al
Wolfram Gloger
wmglo@dent.med.uni-muenchen.de
Wed Jan 8 08:46:00 GMT 2003
Hello,
> The functions have never been public. They were not exported from
> libc.so and not used outside malloc.c.
Ok, I see.
> Now as for providing the interface to users, this is exactly what the
> libc should not do. Once exported, always exported. It would mean the
> interface would have to be maintained even if the malloc implementation
> changes dramatically.
True, it is a matter of seeing such a change before glibc-3.x,
whenever that might be. Personally, I don't see it but it's your
call. Also, we have a (bad?!) precedent already, malloc_stats().
That, too, would have to be maintained. I think it would in fact be
easier to maintain _int_* with a future implementation than
malloc_stats().
> I hope we all agree that this isn't going to happen. I see that such an
> interface is useful. But then it should be in a library on its own.
Ok. Can it be arranged that the _int_* functions are marked
__libc_hidden within libc.so but are exported in a separate library,
say libmalloc.so? libmalloc.so would also ideally have access to
other __libc_hidden symbols in malloc.os from libc.so; I guess this is
impossible to achieve?
Otherwise we would need code duplication in libmalloc.so. Not ideal,
but if it keeps libc.so "clean"...
Regards,
Wolfram.
More information about the Libc-hacker
mailing list