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


--- Ulrich Drepper <drepper@redhat.com> wrote:
> 
> 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.

Both of you are right and wrong. XML doesn't solve Steve's problem, but it does
solve Ulrich's problem. Ulrich wants to write his code and not be limited when
he needs to change information that is being returned. Contrasting this is
Steve who needs to write programs that get this data. This program needs to run
on many versions of the OS. He does not wish to release a different version
every time malloc's internals change. He does not want to radically change the
complexity of his program by adding a robust XML parser for this tangential
feature.

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

Yes only the user program knows what it wants, but only the library knows what
it is providing. There is still a disconnect. Nothing has been solved. All that
has been accomplished is a better method of laying blame on 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,
> 
> 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.

I think YOU have missed the point, we application developers do not like to
rewrite our code because of some whim of a library programmer. And even worse
we do not like to make different versions to run on different versions of a
stable library.

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

Again, you miss the point. See my previous statements. It is not because we
lack the ability to write this code, but if the content changes enough, then
our code will be looking for the wrong content.

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

Yes there is, XML is not a magic wand.

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

Clearly you are missing a very important point. Most application programmers
care only about very basic information that is NOT library implementation
dependent. This information should be trivially available with, at most, a few
calls to the library. This information shouldn't require me to write a parser.
It should not change my memory footprint significantly.

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

You are missing the point, Yes it can. For the information that varies over
time it can have similar problems, but so does the XML. Or I should say the XML
creates a similar problem.

> No binary interface can work.

My you are a visionary to have have conceived AND rejected all possible binary
interface solutions.

> In general such information should never
> ever be shared since it's limiting the freedom of the implementor.

This is not true. Much of the desired information is implementation
independent.

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

I doubt whether you know if he is or is not knowledgeable of all the levels
where 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.

Actually I'm sure that when his program(s) stops working, people do complain to
him and not you. It seems rather silly that the application programmer that
needs basic information should need to do significant work.

   -Steve LoBasso

> - --
> â?§ 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-----



		
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail 


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