Re: [xml] (no subject)

[Daniel Veillard <veillard redhat com>]

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

  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

-- 
Daniel Veillard      | Red Hat Network http://redhat.com/products/network/
veillard redhat com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/