Re: mallinfo not 64-bit clean [PATCH]

[Wolfram Gloger <wmglo at dent dot med dot uni-muenchen dot de>]

Ulrich Drepper wrote:

> The problem I see is that this interface makes implementation details
> visible.  If the implementation changes at some point we will be in the
> same situation again.
> 
> The only somewhat adequate mechanism I can think of is self-describing
> data structures.  It's possible to use something like ASN.1 but maybe a
> plain text format is most adequate and this would mean: XML.  Producing
> XML in this context is simple.

Actually I think this is a good idea.  And since malloc_get_stats can
now be in a separate source file the bloat wouldn't be _too_ bad even
for static linkage.  The next ptmalloc2 release could include a helper
library with the decoding function(s).

I'll start working on this.

>   int malloc_get_stats(char *buffer, size_t);

Would you agree the text buffer should be dynamically allocated and
freed using free()?  After all, it would be hard to suggest a
reasonable buffer size for all future implementations.  I'd suggest:

/* The resulting text buffer will be dynamically allocated and can be
   free()d after use.  __mstate must be 0 to compute global
   statistics.  Returns 0 for out of memory.  */
char *malloc_get_stats(void *__mstate);

even if this means the statistics are changed by that additional
allocated chunk.  Because if you would pass a too short buffer, the
result would be invalid/useless XML, so the user would probably have
to code some dynamic allocation anyway.

Regards,
Wolfram.