This is the mail archive of the
mailing list for the glibc project.
Re: mallinfo not 64-bit clean [PATCH]
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.