Re: [xml] c14n

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


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?

   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, ...)

  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 :-)


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