Re: [xml] xmlIO enhancements?

On Tue, Apr 05, 2005 at 01:22:50PM -0400, Joel Reed wrote:
I'm reviewing xmlFileOpen_real and xmlGzfileOpen_real in xmlIO.c and have
two quick questions/possible improvements (i'll fire off a patch if no

1) xmlFileOpen_real does a

  if (!xmlCheckFilename(path)) return(NULL);

before the fopen(path, "r") call. This quick-out prevents library users
from ever seeing a message in their structure error handler like
"No such file or directory." By deleting this check, we can let fopen call
fail and set errno, then let normal libxml error handling bubble the
error back up to library users. Any reason why not to do this?

   the optimistic way might be better yes. Might be faster too, see

  if you work around improving xmlIO it might be something to keep in mind.
That could get rid of one of the 3 stat() calls.

2) Any reason not to enhance the last line of __xmlIOErr:

  __xmlSimpleError(domain, code, NULL, IOerr[idx], extra);

to say

  __xmlSimpleError(domain, code, strerror(errno), IOerr[idx], extra);

if this change passes all tests i'll submit a patch unless someone
thinks it a bad idea.

  the main question is the portability of strerror() according to
this should be ISO C, but I'm wondering about it on weird platforms/compilers.

3) xmlGzfileOpen_real does not have anything like: 

    if (fd == NULL) xmlIOErr(0, path);

after the gzopen(path, "rb") call, unlike xmlFileOpen_real. this
minor inconsistency could be addressed easily enough. Any reason not to?

   Makes sense of course, yes.
p.s. have a good vacation dv!

   Thanks :-) I may actually work a bit on libxml2 during the first week,


Daniel Veillard      | Red Hat Desktop team
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]