RE: [xslt] Help with compiling libxslt on HP-UX

Ouch.. (me is culprit) I should have read the docs before replying back to
you :(.

Anyways, to clarify what I was trying to convey : If I change the type of
xmlChar to wchar_t, and, if libxslt code is based on xmlChar (not assuming
char to xmlChar convertibility), then the compilation should not have
complained. (but forget it - I'll start with the docs now :) )


>-----Original Message-----
>From: Daniel Veillard []
>Sent: Wednesday, July 16, 2003 3:37 PM
>Subject: Re: [xslt] Help with compiling libxslt on HP-UX
>On Wed, Jul 16, 2003 at 06:24:44PM -0400, 
>MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
>> It works - Thanks !.
>> A following set of questions will be :
>> (1) Can we just do the change and move on ?
>  yes
>> (2) I believe libxslt is designed with a ASCII POV. I say 
>that because, when
>> I changed the definition of xmlChar to "uchar_t", the 
>libxslt would not
>> compile. Is it intentional designed that way ?
>  read the docs !
>  "xmlChar, the libxml2 data type is a byte, those bytes must 
>be assembled as UTF-8 valid strings. The proper way to 
>terminate an xmlChar * string is simply to append 0 byte, as usual."
>  So your change is just plain broken, and all libxml2/libxslt code 
>is garanteed to broke doing so.
>> (3) If (2) is correct, can we just live by checking for 
>"0x30" (DIGIT ZERO),
>> instead of changing the input ?
>  What do you mean by "libxslt is designed with a ASCII POV"
>Libxml2 use UTF8 internally, period, irrevocable, the right 
>decision and
>not to be changed ever. But again read the full doc before 
>jumping on hasty
>conclusions , if you mean that libxslt is limited to ASCII, 
>this is wrong
>and would be totally not compliant (i.e. I would nearly take this as an
>Daniel Veillard      | Red Hat Network
>  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

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