Re: [xml] Potential problem with 2.7.4

[Daniel Veillard <veillard redhat com>]

On Tue, Sep 15, 2009 at 11:35:09PM +0200, Mike Hommey wrote:
> > 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).
>
> What bothers me with the current fix is that somehow the code expects 35
> bytes for the beginning of the buffer, yet doesn't care to make sure
> that there be that amount of bytes. I haven't looked too deeply at the
> code, but that sounds like this could lead to segfaults if some stupid
> things are done with this API.

  I don't think it can segfault. All you might get is a parsing error

> Surely, they should be using other APIs, but this one exists and is
> public. Don't you think it would be better to avoid applications
> shooting themselves in the foot ?

  I think I prefer solving this specific first 'line' problem of the
xmlDecl by failing to parse if someone uses the API too stupidly, that's
easy to spot and actually if they do minimal testing of their code they
should notice and fix it immediately.
  The alternative in that case was silent data corruption due to
excessive use of the guessed encoding and I prefer a parse failure to
a silent corruption.
  I know it doesn't look so nice, but it works well enough. I may have
to rethink this encoding guess and use a replay fallback if we really
hit problems but I doubt it.

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel veillard com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/