On Tue, Sep 15, 2009 at 10:49:23PM +0200, Mike Hommey wrote: > On Tue, Sep 15, 2009 at 10:09:15PM +0200, Mike Hommey wrote: [...] > diff --git a/xmlIO.c b/xmlIO.c > index c03ac43..1e7d213 100644 > --- a/xmlIO.c > +++ b/xmlIO.c > @@ -3149,7 +3149,11 @@ xmlParserInputBufferGrow(xmlParserInputBufferPtr in, > int len) { > * Call the read method for this I/O type. > */ > if (in->readcallback != NULL) { > - res = in->readcallback(in->context, &buffer[0], len); > + nbchars = 0; > + while (len && (res = in->readcallback(in->context, &buffer[nbchars], > len)) > 0) { > + nbchars += res; > + len -= res; > + } > if (res <= 0) > in->readcallback = endOfInput; > } else { > @@ -3160,7 +3164,7 @@ xmlParserInputBufferGrow(xmlParserInputBufferPtr in, > int len) { > if (res < 0) { > return(-1); > } > - len = res; > + len = nbchars; > if (in->encoder != NULL) { > unsigned int use;
Hum, no I don't like that. The semantic of GROW is try to grow not wait until you get that amount of data. len is indicative as expressed in the comment and I prefer not try to guess how much stuff might break in subtle ways if you change that semantic. For example a Jabber client will probably deadlock because we are waiting for a buffer full while the server sent some kind of ping and is waiting for an answer which will never come because the client is still stuck trying to wait for more data instead of answering the ping. Your scheme work for things like reading from a file, but one should use the existing APIs and inkscape extension should just do that (the core inkscape parsing routine actually feed the parser properly). Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ _______________________________________________ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml