Re: [xml] c14n

[Aleksey Sanin <aleksey aleksey com>]

Sounds good. I'll do it this week (I hope).

Aleksey

Daniel Veillard wrote:
> On Tue, Mar 15, 2005 at 10:13:32AM -0800, Aleksey Sanin wrote:
>
> > > > Currently, all c14n errors are ifdef'd with DEBUG_C14N. Should
> > > > we just turn them on by default?
> > >
> > >
> > > Depends:
> > >    1/ do they use the existing structured error reporting framework ?
> > >       I think so but double checking quickly would be good
> >
> > Yes. Errors are printed out using
> >    xmlGenericError(xmlGenericErrorContext, ...)
> > calls.
>
>
>   Hum, it's not the structured API. The structured one provides more
> informations, more generically, see include/libxml/xmlerror.h,
> there is a XML_FROM_C14N error domain, and an error range for C14N
> (starting at XML_C14N_CREATE_CTXT 1950 to 2000) for error numbers.
> Best is to define in c14n.c a couple of intermediate calls which sets
> the context up and call __xmlRaiseError or __xmlSimpleError, see for
> example xmlTreeErrMemory() and xmlTreeErr() at the beginning of 
> the tree.c module. Not really fun to do, defining new enums for errors
> and calling the intermediate functions but it makes a huge difference
> when the library is embedded in a more complex framework.
>
>
> > >    2/ is there any drawback for example speed wise ?
> >
> > I don't think so. It is only error case which should not happen during
> > "normal" run. I'll make sure that only errors will be undefed.
>
>
>   The main drawback can be the code size inflation, but using intermediate
> simpler calls at the beginning of the modules avoid most of the code 
> size increase (don't get me started on ELF symbols lookup at runtime ...)
>
>
> > >    3/ would that be a problem for upper layer like xmldsig ?
> >
> > Not to xmldsig. It should be no difference for normal run.
>
>
>   okay, though the structured error handling might be useful for your
> users too ;-)
>
>
> > > In general people appreciate receiving error messages when stuff fails.
> >
> > Yes, I know :)
>
>
>  especially if they can automate the processing of said errors :-)
>
> Daniel