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

First of all: stop that moronic top quoting.  If you cannot write mails
like a reasonable person, go away.


steve_dum@mentorg.com wrote:
> Your absolutely right, SOME of the information will change over time.
> Unfortunately xml doesn't come any closer to solving this problem

Wrong.


> You've just shifted the problem from the library (malloc) to the
> user program.

Exactly, as I said before, since only the user program knows what it
looks for in the data.


> 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,

You completely miss the point.  If the exported data changes a *new*
parser library has to be used.  That's the whole point.  Try thinking
before criticizing.


> 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.

Again, you fail to grasp the concept.  It is the programmer's
responsibility to decide what information is needed and then extract it.
 If s/he is not able to do this s/he should not write any of that code.


> 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.

Of course, but if the C library changes it's only the parser which needs
to be changed, not the application.  There is no way this level of
compatibility can be achieved when the C library exports binary data.


> It's just as possible to exchange
> version information when passing structs,

You don't get it.  If the implementation changes there is often *no way*
to exported the same kind of information to make all programs using the
data happy.  What if a new implementation does not use an arena concept
but something completely different?  Then exporting data as if arena
would still be used is not possible.  Only the application can decide
what mapping of the new implementation's data to the old data is useful.



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

Versioning cannot solve the problem.  See above, you miss the whole point.


No binary interface can work.  In general such information should never
ever be shared since it's limiting the freedom of the implementor.  This
is unacceptable and providing the data in this abstracted form is a
compromise.  You have apparently no idea what all the levels are at
which binary compatibility is required.  It's not you who people
complain to when their applications stop working.  If somebody wants
this kind of lowlevel information they have to do part of the work.

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

iD8DBQFBP9SD2ijCOnn/RHQRAoi8AJ4zhk+HJPCebvHwrwMQD6nn+C/fgwCghUCY
8XSDsbDp/ye6qQDUwGJ7drQ=
=Aaji
-----END PGP SIGNATURE-----


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