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


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: mallinfo not 64-bit clean


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Wolfram Gloger wrote:

>>You can setup some defines for the request,
>>#define  MALLOC_ALL_ARENAS   000000  /* get summary data for all arena's
>>*/
>>#define  MALLOC_CURR_ARENA   000001  /* get data for current arena */
>>#define  MALLOC_SELECT_ARENA 000002  /* specify arena of interest */

This is exactly what must be avoided.  This once again hardcodes
information about the malloc implementation in the interface.  This is
unacceptable.  If the current implementation is replaced the structure
might be completely different and all these selectors would make no
sense anymore.  Exactly like the current mallinfo situation where the
fields original intention has nothing to do with the way they are used
today.

Any information interface the libc side exposes must be neutral wrt to
the implementation.  And again, a self-describing data structure (XML)
is the only viable way I see.

Then it is up to the parser of the information to make sense of the
changing information.  This is the only possible way to ensure that
applications continue to work if the implementation changes since it
allows each application to make its own decision on how to present the
changed data to the program.


Of course there will be people who don't like this.  It means more work
for application.  Boo hoo!  Get over it.  I already suggested that an
example parser can be provided.


Again, no interface which hardcodes assumptions about the implementation
is acceptable.  With the change to dlmalloc we got away with having a
screwed mallinfo interface since there was none before.  This is not the
case anymore and every change cause casualties among the applications.
The ABI of glibc is not only the structures used, but also the
information they are filled with.  We cannot ensure the content is not
changed, therefore we cannot provide such an interface.

- --
â Ulrich Drepper â Red Hat, Inc. â 444 Castro St â Mountain View, CA â
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFBPi/92ijCOnn/RHQRAsTJAJ9Tti3ki3HFMjiCrYO5ye5LxbKMNQCdF3on
10EuTMsVTJVo8u42JDe1jBU=
=A+Jy
-----END PGP SIGNATURE-----


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