This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: mallinfo not 64-bit clean
- From: Roland McGrath <roland at redhat dot com>
- To: Wolfram Gloger <wmglo at dent dot med dot uni-muenchen dot de>
- Cc: steve_dum at mentorg dot com, libc-alpha at sources dot redhat dot com,drepper at redhat dot com, nevyn-glibc-alpha at and dot org
- Date: Tue, 7 Sep 2004 14:41:35 -0700
- Subject: Re: mallinfo not 64-bit clean
> (A) such a get_malloc_statistics() call: this function would need to
> be within libc, but I think it could well become
> get_libc_statistics() for a more general interface, there are
> surely more interesting variables in the C library than just
> malloc stats
I think it is better to use individually meaningful function interfaces.
Then they can be usefully versioned with normal symbol versioning.
Otherwise you wind up with programs written to expect some new query that
is not available in older versions of the call and this dependency is not
expressed clearly.
> (B) export "struct opaque * _int_get_arena(int n)" from libc like in
> my proposed patch, and do all the messy versioned processing in a
> separate library _outside_ libc. Note that global (non
> arena-related) info can be obtained from the already exported
> malloc_get_state().
This level of interface is libc-private regardless. So that is fine if you
want to provide an additional library. That has the nice effect of not
bloating libc, and perhaps giving a more free hand to change this extra
library's interface in the future.