Re: mallinfo not 64-bit clean

[steve_dum at mentorg dot com]

Your absolutely right, SOME of the information will change over time.
Unfortunately xml doesn't come any closer to solving this problem than
either of the previous solutions. It's the user program that has to be
able to adapt to whatever version of libc that is found on the current
system. You've just shifted the problem from the library (malloc) to the
user program. If there are significant changes in the generated xml, a
program parser is no more likely to be able to have predicted what the
changes would be and be able to parse it, than it could predict the new
information to request. Even if the user program flawlessly parses the
xml, the fields name and meaning may change, leaving any programmatic
interpretation flawed. In fact, it will probably be a less stable
interface, because it will encourage the library developer to make minor
tweaks to the xml - since it is 'self describing', causing more frequent
parser failures. So if I'm just dumping the xml out to the user  (or
some trivially translated version of it), then the xml is reasonable. 
But if I'm trying to write code that does something useful based on the
values then I have to write code that looks for specific fields and apply
specific semantics. If these change over time, how can my code continue to run.

Bottom line, no matter what mechanism you use the program needs to
know what version of malloc the current running program is talking to and
deal with the data accordingly.  It's just as possible to exchange
version information when passing structs,  using the ioctl model,
or with xml.  The xml seems like the least desirable because it isn't
as well defined and the interface could change in more incompatible ways.

Even Wolfram's struct interface can be versioned to allow for changes
over time.

steve
...
>
>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=3D
>=3DA+Jy
>-----END PGP SIGNATURE-----