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 [PATCH]


Wolfram Gloger wrote:

> Ok, here is what I have coded up today for the mallinfo problem.  A
> new test is also included.  I don't intend to change the
> malloc_{arena,global}_info structs any time soon, but they shouldn't
> be considered 'fixed' either.  I added the three new functions with
> GLIBC_PRIVATE for now, but maybe GLIBC_2.3.x is justfied.  Your call.

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.  Yes, this means a little bit more work
on the decoder side but it would be safe.  We could provide a little
helper library which decodes the XML into binary form, maybe even the
interfaces you propose.

The advantage is that the libc interface is stable and programs will
notice if they don't understand the output format and will be able to
recover.

I haven't thought about the details much yet, but I imagine an interface
like this:

  int malloc_get_stats(char *buffer, size_t);

and an XML format like

<mallocstat>
  <total>123231</total>
  <arena idx="0">
    <free>2342</free>
    <allocated>34534</allocated>
  </arena>


-- 
â Ulrich Drepper â Red Hat, Inc. â 444 Castro St â Mountain View, CA â


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