This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: static _int_malloc et al


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]