Re: [xml] (no subject)

On Tue, Mar 20, 2001 at 02:54:32PM -0600, Chuck Griffith wrote:
Error processing is the stepchild of program design, so I can see why I am
having trouble dealing with this.

I am finding that libxml does not cooperate nicely in my transactional
environment where all errors need to be logged to managed location.

xmlGenericErrorDefaultFunc can be easily overridden but it is not the only
one doing printf's to stderr (as pointed out by Matt Sergeant) _plus_

  This is getting fixed, check the version in the CVS base and
send patches if there is still places left where (f)printf is called.

xmlParserPrintFileContext sends one character at a time making a mess if
xmlGenericErrorDefaultFunc is turned into a logging facility.

I suggest taking xmlParserPrintFileContext (2.3.4) and doing the following:
[provided printf("%.*s", n, string) is widely portable]

  Well I don't think it's the case, so I would not rely on it,
using a temporary buffer may be appropriate (it's still an error
path so IMHO adding an allocation there is Okay).

Also, it would be nice if xmlGenericError were the final arbiter for
new-lines but in the mean time I can just clean them out before logging the

  What do you mean ? Can you be more explicit ?

Sorry I didn't provide the change format that Matt supplied but I'm too new
to this process to know what tool creates that. I tried diff but it sure
looked ugly.

  diff -c 

to provide the changes in their context and allow them to apply cleanly
(or allow me to understand them better if the patch fails).


Daniel Veillard      | Red Hat Network
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]