From iin@rgdata.ukrtel.net Wed Oct 1 09:39:57 2003 Return-Path: Delivered-To: xml@gnome.org Received: from ns.rgdata.ukrtel.net (unknown [62.244.14.118]) by mail.gnome.org (Postfix) with ESMTP id 7D85D1816A for ; Wed, 1 Oct 2003 09:39:51 -0400 (EDT) Received: from fs-rgdata.rgdata.ukrtel.net (fs-rgdata.rgdata.ukrtel.net [192.168.100.2]) by ns.rgdata.ukrtel.net (Postfix) with ESMTP id BBD863FC6 for ; Wed, 1 Oct 2003 16:39:40 +0300 (EEST) Received: by fs-rgdata.rgdata.ukrtel.net (Postfix, from userid 555) id 43A9FBD40; Wed, 1 Oct 2003 16:59:36 +0300 (EEST) Received: from kvp (kvp.rgdata.ukrtel.net [192.168.100.41]) by fs-rgdata.rgdata.ukrtel.net (Postfix) with ESMTP id 8C949BD3C for ; Wed, 1 Oct 2003 16:59:35 +0300 (EEST) From: "Igor Izvarin" To: Date: Wed, 1 Oct 2003 16:44:14 +0300 Message-ID: <001901c38822$1a668da0$2964a8c0@kvp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01C3883B.3FB3C5A0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [xml] RAW && NXT with strncmp() Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_001A_01C3883B.3FB3C5A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi community, I think this is the question mainly to Daniel Veillard, but ... :-))) I found 79 (more or less) places in the parser.c code that contains fragments like this: if ((RAW == '<') && (NXT(1) == '?') && (NXT(2) == 'x') && ....) Its functionality is exact repetition of the functionality of the strncmp() standard function. if (strncmp(RAW, " Message
Hi=20 community,
 
I = think this is the=20 question mainly to Daniel Veillard, but ... = :-)))
 
I = found 79 (more or=20 less) places in the parser.c code that contains fragments like=20 this:
if ((RAW =3D=3D '<') && = (NXT(1) =3D=3D=20 '?') && (NXT(2) =3D=3D 'x') && ....)
 
Its = functionality is=20 exact repetition of the functionality of the strncmp() standard=20 function.
if = (strncmp(RAW,=20 "<?x...", n) =3D=3D 0) ...
 
This = function can be=20 expanded inline using the #pragma intrinsic(...)=20 instruction.
 
For my = opinion this=20 change will improve the code readability and maintenance, will reduce = the source=20 code size and object code size.
 
What = is your opinion=20 on this?
 
With = best=20 regards,
Igor=20 Izvarin
------=_NextPart_000_001A_01C3883B.3FB3C5A0-- From veillard@redhat.com Wed Oct 1 09:51:00 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id E9C031838F for ; Wed, 1 Oct 2003 09:50:59 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h91DotB24988; Wed, 1 Oct 2003 09:50:55 -0400 Date: Wed, 1 Oct 2003 09:50:55 -0400 From: Daniel Veillard To: Igor Izvarin Cc: xml@gnome.org Subject: Re: [xml] RAW && NXT with strncmp() Message-ID: <20031001095055.G21529@redhat.com> Reply-To: veillard@redhat.com References: <001901c38822$1a668da0$2964a8c0@kvp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <001901c38822$1a668da0$2964a8c0@kvp>; from iin@rgdata.ukrtel.net on Wed, Oct 01, 2003 at 04:44:14PM +0300 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, Oct 01, 2003 at 04:44:14PM +0300, Igor Izvarin wrote: > Hi community, > > I think this is the question mainly to Daniel Veillard, but ... :-))) > > I found 79 (more or less) places in the parser.c code that contains > fragments like this: > if ((RAW == '<') && (NXT(1) == '?') && (NXT(2) == 'x') && ....) Right, > Its functionality is exact repetition of the functionality of the > strncmp() standard function. > if (strncmp(RAW, " This function can be expanded inline using the #pragma intrinsic(...) > instruction. That's not portable, I can't rely on this. > For my opinion this change will improve the code readability and > maintenance, will reduce the source code size and object code size. yes, > What is your opinion on this? That I was looking at it this yesterday actually but I don't feel that confident about such a change, yet ... Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From swilliams@rinax.com Wed Oct 1 11:55:22 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail.nucleus.com (mail1.nucleus.com [207.34.101.2]) by mail.gnome.org (Postfix) with ESMTP id 13F6B184C4 for ; Wed, 1 Oct 2003 11:55:22 -0400 (EDT) Received: from rinax.com (unverified [205.206.148.14]) by mail.nucleus.com (Vircom SMTPRS 2.1.268) with ESMTP id ; Wed, 1 Oct 2003 09:55:33 -0600 Message-ID: <3F7AF909.7040007@rinax.com> Date: Wed, 01 Oct 2003 09:55:53 -0600 From: Steve Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Igor Izvarin Cc: xml@gnome.org Subject: Re: [xml] RAW && NXT with strncmp() References: <001901c38822$1a668da0$2964a8c0@kvp> In-Reply-To: <001901c38822$1a668da0$2964a8c0@kvp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi, Depending on the frequency of a match NOT occuring, the original code could be significantly faster. The first condition that did not match causes the remaining comparisons to not happen. If in 90% of the cases (I have no idea the context of this code), the match is going to fail on the (RAW=='<'), then the other two comparisons would NOT happen. This compared with the overhead of a function call every time... but then I'm an "old school" C programmer who considers things like speed. I'd be inclined to make a #define for the comparison if it occurs in so many places. But that's just me... Cheers, Steve Igor Izvarin wrote: > Hi community, > > I think this is the question mainly to Daniel Veillard, but ... :-))) > > I found 79 (more or less) places in the parser.c code that contains > fragments like this: > if ((RAW == '<') && (NXT(1) == '?') && (NXT(2) == 'x') && ....) > > Its functionality is exact repetition of the functionality of the > strncmp() standard function. > if (strncmp(RAW, " > This function can be expanded inline using the #pragma intrinsic(...) > instruction. > > For my opinion this change will improve the code readability and > maintenance, will reduce the source code size and object code size. > > What is your opinion on this? > > With best regards, > Igor Izvarin From veillard@redhat.com Wed Oct 1 12:29:35 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 0DF20184FB for ; Wed, 1 Oct 2003 12:29:35 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h91GTak22877; Wed, 1 Oct 2003 12:29:36 -0400 Date: Wed, 1 Oct 2003 12:29:36 -0400 From: Daniel Veillard To: Steve Williams , Igor Izvarin Cc: xml@gnome.org Subject: Re: [xml] RAW && NXT with strncmp() Message-ID: <20031001122936.N21529@redhat.com> Reply-To: veillard@redhat.com References: <001901c38822$1a668da0$2964a8c0@kvp> <3F7AF909.7040007@rinax.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3F7AF909.7040007@rinax.com>; from swilliams@rinax.com on Wed, Oct 01, 2003 at 09:55:53AM -0600 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, Oct 01, 2003 at 09:55:53AM -0600, Steve Williams wrote: > Hi, > > Depending on the frequency of a match NOT occuring, the original code > could be significantly faster. The first condition that did not match > causes the remaining comparisons to not happen. If in 90% of the cases > (I have no idea the context of this code), the match is going to fail on > the (RAW=='<'), then the other two comparisons would NOT happen. > > This compared with the overhead of a function call every time... but > then I'm an "old school" C programmer who considers things like speed. > > I'd be inclined to make a #define for the comparison if it occurs in so > many places. But that's just me... To play the devil's advocate, on modern processors what's really costly are caches misses. Sometimes doing a few more instructions is better than having larger code or touching more data. I still thing the current tests are faster because the test values are embedded as part of the instruction code. On the other hand this makes the code bigger. Then there is maintainance issue etc. I stated I'm balanced over this issue, the points Igor raised are real. I think most of the case are in areas which are not time critical. However we can still look at performances a bit: - I think gcc -O2 inlines things like CUR==a && NXT(1)==b && NXT(2)==c && NXT(3)==d as (*(int *) CUR) == abcd because valgrind complained about uninitialized memory access on such instructions when compiled with -O2 :-) - using strncmp(CUR, static_string, len) might also be inlined if it detects the string is immutable however if not inlined then it's not very good because you're breaking the locality of accesses for both instructions and data. Hand-optimizing (*(int *) CUR) == abcd would probably make the code totally unreadable (need to check for byte ordering of the achitecture + general uglyness of the cast :-) so I'm not going there, though if the compiler does it for me it's nice. Maybe the best is to test both. Igor would you provide me a contextual patch with those changes? I can't guarantee it will make into the final code, but I can garantee I will check it seriously (including some valgrind/cachegrind/kcachegrind profiling checks). Okay let's say that if I get the patch it's likely I will apply it unless results are really not good :-) Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From breese@mail1.stofanet.dk Wed Oct 1 12:45:24 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mx03.stofanet.dk (mx03.stofanet.dk [212.10.30.233]) by mail.gnome.org (Postfix) with ESMTP id C838418849 for ; Wed, 1 Oct 2003 12:45:24 -0400 (EDT) Received: from 3e6b2721.rev.stofanet.dk ([62.107.39.33]) by mx03.stofanet.dk with esmtp (Exim 4.22) id 1A4k6a-0004vA-32 for xml@gnome.org; Wed, 01 Oct 2003 18:45:36 +0200 Subject: Re: [xml] RAW && NXT with strncmp() From: Bjorn Reese To: xml@gnome.org In-Reply-To: <20031001095055.G21529@redhat.com> References: <001901c38822$1a668da0$2964a8c0@kvp> <20031001095055.G21529@redhat.com> Content-Type: text/plain Organization: Hyperspace Academy Message-Id: <1065026851.2063.31.camel@stellifer> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 01 Oct 2003 18:47:31 +0200 Content-Transfer-Encoding: 7bit Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, 2003-10-01 at 15:50, Daniel Veillard wrote: > That I was looking at it this yesterday actually but I don't feel > that confident about such a change, yet ... The libc string functions tend to be highly optimized. Time for informal benchmarking... [breese@stellifer:/home/breese/junk] gcc --version | head -1 gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5) [breese@stellifer:/home/breese/junk] uname -a Linux stellifer 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 2003 i686 i686 i386 GNU/Linux [breese@stellifer:/home/breese/junk] cat compare.c #include int main(void) { int i; int z; char buffer[64] = "xmlns"; for (i = 0; i < 1000000000; ++i) { #if USE_STRNCMP if (strncmp(buffer, "xmlns", sizeof(buffer)) == 0) z = 1; #else if (buffer[0] == 'x' && buffer[1] == 'm' && buffer[2] == 'l' && buffer[3] == 'n' && buffer[4] == 's') z = 1; #endif } return 0; } [breese@stellifer:/home/breese/junk] gcc -O2 compare.c [breese@stellifer:/home/breese/junk] time ./a.out 4.560u 0.040s 0:04.85 94.8% 0+0k 0+0io 65pf+0w [breese@stellifer:/home/breese/junk] gcc -DUSE_STRNCMP -O2 compare.c [breese@stellifer:/home/breese/junk] time ./a.out 0.930u 0.000s 0:01.03 90.2% 0+0k 0+0io 66pf+0w I get roughly the same results if I change the content of 'buffer'. From veillard@redhat.com Wed Oct 1 14:13:44 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 45F4D182B2 for ; Wed, 1 Oct 2003 14:13:44 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h91IDtc24199; Wed, 1 Oct 2003 14:13:55 -0400 Date: Wed, 1 Oct 2003 14:13:55 -0400 From: Daniel Veillard To: Bjorn Reese Cc: xml@gnome.org Subject: Re: [xml] RAW && NXT with strncmp() Message-ID: <20031001141355.Q21529@redhat.com> Reply-To: veillard@redhat.com References: <001901c38822$1a668da0$2964a8c0@kvp> <20031001095055.G21529@redhat.com> <1065026851.2063.31.camel@stellifer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1065026851.2063.31.camel@stellifer>; from breese@mail1.stofanet.dk on Wed, Oct 01, 2003 at 06:47:31PM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, Oct 01, 2003 at 06:47:31PM +0200, Bjorn Reese wrote: > On Wed, 2003-10-01 at 15:50, Daniel Veillard wrote: > > > That I was looking at it this yesterday actually but I don't feel > > that confident about such a change, yet ... > > The libc string functions tend to be highly optimized. yeah, I still have a hint from Ulrich Drepper about a way to speed up the char boundaries test in the internal loop testing CharData, one day maybe ... > Time for informal benchmarking... > [breese@stellifer:/home/breese/junk] gcc -O2 compare.c > [breese@stellifer:/home/breese/junk] time ./a.out > 4.560u 0.040s 0:04.85 94.8% 0+0k 0+0io 65pf+0w > [breese@stellifer:/home/breese/junk] gcc -DUSE_STRNCMP -O2 compare.c > [breese@stellifer:/home/breese/junk] time ./a.out > 0.930u 0.000s 0:01.03 90.2% 0+0k 0+0io 66pf+0w > > I get roughly the same results if I change the content of 'buffer'. The size gain is less stellar, 8 bytes ... paphio:~ -> gcc -O2 compare.c paphio:~ -> nm --print-size -td a.out | grep main U __libc_start_main@@GLIBC_2.0 134513396 00000072 T main paphio:~ -> gcc -DUSE_STRNCMP -O2 compare.c paphio:~ -> nm --print-size -td a.out | grep main U __libc_start_main@@GLIBC_2.0 134513396 00000064 T main paphio:~ -> So Igor, any chance you could do that patch ? Preferably against CVS or 2.6.0beta3 considering the number of change made since 2.5.11, thanks Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From christop@charm.net Wed Oct 1 14:21:17 2003 Return-Path: Delivered-To: xml@gnome.org Received: from hampden.charm.net (hampden.charm.net [207.114.0.146]) by mail.gnome.org (Postfix) with ESMTP id D5BEE1858B for ; Wed, 1 Oct 2003 14:21:16 -0400 (EDT) Received: from christop-209.143.91.188.charm.net (christop-209.143.91.188.charm.net [209.143.91.188]) (authenticated bits=0) by hampden.charm.net (8.12.9p2/8.12.9/LNSG+ORDB+SCOP+NJABL+RSL+SBL+DSBL) with ESMTP id h91ILTPG022323 for ; Wed, 1 Oct 2003 14:21:29 -0400 (EDT) (envelope-from christop@charm.net) Subject: Re: [xml] RAW && NXT with strncmp() From: Chris Anderson To: xml@gnome.org In-Reply-To: <1065026851.2063.31.camel@stellifer> References: <001901c38822$1a668da0$2964a8c0@kvp> <20031001095055.G21529@redhat.com> <1065026851.2063.31.camel@stellifer> Content-Type: text/plain Message-Id: <1065032790.32683.314.camel@kayak.charm.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.3.99 (Preview Release) Date: 01 Oct 2003 14:26:30 -0400 Content-Transfer-Encoding: 7bit Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, 2003-10-01 at 12:47, Bjorn Reese wrote: > On Wed, 2003-10-01 at 15:50, Daniel Veillard wrote: > > > That I was looking at it this yesterday actually but I don't feel > > that confident about such a change, yet ... > Not to belabor this point too much, it's not that important... There are a couple of things going on in that loop: First, icc completely optimizes the loop away, gcc just optimizes away the z = 1 statement since it's not used. Second, gcc puts the all of the characters of "xmlns" into registers before the loop begins, so the no strncmp test is really testing the speed of 5 * 1000000000 register compares and branches, which is a bit faster than loading the constants into registers and comparing. Third, the other point was that there are cases where most of the strings are not equal, this loop just tests the case where they are equal. Fourth, strncmp is not an intrinsic in either gcc or icc. Use memcmp, that will generate x86 repz string instructions as long as the size of the memory being compared is constant (size == 5). no memcmp: cmpb $120, -73(%ebp) jne .L128 cmpb $109, %bl jne .L128 cmpb $108, %cl jne .L128 cmpb $110, %dl memcmp( buffer, "xmlns", 5 ) leal -88(%ebp), %esi movl $.LC0, %edi movl $5, %ecx cld repz cmpsb seta %dl setb %al cmpb %al, %dl The no memcmp is quite a bit faster, but the instruction count isn't that different. I think it's more of a clarity thing unless you are in a code hot spot. > The libc string functions tend to be highly optimized. > > Time for informal benchmarking... > > [breese@stellifer:/home/breese/junk] gcc --version | head -1 > gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5) > [breese@stellifer:/home/breese/junk] uname -a > Linux stellifer 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 2003 i686 i686 i386 > GNU/Linux > [breese@stellifer:/home/breese/junk] cat compare.c > #include > int main(void) > { > int i; > int z; > char buffer[64] = "xmlns"; > > for (i = 0; i < 1000000000; ++i) { > #if USE_STRNCMP > if (strncmp(buffer, "xmlns", sizeof(buffer)) == 0) > z = 1; > #else > if (buffer[0] == 'x' && buffer[1] == 'm' && > buffer[2] == 'l' && buffer[3] == 'n' && > buffer[4] == 's') > z = 1; > #endif > } > return 0; > } > [breese@stellifer:/home/breese/junk] gcc -O2 compare.c > [breese@stellifer:/home/breese/junk] time ./a.out > 4.560u 0.040s 0:04.85 94.8% 0+0k 0+0io 65pf+0w > [breese@stellifer:/home/breese/junk] gcc -DUSE_STRNCMP -O2 compare.c > [breese@stellifer:/home/breese/junk] time ./a.out > 0.930u 0.000s 0:01.03 90.2% 0+0k 0+0io 66pf+0w > > I get roughly the same results if I change the content of 'buffer'. > > > _______________________________________________ > xml mailing list, project page http://xmlsoft.org/ > xml@gnome.org > http://mail.gnome.org/mailman/listinfo/xml > From veillard@redhat.com Wed Oct 1 14:54:28 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 5561418249 for ; Wed, 1 Oct 2003 14:54:28 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h91IseQ22549; Wed, 1 Oct 2003 14:54:40 -0400 Date: Wed, 1 Oct 2003 14:54:39 -0400 From: Daniel Veillard To: Chris Anderson Cc: xml@gnome.org Subject: Re: [xml] RAW && NXT with strncmp() Message-ID: <20031001145439.R21529@redhat.com> Reply-To: veillard@redhat.com References: <001901c38822$1a668da0$2964a8c0@kvp> <20031001095055.G21529@redhat.com> <1065026851.2063.31.camel@stellifer> <1065032790.32683.314.camel@kayak.charm.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1065032790.32683.314.camel@kayak.charm.net>; from christop@charm.net on Wed, Oct 01, 2003 at 02:26:30PM -0400 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, Oct 01, 2003 at 02:26:30PM -0400, Chris Anderson wrote: > On Wed, 2003-10-01 at 12:47, Bjorn Reese wrote: > > On Wed, 2003-10-01 at 15:50, Daniel Veillard wrote: > > > > > That I was looking at it this yesterday actually but I don't feel > > > that confident about such a change, yet ... > > > > Not to belabor this point too much, it's not that important... > There are a couple of things going on in that loop: > > First, icc completely optimizes the loop away, gcc just optimizes away > the z = 1 statement since it's not used. never tried icc, I believe it would generate faster code but my target compiler is obviously gcc :-) > Second, gcc puts the all of the characters of "xmlns" into registers > before the loop begins, so the no strncmp test is really testing the > speed of 5 * 1000000000 register compares and branches, which is a bit > faster than loading the constants into registers and comparing. > > Third, the other point was that there are cases where most of the > strings are not equal, this loop just tests the case where they are > equal. Well I just want the equality. One of the reasons I was using CUR/NXT is that I used to do some "buffer grows if needed" code handling in it. Not the case anymore which allows the optimisation. > Fourth, strncmp is not an intrinsic in either gcc or icc. Use memcmp, > that will generate x86 repz string instructions as long as the size of > the memory being compared is constant (size == 5). Yup I was precisely looking at objdump -d a.out too :-) > The no memcmp is quite a bit faster, but the instruction count isn't > that different. I think it's more of a clarity thing unless you are in > a code hot spot. Yeah it's not in hot spot (element, attributes and character parsing). Now if you really want to chase the microsecond, if you manage to optimize xmlParseCharData in parser.c, then it's an immediate gain ! W.r.t. instruction count cachegrind was a bit surprizing initially finding 2000045214 cycle cost for the original and 400045209 for the memcmp, independantly of the string being compared. Makes some sense once the generated code has been looked at :-) Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From erich@offby1.atm01.sea.blarg.net Wed Oct 1 14:14:12 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail.blarg.net (zoot.blarg.net [206.124.128.9]) by mail.gnome.org (Postfix) with ESMTP id 13770182B2 for ; Wed, 1 Oct 2003 14:14:12 -0400 (EDT) Received: from debian (offby1.atm01.sea.blarg.net [206.124.138.125]) by mail.blarg.net (Postfix) with ESMTP id 06C2B33DA7 for ; Wed, 1 Oct 2003 11:14:24 -0700 (PDT) Received: from erich by debian with local (Exim 3.36 #1 (Debian)) id 1A4lUV-0000EL-00 for ; Wed, 01 Oct 2003 11:14:23 -0700 To: xml@gnome.org From: Eric Hanchrow Date: 01 Oct 2003 11:14:23 -0700 Message-ID: <8765j8j05c.fsf@offby1.atm01.sea.blarg.net> Lines: 39 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [xml] Buffer overflow error in entities.c Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: This is in libxml2 version 2.5.11. Here's how to reproduce the problem: put the following two nonblank lines into a file named "foo.xml": 􏿿 Now type "xmllint foo.xml", and examine the output. Notice that the semicolon is missing. That's the bug. Here's the fix: cd /usr/local/src/libxml2-2.5.11/ diff -wu /usr/local/src/libxml2-2.5.11/entities.c\~ /usr/local/src/libxml2-2.5.11/entities.c --- /usr/local/src/libxml2-2.5.11/entities.c~ 2003-07-15 06:34:04.000000000 -0700 +++ /usr/local/src/libxml2-2.5.11/entities.c 2003-10-01 10:48:20.000000000 -0700 @@ -670,7 +670,7 @@ /* * We assume we have UTF-8 input. */ - char buf[10], *ptr; + char buf[11], *ptr; int val = 0, l = 1; if (*cur < 0xC0) { Diff finished at Wed Oct 1 11:10:41 (I tried to enter this bug into bugzilla.gnome.org, but that system requires a password, and I got impatient waiting for the password to be mailed to me.) -- Asking the Iraqi people to assume Saddam's debts is rather like telling a man who has been shot in the head that he has to pay for the bullet. -- James Surowiecki From veillard@redhat.com Wed Oct 1 15:14:45 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id AD8411811C for ; Wed, 1 Oct 2003 15:14:45 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h91JEvV00618; Wed, 1 Oct 2003 15:14:57 -0400 Date: Wed, 1 Oct 2003 15:14:57 -0400 From: Daniel Veillard To: Eric Hanchrow Cc: xml@gnome.org Subject: Re: [xml] Buffer overflow error in entities.c Message-ID: <20031001151457.S21529@redhat.com> Reply-To: veillard@redhat.com References: <8765j8j05c.fsf@offby1.atm01.sea.blarg.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <8765j8j05c.fsf@offby1.atm01.sea.blarg.net>; from offby1@blarg.net on Wed, Oct 01, 2003 at 11:14:23AM -0700 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, Oct 01, 2003 at 11:14:23AM -0700, Eric Hanchrow wrote: > > This is in libxml2 version 2.5.11. > > Here's how to reproduce the problem: put the following two nonblank > lines into a file named "foo.xml": > > > 􏿿 > > Now type "xmllint foo.xml", and examine the output. Notice that the > semicolon is missing. That's the bug. Damnnn !!! Okay this is not exploitable as a security bug but that's sad. This also tends to prove that nobody uses those high code points. Thanks a lot ! Commited in CVS, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From christop@charm.net Wed Oct 1 15:25:24 2003 Return-Path: Delivered-To: xml@gnome.org Received: from hampden.charm.net (hampden.charm.net [207.114.0.146]) by mail.gnome.org (Postfix) with ESMTP id 894081860C for ; Wed, 1 Oct 2003 15:25:24 -0400 (EDT) Received: from christop-209.143.91.188.charm.net (christop-209.143.91.188.charm.net [209.143.91.188]) (authenticated bits=0) by hampden.charm.net (8.12.9p2/8.12.9/LNSG+ORDB+SCOP+NJABL+RSL+SBL+DSBL) with ESMTP id h91JPbPG038437 for ; Wed, 1 Oct 2003 15:25:37 -0400 (EDT) (envelope-from christop@charm.net) Subject: Re: [xml] RAW && NXT with strncmp() From: Chris Anderson To: xml@gnome.org In-Reply-To: <20031001145439.R21529@redhat.com> References: <001901c38822$1a668da0$2964a8c0@kvp> <20031001095055.G21529@redhat.com> <1065026851.2063.31.camel@stellifer> <1065032790.32683.314.camel@kayak.charm.net> <20031001145439.R21529@redhat.com> Content-Type: text/plain Message-Id: <1065036638.32684.333.camel@kayak.charm.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.3.99 (Preview Release) Date: 01 Oct 2003 15:30:39 -0400 Content-Transfer-Encoding: 7bit Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, 2003-10-01 at 14:54, Daniel Veillard wrote: > On Wed, Oct 01, 2003 at 02:26:30PM -0400, Chris Anderson wrote: > never tried icc, I believe it would generate faster code but > my target compiler is obviously gcc :-) > Ironically, I started using icc because it works with gdb better than g++. icc is one cool cucumber when it comes to optimizing for x86, too bad it's not free. > Well I just want the equality. One of the reasons I was using CUR/NXT > is that I used to do some "buffer grows if needed" code handling in it. > Not the case anymore which allows the optimisation. Ah, that make sense. Oops, Bjorn said he tried changing the buffer contents, I missed that. > > Yeah it's not in hot spot (element, attributes and character parsing). > Now if you really want to chase the microsecond, if you manage to > optimize xmlParseCharData in parser.c, then it's an immediate gain ! > W.r.t. instruction count cachegrind was a bit surprizing initially > finding 2000045214 cycle cost for the original and 400045209 for > the memcmp, independantly of the string being compared. Makes some > sense once the generated code has been looked at :-) > Yeah, I was disappointed that the compilers didn't generate int compares instead of string compares for memcmp with a small constant size, especially since the memories were aligned at compile time. From justin.fletcher@ntlworld.com Wed Oct 1 15:41:30 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mta06-svc.ntlworld.com (mta06-svc.ntlworld.com [62.253.162.46]) by mail.gnome.org (Postfix) with ESMTP id 5051E1830C for ; Wed, 1 Oct 2003 15:41:30 -0400 (EDT) Received: from buttercup.gerph.org ([62.255.97.57]) by mta06-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20031001194141.FBQ12263.mta06-svc.ntlworld.com@buttercup.gerph.org> for ; Wed, 1 Oct 2003 20:41:41 +0100 Received: by buttercup.gerph.org (Postfix, from userid 1001) id 0F002F421F; Wed, 1 Oct 2003 20:37:46 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by buttercup.gerph.org (Postfix) with ESMTP id 091F0EC286 for ; Wed, 1 Oct 2003 20:37:46 +0100 (BST) Date: Wed, 1 Oct 2003 20:37:45 +0100 (BST) From: Justin Fletcher X-X-Sender: justin@buttercup.gerph.org To: xml@gnome.org Subject: Re: [xml] RAW && NXT with strncmp() In-Reply-To: <20031001122936.N21529@redhat.com> Message-ID: References: <001901c38822$1a668da0$2964a8c0@kvp> <3F7AF909.7040007@rinax.com> <20031001122936.N21529@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, 1 Oct 2003, Daniel Veillard wrote: > On Wed, Oct 01, 2003 at 09:55:53AM -0600, Steve Williams wrote: > > Hi, > > > > Depending on the frequency of a match NOT occuring, the original code > > could be significantly faster. The first condition that did not match > > causes the remaining comparisons to not happen. If in 90% of the cases > > (I have no idea the context of this code), the match is going to fail on > > the (RAW=='<'), then the other two comparisons would NOT happen. > > > > This compared with the overhead of a function call every time... but > > then I'm an "old school" C programmer who considers things like speed. > > > > I'd be inclined to make a #define for the comparison if it occurs in so > > many places. But that's just me... > > To play the devil's advocate, on modern processors what's really > costly are caches misses. Sometimes doing a few more instructions > is better than having larger code or touching more data. > I still thing the current tests are faster because the test values > are embedded as part of the instruction code. On the other hand this > makes the code bigger. Then there is maintainance issue etc. > I stated I'm balanced over this issue, the points Igor raised are > real. I think most of the case are in areas which are not time critical. > However we can still look at performances a bit: > - I think gcc -O2 inlines things like > CUR==a && NXT(1)==b && NXT(2)==c && NXT(3)==d > as > (*(int *) CUR) == abcd > because valgrind complained about uninitialized memory access > on such instructions when compiled with -O2 :-) I would suggest then that that's an invalid optimisation - if you were accessing a memory mapped device that might have very bad consequences (*), not to mention the fact that there are alignment issues and the fact that the memory following CUR may not even exist. If the compiler produces broken code like that when optimising then I'd be concerned about using it. I'm slightly surprised that there aren't any extent checks to see whether the NXT runs off the end of the buffer, but I guess that there is a guarentee that the data is sufficiently 'complete' within these blocks. (*) Ignoring for a second that this operation is in LibXML2 and therefore isn't going to be accessing a memory mapped device, but I can imagine a circumstance where the cited sequence would be to access a memory mapped device. -- Gerph {djf0-.3w6e2w2.226,6q6w2q2,2.3,2m4} URL: http://www.movspclr.co.uk/ ... Stuff happens. From graham-libxml@simulcra.org Wed Oct 1 17:12:43 2003 Return-Path: Delivered-To: xml@gnome.org Received: from lamity.org (lamity.org [212.13.197.69]) by mail.gnome.org (Postfix) with SMTP id D61D21836F for ; Wed, 1 Oct 2003 17:12:42 -0400 (EDT) Received: (qmail 12801 invoked by uid 1001); 1 Oct 2003 21:12:55 -0000 Date: Wed, 1 Oct 2003 22:12:55 +0100 From: Graham Bennett To: xml@gnome.org Message-ID: <20031001211255.GA12058@lamity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Subject: [xml] parser context reuse Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: For the benefit of the list I'll summarise the conversations Daniel and I had earlier about how to reuse parser contexts in libxml2. The parser context should be initially created with xmlNewParserCtxt(). This is currently only available via parserInternals.h, but Daniel intends to move it to parser.h with the other functions. Once initialised, the context can be reused with different types of XML input (memory, file etc.) by using the xmlCtxtReadxxx() functions. I actually reduced my code size by quite a bit, as all the common stuff was done in one place. xmlCtxtReadDoc and xmlCtxtReadMemory are very similar, except xmlCtxtReadDoc doesn't require a length and will stop processing at a null terminator. Also xmlCtxtReadDoc takes a const xmlChar * for legacy reasons, but it can just be casted to const char *. cheers, Graham. -- Graham Bennett From graham-libxml@simulcra.org Wed Oct 1 17:42:33 2003 Return-Path: Delivered-To: xml@gnome.org Received: from lamity.org (lamity.org [212.13.197.69]) by mail.gnome.org (Postfix) with SMTP id E7C7C180E6 for ; Wed, 1 Oct 2003 17:42:32 -0400 (EDT) Received: (qmail 14520 invoked by uid 1001); 1 Oct 2003 21:42:45 -0000 Date: Wed, 1 Oct 2003 22:42:45 +0100 From: Graham Bennett To: xml@gnome.org Message-ID: <20031001214245.GB12058@lamity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Subject: [xml] new SAX2 API Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Here's some more summarisation of my experiences of coding against the SAX2 API so far.. In order to initialise the SAX handler struct, I had to do something like: ::memset(ctxt->sax, 0, sizeof(xmlSAXHandler)); // set some callbacks ctxt->sax->initialized = XML_SAX2_MAGIC; Daniel is going to provide a function which initialises the struct for the correct SAX API version so people don't have to know about XML_SAX2_MAGIC. In general, the new API seems pretty nice. The changes I had to make were obviously to override startElementNs and endElementNs instead of the startElement and endElement callbacks. Getting namespace information in these callbacks is pretty painless, much more pleasant to my mind than in Expat. (In Expat you have to run through the strings looking for a separator, in the new libxml API everything is a separate array element or parameter.) Error handling: this has been discussed quite a bit already. My application is a library that builds a DOM-style tree and is used by others, so I can't really impose error-handling semantics too much on client code. Therefore, what I really want to do is this: - if the error is fatal, stop parsing asap, unwind to where I first called the parse function and throw an exception (it's C++) with a decent error message. - if the error is non-fatal (whatever that means :) ), then I would still like to know about it, but I will have to leave it up to the user whether to stop or not. Therefore I will probably let the user set a functor which, if present, my lib will call with the error message as a parameter, so that they can choose what to do. If they don't set the functor then I just carry on regardless. I suppose the functor could return a boolean indicating whether to stop or not. - I would treat warnings much the same as non-fatal errors. Now, I think the current API allows me to do what I want, with a few caveats: - I would rather have a string error message and some location information than the varargs list that is there currently. At the moment I have to run through the args building up a string message myself. - How best to stop the parser? I think there is an xmlStopParser (or similar) function that I should be using. Is there anything else I need to worry about when stopping the parse? cheers, Graham. -- Graham Bennett From veillard@redhat.com Wed Oct 1 18:10:05 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 0569D180E6 for ; Wed, 1 Oct 2003 18:10:05 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h91MAG930932; Wed, 1 Oct 2003 18:10:16 -0400 Date: Wed, 1 Oct 2003 18:10:16 -0400 From: Daniel Veillard To: Graham Bennett Cc: xml@gnome.org Subject: Re: [xml] new SAX2 API Message-ID: <20031001181016.U21529@redhat.com> Reply-To: veillard@redhat.com References: <20031001214245.GB12058@lamity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031001214245.GB12058@lamity.org>; from graham-libxml@simulcra.org on Wed, Oct 01, 2003 at 10:42:45PM +0100 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, Oct 01, 2003 at 10:42:45PM +0100, Graham Bennett wrote: > Here's some more summarisation of my experiences of coding against the > SAX2 API so far.. > > In order to initialise the SAX handler struct, I had to do something > like: > > ::memset(ctxt->sax, 0, sizeof(xmlSAXHandler)); // set some callbacks > ctxt->sax->initialized = XML_SAX2_MAGIC; > > Daniel is going to provide a function which initialises the struct for > the correct SAX API version so people don't have to know about > XML_SAX2_MAGIC. XMLPUBFUN int XMLCALL xmlSAXVersion (xmlSAXHandler *hdlr, int version); Where version can be 1 or 2. The problem is that memset() errases the magic number :-\ > - I would rather have a string error message and some location > information than the varargs list that is there currently. At the > moment I have to run through the args building up a string message > myself. Based on Havoc's and others feedback here is what I started to work on, it's very close to Gerror, just specialized for the parser needs: /** * xmlErrorLevel: * * Indicates the level of an error */ typedef enum { XML_ERR_NONE = 0, XML_ERR_WARNING = 1, /* A simple warning */ XML_ERR_ERROR = 2, /* A recoverable error */ XML_ERR_FATAL = 3 /* A fatal error */ } xmlErrorLevel; /** * xmlErrorDomain: * * Indicates where an error may have come from */ typedef enum { XML_FROM_NONE = 0, XML_FROM_PARSER, /* The XML parser */ XML_ERR_HTML, /* The HTML parser */ XML_ERR_MEMORY, /* The memory allocator */ XML_ERR_OUTPUT, /* The serialization code */ XML_ERR_IO, /* The Input/Output stack */ XML_ERR_XINCLUDE, /* The XInclude processing */ XML_ERR_XPATH, /* The XPath engine */ XML_ERR_XPOINTER /* The XPointer engine */ } xmlErrorDomain; /** * xmlError: * * An XML Error instance. */ typedef struct _xmlError xmlError; typedef xmlError *xmlErrorPtr; struct _xmlError { int domain; /* What part of the library raised this error */ int code; /* The error code, e.g. an xmlParserError */ char *message;/* human-readable informative error message */ xmlErrorLevel level;/* how consequent is the error */ char *file; /* the filename */ int line; /* the line number if available */ char *str1; /* extra string information */ char *str2; /* extra string information */ int int1; /* extra number information */ int int2; /* extra number information */ }; And /* * Extended error information routines */ XMLPUBFUN xmlErrorPtr XMLCALL xmlGetLastError (void); XMLPUBFUN void XMLCALL xmlResetLastError (void); XMLPUBFUN int XMLCALL xmlCopyError (xmlErrorPtr from, xmlErrorPtr to); XMLPUBFUN xmlErrorPtr XMLCALL xmlCtxtGetLastError (void *ctx); XMLPUBFUN void XMLCALL xmlCtxtResetLastError (void *ctx); The xmlGetLastError() and xmlResetLastError() will work on a global xmlError which is defined per-thread if the library is configured with threads. The xmlCtxtGetLastError() and xmlCtxtGetLastError() will be associated to a parser context, the xmlError is allocated and stored within the parser context so there is no risk of facing memory allocation to report error in out of memory condition. The real pain is to conver all message reporting in the library to use those facilities, type of grunt job which is both boring and dangerous, but this need to get done, and now is the time :-\ , it's certainly more useful than flaming on xml-dev ... > - How best to stop the parser? I think there is an xmlStopParser (or > similar) function that I should be using. Is there anything else I > need to worry about when stopping the parse? Hum, no, not really. All parsing state will be freed or cleaned up when calling xmlFreeParserCtxt() or reusing the context with xmlCtxtReadxxx() I still need to provide similar initialization/reuse for the xmlReader. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From graham-libxml@simulcra.org Wed Oct 1 18:23:15 2003 Return-Path: Delivered-To: xml@gnome.org Received: from lamity.org (lamity.org [212.13.197.69]) by mail.gnome.org (Postfix) with SMTP id 56297186EF for ; Wed, 1 Oct 2003 18:23:15 -0400 (EDT) Received: (qmail 16753 invoked by uid 1001); 1 Oct 2003 22:23:28 -0000 Date: Wed, 1 Oct 2003 23:23:28 +0100 From: Graham Bennett To: Daniel Veillard Cc: xml@gnome.org Subject: Re: [xml] new SAX2 API Message-ID: <20031001222328.GC12058@lamity.org> References: <20031001214245.GB12058@lamity.org> <20031001181016.U21529@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031001181016.U21529@redhat.com> User-Agent: Mutt/1.3.28i Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, Oct 01, 2003 at 06:10:16PM -0400, Daniel Veillard wrote: > I still need to provide similar initialization/reuse for the xmlReader. Yes this would be very useful. On a related note, how can I go about reusing the context when using the push parser? cheers, Graham. -- Graham Bennett From veillard@redhat.com Wed Oct 1 18:30:08 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 54298183B9 for ; Wed, 1 Oct 2003 18:30:08 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h91MUK709980; Wed, 1 Oct 2003 18:30:20 -0400 Date: Wed, 1 Oct 2003 18:30:20 -0400 From: Daniel Veillard To: Graham Bennett Cc: xml@gnome.org Subject: Re: [xml] new SAX2 API Message-ID: <20031001183020.V21529@redhat.com> Reply-To: veillard@redhat.com References: <20031001214245.GB12058@lamity.org> <20031001181016.U21529@redhat.com> <20031001222328.GC12058@lamity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031001222328.GC12058@lamity.org>; from graham-libxml@simulcra.org on Wed, Oct 01, 2003 at 11:23:28PM +0100 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, Oct 01, 2003 at 11:23:28PM +0100, Graham Bennett wrote: > On Wed, Oct 01, 2003 at 06:10:16PM -0400, Daniel Veillard wrote: > > I still need to provide similar initialization/reuse for the xmlReader. > > Yes this would be very useful. TODO.2.6.0 .... > On a related note, how can I go about reusing the context when using the > push parser? yeah the Push is the API which is the hardest to integrate in the same scheme as the others. Using xmlCtxtReset(ctxt) between calls *should* work, but I would have to go over the details to make sure. Adding at least basic docs for this whole new set of APIs is also in TODO.2.6.0 , Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From malcolm@commsecure.com.au Wed Oct 1 20:44:47 2003 Return-Path: Delivered-To: xml@gnome.org Received: from commsecure.com.au (CommSecureAustPtyLtd.sb1.optus.net.au [203.202.148.106]) by mail.gnome.org (Postfix) with ESMTP id 64BEB18298 for ; Wed, 1 Oct 2003 20:44:46 -0400 (EDT) Received: from sunhill.commsecure.com.au (sunhill.commsecure.com.au [172.16.15.1]) by commsecure.com.au (8.11.6/8.11.6) with ESMTP id h920is729978 for ; Thu, 2 Oct 2003 10:44:54 +1000 Received: from ws14.commsecure.com.au (ws14.commsecure.com.au [172.16.15.14]) by sunhill.commsecure.com.au (8.11.6/8.11.6) with ESMTP id h920ivO04910 for ; Thu, 2 Oct 2003 10:44:57 +1000 Received: from ws14.commsecure.com.au (localhost.localdomain [127.0.0.1]) by ws14.commsecure.com.au (8.12.8/8.12.8) with ESMTP id h920ivCH007039 for ; Thu, 2 Oct 2003 10:44:57 +1000 Received: (from malcolm@localhost) by ws14.commsecure.com.au (8.12.8/8.12.8/Submit) id h920ivpb007037 for xml@gnome.org; Thu, 2 Oct 2003 10:44:57 +1000 X-Authentication-Warning: ws14.commsecure.com.au: malcolm set sender to malcolm@commsecure.com.au using -f Subject: Re: [xml] new SAX2 API From: Malcolm Tredinnick To: xml@gnome.org In-Reply-To: <20031001181016.U21529@redhat.com> References: <20031001214245.GB12058@lamity.org> <20031001181016.U21529@redhat.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1065055496.5745.48.camel@ws14.commsecure.com.au> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Thu, 02 Oct 2003 10:44:57 +1000 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, 2003-10-02 at 08:10, Daniel Veillard wrote: [...] > Based on Havoc's and others feedback here is what I started to work > on, it's very close to Gerror, just specialized for the parser needs: > > /** > * xmlErrorLevel: > * > * Indicates the level of an error > */ > typedef enum { > XML_ERR_NONE = 0, > XML_ERR_WARNING = 1, /* A simple warning */ > XML_ERR_ERROR = 2, /* A recoverable error */ > XML_ERR_FATAL = 3 /* A fatal error */ > } xmlErrorLevel; Can somebody gie me an example of something that is an "error", but not "fatal"? At least during parsing, I thought that all errors were fatal. And all of the errors I can think of from each of the xmlErrorDomain (below) values looks fatal (except maybe some HTML things, if the library was operating in a kind of tag soup mode). Of course, that doesn't stop me (and others, apparently) from trying to recover from errors inside error handlers and either continue parsing or queue things up for a restart, but that is slightly different. > /** > * xmlErrorDomain: > * > * Indicates where an error may have come from > */ > typedef enum { > XML_FROM_NONE = 0, > XML_FROM_PARSER, /* The XML parser */ > XML_ERR_HTML, /* The HTML parser */ > XML_ERR_MEMORY, /* The memory allocator */ > XML_ERR_OUTPUT, /* The serialization code */ > XML_ERR_IO, /* The Input/Output stack */ > XML_ERR_XINCLUDE, /* The XInclude processing */ > XML_ERR_XPATH, /* The XPath engine */ > XML_ERR_XPOINTER /* The XPointer engine */ > } xmlErrorDomain; > > /** > * xmlError: > * > * An XML Error instance. > */ > > typedef struct _xmlError xmlError; > typedef xmlError *xmlErrorPtr; > struct _xmlError { > int domain; /* What part of the library raised this error */ > int code; /* The error code, e.g. an xmlParserError */ > char *message;/* human-readable informative error message */ > xmlErrorLevel level;/* how consequent is the error */ > char *file; /* the filename */ > int line; /* the line number if available */ > char *str1; /* extra string information */ > char *str2; /* extra string information */ > int int1; /* extra number information */ > int int2; /* extra number information */ > }; Nice. :-) Cheers, Malcolm From malcolm@commsecure.com.au Wed Oct 1 20:50:13 2003 Return-Path: Delivered-To: xml@gnome.org Received: from commsecure.com.au (CommSecureAustPtyLtd.sb1.optus.net.au [203.202.148.106]) by mail.gnome.org (Postfix) with ESMTP id EC38A180F0 for ; Wed, 1 Oct 2003 20:50:11 -0400 (EDT) Received: from sunhill.commsecure.com.au (sunhill.commsecure.com.au [172.16.15.1]) by commsecure.com.au (8.11.6/8.11.6) with ESMTP id h920oK730096 for ; Thu, 2 Oct 2003 10:50:20 +1000 Received: from ws14.commsecure.com.au (ws14.commsecure.com.au [172.16.15.14]) by sunhill.commsecure.com.au (8.11.6/8.11.6) with ESMTP id h920oOO04946 for ; Thu, 2 Oct 2003 10:50:24 +1000 Received: from ws14.commsecure.com.au (localhost.localdomain [127.0.0.1]) by ws14.commsecure.com.au (8.12.8/8.12.8) with ESMTP id h920oOCH007110 for ; Thu, 2 Oct 2003 10:50:24 +1000 Received: (from malcolm@localhost) by ws14.commsecure.com.au (8.12.8/8.12.8/Submit) id h920oO32007108 for xml@gnome.org; Thu, 2 Oct 2003 10:50:24 +1000 X-Authentication-Warning: ws14.commsecure.com.au: malcolm set sender to malcolm@commsecure.com.au using -f Subject: Re: [xml] new SAX2 API From: Malcolm Tredinnick To: xml@gnome.org In-Reply-To: <20031001214245.GB12058@lamity.org> References: <20031001214245.GB12058@lamity.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1065055823.5745.55.camel@ws14.commsecure.com.au> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Thu, 02 Oct 2003 10:50:23 +1000 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, 2003-10-02 at 07:42, Graham Bennett wrote: > Here's some more summarisation of my experiences of coding against the > SAX2 API so far.. Thanks for writing this stuff down. It should save a bit of time later on. Malcolm From rrichards@ctindustries.net Wed Oct 1 22:45:29 2003 Return-Path: Delivered-To: xml@gnome.org Received: from phoebe.host4u.net (phoebe.host4u.net [209.150.128.26]) by mail.gnome.org (Postfix) with ESMTP id B0E90180DA for ; Wed, 1 Oct 2003 22:45:29 -0400 (EDT) Received: from ctdrob (dsta-aa203.pivot.net [66.186.171.203]) by phoebe.host4u.net (8.11.6/8.11.6) with SMTP id h922jgn20060 for ; Wed, 1 Oct 2003 21:45:42 -0500 Message-ID: <074801c3888f$72d15c50$f7dea8c0@cyberware.local> From: "Rob Richards" To: Date: Wed, 1 Oct 2003 22:46:57 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0744_01C3886D.EB75BB00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [xml] xmlRemoveID patch Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_0744_01C3886D.EB75BB00 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0745_01C3886D.EB75BB00" ------=_NextPart_001_0745_01C3886D.EB75BB00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable After running into an issue with xmlRemoveID today and reading a post = from August on the same issue, the attached patch seems to resolve the = issue. An xmlIDPtr is now retrieved from the hash table and its attr = property is checked against the xmlAttrPtr passed in. Lastly = xmlHashRemoveEntry is called rather than xmlHashUpdateEntry so that its = actually removed and the table is updated properly. Rob ------=_NextPart_001_0745_01C3886D.EB75BB00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
After running into an issue with = xmlRemoveID today=20 and reading a post from August on the same issue, the attached patch = seems to=20 resolve the issue. An xmlIDPtr is now retrieved from the = hash table=20 and its attr property is checked against the xmlAttrPtr passed in. = Lastly=20 xmlHashRemoveEntry is called rather than xmlHashUpdateEntry so that its = actually=20 removed and the table is updated properly.
 
Rob
------=_NextPart_001_0745_01C3886D.EB75BB00-- ------=_NextPart_000_0744_01C3886D.EB75BB00 Content-Type: text/plain; name="valid.c.diff.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="valid.c.diff.txt" Index: valid.c =================================================================== RCS file: /cvs/gnome/gnome-xml/valid.c,v retrieving revision 1.163 diff -c -r1.163 valid.c *** valid.c 29 Sep 2003 18:02:37 -0000 1.163 --- valid.c 2 Oct 2003 02:39:24 -0000 *************** *** 2379,2385 **** */ int xmlRemoveID(xmlDocPtr doc, xmlAttrPtr attr) { ! xmlAttrPtr cur; xmlIDTablePtr table; xmlChar *ID; --- 2379,2385 ---- */ int xmlRemoveID(xmlDocPtr doc, xmlAttrPtr attr) { ! xmlIDPtr cur; xmlIDTablePtr table; xmlChar *ID; *************** *** 2395,2405 **** if (ID == NULL) return(-1); cur = xmlHashLookup(table, ID); ! if (cur != attr) { xmlFree(ID); return(-1); } ! xmlHashUpdateEntry(table, ID, NULL, (xmlHashDeallocator) xmlFreeID); xmlFree(ID); return(0); } --- 2395,2405 ---- if (ID == NULL) return(-1); cur = xmlHashLookup(table, ID); ! if (cur->attr != attr) { xmlFree(ID); return(-1); } ! xmlHashRemoveEntry(table, ID, (xmlHashDeallocator) xmlFreeID); xmlFree(ID); return(0); } ------=_NextPart_000_0744_01C3886D.EB75BB00-- From veillard@redhat.com Thu Oct 2 02:01:07 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 5FCC218219 for ; Thu, 2 Oct 2003 02:01:07 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9261He26131; Thu, 2 Oct 2003 02:01:17 -0400 Date: Thu, 2 Oct 2003 02:01:17 -0400 From: Daniel Veillard To: Malcolm Tredinnick Cc: xml@gnome.org Subject: Re: [xml] new SAX2 API Message-ID: <20031002020116.W21529@redhat.com> Reply-To: veillard@redhat.com References: <20031001214245.GB12058@lamity.org> <20031001181016.U21529@redhat.com> <1065055496.5745.48.camel@ws14.commsecure.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1065055496.5745.48.camel@ws14.commsecure.com.au>; from malcolm@commsecure.com.au on Thu, Oct 02, 2003 at 10:44:57AM +1000 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, Oct 02, 2003 at 10:44:57AM +1000, Malcolm Tredinnick wrote: > On Thu, 2003-10-02 at 08:10, Daniel Veillard wrote: > Can somebody gie me an example of something that is an "error", but not > "fatal"? At least during parsing, I thought that all errors were fatal. No, no, the spec makes them quite different. ----------- error [Definition: A violation of the rules of this specification; results are undefined. Conforming software may detect and report an error and may recover from it.] fatal error [Definition: An error which a conforming XML processor must detect and report to the application. After encountering a fatal error, the processor may continue processing the data to search for further errors and may report such errors to the application. In order to support correction of errors, the processor may make unprocessed data from the document (with intermingled character data and markup) available to the application. Once a fatal error is detected, however, the processor must not continue normal processing (i.e., it must not continue to pass character data and information about the document's logical structure to the application in the normal way).] ----------- example of error - - non-deterministic content model in DTDs ((a , b) | (a , c)) - - etc ... > And all of the errors I can think of from each of the xmlErrorDomain > (below) values looks fatal (except maybe some HTML things, if the > library was operating in a kind of tag soup mode). Well In most case the associated specs have definitions for the equivalent of error vs. fatal error. This is common practice inherited from the IETF and now embedded in all W3C specs. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard@redhat.com Thu Oct 2 02:11:07 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 99D87180EE for ; Thu, 2 Oct 2003 02:11:06 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h926BHI28421; Thu, 2 Oct 2003 02:11:17 -0400 Date: Thu, 2 Oct 2003 02:11:16 -0400 From: Daniel Veillard To: Rob Richards Cc: xml@gnome.org Subject: Re: [xml] xmlRemoveID patch Message-ID: <20031002021116.X21529@redhat.com> Reply-To: veillard@redhat.com References: <074801c3888f$72d15c50$f7dea8c0@cyberware.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <074801c3888f$72d15c50$f7dea8c0@cyberware.local>; from rrichards@ctindustries.net on Wed, Oct 01, 2003 at 10:46:57PM -0400 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, Oct 01, 2003 at 10:46:57PM -0400, Rob Richards wrote: > After running into an issue with xmlRemoveID today and reading a post > from August on the same issue, the attached patch seems to resolve > the issue. An xmlIDPtr is now retrieved from the hash table and its > attr property is checked against the xmlAttrPtr passed in. Lastly > xmlHashRemoveEntry is called rather than xmlHashUpdateEntry so that its > actually removed and the table is updated properly. What problem does it fixes ? Did you run the full regression tests, including the streaming/validation ones ? I'm pretty sure this breaks streaming validation. So without even a description of what it's supposed to fix, I'm not tempted a priori to apply it. Actually I just checked to make sure, xmllint --valid --stream test/valid/REC-xml-19980210.xml fails all the ID/IDREF detection and even segfaults with your patch. Sorry I really can't apply this ! Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From rrichards@ctindustries.net Thu Oct 2 09:43:05 2003 Return-Path: Delivered-To: xml@gnome.org Received: from phoebe.host4u.net (phoebe.host4u.net [209.150.128.26]) by mail.gnome.org (Postfix) with ESMTP id 38A7D181B9 for ; Thu, 2 Oct 2003 09:43:05 -0400 (EDT) Received: from ctdrob (dsta-aa203.pivot.net [66.186.171.203]) by phoebe.host4u.net (8.11.6/8.11.6) with SMTP id h92DhCU09869; Thu, 2 Oct 2003 08:43:12 -0500 Message-ID: <00e301c388eb$4cae9db0$f7dea8c0@cyberware.local> From: "Rob Richards" To: Cc: References: <074801c3888f$72d15c50$f7dea8c0@cyberware.local> <20031002021116.X21529@redhat.com> Subject: Re: [xml] xmlRemoveID patch Date: Thu, 2 Oct 2003 09:44:27 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: From: Daniel Veillard > What problem does it fixes ? Did you run the full regression tests, > including the streaming/validation ones ? I'm pretty sure this breaks > streaming validation. So without even a description of what it's supposed > to fix, I'm not tempted a priori to apply it. > Actually I just checked to make sure, > xmllint --valid --stream test/valid/REC-xml-19980210.xml > fails all the ID/IDREF detection and even segfaults with your patch. Sorry > I really can't apply this ! Hmm, just found the reference to the previous thread on this with someone elses patch as well: http://mail.gnome.org/archives/xml/2003-August/msg00230.html Patches are almost identical, but there is more to this it seems. Sorry hadn't run the regression tests. I know, my bad. Working with it on windows so not sure how to run the tests other than one at a time. The problem I ran into was that I was looking at implementing the setIDAttribute (dom level 3), which looks like it should also remove ids based on the boolean passed in so was trying to use the xmlRemoveID function. One question on the streaming issue: In xmlAddID and xmlAddRef it supposedly checks for streaming mode, yet I found out when running the exact same test you did, ctxt->vstateNr is always 0 in here so ret->attr always gets set which causes the issues when streaming (following from xmlAddID): if ((ctxt != NULL) && (ctxt->vstateNr != 0)) { /* * Operating in streaming mode, attr is gonna disapear */ ret->name = xmlStrdup(attr->name); ret->attr = NULL; } else { ret->attr = attr; ret->name = NULL; } From the looks of it though, xmlRemoveID never worked. It is only used in the source in 2 functions: xmlFreeProp in tree.c (line 1970) and xmlTextReaderFreeProp in xmlreader.c (line 188) Before the patch, it xmlRemoveID would never work as in the following, cur is an xmlIDPtr (which its attr property should be compared to attr, not itself), so this function would always return -1. cur = xmlHashLookup(table, ID); if (cur != attr) { xmlFree(ID); return(-1); } The patch breaks the regression tests due to the following: xmlTextReaderFreeProp calls xmlRemoveID which now works and really removed the xmlIDPtr from doc-ids. During xmlValidateDocumentFinal, xmlValidateRef gets called from xmlValidateCheckRefCallback. The following block of code in xmlValidateRef fails (with the patch) for the following reason: id is now NULL as the ID has really been removed from the doc->ids table. attr->parent does not exist as it was free'd a long time ago which ends up segfaulting xmlNodeGetBase as VECTXT passes in NULL for doc so xmlNodeGetBase uses attr->parent->doc which we already establishes doesnt exist. id = xmlGetID(ctxt->doc, name); if (id == NULL) { VECTXT(ctxt, attr->parent); VERROR(ctxt->userData, "IDREF attribute %s references an unknown ID \"%s\"\n", attr->name, name); ctxt->valid = 0; } Before the patch, as xmlRemoveID was not working correctly, when it is called in xmlTextReaderFreeProp, the xmlIDPtr is not removed, so the id = xmlGetID(ctxt->doc, name); test from above would return a value. I had looked at adding xmlRemoveRef right after the xmlRemoveID call in xmlTextReaderFreeProp, when running the test however I get a lot of validity errors. Lastly, both xmlRemoveID and xmlRemoveRef use xmlHashUpdateEntry with a xmlHashDeallocator passed in. This however wont decrease the table nbElems. Is there a reason for using xmlHashUpdateEntry rather than xmlHashRemoveEntry? Thanks, Rob From justin.fletcher@ntlworld.com Thu Oct 2 11:32:10 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mta06-svc.ntlworld.com (mta06-svc.ntlworld.com [62.253.162.46]) by mail.gnome.org (Postfix) with ESMTP id 80053184A0 for ; Thu, 2 Oct 2003 11:32:10 -0400 (EDT) Received: from buttercup.gerph.org ([62.255.96.117]) by mta06-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20031002153221.DLRV12263.mta06-svc.ntlworld.com@buttercup.gerph.org>; Thu, 2 Oct 2003 16:32:21 +0100 Received: by buttercup.gerph.org (Postfix, from userid 1001) id 2E143F421F; Thu, 2 Oct 2003 16:29:16 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by buttercup.gerph.org (Postfix) with ESMTP id 28130EC286; Thu, 2 Oct 2003 16:29:16 +0100 (BST) Date: Thu, 2 Oct 2003 16:29:16 +0100 (BST) From: Justin Fletcher X-X-Sender: justin@buttercup.gerph.org To: Igor Izvarin Cc: xml@gnome.org Subject: RE: [xml] RAW && NXT with strncmp() In-Reply-To: <002601c388ca$28a3a350$2964a8c0@kvp> Message-ID: References: <002601c388ca$28a3a350$2964a8c0@kvp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: [CC'd reply back to the list because it looks like Igor sent me alone] On Thu, 2 Oct 2003, Igor Izvarin wrote: > Hi community, > > Good chat!!! > > At the end of this message I see the question #2: how can I be sure that > during this long check all the keyword is presented in the buffer? > > For example: if I check (from the parser.c) > If ((RAW == 'S') && (NXT(1) == 'Y') && (NXT(2) == 'S') && (NXT(3) == > 'T') && (NXT(4) == 'E') && (NXT(6) == 'M') { > .... > } > How can I be sure that buffer ctxt->input->cur contains all the chars > 'S', 'Y', 'S', 'T', 'E', 'M'? And not only some of them and then buffer > ends!?? > > It looks like a potential bug. Yes???? Or No??? Whilst I was surprised; Daniel said something in a reply which arrived an hour or so after I posted my comment (in <20031001145439.R21529@redhat.com>) which said : "One of the reasons I was using CUR/NXT is that I used to do some "buffer grows if needed" code handling in it. Not the case anymore which allows the optimisation." which I think satisfies me that the buffer contents should be treated as safe up to the end of the <> section (or the next ; if we're working on a character or entity reference. If the buffer were not guarenteed then using the push parser with one character at a time would (probably) result in the NXT going off the end of the buffer. A quick investigation shows a number of checks on the available input in xmlParseTryOrFinish (eg 'if (avail < 4)...') which would guarentee the buffer to be safe within certain specific limits, as Daniel stated in the cited posting (and the comment around the definition of NXT and CUR - 'one often need to make assumption on the context to use them'. However, as I was looking at this section I noticed a slightly odd thing - in XML_PARSER_START state the parser could conceivably read off the end of the buffer if the character set was initially set and only a single byte of data was passed. The clause in xmlParseTryOrFinish which checks XML_PARSER_START checks for 1 byte being available (outside the state check) then for 4 bytes if there is no encoding known yet. Iff the charset had been set by the application then the code would roll on without checking that sufficient data was present. If there are other checks present which guarentee that this condition cannot occur, I cannot see them (although I've only checked the path very quickly). The following patch against libxml2-2.5.11 should fix this, I think... --- parser.c Tue Sep 9 11:02:47 2003 +++ parser-jf.c Thu Oct 2 16:24:10 2003 @@ -8438,6 +8438,8 @@ break; } + if (avail < 2) + goto done; cur = ctxt->input->cur[0]; next = ctxt->input->cur[1]; if (cur == 0) { There may be others like this around the same area but I couldn't see any barring that one, but I hope that's helpful. > -----Original Message----- > From: xml-admin@gnome.org [mailto:xml-admin@gnome.org] On Behalf Of > Justin Fletcher > Sent: Wednesday, October 01, 2003 10:38 PM > To: xml@gnome.org > Subject: Re: [xml] RAW && NXT with strncmp() > > > On Wed, 1 Oct 2003, Daniel Veillard wrote: > > > On Wed, Oct 01, 2003 at 09:55:53AM -0600, Steve Williams wrote: > > > Hi, [snip - stuff about optimisation in parser.c with reference to the access to buffer values] > > I'm slightly surprised that there aren't any extent checks to see > whether the NXT runs off the end of the buffer, but I guess that there > is a guarentee that the data is sufficiently 'complete' within these > blocks. [snip] -- Gerph {djf0-.3w6e2w2.226,6q6w2q2,2.3,2m4} URL: http://www.movspclr.co.uk/ ... Yet more stuff happens. From veillard@redhat.com Thu Oct 2 12:33:36 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 2FC37180FA for ; Thu, 2 Oct 2003 12:33:36 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h92GXZG13403; Thu, 2 Oct 2003 12:33:35 -0400 Date: Thu, 2 Oct 2003 12:33:35 -0400 From: Daniel Veillard To: Justin Fletcher Cc: Igor Izvarin , xml@gnome.org Subject: Re: [xml] RAW && NXT with strncmp() Message-ID: <20031002123334.A21001@redhat.com> Reply-To: veillard@redhat.com References: <002601c388ca$28a3a350$2964a8c0@kvp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from justin.fletcher@ntlworld.com on Thu, Oct 02, 2003 at 04:29:16PM +0100 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, Oct 02, 2003 at 04:29:16PM +0100, Justin Fletcher wrote: > If there are other checks present which guarentee that this condition > cannot occur, I cannot see them (although I've only checked the path very > quickly). > > The following patch against libxml2-2.5.11 should fix this, I think... Hum, right. I applied the patch on my tree, I will commit later, thanks, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard@redhat.com Thu Oct 2 12:43:44 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 4756C181D5 for ; Thu, 2 Oct 2003 12:43:44 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h92Ghum20379; Thu, 2 Oct 2003 12:43:56 -0400 Date: Thu, 2 Oct 2003 12:43:56 -0400 From: Daniel Veillard To: Rob Richards Cc: xml@gnome.org Subject: Re: [xml] xmlRemoveID patch Message-ID: <20031002124356.B21001@redhat.com> Reply-To: veillard@redhat.com References: <074801c3888f$72d15c50$f7dea8c0@cyberware.local> <20031002021116.X21529@redhat.com> <00e301c388eb$4cae9db0$f7dea8c0@cyberware.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <00e301c388eb$4cae9db0$f7dea8c0@cyberware.local>; from rrichards@ctindustries.net on Thu, Oct 02, 2003 at 09:44:27AM -0400 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, Oct 02, 2003 at 09:44:27AM -0400, Rob Richards wrote: > One question on the streaming issue: > In xmlAddID and xmlAddRef it supposedly checks for streaming mode, yet I > found out when running the exact same test you did, ctxt->vstateNr is always > 0 in here so ret->attr always gets set which causes the issues when > streaming (following from xmlAddID): Yes my test was precisely about streaming + DTD validation. > >From the looks of it though, xmlRemoveID never worked. Don't understand why. > cur = xmlHashLookup(table, ID); > if (cur != attr) { > xmlFree(ID); > return(-1); > } hum, maybe. > The patch breaks the regression tests due to the following: > xmlTextReaderFreeProp calls xmlRemoveID which now works and really removed > the xmlIDPtr from doc-ids. and I don't want that behaviour when streaming. When streaming I don't want the ID to be removed from the table by that function. I want the attribute it reference to be NULLed and the id kept in the table so that validation checking works in streaming mode too. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From aleksey@aleksey.com Thu Oct 2 12:59:18 2003 Return-Path: Delivered-To: xml@gnome.org Received: from shell.aleksey.com (dsl081-246-064.sfo1.dsl.speakeasy.net [64.81.246.64]) by mail.gnome.org (Postfix) with ESMTP id 293AB181F3 for ; Thu, 2 Oct 2003 12:59:18 -0400 (EDT) Received: from aleksey.com (unknown [64.236.139.249]) by shell.aleksey.com (Postfix) with ESMTP id BDD84B5CF for ; Thu, 2 Oct 2003 09:59:27 -0700 (PDT) Message-ID: <3F7C5950.4050300@aleksey.com> Date: Thu, 02 Oct 2003 09:58:56 -0700 From: Aleksey Sanin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, ru MIME-Version: 1.0 To: xml@gnome.org Content-Type: multipart/mixed; boundary="------------000203090301080004030107" Subject: [xml] xmlStrPrintf function Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. --------------000203090301080004030107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Daniel, I know that you would prefer not to add new functions which are not directly related to XML parsing so the LibXML2 API which is already huge wouldn't grow. But I would like to ask you to consider adding one more string processing function xmlStrPrintf which is basicaly a wrapper for vsnprintf (see attached patch). The reasons why I think it would be a good idea to add this function are: - sprintf function has well known security issue. Providing a safe way to do the same thing in LibXML2 might help to reduce the number of security issues in the world :) - snprintf (and friends) are still not available on all platforms. LibXML2 uses Trio to workaround these problems. However, since Trio is linked staticaly into LibXML2 it makes it hard to use Trio in libraries linked with LibXML2 (I run into this problem last night). Providing a trivial wrapper for Trio's functionality solves this problem. - Using snprintf when it's available generates warnings about xmlChar*-->char* conversion. Instead of using BAD_CAST everywhere it's better to have it in one place. - For the sake of completeness there have to be a sprintf like function for xmlChar * strings :) Thanks, Aleksey --------------000203090301080004030107 Content-Type: text/plain; name="xmlStrPrintf.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xmlStrPrintf.diff" Index: parser.c =================================================================== RCS file: /cvs/gnome/gnome-xml/parser.c,v retrieving revision 1.316 diff -u -r1.316 parser.c --- parser.c 30 Sep 2003 13:38:04 -0000 1.316 +++ parser.c 2 Oct 2003 16:47:13 -0000 @@ -41,6 +41,7 @@ #include #include +#include #include #include #include @@ -2397,6 +2398,33 @@ while (*p != 0) p++; /* non input consuming */ return(xmlStrncat(cur, add, p - add)); +} + +/** + * xmlStrPrintf: + * @buf: the result buffer. + * @len: the result buffer length. + * @msg: the message with printf formatting. + * @...: extra parameters for the message. + * + * Formats @msg and places result into @buf. + * + * Returns the number of characters written to @buf or -1 if an error occurs. + */ +int +xmlStrPrintf(xmlChar *buf, int len, const xmlChar *msg, ...) { + va_list args; + int ret; + + if((buf == NULL) || (msg == NULL)) { + return(-1); + } + + va_start(args, msg); + ret = vsnprintf(BAD_CAST buf, len, BAD_CAST msg, args); + va_end(args); + + return(ret); } /************************************************************************ Index: include/libxml/parser.h =================================================================== RCS file: /cvs/gnome/gnome-xml/include/libxml/parser.h,v retrieving revision 1.103 diff -u -r1.103 parser.h --- include/libxml/parser.h 30 Sep 2003 12:36:01 -0000 1.103 +++ include/libxml/parser.h 2 Oct 2003 16:47:13 -0000 @@ -851,6 +851,12 @@ const xmlChar *add, int len); +XMLPUBFUN int XMLCALL + xmlStrPrintf (xmlChar *buf, + int len, + const xmlChar *msg, + ...); + /* * Basic parsing Interfaces */ --------------000203090301080004030107-- From rrichards@ctindustries.net Thu Oct 2 14:57:43 2003 Return-Path: Delivered-To: xml@gnome.org Received: from phoebe.host4u.net (phoebe.host4u.net [209.150.128.26]) by mail.gnome.org (Postfix) with ESMTP id 2B0A1181D5 for ; Thu, 2 Oct 2003 14:57:43 -0400 (EDT) Received: from ctdrob (dsta-aa203.pivot.net [66.186.171.203]) by phoebe.host4u.net (8.11.6/8.11.6) with SMTP id h92Ivow31366; Thu, 2 Oct 2003 13:57:50 -0500 Message-ID: <032f01c38917$412c47e0$f7dea8c0@cyberware.local> From: "Rob Richards" To: Cc: References: <074801c3888f$72d15c50$f7dea8c0@cyberware.local> <20031002021116.X21529@redhat.com> <00e301c388eb$4cae9db0$f7dea8c0@cyberware.local> <20031002124356.B21001@redhat.com> Subject: Re: [xml] xmlRemoveID patch Date: Thu, 2 Oct 2003 14:59:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: From: Daniel Veillard > and I don't want that behaviour when streaming. > When streaming I don't want the ID to be removed from the table by that > function. > I want the attribute it reference to be NULLed and the id kept in the > table so that validation checking works in streaming mode too. The only way I can see this working is that xmlTextReaderFreeProp calls a different function than xmlRemoveID, or adding an additonal parameter, which is probably not a good thing to do if people are using it - though I still say it never worked ;). If you dont need the reference to the attribute, though I believe you would since someone could call xmlGetID while the element was still in scope which would return NULL, I am not sure wether xmlAddID could be fixed to test for this streaming condition as currently its test: ctxt->vstateNr != 0 fails. I tweaked that patch a bit and changed the line where it removes the ID from the hash to just cur->attr = NULL; That test works fine that way. No leaks, no segfaults. This really isnt the desired behavior however when not streaming, as it should remove the IDPtr and not just remove the reference between the IDPtr and AttrPtr, which is why I suggest either an additional function or just remove that block in xmlTextReaderFreeProp which was added last week (if the patch had been submitted before 9/27, the tests would have passed). Rob From veillard@redhat.com Thu Oct 2 15:48:54 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id D8EC91818D for ; Thu, 2 Oct 2003 15:48:53 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h92Jn5311914; Thu, 2 Oct 2003 15:49:05 -0400 Date: Thu, 2 Oct 2003 15:49:05 -0400 From: Daniel Veillard To: Rob Richards Cc: xml@gnome.org Subject: Re: [xml] xmlRemoveID patch Message-ID: <20031002154905.C21001@redhat.com> Reply-To: veillard@redhat.com References: <074801c3888f$72d15c50$f7dea8c0@cyberware.local> <20031002021116.X21529@redhat.com> <00e301c388eb$4cae9db0$f7dea8c0@cyberware.local> <20031002124356.B21001@redhat.com> <032f01c38917$412c47e0$f7dea8c0@cyberware.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <032f01c38917$412c47e0$f7dea8c0@cyberware.local>; from rrichards@ctindustries.net on Thu, Oct 02, 2003 at 02:59:06PM -0400 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, Oct 02, 2003 at 02:59:06PM -0400, Rob Richards wrote: > From: Daniel Veillard > > and I don't want that behaviour when streaming. > > When streaming I don't want the ID to be removed from the table by that > > function. > > I want the attribute it reference to be NULLed and the id kept in the > > table so that validation checking works in streaming mode too. > > The only way I can see this working is that xmlTextReaderFreeProp calls a > different function than xmlRemoveID, or adding an additonal parameter, which > is probably not a good thing to do if people are using it - though I still > say it never worked ;). If you dont need the reference to the attribute, > though I believe you would since someone could call xmlGetID while the > element was still in scope which would return NULL, I am not sure wether > xmlAddID could be fixed to test for this streaming condition as currently > its test: ctxt->vstateNr != 0 fails. Yeah, I'm slowly migrating myself to this decision. It's quite easier now at the time the reader was using the same functions. > I tweaked that patch a bit and changed the line where it removes the ID from > the hash to just cur->attr = NULL; > > That test works fine that way. No leaks, no segfaults. This really isnt the > desired behavior however when not streaming, as it should remove the IDPtr > and not just remove the reference between the IDPtr and AttrPtr, which is > why I suggest either an additional function or just remove that block in > xmlTextReaderFreeProp which was added last week (if the patch had been > submitted before 9/27, the tests would have passed). Well if you have a new patch which works with CVS, please send it, though creating that new xmlReaderFreeID() is the right solution. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard@redhat.com Thu Oct 2 15:53:14 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id D43871818D for ; Thu, 2 Oct 2003 15:53:13 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h92JrPt14986; Thu, 2 Oct 2003 15:53:25 -0400 Date: Thu, 2 Oct 2003 15:53:25 -0400 From: Daniel Veillard To: Aleksey Sanin Cc: xml@gnome.org Subject: Re: [xml] xmlStrPrintf function Message-ID: <20031002155325.D21001@redhat.com> Reply-To: veillard@redhat.com References: <3F7C5950.4050300@aleksey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3F7C5950.4050300@aleksey.com>; from aleksey@aleksey.com on Thu, Oct 02, 2003 at 09:58:56AM -0700 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, Oct 02, 2003 at 09:58:56AM -0700, Aleksey Sanin wrote: > Daniel, > > I know that you would prefer not to add new functions which are not > directly related > to XML parsing so the LibXML2 API which is already huge wouldn't grow. > But I would like to ask you to consider adding one more string processing > function xmlStrPrintf which is basicaly a wrapper for vsnprintf (see > attached Since the patch is very small, and you have plenty of good reasons to do so, fine. Go ahead, and commit, I'm busy refactoring the errors handling though the whole lib :-\ BTW The C14N module will also be integrated into the new error handling this won't change the API/ABI but I will have to touch your code a bit I think. I will do my best to not break things though :-) Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From alfred.mickautsch@schuler-ag.com Thu Oct 2 13:17:13 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail-relay1 (mail-relay1.schuler-ag.com [62.156.183.20]) by mail.gnome.org (Postfix) with ESMTP id 8491B180FA for ; Thu, 2 Oct 2003 13:17:12 -0400 (EDT) Received: from sbs-proxy-test.schuler-ag.com ([192.168.16.254]) by mail-relay1 with Microsoft SMTPSVC(6.0.3790.0); Thu, 2 Oct 2003 19:21:00 +0200 Received: from mail pickup service by sbs-proxy-test.schuler-ag.com with Microsoft SMTPSVC; Thu, 2 Oct 2003 19:17:24 +0200 Content-Type: multipart/mixed; boundary="----=_NextPart_000_221EA_01C38919.CF4E51B0" Received: from pandora.schuler-ag.com ([192.168.16.20]) by sbs-proxy-test.schuler-ag.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 2 Oct 2003 19:17:22 +0200 Content-Class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Date: Thu, 2 Oct 2003 19:17:22 +0200 Message-ID: <4F38C8B9DAB1014DBDCB29538BBFD6A128507B@pandora.schuler-ag.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Document traversing interface for libxml2 thread-index: AcOJBipDkaVTzIR7Smiz+7iRpyNQvQAA52sw From: "Mickautsch, Alfred" To: X-OriginalArrivalTime: 02 Oct 2003 17:17:22.0929 (UTC) FILETIME=[0B07FE10:01C38909] Subject: [xml] WG: Document traversing interface for libxml2 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_221EA_01C38919.CF4E51B0 x-gfisavedcharset: iso-8859-1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Daniel suggested that I post this to the list. Comments and suggestions = are welcome, but please do not flame me :-). Servus -- Alfred > -----Urspr=FCngliche Nachricht----- > Von: Daniel Veillard [mailto:daniel@veillard.com] > Gesendet: Donnerstag, 2. Oktober 2003 18:57 > An: Mickautsch, Alfred > Cc: daniel@veillard.com > Betreff: Re: Document traversing interface for libxml2 >=20 >=20 > On Thu, Oct 02, 2003 at 06:13:16PM +0200, Mickautsch, Alfred wrote: > > Hello Daniel, > >=20 > > because I liked the approach of the TextReader very much, I=20 > wrote an XML document tree traversing interface in the manner=20 > of the xmlTextReader API (in fact I copied parts of the=20 > xmlreader.* files and modified them to work with an=20 > xmlDocPtr). So I thought that it would be only fair, that I=20 > inform you about this, since it is based on your work. > > In the attachment you will find the source files of the=20 > traversing interface. Please feel free to do what you like=20 > with them -- modify, change, include them in libxml2, etc. or=20 > forget them :-). > >=20 >=20 > Would you mind posting this to the mailing-list [1] ? This=20 > may generate > some reactions, and also would be a public proof of the origin and the > intent of the code. This would allow people to find and use it in case > I do not integrate it in the main release. >=20 > thanks ! >=20 > Daniel >=20 > [1] xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml >=20 > --=20 > Daniel Veillard | libxml Gnome XML XSLT toolkit =20 http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ |=20 -- Alfred Mickautsch schuler business solutions AG Karl-Berner-Str. 4 D-72285 Pfalzgrafenweiler tel: +49 (0)74 45 830-184 fax: +49 (0)74 45 830-349 e-mail: alfred.mickautsch@schuler-ag.com ------=_NextPart_000_221EA_01C38919.CF4E51B0 Content-Disposition: attachment; filename="xmldwalk.zip" Content-Description: xmldwalk.zip Content-Type: application/x-zip-compressed; name="xmldwalk.zip"; name="xmldwalk.zip" Content-Transfer-Encoding: base64 UEsDBBQAAgAIACKOQi9XwwU6IAMAABcLAAAKAAAAeG1sZHdhbGsuaK1WXW/aMBR9DhL/4aqTphZV MO1x1aRSoCtql1XA2r0hk9wsXhM7sh1aNPW/79qBLJTPTEOAkut7zv06id1pNRvQgpc0CZ9Z8tSO 4RMMhUEVsQD1OQRSaMOE0cBECGaRoQYZgYkRQhnkKQoDRrE5Ks3FT+jeD9uRVPDj653lddwm5hro GyOb82QBM6YxhDyTwtFQ6Am+mBGyEBVoo5CllkrIEC2f46CQCZ+R60eYLaDPBMcEHpAnCVMhnIbO cDlfGtqBTM/aVAdQFQYKil+5NlROxim4rSWVIY/sDbEqF7wdlzmPJdgyEh6g0Oj8Q66DhPHUJono Ut+xLCPHsUy4XZKyJFIYXqY8eGK50UHcDtEudJqNZuMdj0SIEUyn1Dv76z92726nN9MprdECF7h1 zSELYJAluba/ZoMaikrASe8EfpMHCqrV+toBWmcUedps0JJnGQs6/5s/gM/w4XzNOp50R5N101W3 dzsZ0d+6eeD3m41XKrkvg0fSEqqxYQYvqnFpvDlNZFr1KvIoLPdGeZ5HyrrwOi0IcqWswEql2VYB fcjZJ3kU3lYoa+5OOVtdyWPDmxmj+Cw3uI7jwnj2E2Jm4gsAQrjLlfo3gnkblVO1tn4bzF2toJxm wwzJy8LWGrbWq+oCtKp3VIzz7BS66tln1PaVKN9DH1c3S229Qdo8fXwuTadl522fz4h4LnlIlZP9 WiG+dSyJXB1n1USGq8KucxEYTmktU3DNrMJH+MxFuJNxw39sMNsTf8O/uxpqT+bCHB+nb0d8vPsN 02UkXQv2wJIcj0cM9SDNzGKQoH0OduLI3ovZG7XcyYAlPkuxHmwvYiNB+4xNSLj1YtwrerG91M9L Z7Q7fVe8HvKKNp7aoP2D2gH6gqbUhS+3os/tG4beHjsDVzl2MLjNGUq0oM4cRefr4wiTlXK2hiqG MBruEZ58yrNyXsfFzJwktmrsq5zjRNZp7CGKen09mNB/b+uOiNdc6QPi2IP26XDwz+BDbyAnhdWG W3XqFfulXdr3AC7PAFuQdL8n6rZD0KvX6fw9CFWPQcWV3dM3j1Ruw/oDUEsDBBQAAgAIABuOQi9n UgbZ1w8AAK1eAAAKAAAAeG1sZHdhbGsuY+0ca3PbNvKzO9P/gLgzHSmRZSX3TW4ykSUl0dSRfbLc pDM346FJyOKZInUkZcVN898PixcBEHzJdpJ2mjYPA4vFYl/YBRY8fPrjD+gp+rQKvK0T3HRd1Efp EiMvcjcrHKYojZ1bHCd+eI0GZ5PuIorRx/cnCEbRkenSTxD5f4mdWz+4Q1dOgj20WUchxUMQz/Gn dIYdD8coSWPsrABXGHkYEFIc0QIF/hUBfYGu7tDICX0coN+wHwRO7KGWRxte3/KGrhut2l00CdHC cVPEUPx3k6TIjdY+mdwJPbSKPH8BPxCsMZ2860qazyME6wh8F4cJpvCen7iB46+ASIwp6QXd0YLi 4AR3JVInWMTYe73y3Rtnkybusuth6Dj88Qf47yc/dIMNWfQvhAmEA93lK72ZITwkv1d4FcV3FMDW PTkt7OIrNVDvS+ku96Hj8KkU+hRvR5H7gfThuE8bXxPJ95GQHek8S2O5xiGZIMUJclCIt8gPk9QJ XQzyy+AZMjlkhtNNHCaoR8CRS5QDoHEcR3GHDgJEThBELkHsaSjIxCgiIPHWTwQnjX7aoK6hJWkG DW7/+MNnMpD8MvHGOD0CVuz5ixYBRC9foh6B3tuLKbmox3rJT+glDH5PSWwl/h84WrRUbO32EUND YTmaz4CKQL3FIY59dwzLbRk/D6MwJZbRoeJR10AscEWnI/rtB9j7T7hP51Bp2/tC6SOakuAUpu6g XgcVkcdWcvCKrhQYc8S4QhupJb5kWGkDEWoKLcTML0cfBie/Xk5Pp2OJBkhg7PtiKNObGGNTm/yU /BPl1ENVqhEW8rdqEZH6beR7VNTaDC1TqDAXEznIA35CT4Rc+WDa2rbQLhHN8NYPvfrUT0I/9Z2A cD6pYwTE7Rw8z5kCX6cfprqKM2LqLBQ0D/35J+3igjZU+uC51HgJdPDKXfqBF+OwyAIYaKFK8H4P r9OlUCLWpKhVpjfPyzh/nuJ1fb4DNHA8jjbXSwFJdiuM7811QF2X56Uc5mxT+TaejmxcFiMY10CW P/+MVCRPLEiol6kSJwUqFCPBRF2L5lu4c9EFaZnkKAPKYz6fD2Zz1W09z9yWwSBtbceD4a/zGfmj OQeAUoUFT2ws0FajDzhSwKhCP3t2VMq8bInaGiX7dLrSu7XUhfHJ+P14OidWNBpnVpuHG8zns8nx xXxMIWvIU3LPTpbJfzZjSLYhyq36LC/iJaC6v1owXGsnhgD0yU7WoKLQeTo6HV5I5j+CiagzK6yg GnVwUMocXXoWBpWSWNPNDlISf15tUjyMNmFa3+GexdGt7/FdLtysrmgsjByBLhFhoLuJqeCAEbYw cEF6lGEdm2sGjw24JBiJ7Tfgp+0eW19Tie+GqIeM5gEMjwxhNIDBZFnrNIG2MFFayIJoG/lb89vV O4H062XOnzCOwknHpekV7wVtwAEExEa/RpXiSp7kXU5hpEt1G9hA/s31OI7WOE59DHzY2xJXiVsU 4Ika6pLR3FnywfBX5g2Y9hLpC6xhMsKLDCHpKUDHxiQmqtIwVIp+BCZXX8HnkPbSQIYrMmWvz/JY CCy6OW1OsyGNIgxK2YOEGDsplu4qeW/ZzpPtUVbg6eD9+PxsMBxfjsbDk7bqLdX48Bni1Ns7X+Tk q/SXyfmdk0gHkNSX94clhuwyE/XSSRS/lJf2c/BdabzBHebGFg6xww49H1BlH5fLXqO2wlXt4nSo i+MgpfqhA5Y5H6R6HxhmcUBI8UAcc0XcQ/Z008dksys7mcxVBellivCbE2zwPXTAdUKiB7dk50GQ naNbwPeIqkDpLfMEf6F9J9n6qbtUxC58DWVG3qv01a75+OM83zocDeaDy/PxcD45nea7zyaWIafv pY5pHbqX6pshlocXziZIaftVjJ2bnDsq1b1JMl6t07txgOHYtL4GDpfYvaHaZIROcKiKAaVd+WhX R8RTaU71KnYgndzmJwxWxbKqX6MwpFgnSxJmW86Xi24q4+KTyHWCqbPCzSIGOLkKUEjGqWGDPVRQ YWM0vTg5kdK7dfzAuQqUc87h0okBh5XG++4bFYL8OpFpYfQgjk9FCE4wtcSPbbEiGsFAaLiO8cL/ lK1BLIKMOE9jb7NuHQ9Gl8PB+ZwetYYJP04VtObhM6xtLTstV+dsQ1MhLCk8m08TIZUplWFb01iF JhY4EzgGUajHzVX4fxsnYJclphp3EIZOlEYk/aNc7ksVfCQV30m7eSvDp57tf2uFr94SVQ3ql++V mQqCSfBFiQbVDoDtBaagq9EeZwG75NBBdBvQoFyH3zlkhtXfLwEzJtXTt4IQoMyKf4LQjE1YESmU YnE9J3UOEuymfhQa6IhIJvPf81Lh7bPxm5I5jPXawpX6g8x4pnxJ0Qr2c2Mx2pGXtpx3c0v3T/6C BEPoZHLMBx+TZQ+OT8YjA+lxfigOPX9RRaW4XC4i881s8LbeegWmg0XsXFtQTk/ngwqFKOK7pGb+ +5klXh3NRzsgtcSg7PSxarcT1qxZqn1fK9wXDburbdMFRm04iC8lli2cnFi0xcnluril5do/TqbD k4vRmB0l27vG01HffmNaJ5SHzWVOfHX9XfQtYZBMIenuX3AWSvbKBSYtLke+TNN1//DQi9LrcNON 4uvDdYjTwL86IJp9eH6XpHh1+HEVwG9BVneZrgLr5vspA7IR0PCQSqBqlp3Wz00fOKgs2tObb8FV F3hZLGHpl2f42gYM/bPxYDSeMXdCsIhp1R0xByZByp1IWdBQgFpCGsj1Tdin1QST5DhwwhuQtJJ2 tdXLEwoHAMQUzteOi0m8mOD4Nj+gkKLzydvp5M1kOCCi+PBuMmdrVHyfbZAGqDshExRWZiy2PGgw EVBoA0NJPJCXuQAdz8bT4diOqR4WY6wlsDDHnc1Oh+Pz88n07eVkej6fXdA1m/woiDVynGBwxuhv GGaYBIoBRRRaI4wiJBTaZodFwYWJSAAWUVM/wigkEX4yFerbbrp5JrCKEW0fPig9kmE5Z/1teICS ZRSnSzgLi8VGC8kr3ZtJMJaAZ0JOkkSuT+vNyN6wrDi04WHUbtksW8G9znctmatZMsDTwZoJrcwO v4NDnBrHOD39zqgi+n2csxrKM2P1/NIyw6QswjyGLE+u64alQoEvYr/ZAc/FbIKIq/VDqLy9jy1k 4wDl7gc8YhkPbRjf0Rlmmb7yqH+73Xa3/6JR/4ter3dI1fhwv330ODrcsytwlZ4uiZ5Wa2lW5H1M NobGGgpV40ynqs7QM8idtI9T90AXHj3zsJZHwDBLq9dRhpbWnDa8tNQqcbJbSr1sYQEbV4JZzUyO i6wGvZCHXSoUsqxkE6RoBbX1V1DpIAu1KUL4RZ2GKK5tl/N+h7vOv8YZbvHNYmZQLWPza2eWVZq+ yeMhtUqJ76W8ST8kIutn1TdK/ZyeeHE2n/hJCtkaVQVtDK3z7PAiHnG31kHP+XGQvDgpRdgrRPBF u2J9/BvgzOW5UHOv8aTA8XHAdtnFsLjHofFUmXkTnsiKj2lUy87R6zBiD3H+wHF0wB7V+KGHPwkr zyrjYhw4qX8rA12g3WF7PWbXu3bPoTmNDJ0MA5I1dtm1EJtYzMOe/RTNlffajvA2CnBu/mwySUlH uCfhbMyDK+alOHKLk4LHRJRI0oLjbrlz0oXUYt4o56g64GDocVrmstRbJ9rpH7EOYbHE1fAWpaaw SZSvejJruXC9y3Uag+t5Ay/DW0Rxy6f1f8hHv0B9JsQWLD4gTc+etW3FeDyYyIURLf0mlbo5HkGQ lZiFslqBIcFHQeyuHcg8YgQecaKoe2RYyZ9qAbKByX4WzI61885LpZD6Qorc9GTGq5/88ltSPdr7 +8bVbkXxoqqPdV0G3PzSbvuNrrSs7n0dgo7/72DyZQZPFkEmkkjorY56Gc2aRf5KNUzroXfiMKqs uFh6kezRzNf2D5JOftmzDvz035CuvWhBawf9rNz3EOIU+HweQZhLlGutWFIHZdULzJfAJNiJ3eU0 yVucOlCf1/A4DBGZjzDVnFGSyO6rlFxGoz/3TEx28TlRy8zsBaQtjW9g2tOkpnEHsjwpV2dhs27m DViePZv0bdn7Dk7BYrJ/h+0+aWD9Ug4FnkGwvF4yeQ9r1UytSPWnTPVVuspr4KKbzVqe0NRUTWYC ffW0dLuMElPh/ASixisIWJMouMUeEWjE63plPkl/sbJ6GnVnODpcae6kknC1o8jom2Q5HaeC1+4n bpS/EG0cruqLISvZLn13qS565awTsRCZWT+mEhviaqDF3GtpJVVNYlN7NfmuTp3Vi6MWO8eW59NG fpVVgRcFmIV6/T66xfPo2yRhmWrnVA7I4pcMUeJDFZKppfKJPUerR2X8AwzFqVqTNE0rDEg2rosT +9sspeh4EW1Cr6h+IMf02knVAyZRTd/nwi1Vvfv9UqiiZ76oXmE0KnqILSK9l8qNxE5pHR1eP7NT Xn1mJLSy87o2k4ft0eLDpXzoAXK+0jVwHatTLW4o9+NlaI/gI6qyt8f2BDvlWnv5RIubwJ410TI8 hepKQP9qZ1jW/OY78CStb5bkfc4Kg8gmPAZt4kNzN7JKhVCxl9rLvwIVg4pLGXl/LZ9kPoTnJ9CW 16XyXbf1sTfoTakr4wuhcObXB3R+AQirD+VZMXhm0SqjIFAM0Zar79b5VMYGru95PjA28GXxiQQn vmi37j3tbl1fCVBVIPvPcnOxSz4v+M+WCla+XQGLNJ2TEEqe34AtUjuuozRiDkxlS145aDsFJh7v Ug5gbKlUDl03RJBrMyZVObKFwfKlghSwxFQWGWTnvnNQqSoGU74oBqBrCumR7Og/0tGK7sPEVA0n aunqpMH22vUfiplx7Q4nODsd4TQ6w7lv2ABNFFEWNij0QoGVRsk3SCce8dAmHyvsXKYlZ9YCCjHf 3ymwKLg95z7jgT3iVO6ZLdMnsma7V4STAuM4rL2Db7R97afIN9Ys7mLa/caPk4bXPjta+wJm0k9x rbVg6vuBr2bkOhuK7PwB3if/dazL/GQThFB5qylTX3sEVv0VJu3jDLtNZ0TJ+TnrW8iUWNZXMRD6 Uazv1D40JvxjHvmSL8spcqWXUV9fl38bp2mtc67gTOQ34sNrktYau5CeruY+8FbPfOtMVGLA1g3Q yBRplRh8Bab+V4bYzm2AazwqdD2WQfd2NY0/5bGDk6HvBZcOrdASp/SJNkQqKHpAH7MilFb4GPFl kH823/JXFFZ1FCeTO+rfkMkeTLG+9r1z3Bu44CHyxPGC1vYHQbSl15cRuuYvVJU8xo3ILOso9DiI yPi0J6NXGHodqlXZ7aRKQ7fsKSr9hnPRVWh2uclBdT1UuNBAC5s+guHbgwagHwZoGU2VzMjPjyAy /knrKonJj7bfQ2p8qhpCE98Gt3PhfiLTPwBHP1hNOP9/UEsBAhQAFAACAAgAIo5CL1fDBTogAwAA FwsAAAoAAAAAAAAAAQAgALaBAAAAAHhtbGR3YWxrLmhQSwECFAAUAAIACAAbjkIvZ1IG2dcPAACt XgAACgAAAAAAAAABACAAtoFIAwAAeG1sZHdhbGsuY1BLBQYAAAAAAgACAHAAAABHEwAAAAA= ------=_NextPart_000_221EA_01C38919.CF4E51B0-- From aleksey@aleksey.com Thu Oct 2 16:07:01 2003 Return-Path: Delivered-To: xml@gnome.org Received: from shell.aleksey.com (dsl081-246-064.sfo1.dsl.speakeasy.net [64.81.246.64]) by mail.gnome.org (Postfix) with ESMTP id 9F50518A9C for ; Thu, 2 Oct 2003 16:07:00 -0400 (EDT) Received: from aleksey.com (unknown [64.236.139.249]) by shell.aleksey.com (Postfix) with ESMTP id 50717B5BA; Thu, 2 Oct 2003 13:07:12 -0700 (PDT) Message-ID: <3F7C84E4.6010200@aleksey.com> Date: Thu, 02 Oct 2003 13:04:52 -0700 From: Aleksey Sanin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, ru MIME-Version: 1.0 To: veillard@redhat.com Cc: xml@gnome.org Subject: Re: [xml] xmlStrPrintf function References: <3F7C5950.4050300@aleksey.com> <20031002155325.D21001@redhat.com> In-Reply-To: <20031002155325.D21001@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: > Since the patch is very small, and you have plenty of good reasons to >do so, fine. Go ahead, and commit... > Thanks! The patch is commited: Checking in ChangeLog; /cvs/gnome/gnome-xml/ChangeLog,v <-- ChangeLog new revision: 1.1649; previous revision: 1.1648 done Checking in parser.c; /cvs/gnome/gnome-xml/parser.c,v <-- parser.c new revision: 1.317; previous revision: 1.316 done Checking in include/libxml/parser.h; /cvs/gnome/gnome-xml/include/libxml/parser.h,v <-- parser.h new revision: 1.104; previous revision: 1.103 done >BTW The C14N module will also be integrated into the new error handling >this won't change the API/ABI but I will have to touch your code a bit >I think. I will do my best to not break things though :-) > The tests in the suite provide pretty good coverage. And I am recompiling xmlsec with CVS version of libxml2 every other day anyway so even if you break something we would quickly find it out :) Aleksey From veillard@redhat.com Thu Oct 2 16:56:21 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id AB74D18116 for ; Thu, 2 Oct 2003 16:56:21 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h92KuX021533; Thu, 2 Oct 2003 16:56:33 -0400 Date: Thu, 2 Oct 2003 16:56:33 -0400 From: Daniel Veillard To: Aleksey Sanin Cc: xml@gnome.org Subject: Re: [xml] xmlStrPrintf function Message-ID: <20031002165632.E21001@redhat.com> Reply-To: veillard@redhat.com References: <3F7C5950.4050300@aleksey.com> <20031002155325.D21001@redhat.com> <3F7C84E4.6010200@aleksey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3F7C84E4.6010200@aleksey.com>; from aleksey@aleksey.com on Thu, Oct 02, 2003 at 01:04:52PM -0700 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, Oct 02, 2003 at 01:04:52PM -0700, Aleksey Sanin wrote: > > > Since the patch is very small, and you have plenty of good reasons to > >do so, fine. Go ahead, and commit... > > > Thanks! The patch is commited: cool, > >BTW The C14N module will also be integrated into the new error handling > >this won't change the API/ABI but I will have to touch your code a bit > >I think. I will do my best to not break things though :-) > > > The tests in the suite provide pretty good coverage. And I am > recompiling xmlsec with CVS > version of libxml2 every other day anyway so even if you break something > we would quickly > find it out :) yeah. If one day I have some free time I will have to look at your documentation for xmlsec, it looks good and that's an area where I'm lacking seriously ... Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From breese@mail1.stofanet.dk Thu Oct 2 17:15:21 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mx04.stofanet.dk (mx04.stofanet.dk [212.10.30.234]) by mail.gnome.org (Postfix) with ESMTP id EAD9518111 for ; Thu, 2 Oct 2003 17:15:20 -0400 (EDT) Received: from 3e6b3c89.rev.stofanet.dk ([62.107.60.137]) by mx04.stofanet.dk with esmtp (Exim 4.22) id 1A5AnN-0000Pz-1k for xml@gnome.org; Thu, 02 Oct 2003 23:15:33 +0200 Subject: Re: [xml] WG: Document traversing interface for libxml2 From: Bjorn Reese To: xml@gnome.org In-Reply-To: <4F38C8B9DAB1014DBDCB29538BBFD6A128507B@pandora.schuler-ag.com> References: <4F38C8B9DAB1014DBDCB29538BBFD6A128507B@pandora.schuler-ag.com> Content-Type: text/plain Organization: Hyperspace Academy Message-Id: <1065129451.2059.12.camel@stellifer> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 02 Oct 2003 23:17:32 +0200 Content-Transfer-Encoding: 7bit Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Alfred, >From a brief glance at the walker interface, I must say that I like it. Suggestion: You may consider adding a xmlDocWalkerNext() that moves to the next sibling, just like xmlTextReaderNext(). From aleksey@aleksey.com Thu Oct 2 17:40:00 2003 Return-Path: Delivered-To: xml@gnome.org Received: from shell.aleksey.com (dsl081-246-064.sfo1.dsl.speakeasy.net [64.81.246.64]) by mail.gnome.org (Postfix) with ESMTP id 8A98A18137 for ; Thu, 2 Oct 2003 17:40:00 -0400 (EDT) Received: from aleksey.com (unknown [64.236.139.249]) by shell.aleksey.com (Postfix) with ESMTP id 7B29AB5BA; Thu, 2 Oct 2003 14:40:12 -0700 (PDT) Message-ID: <3F7C9A7B.6070702@aleksey.com> Date: Thu, 02 Oct 2003 14:36:59 -0700 From: Aleksey Sanin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, ru MIME-Version: 1.0 To: veillard@redhat.com Cc: xml@gnome.org Subject: Re: [xml] xmlStrPrintf function References: <3F7C5950.4050300@aleksey.com> <20031002155325.D21001@redhat.com> <3F7C84E4.6010200@aleksey.com> <20031002165632.E21001@redhat.com> In-Reply-To: <20031002165632.E21001@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: > yeah. If one day I have some free time I will have to look >at your documentation for xmlsec, it looks good and that's an area >where I'm lacking seriously ... > > Feel free to ask questions, I'll be glad to answer :) Aleksey From veillard@redhat.com Thu Oct 2 18:16:29 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id A3BE21813D for ; Thu, 2 Oct 2003 18:16:29 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h92MGfB30658; Thu, 2 Oct 2003 18:16:41 -0400 Date: Thu, 2 Oct 2003 18:16:41 -0400 From: Daniel Veillard To: Bjorn Reese Cc: xml@gnome.org Subject: Re: [xml] WG: Document traversing interface for libxml2 Message-ID: <20031002181641.G21001@redhat.com> Reply-To: veillard@redhat.com References: <4F38C8B9DAB1014DBDCB29538BBFD6A128507B@pandora.schuler-ag.com> <1065129451.2059.12.camel@stellifer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1065129451.2059.12.camel@stellifer>; from breese@mail1.stofanet.dk on Thu, Oct 02, 2003 at 11:17:32PM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, Oct 02, 2003 at 11:17:32PM +0200, Bjorn Reese wrote: > Alfred, > > >From a brief glance at the walker interface, I must say that I > like it. > > Suggestion: You may consider adding a xmlDocWalkerNext() that > moves to the next sibling, just like xmlTextReaderNext(). Bjorn, since you seem to have looked at it can you share some review of the code. If relatively small that could be useful as a tree API. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From pgarnier@mega.com Fri Oct 3 08:41:32 2003 Return-Path: Delivered-To: xml@gnome.org Received: from rio.mega.com (rio.mega.fr [213.11.73.221]) by mail.gnome.org (Postfix) with ESMTP id 8AEB418950 for ; Fri, 3 Oct 2003 08:41:31 -0400 (EDT) Received: from relay.mega.com by rio.mega.com via smtpd (for moniker.gnome.org [67.72.78.218]) with ESMTP; Fri, 3 Oct 2003 14:41:30 +0100 Received: from xor.mega.com ([194.3.176.3]) by relay with InterScan Messaging Security Suite; Fri, 03 Oct 2003 14:38:48 +0100 Received: from rio.fr.mega.com by xor.mega.com via smtpd (for relay.mega.com [192.168.167.9]) with ESMTP; Fri, 3 Oct 2003 14:41:26 +0100 Received: by RIO with Internet Mail Service (5.5.2653.19) id <4DBWBYT1>; Fri, 3 Oct 2003 14:41:08 +0100 Message-ID: From: GARNIER Pierre To: xml@gnome.org Date: Fri, 3 Oct 2003 14:41:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [xml] Current line number and position with xmlTextReader API Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hello, I'm using xmlTextReader API. I would like to know the position of the current node in the document at any moment of the read. I think that I can get the line number by calling : nbline = xmlGetLineNo(xmlTextReaderCurrentNode(reader)); How can I get the position in the line? Is it possible? Thanks, Pierre From alfred.mickautsch@schuler-ag.com Fri Oct 3 08:54:23 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail-relay1 (mail-relay1.schuler-ag.com [62.156.183.20]) by mail.gnome.org (Postfix) with ESMTP id 7D0FC182F4 for ; Fri, 3 Oct 2003 08:54:23 -0400 (EDT) Received: from sbs-proxy-test.schuler-ag.com ([192.168.16.254]) by mail-relay1 with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Oct 2003 14:59:06 +0200 Received: from mail pickup service by sbs-proxy-test.schuler-ag.com with Microsoft SMTPSVC; Fri, 3 Oct 2003 14:54:36 +0200 x-gfisavedcharset: iso-8859-1 Content-Type: text/plain; charset="iso-8859-1" Received: from pandora.schuler-ag.com ([192.168.16.20]) by sbs-proxy-test.schuler-ag.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Oct 2003 14:54:34 +0200 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: AW: [xml] WG: Document traversing interface for libxml2 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Date: Fri, 3 Oct 2003 14:54:34 +0200 Message-ID: <4F38C8B9DAB1014DBDCB29538BBFD6A128507D@pandora.schuler-ag.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [xml] WG: Document traversing interface for libxml2 thread-index: AcOJKnHX0gBdLZXpQb6qREf8rw3lkQAg4QAw From: "Mickautsch, Alfred" To: X-OriginalArrivalTime: 03 Oct 2003 12:54:35.0054 (UTC) FILETIME=[7F0EF4E0:01C389AD] Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Bjorn, ... >=20 > >From a brief glance at the walker interface, I must say that I > like it. ... > Suggestion: You may consider adding a xmlDocWalkerNext() that > moves to the next sibling, just like xmlTextReaderNext(). Thanks, see the attached patch for xmlTextReaderNext and some cleanup of = the code. Servus -- Alfred From breese@mail1.stofanet.dk Fri Oct 3 08:59:40 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mx04.stofanet.dk (mx04.stofanet.dk [212.10.30.234]) by mail.gnome.org (Postfix) with ESMTP id 9EBD318778 for ; Fri, 3 Oct 2003 08:59:39 -0400 (EDT) Received: from 3e6b3c89.rev.stofanet.dk ([62.107.60.137]) by mx04.stofanet.dk with esmtp (Exim 4.22) id 1A5PXD-0004sq-28 for xml@gnome.org; Fri, 03 Oct 2003 14:59:51 +0200 Subject: Re: [xml] WG: Document traversing interface for libxml2 From: Bjorn Reese To: xml@gnome.org In-Reply-To: <20031002181641.G21001@redhat.com> References: <4F38C8B9DAB1014DBDCB29538BBFD6A128507B@pandora.schuler-ag.com> <1065129451.2059.12.camel@stellifer> <20031002181641.G21001@redhat.com> Content-Type: multipart/mixed; boundary="=-184Sj90WB6dNVHigRX4R" Organization: Hyperspace Academy Message-Id: <1065186112.2059.119.camel@stellifer> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 03 Oct 2003 15:01:52 +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: --=-184Sj90WB6dNVHigRX4R Content-Type: text/plain Content-Transfer-Encoding: 7bit On Fri, 2003-10-03 at 00:16, Daniel Veillard wrote: > Bjorn, since you seem to have looked at it can you share > some review of the code. If relatively small that could be useful > as a tree API. Overall the code is well-written. I find it useful as a tree API. Now we just need xmlTextWriter and its equivalence for the tree API. There were an error in xmlDocWalkerMoveToAttribute were a null pointer was freed. I have fixed this, and furthermore added a little extra error handling. I have also made some cosmetic changes to make the code more in line with the rest of the libxml code (e.g. converting tab to 8.) There is one unresolved issue: depends on for types. Modified version of xmldwalk is attached. --=-184Sj90WB6dNVHigRX4R Content-Disposition: attachment; filename=xmldwalk.c Content-Type: text/x-c; name=xmldwalk.c; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit /* * xmldwalk.c : the document traversing API.for XML * * this is heavily based upon the xmlTextReader streaming node API * of libxml2 by Daniel Veillard (daniel@veillard.com). In fact I * just copied and modified xmlreader.c * * So for license and disclaimer see the license and disclaimer of * libxml2. * * alfred@mickautsch.de */ #include #include #include #include #include /** * xmlNewDocWalker: * @doc: the xmlDocPtr * * Creates a new instance of the xmlDocWalker * * Returns 0 in case of error, the new allocated xmlDocWalkerPtr otherwise */ xmlDocWalkerPtr xmlNewDocWalker(xmlDocPtr doc) { xmlDocWalkerPtr ret; if (doc == 0) return 0; ret = xmlMalloc(sizeof(xmlDocWalker)); if (ret == 0) { xmlGenericError(xmlGenericErrorContext, "xmlNewDocWalker : malloc failed\n"); return 0; } memset(ret, 0, sizeof(xmlDocWalker)); ret->doc = doc; ret->node = 0; ret->state = XML_DWALK_NONE; return ret; } /** * xmlFreeDocWalker: * @iter: the xmlDocWalkerPtr * * Deallocate the xmlDocWalker */ void xmlFreeDocWalker(xmlDocWalkerPtr iter) { if (iter != 0) xmlFree(iter); } /** * xmlDocWalkerRewind: * @iter: the xmlDocWalkerPtr * * Initializes the xmlDocWalker * * Returns 0 or -1 in case of error */ int xmlDocWalkerRewind(xmlDocWalkerPtr iter) { if (iter == 0 || iter->doc == 0) return -1; if (iter->doc->children == 0) return 0; iter->state = XML_DWALK_NONE; iter->depth = 0; iter->node = 0; return 1; } /** * xmlDocWalkerStep: * @iter: the xmlDocWalkerPtr * * Steps through the xml tree * * Returns 0 or -1 in case of error */ int xmlDocWalkerStep(xmlDocWalkerPtr iter) { if (iter == 0) return -1; if (iter->state == XML_DWALK_END) return 0; if (iter->node == 0) { if (iter->doc->children == 0) { iter->state = XML_DWALK_END; return 0; } iter->node = iter->doc->children; iter->state = XML_DWALK_START; return 1; } if ((iter->state != XML_DWALK_BACKTRACK) && (iter->state != XML_DWALK_END)) { if (iter->node->children != 0) { iter->node = iter->node->children; iter->depth++; iter->state = XML_DWALK_START; return 1; } if ((iter->node->type == XML_ELEMENT_NODE) || (iter->node->type == XML_ATTRIBUTE_NODE)) { iter->state = XML_DWALK_BACKTRACK; return 1; } } if ((iter->node->next != 0) && (iter->state != XML_DWALK_END)) { iter->node = iter->node->next; iter->state = XML_DWALK_START; return 1; } if ((iter->node->parent != 0) && (iter->state != XML_DWALK_END)) { if (iter->node->parent->type == XML_DOCUMENT_NODE) { iter->state = XML_DWALK_END; return 0; } iter->node = iter->node->parent; iter->depth--; iter->state = XML_DWALK_BACKTRACK; return 1; } iter->state = XML_DWALK_END; return 1; } /** * xmlDocWalkerAttributeCount: * @iter: the xmlDocWalkerPtr * * Provides the number of attributes of the current node * * Returns 0 if no attributes, -1 in case of error or the attribute count */ int xmlDocWalkerAttributeCount(xmlDocWalkerPtr iter) { int ret; xmlAttrPtr attr; xmlNsPtr ns; xmlNodePtr node; if (iter == 0) return -1; if (iter->node == 0) return 0; if (iter->curnode != 0) node = iter->curnode; else node = iter->node; if (node->type != XML_ELEMENT_NODE) return 0; ret = 0; attr = node->properties; while (attr != 0) { ret++; attr = attr->next; } ns = node->nsDef; while (ns != 0) { ret++; ns = ns->next; } return ret; } /** * xmlDocWalkerDepth: * @iter: the xmlDocWalkerPtr * * The depth of the node in the tree. * * Returns the depth or -1 in case of error */ int xmlDocWalkerDepth(xmlDocWalkerPtr iter) { if (iter == 0) return -1; if (iter->node == 0) return 0; if (iter->curnode != 0) { if ((iter->curnode->type == XML_ATTRIBUTE_NODE) || (iter->curnode->type == XML_NAMESPACE_DECL)) return iter->depth + 1; return iter->depth + 2; } return iter->depth; } /** * xmlDocWalkerHasAttributes: * @iter: the xmlDocWalkerPtr * * Whether the node has attributes. * * Returns 1 if true, 0 if false, and -1 in case or error */ int xmlDocWalkerHasAttributes(xmlDocWalkerPtr iter) { xmlNodePtr node; if (iter == 0) return -1; if (iter->node == 0) return 0; if (iter->curnode != 0) node = iter ->curnode; else node = iter ->node; if ((node->type == XML_ELEMENT_NODE) && (node->properties != 0)) return 1; return 0; } /** * xmlDocWalkerHasValue: * @iter: the xmlDocWalkerPtr * * Whether the node can have a text value. * * Returns 1 if true, 0 if false, and -1 in case or error */ int xmlDocWalkerHasValue(xmlDocWalkerPtr iter) { xmlNodePtr node; if (iter == 0) return -1; if (iter->node == 0) return 0; if (iter->curnode != 0) node = iter->curnode; else node = iter->node; switch (node->type) { case XML_ATTRIBUTE_NODE: case XML_TEXT_NODE: case XML_CDATA_SECTION_NODE: case XML_PI_NODE: case XML_COMMENT_NODE: case XML_NAMESPACE_DECL: return 1; default: break; } return 0; } /** * xmlDocWalkerIsEmptyElement: * @iter: the xmlDocWalkerPtr * * Check if the current node is empty * * Returns 1 if empty, 0 if not and -1 in case of error */ int xmlDocWalkerIsEmptyElement(xmlDocWalkerPtr iter) { if ((iter == 0) || (iter->node == 0)) return -1; if (iter->node->type != XML_ELEMENT_NODE) return 0; if (iter->curnode != 0) return 0; if (iter->node->children != 0) return 0; return 1; } /** * xmlDocWalkerLocalName: * @iter: the xmlDocWalkerPtr * * The local name of the node. * * Returns the local name or NULL if not available */ xmlChar * xmlDocWalkerLocalName(xmlDocWalkerPtr iter) { xmlNodePtr node; if ((iter == 0) || (iter->node == 0)) return 0; if (iter->curnode != 0) node = iter->curnode; else node = iter->node; if (node->type == XML_NAMESPACE_DECL) { xmlNsPtr ns = (xmlNsPtr) node; if (ns->prefix == 0) return xmlStrdup(BAD_CAST "xmlns"); else return xmlStrdup(ns->prefix); } if ((node->type != XML_ELEMENT_NODE) && (node->type != XML_ATTRIBUTE_NODE)) return(xmlDocWalkerName(iter)); return xmlStrdup(node->name); } /** * xmlDocWalkerName: * @iter: the xmlDocWalkerPtr * * The qualified name of the node, equal to Prefix :LocalName. * * Returns the local name or NULL if not available */ xmlChar * xmlDocWalkerName(xmlDocWalkerPtr iter) { xmlNodePtr node; xmlChar *ret; if ((iter == 0) || (iter->node == 0)) return 0; if (iter->curnode != 0) node = iter->curnode; else node = iter->node; switch (node->type) { case XML_ELEMENT_NODE: case XML_ATTRIBUTE_NODE: if ((node->ns == 0) || (node->ns->prefix == NULL)) return xmlStrdup(node->name); if ((ret = xmlStrdup(node->ns->prefix)) && (ret = xmlStrcat(ret, BAD_CAST ":")) && (ret = xmlStrcat(ret, node->name))) return ret; if (ret) xmlFree(ret); return 0; case XML_TEXT_NODE: return xmlStrdup(BAD_CAST "#text"); case XML_CDATA_SECTION_NODE: return xmlStrdup(BAD_CAST "#cdata-section"); case XML_ENTITY_NODE: case XML_ENTITY_REF_NODE: return xmlStrdup(node->name); case XML_PI_NODE: return xmlStrdup(node->name); case XML_COMMENT_NODE: return xmlStrdup(BAD_CAST "#comment"); case XML_DOCUMENT_NODE: case XML_HTML_DOCUMENT_NODE: #ifdef LIBXML_DOCB_ENABLED case XML_DOCB_DOCUMENT_NODE: #endif return xmlStrdup(BAD_CAST "#document"); case XML_DOCUMENT_FRAG_NODE: return xmlStrdup(BAD_CAST "#document-fragment"); case XML_NOTATION_NODE: return xmlStrdup(node->name); case XML_DOCUMENT_TYPE_NODE: case XML_DTD_NODE: return xmlStrdup(node->name); case XML_NAMESPACE_DECL: { xmlNsPtr ns = (xmlNsPtr) node; ret = xmlStrdup(BAD_CAST "xmlns"); if(ns->prefix == 0) return ret; if ((ret) && (ret = xmlStrcat(ret, BAD_CAST ":")) && (ret = xmlStrcat(ret, ns->prefix))) return ret; if (ret) xmlFree(ret); return 0; } case XML_ELEMENT_DECL: case XML_ATTRIBUTE_DECL: case XML_ENTITY_DECL: case XML_XINCLUDE_START: case XML_XINCLUDE_END: return 0; } return 0; } /** * xmlDocWalkerNodeType: * @iter: the xmlDocWalkerPtr * * Get the node type of the current node * Reference: * http://dotgnu.org/pnetlib-doc/System/Xml/XmlNodeType.html * * Returns the xmlNodeType of the current node or -1 in case of error */ int xmlDocWalkerNodeType(xmlDocWalkerPtr iter) { xmlNodePtr node; if (iter == 0) return -1; if (iter->curnode != 0) node = iter->curnode; else node = iter->node; if (node == 0) return 0; switch(node->type) { case XML_ELEMENT_NODE: if ((iter->state == XML_DWALK_END) || (iter->state == XML_DWALK_BACKTRACK)) return XML_READER_TYPE_END_ELEMENT; return XML_READER_TYPE_ELEMENT; case XML_NAMESPACE_DECL: case XML_ATTRIBUTE_NODE: return XML_READER_TYPE_ATTRIBUTE; case XML_TEXT_NODE: if (xmlIsBlankNode(iter->node)) { if (xmlNodeGetSpacePreserve(iter->node)) return XML_READER_TYPE_SIGNIFICANT_WHITESPACE; return XML_READER_TYPE_WHITESPACE; } return XML_READER_TYPE_TEXT; case XML_CDATA_SECTION_NODE: return XML_READER_TYPE_CDATA; case XML_ENTITY_REF_NODE: return XML_READER_TYPE_ENTITY_REFERENCE; case XML_ENTITY_NODE: return XML_READER_TYPE_ENTITY; case XML_PI_NODE: return XML_READER_TYPE_PROCESSING_INSTRUCTION; case XML_COMMENT_NODE: return XML_READER_TYPE_COMMENT; case XML_DOCUMENT_NODE: case XML_HTML_DOCUMENT_NODE: #ifdef LIBXML_DOCB_ENABLED case XML_DOCB_DOCUMENT_NODE: #endif return XML_READER_TYPE_DOCUMENT; case XML_DOCUMENT_FRAG_NODE: return XML_READER_TYPE_DOCUMENT_FRAGMENT; case XML_NOTATION_NODE: return XML_READER_TYPE_NOTATION; case XML_DOCUMENT_TYPE_NODE: case XML_DTD_NODE: return XML_READER_TYPE_DOCUMENT_TYPE; case XML_ELEMENT_DECL: case XML_ATTRIBUTE_DECL: case XML_ENTITY_DECL: case XML_XINCLUDE_START: case XML_XINCLUDE_END: return XML_READER_TYPE_NONE; } return -1; } /** * xmlDocWalkerPrefix: * @iter: the xmlDocWalkerPtr * * A shorthand reference to the namespace associated with the node. * * Returns the prefix or NULL if not available */ xmlChar * xmlDocWalkerPrefix(xmlDocWalkerPtr iter) { xmlNodePtr node; if ((iter == 0) || (iter->node == 0) || (iter->node->ns == 0)) return 0; if (iter->curnode != NULL) node = iter->curnode; else node = iter->node; if (node->type == XML_NAMESPACE_DECL) { xmlNsPtr ns = (xmlNsPtr) node; if (ns->prefix == 0) return 0; return xmlStrdup(BAD_CAST "xmlns"); } if ((node->type != XML_ELEMENT_NODE) && (node->type != XML_ATTRIBUTE_NODE)) return NULL; if ((node->ns != 0) && (node->ns->prefix != 0)) return xmlStrdup(node->ns->prefix); return 0; } /** * xmlDocWalkerNamespaceUri: * @iter: the xmlDocWalkerPtr * * The URI defining the namespace associated with the node. * * Returns the namespace URI or NULL if not available */ xmlChar * xmlDocWalkerNamespaceUri(xmlDocWalkerPtr iter) { xmlNodePtr node; if ((iter == 0) || (iter->node == 0)) return 0; if (iter->curnode != 0) node = iter->curnode; else node = iter->node; if (node->type == XML_NAMESPACE_DECL) return xmlStrdup(BAD_CAST "http://www.w3.org/2000/xmlns/"); if ((node->type != XML_ELEMENT_NODE) && (node->type != XML_ATTRIBUTE_NODE)) return 0; if (node->ns != 0) return xmlStrdup(node->ns->href); return 0; } /** * xmlTextReaderBaseUri: * @iter: the xmlDocWalkerPtr * * The base URI of the node. * * Returns the base URI or NULL if not available */ xmlChar * xmlDocWalkerBaseUri(xmlDocWalkerPtr iter) { if ((iter == 0) || (iter->node == 0)) return 0; return xmlNodeGetBase(0, iter->node); } /** * xmlDocWalkerValue: * @iter: the xmlDocWalkerPtr * * Provides the text value of the node if present * * Returns the string or NULL if not available. The retsult must be deallocated * with xmlFree() */ xmlChar * xmlDocWalkerValue(xmlDocWalkerPtr iter) { xmlNodePtr node; if ((iter == 0) || (iter->node == 0)) return 0; if (iter->curnode != 0) node = iter->curnode; else node = iter->node; switch (node->type) { case XML_NAMESPACE_DECL: return xmlStrdup(((xmlNsPtr) node)->href); case XML_ATTRIBUTE_NODE: { xmlAttrPtr attr = (xmlAttrPtr) node; if (attr->parent != 0) return xmlNodeListGetString(attr->parent->doc, attr->children, 1); else return xmlNodeListGetString(0, attr->children, 1); } break; case XML_TEXT_NODE: case XML_CDATA_SECTION_NODE: case XML_PI_NODE: case XML_COMMENT_NODE: if (node->content != 0) return xmlStrdup(node->content); default: break; } return(NULL); } /** * xmlDocWalkerGetAttributeNo: * @iter: the xmlDocWalkerPtr * @no: the zero-based index of the attribute relative to the containing element * * Provides the value of the attribute with the specified index relative * to the containing element. * * Returns a string containing the value of the specified attribute, or NULL * in case of error. The string must be deallocated by the caller. */ xmlChar * xmlDocWalkerGetAttributeNo(xmlDocWalkerPtr iter, int no) { xmlChar *ret; int i; xmlAttrPtr cur; xmlNsPtr ns; if ((iter == 0) || (iter->node == 0) || (iter->curnode != 0) || (iter->node->type != XML_ELEMENT_NODE)) return 0; ns = iter->node->nsDef; for (i = 0; i < no && ns != 0; i++) ns = ns->next; if (ns != 0) return(xmlStrdup(ns->href)); cur = iter->node->properties; if (cur == 0) return 0; for (; i < no;i++) { cur = cur->next; if (cur == 0) return 0; } ret = xmlNodeListGetString(iter->node->doc, cur->children, 1); if (ret == 0) return(xmlStrdup((xmlChar *)"")); return ret; } /** * xmlDocWalkerGetAttribute: * @iter: the xmlDocWalkerPtr * @name: the qualified name of the attribute. * * Provides the value of the attribute with the specified qualified name. * * Returns a string containing the value of the specified attribute, or NULL * in case of error. The string must be deallocated by the caller. */ xmlChar * xmlDocWalkerGetAttribute(xmlDocWalkerPtr iter, const xmlChar *name) { xmlChar *prefix = 0; xmlChar *localname; xmlNsPtr ns; xmlChar *ret = 0; if ((iter == 0) || (iter->node == 0) || (iter->curnode != 0) || (iter->node->type != XML_ELEMENT_NODE)) return 0; localname = xmlSplitQName2(name, &prefix); if (localname == 0) return xmlGetProp(iter->node, name); ns = xmlSearchNs(iter->node->doc, iter->node, prefix); if (ns != 0) ret = xmlGetNsProp(iter->node, localname, ns->href); if (localname != 0) xmlFree(localname); if (prefix != 0) xmlFree(prefix); return ret; } /** * xmlDocWalkerGetAttributeNs: * @iter: the xmlDocWalkerPtr * @localName: the local name of the attribute. * @namespaceURI: the namespace URI of the attribute. * * Provides the value of the specified attribute * * Returns a string containing the value of the specified attribute, or NULL * in case of error. The string must be deallocated by the caller. */ xmlChar * xmlDocWalkerGetAttributeNs(xmlDocWalkerPtr iter, const xmlChar *localName, const xmlChar *namespaceURI) { if ((iter == 0) || (iter->node == 0) || (iter->node->type != XML_ELEMENT_NODE)) return 0; return xmlGetNsProp(iter->node, localName, namespaceURI); } /** * xmlDocWalkerLookupNamespace: * @iter: the xmlDocWalkerPtr * @prefix: the prefix whose namespace URI is to be resolved. To return * the default namespace, specify NULL * * Resolves a namespace prefix in the scope of the current element. * * Returns a string containing the namespace URI to which the prefix maps * or NULL in case of error. The string must be deallocated by the caller. */ xmlChar * xmlDocWalkerLookupNamespace(xmlDocWalkerPtr iter, const xmlChar *prefix) { xmlNsPtr ns; if ((iter == 0) || (iter->node == 0)) return 0; ns = xmlSearchNs(iter->node->doc, iter->node, prefix); if (ns == NULL) return(NULL); return(xmlStrdup(ns->href)); } /** * xmlDocWalkerMoveToAttributeNo: * @iter: the xmlDocWalkerPtr * @no: the zero-based index of the attribute relative to the containing * element. * * Moves the position of the current instance to the attribute with * the specified index relative to the containing element. * * Returns 1 in case of success, -1 in case of error, 0 if not found */ int xmlDocWalkerMoveToAttributeNo(xmlDocWalkerPtr iter, int no) { int i; xmlAttrPtr cur; xmlNsPtr ns; if ((iter == 0) || (iter->node == 0)) return -1; if ((iter->state == XML_DWALK_NONE) || (iter->state == XML_DWALK_BACKTRACK) || (iter->state == XML_DWALK_END)) return 0; if (iter->node->type != XML_ELEMENT_NODE) return 0; iter->curnode = NULL; ns = iter->node->nsDef; for (i = 0; i < no && ns != NULL; i++) ns = ns->next; if (ns != 0) { iter->curnode = (xmlNodePtr) ns; return 1; } cur = iter->node->properties; if (cur == 0) return 0; for (; i < no; i++) { cur = cur->next; if(cur == 0) return 0; } iter->curnode = (xmlNodePtr) cur; return 1; } /** * xmlDocWalkerMoveToAttribute: * @iter: the xmlDocWalkerPtr * @name: the qualified name of the attribute. * * Moves the position of the current instance to the attribute with * the specified qualified name. * * Returns 1 in case of success, -1 in case of error, 0 if not found */ int xmlDocWalkerMoveToAttribute(xmlDocWalkerPtr iter, const xmlChar *name) { xmlChar *prefix = NULL; xmlChar *localname = NULL; xmlNsPtr ns; xmlAttrPtr prop; int ret = 0; if ((iter == 0) || (iter->node == 0) || (name == 0)) return -1; if ((iter->state == XML_DWALK_NONE) || (iter->state == XML_DWALK_BACKTRACK) || (iter->state == XML_DWALK_END)) goto not_found; if (iter->node->type != XML_ELEMENT_NODE) goto not_found; localname = xmlSplitQName2(name, &prefix); if (localname == 0) { if (xmlStrEqual(name, BAD_CAST "xmlns")) { ns = iter->node->nsDef; while (ns != 0) { if (ns->prefix == 0) { iter->curnode = (xmlNodePtr) ns; goto found; } ns = ns->next; } goto not_found; } prop = iter->node->properties; while (prop != 0) { if (xmlStrEqual(prop->name, name) && ((prop->ns == NULL) || (prop->ns->prefix == NULL))) { iter->curnode = (xmlNodePtr) prop; goto found; } prop = prop->next; } goto not_found; } if (xmlStrEqual(prefix, BAD_CAST "xmlns")) { ns = iter->node->nsDef; while (ns != 0) { if (ns->prefix != NULL && xmlStrEqual(ns->prefix, localname)) { iter->curnode = (xmlNodePtr) ns; goto found; } ns = ns->next; } goto not_found; } prop = iter->node->properties; while (prop != NULL) { if (xmlStrEqual(prop->name, localname) && (prop->ns != NULL) && xmlStrEqual(prop->ns->prefix, prefix)) { iter->curnode = (xmlNodePtr) prop; goto found; } prop = prop->next; } if (0) found: { ret = 1; } not_found: if (localname != 0) xmlFree(localname); if (prefix != 0) xmlFree(prefix); return ret; } /** * xmlDocWalkerMoveToAttributeNs: * @iter: the xmlDocWalkerPtr * @localName: the local name of the attribute. * @namespaceURI: the namespace URI of the attribute. * * Moves the position of the current instance to the attribute with the * specified local name and namespace URI. * * Returns 1 in case of success, -1 in case of error, 0 if not found */ int xmlDocWalkerMoveToAttributeNs(xmlDocWalkerPtr iter, const xmlChar *localName, const xmlChar *namespaceURI) { xmlAttrPtr prop; xmlNodePtr node; if ((iter == 0) || (iter->node == 0) || (localName == 0) || (namespaceURI == 0)) return -1; if ((iter->state == XML_DWALK_NONE) || (iter->state == XML_DWALK_BACKTRACK) || (iter->state == XML_DWALK_END)) return 0; if (iter->node->type != XML_ELEMENT_NODE) return 0; node = iter->node; prop = node->properties; while (prop != NULL) { if (xmlStrEqual(prop->name, localName) && ((prop->ns != NULL) && (xmlStrEqual(prop->ns->href, namespaceURI)))) { iter->curnode = (xmlNodePtr) prop; return 1; } prop = prop->next; } return 0; } /** * xmlDocWalkerMoveToFirstAttribute: * @iter: the xmlDocWalkerPtr * * Moves the position of the current instance to the first attribute * associated with the current node. * * Returns 1 in case of success, -1 in case of error, 0 if not found */ int xmlDocWalkerMoveToFirstAttribute(xmlDocWalkerPtr iter) { if ((iter == 0) || (iter->node == 0)) return -1; if ((iter->state == XML_DWALK_NONE) || (iter->state == XML_DWALK_BACKTRACK) || (iter->state == XML_DWALK_END)) return 0; if (iter->node->type != XML_ELEMENT_NODE) return 0; if (iter->node->nsDef != NULL) { iter->curnode = (xmlNodePtr) iter->node->nsDef; return 1; } if (iter->node->properties != NULL) { iter->curnode = (xmlNodePtr) iter->node->properties; return 1; } return 0; } /** * xmlDocWalkerMoveToNextAttribute: * @iter: the xmlDocWalkerPtr * * Moves the position of the current instance to the next attribute * associated with the current node. * * Returns 1 in case of success, -1 in case of error, 0 if not found */ int xmlDocWalkerMoveToNextAttribute(xmlDocWalkerPtr iter) { if ((iter == 0) || (iter->node == 0)) return -1; if ((iter->state == XML_DWALK_NONE) || (iter->state == XML_DWALK_BACKTRACK) || (iter->state == XML_DWALK_END)) return 0; if (iter->node->type != XML_ELEMENT_NODE) return 0; if (iter->curnode == NULL) return(xmlDocWalkerMoveToFirstAttribute(iter)); if (iter->curnode->type == XML_NAMESPACE_DECL) { xmlNsPtr ns = (xmlNsPtr) iter->curnode; if (ns->next != NULL) { iter->curnode = (xmlNodePtr) ns->next; return 1; } if (iter->node->properties != NULL) { iter->curnode = (xmlNodePtr) iter->node->properties; return 1; } return 0; } else if ((iter->curnode->type == XML_ATTRIBUTE_NODE) && (iter->curnode->next != NULL)) { iter->curnode = iter->curnode->next; return 1; } return 0; } /** * xmlDocWalkerMoveToElement: * @iter: the xmlDocWalkerPtr * * Moves the position of the current instance to the node that * contains the current Attribute node. * * Returns 1 in case of success, -1 in case of error, 0 if not moved */ int xmlDocWalkerMoveToElement(xmlDocWalkerPtr iter) { if ((iter == 0) || (iter->node == 0)) return -1; if ((iter->state == XML_DWALK_NONE) || (iter->state == XML_DWALK_BACKTRACK) || (iter->state == XML_DWALK_END)) return 0; if (iter->node->type != XML_ELEMENT_NODE) return 0; if (iter->curnode != NULL) { iter->curnode = NULL; return 1; } return 0; } /** * xmlDocWalkerCurrentNode: * @iter: the xmlDocWalkerPtr * * Hacking interface allowing to get the xmlNodePtr correponding to the * current node being accessed by the xmlDocWalker. * * Returns the xmlNodePtr or NULL in case of error. */ xmlNodePtr xmlDocWalkerCurrentNode(xmlDocWalkerPtr iter) { if (iter == 0) return 0; if (iter->curnode != NULL) return iter->curnode; return iter->node; } /** * xmlDocWalkerCurrentDoc: * @iter: the xmlDocWalkerPtr * * Hacking interface allowing to get the xmlDocPtr correponding to the * current document being accessed by the xmlDocWalker. * * Returns the xmlDocPtr or NULL in case of error. */ xmlDocPtr xmlDocWalkerCurrentDoc(xmlDocWalkerPtr iter) { if (iter == 0) return 0; return iter->doc; } --=-184Sj90WB6dNVHigRX4R Content-Disposition: attachment; filename=xmldwalk.h Content-Type: text/x-c-header; name=xmldwalk.h; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit /* * xmldwalk.h : Interfaces, constants and types of the document traversing API.for XML * * this is heavily based upon the xmlTextReader streaming node API * of libxml2 by Daniel Veillard (daniel@veillard.com). In fact I * just copied and modified xmlreader.h * * So for license and disclaimer see the license and disclaimer of * libxml2. * * alfred@mickautsch.de */ #ifndef __XML_XMLDWALK_H__ #define __XML_XMLDWALK_H__ #ifdef __cplusplus extern "C" { #endif typedef enum { XML_DWALK_NONE = 0, XML_DWALK_START, XML_DWALK_BACKTRACK, XML_DWALK_END } xmlDocWalkerState; typedef struct _xmlDocWalker { xmlDocPtr doc; /* current document */ xmlNodePtr node; /* current node */ xmlNodePtr curnode; /* current attribute node */ int depth; /* depth of the current node */ xmlDocWalkerState state; /* state of the iterator */ } xmlDocWalker; typedef xmlDocWalker *xmlDocWalkerPtr; /* * Constructor & Destructor */ xmlDocWalkerPtr xmlNewDocWalker(xmlDocPtr doc); void xmlFreeDocWalker(xmlDocWalkerPtr iter); /* * Iterator Functions */ int xmlDocWalkerRewind(xmlDocWalkerPtr iter); int xmlDocWalkerStep(xmlDocWalkerPtr iter); int xmlDocWalkerAttributeCount(xmlDocWalkerPtr iter); int xmlDocWalkerDepth(xmlDocWalkerPtr iter); int xmlDocWalkerHasAttributes(xmlDocWalkerPtr iter); int xmlDocWalkerHasValue(xmlDocWalkerPtr iter); int xmlDocWalkerIsEmptyElement(xmlDocWalkerPtr iter); xmlChar *xmlDocWalkerLocalName(xmlDocWalkerPtr iter); xmlChar *xmlDocWalkerName(xmlDocWalkerPtr iter); int xmlDocWalkerNodeType(xmlDocWalkerPtr iter); xmlChar *xmlDocWalkerPrefix(xmlDocWalkerPtr iter); xmlChar *xmlDocWalkerNamespaceUri(xmlDocWalkerPtr iter); xmlChar *xmlDocWalkerBaseUri(xmlDocWalkerPtr iter); xmlChar *xmlDocWalkerValue(xmlDocWalkerPtr iter); xmlChar *xmlDocWalkerGetAttributeNo(xmlDocWalkerPtr iter, int no); xmlChar *xmlDocWalkerGetAttribute(xmlDocWalkerPtr iter, const xmlChar *name); xmlChar *xmlDocWalkerGetAttributeNs(xmlDocWalkerPtr iter, const xmlChar *localName, const xmlChar *namespaceURI); xmlChar *xmlDocWalkerLookupNamespace(xmlDocWalkerPtr iter, const xmlChar *prefix); int xmlDocWalkerMoveToAttributeNo(xmlDocWalkerPtr iter, int no); int xmlDocWalkerMoveToAttribute(xmlDocWalkerPtr iter, const xmlChar *name); int xmlDocWalkerMoveToAttributeNs(xmlDocWalkerPtr iter, const xmlChar *localName, const xmlChar *namespaceURI); int xmlDocWalkerMoveToFirstAttribute(xmlDocWalkerPtr iter); int xmlDocWalkerMoveToNextAttribute(xmlDocWalkerPtr iter); int xmlDocWalkerMoveToElement(xmlDocWalkerPtr iter); xmlNodePtr xmlDocWalkerCurrentNode(xmlDocWalkerPtr iter); xmlDocPtr xmlDocWalkerCurrentDoc(xmlDocWalkerPtr iter); #ifdef __cplusplus } //extern "C" #endif #endif /* __XML_XMLDWALK_H__ */ --=-184Sj90WB6dNVHigRX4R-- From alfred.mickautsch@schuler-ag.com Fri Oct 3 09:00:39 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail-relay1 (mail-relay1.schuler-ag.com [62.156.183.20]) by mail.gnome.org (Postfix) with ESMTP id 5586B187AF for ; Fri, 3 Oct 2003 09:00:39 -0400 (EDT) Received: from sbs-proxy-test.schuler-ag.com ([192.168.16.254]) by mail-relay1 with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Oct 2003 15:05:21 +0200 Received: from mail pickup service by sbs-proxy-test.schuler-ag.com with Microsoft SMTPSVC; Fri, 3 Oct 2003 15:00:51 +0200 Content-Type: multipart/mixed; boundary="----=_NextPart_000_23A61_01C389BF.22FC6130" Received: from pandora.schuler-ag.com ([192.168.16.20]) by sbs-proxy-test.schuler-ag.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Oct 2003 15:00:50 +0200 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: AW: [xml] WG: Document traversing interface for libxml2 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Date: Fri, 3 Oct 2003 15:00:50 +0200 Message-ID: <4F38C8B9DAB1014DBDCB29538BBFD6A128507E@pandora.schuler-ag.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [xml] WG: Document traversing interface for libxml2 thread-index: AcOJKnHX0gBdLZXpQb6qREf8rw3lkQAg4QAwAABTfZA= From: "Mickautsch, Alfred" To: X-OriginalArrivalTime: 03 Oct 2003 13:00:50.0802 (UTC) FILETIME=[5F058D20:01C389AE] Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_23A61_01C389BF.22FC6130 x-gfisavedcharset: iso-8859-1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ooops, forgot the patch :-) > -----Urspr=FCngliche Nachricht----- > Von: Mickautsch, Alfred=20 > Gesendet: Freitag, 3. Oktober 2003 14:55 > An: xml@gnome.org > Betreff: AW: [xml] WG: Document traversing interface for libxml2 >=20 >=20 > Bjorn, > ... > >=20 > > >From a brief glance at the walker interface, I must say that I > > like it. > ... > > Suggestion: You may consider adding a xmlDocWalkerNext() that > > moves to the next sibling, just like xmlTextReaderNext(). > Thanks, see the attached patch for xmlTextReaderNext and some=20 > cleanup of the code. >=20 > Servus -- Alfred >=20 >=20 >=20 > _______________________________________________ > xml mailing list, project page http://xmlsoft.org/ > xml@gnome.org > http://mail.gnome.org/mailman/listinfo/xml >=20 ------=_NextPart_000_23A61_01C389BF.22FC6130 Content-Disposition: attachment; filename="xmldwalk.diff" Content-Description: xmldwalk.diff Content-Type: application/octet-stream; name="xmldwalk.diff"; name="xmldwalk.diff" Content-Transfer-Encoding: base64 LS0tIHhtbGR3YWxrfi5jCVRodSBPY3QgIDIgMTU6NDg6NTQgMjAwMw0KKysrIHhtbGR3YWxrLmMJ RnJpIE9jdCAgMyAxMTo0NTowNSAyMDAzDQpAQCAtODUsNiArODUsNyBAQA0KIAlpdGVyLT5zdGF0 ZSA9IFhNTF9EV0FMS19OT05FOw0KIAlpdGVyLT5kZXB0aCA9IDA7DQogCWl0ZXItPm5vZGUgPSAw Ow0KKwlpdGVyLT5jdXJub2RlID0gMDsNCiANCiAJcmV0dXJuIDE7DQogfQ0KQEAgLTEwNiw3ICsx MDcsNyBAQA0KIAlpZihpdGVyLT5zdGF0ZSA9PSBYTUxfRFdBTEtfRU5EKQ0KIAkJcmV0dXJuIDA7 DQogDQotCWlmKGl0ZXItPm5vZGUgPT0gMCAmJiBpdGVyLT5zdGF0ZSAhPSBYTUxfRFdBTEtfRU5E KQ0KKwlpZihpdGVyLT5ub2RlID09IDApDQogCXsNCiAJCWlmKGl0ZXItPmRvYy0+Y2hpbGRyZW4g PT0gMCkNCiAJCXsNCkBAIC0xMTksNyArMTIwLDcgQEANCiAJCXJldHVybiAxOw0KIAl9DQogDQot CWlmKGl0ZXItPnN0YXRlICE9IFhNTF9EV0FMS19CQUNLVFJBQ0sgJiYgaXRlci0+c3RhdGUgIT0g WE1MX0RXQUxLX0VORCkNCisJaWYoaXRlci0+c3RhdGUgIT0gWE1MX0RXQUxLX0JBQ0tUUkFDSykN CiAJew0KIAkJaWYoaXRlci0+bm9kZS0+Y2hpbGRyZW4gIT0gMCkNCiAJCXsNCkBAIC0xMzYsMTQg KzEzNywxNCBAQA0KIAkJfQ0KIAl9DQogDQotCWlmKGl0ZXItPm5vZGUtPm5leHQgIT0gMCAmJiBp dGVyLT5zdGF0ZSAhPSBYTUxfRFdBTEtfRU5EKQ0KKwlpZihpdGVyLT5ub2RlLT5uZXh0ICE9IDAp DQogCXsNCiAJCWl0ZXItPm5vZGUgPSBpdGVyLT5ub2RlLT5uZXh0Ow0KIAkJaXRlci0+c3RhdGUg PSBYTUxfRFdBTEtfU1RBUlQ7DQogCQlyZXR1cm4gMTsNCiAJfQ0KIA0KLQlpZihpdGVyLT5ub2Rl LT5wYXJlbnQgIT0gMCAmJiBpdGVyLT5zdGF0ZSAhPSBYTUxfRFdBTEtfRU5EKQ0KKwlpZihpdGVy LT5ub2RlLT5wYXJlbnQgIT0gMCkNCiAJew0KIAkJaWYoaXRlci0+bm9kZS0+cGFyZW50LT50eXBl ID09IFhNTF9ET0NVTUVOVF9OT0RFKQ0KIAkJew0KQEAgLTExNzYsNCArMTE3NywzNSBAQA0KIAkJ cmV0dXJuIDA7DQogDQogCXJldHVybiBpdGVyLT5kb2M7DQorfQ0KKw0KKy8qKg0KKyAqIHhtbERv Y1dhbGtlck5leHQ6DQorICogQGl0ZXI6ICB0aGUgeG1sRG9jV2Fsa2VyUHRyDQorICoNCisgKiBT dGVwIHRvIHRoZSBuZXh0IHNpYmxpbmcgb2YgdGhlIGN1cnJlbnQgbm9kZSBpbiBkb2N1bWVudCBv cmRlcg0KKyAqDQorICogUmV0dXJucyAxIGlmIG9rLCAwIGlmIHRoZXJlIGFyZSBubyBtb3JlIG5v ZGVzLCBvciAtMSBpbiBjYXNlIG9mIGVycm9yDQorICovDQoraW50DQoreG1sRG9jV2Fsa2VyTmV4 dCgNCisJeG1sRG9jV2Fsa2VyUHRyIGl0ZXIpDQorew0KKwlpZihpdGVyID09IDAgfHwgaXRlci0+ ZG9jID09IDApDQorCQlyZXR1cm4gLTE7DQorDQorCWlmKGl0ZXItPnN0YXRlID09IFhNTF9EV0FM S19FTkQpDQorCQlyZXR1cm4gMDsNCisNCisJaWYoaXRlci0+bm9kZSA9PSAwKQ0KKwkJcmV0dXJu IHhtbERvY1dhbGtlclN0ZXAoaXRlcik7DQorDQorCWlmKGl0ZXItPm5vZGUtPm5leHQgIT0gMCkN CisJew0KKwkJaXRlci0+bm9kZSA9IGl0ZXItPm5vZGUtPm5leHQ7DQorCQlpdGVyLT5zdGF0ZSA9 IFhNTF9EV0FMS19TVEFSVDsNCisJCXJldHVybiAxOw0KKwl9DQorDQorCXJldHVybiAwOw0KIH0N Ci0tLSB4bWxkd2Fsa34uaAlUaHUgT2N0ICAyIDE1OjQ5OjA0IDIwMDMNCisrKyB4bWxkd2Fsay5o CUZyaSBPY3QgIDMgMTA6NDE6MjYgMjAwMw0KQEAgLTc1LDYgKzc1LDcgQEANCiANCiB4bWxOb2Rl UHRyCXhtbERvY1dhbGtlckN1cnJlbnROb2RlKHhtbERvY1dhbGtlclB0ciBpdGVyKTsNCiB4bWxE b2NQdHIJeG1sRG9jV2Fsa2VyQ3VycmVudERvYyh4bWxEb2NXYWxrZXJQdHIgaXRlcik7DQoraW50 CQl4bWxEb2NXYWxrZXJOZXh0KHhtbERvY1dhbGtlclB0ciBpdGVyKTsNCiANCiAjaWZkZWYgX19j cGx1c3BsdXMNCiB9CS8vZXh0ZXJuICJDIg0K ------=_NextPart_000_23A61_01C389BF.22FC6130-- From alfred.mickautsch@schuler-ag.com Fri Oct 3 09:30:17 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail-relay1 (mail-relay1.schuler-ag.com [62.156.183.20]) by mail.gnome.org (Postfix) with ESMTP id 1A962182C7 for ; Fri, 3 Oct 2003 09:30:15 -0400 (EDT) Received: from sbs-proxy-test.schuler-ag.com ([192.168.16.254]) by mail-relay1 with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Oct 2003 15:34:57 +0200 Received: from mail pickup service by sbs-proxy-test.schuler-ag.com with Microsoft SMTPSVC; Fri, 3 Oct 2003 15:30:27 +0200 Content-Type: multipart/mixed; boundary="----=_NextPart_000_23B47_01C389C3.456C0140" Received: from pandora.schuler-ag.com ([192.168.16.20]) by sbs-proxy-test.schuler-ag.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Oct 2003 15:30:24 +0200 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: WG: [xml] WG: Document traversing interface for libxml2 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Date: Fri, 3 Oct 2003 15:30:24 +0200 Message-ID: <4F38C8B9DAB1014DBDCB29538BBFD6A1285080@pandora.schuler-ag.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [xml] WG: Document traversing interface for libxml2 thread-index: AcOJrlb148lsB0/dTRSY4IbYMjpfgAABDU1wAAAz+HA= From: "Mickautsch, Alfred" To: X-OriginalArrivalTime: 03 Oct 2003 13:30:24.0149 (UTC) FILETIME=[8004D450:01C389B2] Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_23B47_01C389C3.456C0140 x-gfisavedcharset: iso-8859-1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you Bjorn, since I just sent a patch for the original to the list, here is your = version with the patch I just sent. > -----Urspr=FCngliche Nachricht----- > Von: Bjorn Reese [mailto:breese@mail1.stofanet.dk] > Gesendet: Freitag, 3. Oktober 2003 15:02 > An: xml@gnome.org > Betreff: Re: [xml] WG: Document traversing interface for libxml2 >=20 >=20 > On Fri, 2003-10-03 at 00:16, Daniel Veillard wrote: >=20 > > Bjorn, since you seem to have looked at it can you share > > some review of the code. If relatively small that could be useful > > as a tree API. >=20 > Overall the code is well-written. I find it useful as a tree API. > Now we just need xmlTextWriter and its equivalence for the tree API. >=20 > There were an error in xmlDocWalkerMoveToAttribute were a null > pointer was freed. I have fixed this, and furthermore added a little > extra error handling. >=20 > I have also made some cosmetic changes to make the code more in line > with the rest of the libxml code (e.g. converting tab to 8.) >=20 > There is one unresolved issue: depends on > for types. >=20 > Modified version of xmldwalk is attached. >=20 >=20 ------=_NextPart_000_23B47_01C389C3.456C0140 Content-Disposition: attachment; filename="xmldwalk.h" Content-Description: xmldwalk.h Content-Type: application/octet-stream; name="xmldwalk.h"; name="xmldwalk.h" Content-Transfer-Encoding: base64 LyoNCiAqIHhtbGR3YWxrLmggOiBJbnRlcmZhY2VzLCBjb25zdGFudHMgYW5kIHR5cGVzIG9mIHRo ZSBkb2N1bWVudCB0cmF2ZXJzaW5nIEFQSS5mb3IgWE1MDQogKg0KICogdGhpcyBpcyBoZWF2aWx5 IGJhc2VkIHVwb24gdGhlIHhtbFRleHRSZWFkZXIgc3RyZWFtaW5nIG5vZGUgQVBJDQogKiBvZiBs aWJ4bWwyIGJ5IERhbmllbCBWZWlsbGFyZCAoZGFuaWVsQHZlaWxsYXJkLmNvbSkuIEluIGZhY3Qg SQ0KICoganVzdCBjb3BpZWQgYW5kIG1vZGlmaWVkIHhtbHJlYWRlci5oDQogKg0KICogU28gZm9y IGxpY2Vuc2UgYW5kIGRpc2NsYWltZXIgc2VlIHRoZSBsaWNlbnNlIGFuZCBkaXNjbGFpbWVyIG9m DQogKiBsaWJ4bWwyLg0KICoNCiAqIGFsZnJlZEBtaWNrYXV0c2NoLmRlDQogKi8NCg0KI2lmbmRl ZiBfX1hNTF9YTUxEV0FMS19IX18NCiNkZWZpbmUgX19YTUxfWE1MRFdBTEtfSF9fDQoNCiNpZmRl ZiBfX2NwbHVzcGx1cw0KZXh0ZXJuICJDIiB7DQojZW5kaWYNCg0KdHlwZWRlZiBlbnVtIHsNCiAg ICBYTUxfRFdBTEtfTk9ORSA9IDAsDQogICAgWE1MX0RXQUxLX1NUQVJULA0KICAgIFhNTF9EV0FM S19CQUNLVFJBQ0ssDQogICAgWE1MX0RXQUxLX0VORA0KfSB4bWxEb2NXYWxrZXJTdGF0ZTsNCg0K dHlwZWRlZiBzdHJ1Y3QgX3htbERvY1dhbGtlciB7DQogICAgeG1sRG9jUHRyCQlkb2M7CS8qIGN1 cnJlbnQgZG9jdW1lbnQgKi8NCiAgICB4bWxOb2RlUHRyCQlub2RlOwkvKiBjdXJyZW50IG5vZGUg Ki8NCiAgICB4bWxOb2RlUHRyCQljdXJub2RlOwkvKiBjdXJyZW50IGF0dHJpYnV0ZSBub2RlICov DQogICAgaW50CQkJZGVwdGg7ICAvKiBkZXB0aCBvZiB0aGUgY3VycmVudCBub2RlICovDQogICAg eG1sRG9jV2Fsa2VyU3RhdGUJc3RhdGU7CS8qIHN0YXRlIG9mIHRoZSBpdGVyYXRvciAqLw0KfSB4 bWxEb2NXYWxrZXI7DQoNCnR5cGVkZWYgeG1sRG9jV2Fsa2VyICp4bWxEb2NXYWxrZXJQdHI7DQoN Ci8qDQogKiBDb25zdHJ1Y3RvciAmIERlc3RydWN0b3INCiAqLw0KeG1sRG9jV2Fsa2VyUHRyCXht bE5ld0RvY1dhbGtlcih4bWxEb2NQdHIgZG9jKTsNCnZvaWQgeG1sRnJlZURvY1dhbGtlcih4bWxE b2NXYWxrZXJQdHIgaXRlcik7DQoNCi8qDQogKiBJdGVyYXRvciBGdW5jdGlvbnMNCiAqLw0KaW50 CXhtbERvY1dhbGtlclJld2luZCh4bWxEb2NXYWxrZXJQdHIgaXRlcik7DQppbnQJeG1sRG9jV2Fs a2VyU3RlcCh4bWxEb2NXYWxrZXJQdHIgaXRlcik7DQoNCmludAl4bWxEb2NXYWxrZXJBdHRyaWJ1 dGVDb3VudCh4bWxEb2NXYWxrZXJQdHIgaXRlcik7DQppbnQJeG1sRG9jV2Fsa2VyRGVwdGgoeG1s RG9jV2Fsa2VyUHRyIGl0ZXIpOw0KaW50CXhtbERvY1dhbGtlckhhc0F0dHJpYnV0ZXMoeG1sRG9j V2Fsa2VyUHRyIGl0ZXIpOw0KaW50CXhtbERvY1dhbGtlckhhc1ZhbHVlKHhtbERvY1dhbGtlclB0 ciBpdGVyKTsNCmludAl4bWxEb2NXYWxrZXJJc0VtcHR5RWxlbWVudCh4bWxEb2NXYWxrZXJQdHIg aXRlcik7DQp4bWxDaGFyICp4bWxEb2NXYWxrZXJMb2NhbE5hbWUoeG1sRG9jV2Fsa2VyUHRyIGl0 ZXIpOw0KeG1sQ2hhciAqeG1sRG9jV2Fsa2VyTmFtZSh4bWxEb2NXYWxrZXJQdHIgaXRlcik7DQpp bnQJeG1sRG9jV2Fsa2VyTm9kZVR5cGUoeG1sRG9jV2Fsa2VyUHRyIGl0ZXIpOw0KeG1sQ2hhciAq eG1sRG9jV2Fsa2VyUHJlZml4KHhtbERvY1dhbGtlclB0ciBpdGVyKTsNCnhtbENoYXIgKnhtbERv Y1dhbGtlck5hbWVzcGFjZVVyaSh4bWxEb2NXYWxrZXJQdHIgaXRlcik7DQp4bWxDaGFyICp4bWxE b2NXYWxrZXJCYXNlVXJpKHhtbERvY1dhbGtlclB0ciBpdGVyKTsNCnhtbENoYXIgKnhtbERvY1dh bGtlclZhbHVlKHhtbERvY1dhbGtlclB0ciBpdGVyKTsNCg0KeG1sQ2hhciAqeG1sRG9jV2Fsa2Vy R2V0QXR0cmlidXRlTm8oeG1sRG9jV2Fsa2VyUHRyIGl0ZXIsIGludCBubyk7DQp4bWxDaGFyICp4 bWxEb2NXYWxrZXJHZXRBdHRyaWJ1dGUoeG1sRG9jV2Fsa2VyUHRyIGl0ZXIsIGNvbnN0IHhtbENo YXIgKm5hbWUpOw0KeG1sQ2hhciAqeG1sRG9jV2Fsa2VyR2V0QXR0cmlidXRlTnMoeG1sRG9jV2Fs a2VyUHRyIGl0ZXIsIGNvbnN0IHhtbENoYXIgKmxvY2FsTmFtZSwgY29uc3QgeG1sQ2hhciAqbmFt ZXNwYWNlVVJJKTsNCnhtbENoYXIgKnhtbERvY1dhbGtlckxvb2t1cE5hbWVzcGFjZSh4bWxEb2NX YWxrZXJQdHIgaXRlciwgY29uc3QgeG1sQ2hhciAqcHJlZml4KTsNCmludAl4bWxEb2NXYWxrZXJN b3ZlVG9BdHRyaWJ1dGVObyh4bWxEb2NXYWxrZXJQdHIgaXRlciwgaW50IG5vKTsNCmludAl4bWxE b2NXYWxrZXJNb3ZlVG9BdHRyaWJ1dGUoeG1sRG9jV2Fsa2VyUHRyIGl0ZXIsIGNvbnN0IHhtbENo YXIgKm5hbWUpOw0KaW50CXhtbERvY1dhbGtlck1vdmVUb0F0dHJpYnV0ZU5zKHhtbERvY1dhbGtl clB0ciBpdGVyLCBjb25zdCB4bWxDaGFyICpsb2NhbE5hbWUsIGNvbnN0IHhtbENoYXIgKm5hbWVz cGFjZVVSSSk7DQppbnQJeG1sRG9jV2Fsa2VyTW92ZVRvRmlyc3RBdHRyaWJ1dGUoeG1sRG9jV2Fs a2VyUHRyIGl0ZXIpOw0KaW50CXhtbERvY1dhbGtlck1vdmVUb05leHRBdHRyaWJ1dGUoeG1sRG9j V2Fsa2VyUHRyIGl0ZXIpOw0KaW50CXhtbERvY1dhbGtlck1vdmVUb0VsZW1lbnQoeG1sRG9jV2Fs a2VyUHRyIGl0ZXIpOw0KDQp4bWxOb2RlUHRyIHhtbERvY1dhbGtlckN1cnJlbnROb2RlKHhtbERv Y1dhbGtlclB0ciBpdGVyKTsNCnhtbERvY1B0ciB4bWxEb2NXYWxrZXJDdXJyZW50RG9jKHhtbERv Y1dhbGtlclB0ciBpdGVyKTsNCmludCB4bWxEb2NXYWxrZXJOZXh0KHhtbERvY1dhbGtlclB0ciBp dGVyKTsNCg0KI2lmZGVmIF9fY3BsdXNwbHVzDQp9CS8vZXh0ZXJuICJDIg0KI2VuZGlmDQoNCiNl bmRpZiAvKiBfX1hNTF9YTUxEV0FMS19IX18gKi8NCg== ------=_NextPart_000_23B47_01C389C3.456C0140 Content-Disposition: attachment; filename="xmldwalk.c" Content-Description: xmldwalk.c Content-Type: application/octet-stream; name="xmldwalk.c"; name="xmldwalk.c" Content-Transfer-Encoding: base64 LyoNCiAqIHhtbGR3YWxrLmMgOiB0aGUgZG9jdW1lbnQgdHJhdmVyc2luZyBBUEkuZm9yIFhNTCAN CiAqDQogKiB0aGlzIGlzIGhlYXZpbHkgYmFzZWQgdXBvbiB0aGUgeG1sVGV4dFJlYWRlciBzdHJl YW1pbmcgbm9kZSBBUEkNCiAqIG9mIGxpYnhtbDIgYnkgRGFuaWVsIFZlaWxsYXJkIChkYW5pZWxA dmVpbGxhcmQuY29tKS4gSW4gZmFjdCBJDQogKiBqdXN0IGNvcGllZCBhbmQgbW9kaWZpZWQgeG1s cmVhZGVyLmMNCiAqDQogKiBTbyBmb3IgbGljZW5zZSBhbmQgZGlzY2xhaW1lciBzZWUgdGhlIGxp Y2Vuc2UgYW5kIGRpc2NsYWltZXIgb2YNCiAqIGxpYnhtbDIuDQogKg0KICogYWxmcmVkQG1pY2th dXRzY2guZGUNCiAqLw0KDQoNCiNpbmNsdWRlIDxzdHJpbmcuaD4NCg0KI2luY2x1ZGUgPGxpYnht bC94bWxtZW1vcnkuaD4NCiNpbmNsdWRlIDxsaWJ4bWwveG1sSU8uaD4NCiNpbmNsdWRlIDxsaWJ4 bWwveG1scmVhZGVyLmg+DQojaW5jbHVkZSA8bGlieG1sL3htbGR3YWxrLmg+DQoNCi8qKg0KICog eG1sTmV3RG9jV2Fsa2VyOg0KICogQGRvYzogIHRoZSB4bWxEb2NQdHINCiAqDQogKiBDcmVhdGVz IGEgbmV3IGluc3RhbmNlIG9mIHRoZSB4bWxEb2NXYWxrZXINCiAqDQogKiBSZXR1cm5zIDAgaW4g Y2FzZSBvZiBlcnJvciwgdGhlIG5ldyBhbGxvY2F0ZWQgeG1sRG9jV2Fsa2VyUHRyIG90aGVyd2lz ZQ0KICovDQp4bWxEb2NXYWxrZXJQdHINCnhtbE5ld0RvY1dhbGtlcih4bWxEb2NQdHIgZG9jKQ0K ew0KICAgIHhtbERvY1dhbGtlclB0ciByZXQ7DQoNCiAgICBpZiAoZG9jID09IDApDQoJcmV0dXJu IDA7DQoNCiAgICByZXQgPSB4bWxNYWxsb2Moc2l6ZW9mKHhtbERvY1dhbGtlcikpOw0KICAgIGlm IChyZXQgPT0gMCkgew0KCXhtbEdlbmVyaWNFcnJvcih4bWxHZW5lcmljRXJyb3JDb250ZXh0LCAi eG1sTmV3RG9jV2Fsa2VyIDogbWFsbG9jIGZhaWxlZFxuIik7DQoJcmV0dXJuIDA7DQogICAgfQ0K DQogICAgbWVtc2V0KHJldCwgMCwgc2l6ZW9mKHhtbERvY1dhbGtlcikpOw0KDQogICAgcmV0LT5k b2MgPSBkb2M7DQogICAgcmV0LT5ub2RlID0gMDsNCiAgICByZXQtPnN0YXRlID0gWE1MX0RXQUxL X05PTkU7DQoNCiAgICByZXR1cm4gcmV0Ow0KfQ0KDQovKioNCiAqIHhtbEZyZWVEb2NXYWxrZXI6 DQogKiBAaXRlcjogIHRoZSB4bWxEb2NXYWxrZXJQdHINCiAqDQogKiBEZWFsbG9jYXRlIHRoZSB4 bWxEb2NXYWxrZXINCiAqLw0Kdm9pZA0KeG1sRnJlZURvY1dhbGtlcih4bWxEb2NXYWxrZXJQdHIg aXRlcikNCnsNCiAgICBpZiAoaXRlciAhPSAwKQ0KCXhtbEZyZWUoaXRlcik7DQp9DQoNCi8qKg0K ICogeG1sRG9jV2Fsa2VyUmV3aW5kOg0KICogQGl0ZXI6ICB0aGUgeG1sRG9jV2Fsa2VyUHRyDQog Kg0KICogSW5pdGlhbGl6ZXMgdGhlIHhtbERvY1dhbGtlcg0KICoNCiAqIFJldHVybnMgMCBvciAt MSBpbiBjYXNlIG9mIGVycm9yDQogKi8NCmludA0KeG1sRG9jV2Fsa2VyUmV3aW5kKHhtbERvY1dh bGtlclB0ciBpdGVyKQ0Kew0KICAgIGlmIChpdGVyID09IDAgfHwgaXRlci0+ZG9jID09IDApDQoJ cmV0dXJuIC0xOw0KDQogICAgaWYgKGl0ZXItPmRvYy0+Y2hpbGRyZW4gPT0gMCkNCglyZXR1cm4g MDsNCg0KICAgIGl0ZXItPnN0YXRlID0gWE1MX0RXQUxLX05PTkU7DQogICAgaXRlci0+ZGVwdGgg PSAwOw0KICAgIGl0ZXItPm5vZGUgPSAwOw0KDQogICAgcmV0dXJuIDE7DQp9DQoNCi8qKg0KICog eG1sRG9jV2Fsa2VyU3RlcDoNCiAqIEBpdGVyOiAgdGhlIHhtbERvY1dhbGtlclB0cg0KICoNCiAq IFN0ZXBzIHRocm91Z2ggdGhlIHhtbCB0cmVlDQogKg0KICogUmV0dXJucyAwIG9yIC0xIGluIGNh c2Ugb2YgZXJyb3INCiAqLw0KaW50DQp4bWxEb2NXYWxrZXJTdGVwKHhtbERvY1dhbGtlclB0ciBp dGVyKQ0Kew0KICAgIGlmIChpdGVyID09IDApDQoJcmV0dXJuIC0xOw0KDQogICAgaWYgKGl0ZXIt PnN0YXRlID09IFhNTF9EV0FMS19FTkQpDQoJcmV0dXJuIDA7DQoNCiAgICBpZiAoaXRlci0+bm9k ZSA9PSAwKSB7DQoJaWYgKGl0ZXItPmRvYy0+Y2hpbGRyZW4gPT0gMCkgew0KCSAgICBpdGVyLT5z dGF0ZSA9IFhNTF9EV0FMS19FTkQ7DQoJICAgIHJldHVybiAwOw0KCX0NCg0KCWl0ZXItPm5vZGUg PSBpdGVyLT5kb2MtPmNoaWxkcmVuOw0KCWl0ZXItPnN0YXRlID0gWE1MX0RXQUxLX1NUQVJUOw0K CXJldHVybiAxOw0KICAgIH0NCg0KICAgIGlmIChpdGVyLT5zdGF0ZSAhPSBYTUxfRFdBTEtfQkFD S1RSQUNLKSB7DQoJaWYgKGl0ZXItPm5vZGUtPmNoaWxkcmVuICE9IDApIHsNCgkgICAgaXRlci0+ bm9kZSA9IGl0ZXItPm5vZGUtPmNoaWxkcmVuOw0KCSAgICBpdGVyLT5kZXB0aCsrOw0KCSAgICBp dGVyLT5zdGF0ZSA9IFhNTF9EV0FMS19TVEFSVDsNCgkgICAgcmV0dXJuIDE7DQoJfQ0KDQoJaWYg KChpdGVyLT5ub2RlLT50eXBlID09IFhNTF9FTEVNRU5UX05PREUpIHx8DQoJICAgIChpdGVyLT5u b2RlLT50eXBlID09IFhNTF9BVFRSSUJVVEVfTk9ERSkpIHsNCgkgICAgaXRlci0+c3RhdGUgPSBY TUxfRFdBTEtfQkFDS1RSQUNLOw0KCSAgICByZXR1cm4gMTsNCgl9DQogICAgfQ0KDQogICAgaWYg KGl0ZXItPm5vZGUtPm5leHQgIT0gMCkgew0KCWl0ZXItPm5vZGUgPSBpdGVyLT5ub2RlLT5uZXh0 Ow0KCWl0ZXItPnN0YXRlID0gWE1MX0RXQUxLX1NUQVJUOw0KCXJldHVybiAxOw0KICAgIH0NCg0K ICAgIGlmIChpdGVyLT5ub2RlLT5wYXJlbnQgIT0gMCkgew0KCWlmIChpdGVyLT5ub2RlLT5wYXJl bnQtPnR5cGUgPT0gWE1MX0RPQ1VNRU5UX05PREUpIHsNCgkgICAgaXRlci0+c3RhdGUgPSBYTUxf RFdBTEtfRU5EOw0KCSAgICByZXR1cm4gMDsNCgl9DQoNCglpdGVyLT5ub2RlID0gaXRlci0+bm9k ZS0+cGFyZW50Ow0KCWl0ZXItPmRlcHRoLS07DQoJaXRlci0+c3RhdGUgPSBYTUxfRFdBTEtfQkFD S1RSQUNLOw0KCXJldHVybiAxOw0KICAgIH0NCg0KICAgIGl0ZXItPnN0YXRlID0gWE1MX0RXQUxL X0VORDsNCg0KICAgIHJldHVybiAxOw0KfQ0KDQovKioNCiAqIHhtbERvY1dhbGtlckF0dHJpYnV0 ZUNvdW50Og0KICogQGl0ZXI6ICB0aGUgeG1sRG9jV2Fsa2VyUHRyDQogKg0KICogUHJvdmlkZXMg dGhlIG51bWJlciBvZiBhdHRyaWJ1dGVzIG9mIHRoZSBjdXJyZW50IG5vZGUNCiAqDQogKiBSZXR1 cm5zIDAgaWYgbm8gYXR0cmlidXRlcywgLTEgaW4gY2FzZSBvZiBlcnJvciBvciB0aGUgYXR0cmli dXRlIGNvdW50DQogKi8NCmludA0KeG1sRG9jV2Fsa2VyQXR0cmlidXRlQ291bnQoeG1sRG9jV2Fs a2VyUHRyIGl0ZXIpDQp7DQogICAgaW50IHJldDsNCiAgICB4bWxBdHRyUHRyIGF0dHI7DQogICAg eG1sTnNQdHIgbnM7DQogICAgeG1sTm9kZVB0ciBub2RlOw0KDQogICAgaWYgKGl0ZXIgPT0gMCkN CglyZXR1cm4gLTE7DQoNCiAgICBpZiAoaXRlci0+bm9kZSA9PSAwKQ0KCXJldHVybiAwOw0KDQog ICAgaWYgKGl0ZXItPmN1cm5vZGUgIT0gMCkNCglub2RlID0gaXRlci0+Y3Vybm9kZTsNCiAgICBl bHNlDQoJbm9kZSA9IGl0ZXItPm5vZGU7DQoNCiAgICBpZiAobm9kZS0+dHlwZSAhPSBYTUxfRUxF TUVOVF9OT0RFKQ0KCXJldHVybiAwOw0KDQogICAgcmV0ID0gMDsNCiAgICBhdHRyID0gbm9kZS0+ cHJvcGVydGllczsNCiAgICB3aGlsZSAoYXR0ciAhPSAwKSB7DQoJcmV0Kys7DQoJYXR0ciA9IGF0 dHItPm5leHQ7DQogICAgfQ0KDQogICAgbnMgPSBub2RlLT5uc0RlZjsNCiAgICB3aGlsZSAobnMg IT0gMCkgew0KCXJldCsrOw0KCW5zID0gbnMtPm5leHQ7DQogICAgfQ0KDQogICAgcmV0dXJuIHJl dDsNCn0NCg0KLyoqDQogKiB4bWxEb2NXYWxrZXJEZXB0aDoNCiAqIEBpdGVyOiAgdGhlIHhtbERv Y1dhbGtlclB0cg0KICoNCiAqIFRoZSBkZXB0aCBvZiB0aGUgbm9kZSBpbiB0aGUgdHJlZS4NCiAq DQogKiBSZXR1cm5zIHRoZSBkZXB0aCBvciAtMSBpbiBjYXNlIG9mIGVycm9yDQogKi8NCmludA0K eG1sRG9jV2Fsa2VyRGVwdGgoeG1sRG9jV2Fsa2VyUHRyIGl0ZXIpDQp7DQogICAgaWYgKGl0ZXIg PT0gMCkNCglyZXR1cm4gLTE7DQoNCiAgICBpZiAoaXRlci0+bm9kZSA9PSAwKQ0KCXJldHVybiAw Ow0KDQogICAgaWYgKGl0ZXItPmN1cm5vZGUgIT0gMCkgew0KCWlmICgoaXRlci0+Y3Vybm9kZS0+ dHlwZSA9PSBYTUxfQVRUUklCVVRFX05PREUpIHx8DQoJICAgIChpdGVyLT5jdXJub2RlLT50eXBl ID09IFhNTF9OQU1FU1BBQ0VfREVDTCkpDQoJICAgIHJldHVybiBpdGVyLT5kZXB0aCArIDE7DQoJ DQoJcmV0dXJuIGl0ZXItPmRlcHRoICsgMjsNCiAgICB9DQoNCiAgICByZXR1cm4gaXRlci0+ZGVw dGg7DQp9DQoNCi8qKg0KICogeG1sRG9jV2Fsa2VySGFzQXR0cmlidXRlczoNCiAqIEBpdGVyOiAg dGhlIHhtbERvY1dhbGtlclB0cg0KICoNCiAqIFdoZXRoZXIgdGhlIG5vZGUgaGFzIGF0dHJpYnV0 ZXMuDQogKg0KICogUmV0dXJucyAxIGlmIHRydWUsIDAgaWYgZmFsc2UsIGFuZCAtMSBpbiBjYXNl IG9yIGVycm9yDQogKi8NCmludA0KeG1sRG9jV2Fsa2VySGFzQXR0cmlidXRlcyh4bWxEb2NXYWxr ZXJQdHIgaXRlcikNCnsNCiAgICB4bWxOb2RlUHRyIG5vZGU7DQoNCiAgICBpZiAoaXRlciA9PSAw KQ0KCXJldHVybiAtMTsNCg0KICAgIGlmIChpdGVyLT5ub2RlID09IDApDQoJcmV0dXJuIDA7DQoN CiAgICBpZiAoaXRlci0+Y3Vybm9kZSAhPSAwKQ0KCW5vZGUgPSBpdGVyIC0+Y3Vybm9kZTsNCiAg ICBlbHNlDQoJbm9kZSA9IGl0ZXIgLT5ub2RlOw0KDQogICAgaWYgKChub2RlLT50eXBlID09IFhN TF9FTEVNRU5UX05PREUpICYmIChub2RlLT5wcm9wZXJ0aWVzICE9IDApKQ0KCXJldHVybiAxOw0K DQogICAgcmV0dXJuIDA7DQp9DQoNCi8qKg0KICogeG1sRG9jV2Fsa2VySGFzVmFsdWU6DQogKiBA aXRlcjogIHRoZSB4bWxEb2NXYWxrZXJQdHINCiAqDQogKiBXaGV0aGVyIHRoZSBub2RlIGNhbiBo YXZlIGEgdGV4dCB2YWx1ZS4NCiAqDQogKiBSZXR1cm5zIDEgaWYgdHJ1ZSwgMCBpZiBmYWxzZSwg YW5kIC0xIGluIGNhc2Ugb3IgZXJyb3INCiAqLw0KaW50DQp4bWxEb2NXYWxrZXJIYXNWYWx1ZSh4 bWxEb2NXYWxrZXJQdHIgaXRlcikNCnsNCiAgICB4bWxOb2RlUHRyIG5vZGU7DQoNCiAgICBpZiAo aXRlciA9PSAwKQ0KCXJldHVybiAtMTsNCg0KICAgIGlmIChpdGVyLT5ub2RlID09IDApDQoJcmV0 dXJuIDA7DQoNCiAgICBpZiAoaXRlci0+Y3Vybm9kZSAhPSAwKQ0KCW5vZGUgPSBpdGVyLT5jdXJu b2RlOw0KICAgIGVsc2UNCglub2RlID0gaXRlci0+bm9kZTsNCg0KICAgIHN3aXRjaCAobm9kZS0+ dHlwZSkgew0KICAgIGNhc2UgWE1MX0FUVFJJQlVURV9OT0RFOg0KICAgIGNhc2UgWE1MX1RFWFRf Tk9ERToNCiAgICBjYXNlIFhNTF9DREFUQV9TRUNUSU9OX05PREU6DQogICAgY2FzZSBYTUxfUElf Tk9ERToNCiAgICBjYXNlIFhNTF9DT01NRU5UX05PREU6DQogICAgY2FzZSBYTUxfTkFNRVNQQUNF X0RFQ0w6DQoJcmV0dXJuIDE7DQogICAgZGVmYXVsdDoNCglicmVhazsNCiAgICB9DQoNCiAgICBy ZXR1cm4gMDsNCn0NCg0KLyoqDQogKiB4bWxEb2NXYWxrZXJJc0VtcHR5RWxlbWVudDoNCiAqIEBp dGVyOiAgdGhlIHhtbERvY1dhbGtlclB0cg0KICoNCiAqIENoZWNrIGlmIHRoZSBjdXJyZW50IG5v ZGUgaXMgZW1wdHkNCiAqDQogKiBSZXR1cm5zIDEgaWYgZW1wdHksIDAgaWYgbm90IGFuZCAtMSBp biBjYXNlIG9mIGVycm9yDQogKi8NCmludA0KeG1sRG9jV2Fsa2VySXNFbXB0eUVsZW1lbnQoeG1s RG9jV2Fsa2VyUHRyIGl0ZXIpDQp7DQogICAgaWYgKChpdGVyID09IDApIHx8IChpdGVyLT5ub2Rl ID09IDApKQ0KCXJldHVybiAtMTsNCg0KICAgIGlmIChpdGVyLT5ub2RlLT50eXBlICE9IFhNTF9F TEVNRU5UX05PREUpDQoJcmV0dXJuIDA7DQoNCiAgICBpZiAoaXRlci0+Y3Vybm9kZSAhPSAwKQ0K CXJldHVybiAwOw0KDQogICAgaWYgKGl0ZXItPm5vZGUtPmNoaWxkcmVuICE9IDApDQoJcmV0dXJu IDA7DQoNCiAgICByZXR1cm4gMTsNCn0NCg0KLyoqDQogKiB4bWxEb2NXYWxrZXJMb2NhbE5hbWU6 DQogKiBAaXRlcjogIHRoZSB4bWxEb2NXYWxrZXJQdHINCiAqDQogKiBUaGUgbG9jYWwgbmFtZSBv ZiB0aGUgbm9kZS4NCiAqDQogKiBSZXR1cm5zIHRoZSBsb2NhbCBuYW1lIG9yIE5VTEwgaWYgbm90 IGF2YWlsYWJsZQ0KICovDQp4bWxDaGFyICoNCnhtbERvY1dhbGtlckxvY2FsTmFtZSh4bWxEb2NX YWxrZXJQdHIgaXRlcikNCnsNCiAgICB4bWxOb2RlUHRyIG5vZGU7DQoNCiAgICBpZiAoKGl0ZXIg PT0gMCkgfHwgKGl0ZXItPm5vZGUgPT0gMCkpDQoJcmV0dXJuIDA7DQoNCiAgICBpZiAoaXRlci0+ Y3Vybm9kZSAhPSAwKQ0KCW5vZGUgPSBpdGVyLT5jdXJub2RlOw0KICAgIGVsc2UNCglub2RlID0g aXRlci0+bm9kZTsNCg0KICAgIGlmIChub2RlLT50eXBlID09IFhNTF9OQU1FU1BBQ0VfREVDTCkg ew0KCXhtbE5zUHRyIG5zID0gKHhtbE5zUHRyKSBub2RlOw0KCWlmIChucy0+cHJlZml4ID09IDAp DQoJICAgIHJldHVybiB4bWxTdHJkdXAoQkFEX0NBU1QgInhtbG5zIik7DQoJZWxzZQ0KCSAgICBy ZXR1cm4geG1sU3RyZHVwKG5zLT5wcmVmaXgpOw0KICAgIH0NCg0KICAgIGlmICgobm9kZS0+dHlw ZSAhPSBYTUxfRUxFTUVOVF9OT0RFKSAmJiAobm9kZS0+dHlwZSAhPSBYTUxfQVRUUklCVVRFX05P REUpKQ0KCXJldHVybih4bWxEb2NXYWxrZXJOYW1lKGl0ZXIpKTsNCg0KICAgIHJldHVybiB4bWxT dHJkdXAobm9kZS0+bmFtZSk7DQoNCn0NCg0KLyoqDQogKiB4bWxEb2NXYWxrZXJOYW1lOg0KICog QGl0ZXI6ICB0aGUgeG1sRG9jV2Fsa2VyUHRyDQogKg0KICogVGhlIHF1YWxpZmllZCBuYW1lIG9m IHRoZSBub2RlLCBlcXVhbCB0byBQcmVmaXggOkxvY2FsTmFtZS4NCiAqDQogKiBSZXR1cm5zIHRo ZSBsb2NhbCBuYW1lIG9yIE5VTEwgaWYgbm90IGF2YWlsYWJsZQ0KICovDQp4bWxDaGFyICoNCnht bERvY1dhbGtlck5hbWUoeG1sRG9jV2Fsa2VyUHRyIGl0ZXIpDQp7DQogICAgeG1sTm9kZVB0ciBu b2RlOw0KICAgIHhtbENoYXIgKnJldDsNCg0KICAgIGlmICgoaXRlciA9PSAwKSB8fCAoaXRlci0+ bm9kZSA9PSAwKSkNCglyZXR1cm4gMDsNCg0KICAgIGlmIChpdGVyLT5jdXJub2RlICE9IDApDQoJ bm9kZSA9IGl0ZXItPmN1cm5vZGU7DQogICAgZWxzZQ0KCW5vZGUgPSBpdGVyLT5ub2RlOw0KDQog ICAgc3dpdGNoIChub2RlLT50eXBlKSB7DQogICAgY2FzZSBYTUxfRUxFTUVOVF9OT0RFOg0KICAg IGNhc2UgWE1MX0FUVFJJQlVURV9OT0RFOg0KCWlmICgobm9kZS0+bnMgPT0gMCkgfHwgKG5vZGUt Pm5zLT5wcmVmaXggPT0gTlVMTCkpDQoJICAgIHJldHVybiB4bWxTdHJkdXAobm9kZS0+bmFtZSk7 DQoJDQoJaWYgKChyZXQgPSB4bWxTdHJkdXAobm9kZS0+bnMtPnByZWZpeCkpICYmDQoJICAgIChy ZXQgPSB4bWxTdHJjYXQocmV0LCBCQURfQ0FTVCAiOiIpKSAmJg0KCSAgICAocmV0ID0geG1sU3Ry Y2F0KHJldCwgbm9kZS0+bmFtZSkpKQ0KCSAgICByZXR1cm4gcmV0Ow0KCWlmIChyZXQpIHhtbEZy ZWUocmV0KTsNCglyZXR1cm4gMDsNCiAgICBjYXNlIFhNTF9URVhUX05PREU6DQoJcmV0dXJuIHht bFN0cmR1cChCQURfQ0FTVCAiI3RleHQiKTsNCiAgICBjYXNlIFhNTF9DREFUQV9TRUNUSU9OX05P REU6DQoJcmV0dXJuIHhtbFN0cmR1cChCQURfQ0FTVCAiI2NkYXRhLXNlY3Rpb24iKTsNCiAgICBj YXNlIFhNTF9FTlRJVFlfTk9ERToNCiAgICBjYXNlIFhNTF9FTlRJVFlfUkVGX05PREU6DQoJcmV0 dXJuIHhtbFN0cmR1cChub2RlLT5uYW1lKTsNCiAgICBjYXNlIFhNTF9QSV9OT0RFOg0KCXJldHVy biB4bWxTdHJkdXAobm9kZS0+bmFtZSk7DQogICAgY2FzZSBYTUxfQ09NTUVOVF9OT0RFOg0KCXJl dHVybiB4bWxTdHJkdXAoQkFEX0NBU1QgIiNjb21tZW50Iik7DQogICAgY2FzZSBYTUxfRE9DVU1F TlRfTk9ERToNCiAgICBjYXNlIFhNTF9IVE1MX0RPQ1VNRU5UX05PREU6DQojaWZkZWYgTElCWE1M X0RPQ0JfRU5BQkxFRA0KICAgIGNhc2UgWE1MX0RPQ0JfRE9DVU1FTlRfTk9ERToNCiNlbmRpZg0K CXJldHVybiB4bWxTdHJkdXAoQkFEX0NBU1QgIiNkb2N1bWVudCIpOw0KICAgIGNhc2UgWE1MX0RP Q1VNRU5UX0ZSQUdfTk9ERToNCglyZXR1cm4geG1sU3RyZHVwKEJBRF9DQVNUICIjZG9jdW1lbnQt ZnJhZ21lbnQiKTsNCiAgICBjYXNlIFhNTF9OT1RBVElPTl9OT0RFOg0KCXJldHVybiB4bWxTdHJk dXAobm9kZS0+bmFtZSk7DQogICAgY2FzZSBYTUxfRE9DVU1FTlRfVFlQRV9OT0RFOg0KICAgIGNh c2UgWE1MX0RURF9OT0RFOg0KCXJldHVybiB4bWxTdHJkdXAobm9kZS0+bmFtZSk7DQogICAgY2Fz ZSBYTUxfTkFNRVNQQUNFX0RFQ0w6DQoJew0KCSAgICB4bWxOc1B0ciBucyA9ICh4bWxOc1B0cikg bm9kZTsNCg0KCSAgICByZXQgPSB4bWxTdHJkdXAoQkFEX0NBU1QgInhtbG5zIik7DQoJICAgIGlm KG5zLT5wcmVmaXggPT0gMCkNCgkJcmV0dXJuIHJldDsNCgkgICAgaWYgKChyZXQpICYmDQoJCShy ZXQgPSB4bWxTdHJjYXQocmV0LCBCQURfQ0FTVCAiOiIpKSAmJg0KCQkocmV0ID0geG1sU3RyY2F0 KHJldCwgbnMtPnByZWZpeCkpKQ0KCQlyZXR1cm4gcmV0Ow0KCSAgICBpZiAocmV0KSB4bWxGcmVl KHJldCk7DQoJICAgIHJldHVybiAwOw0KCX0NCiAgICBjYXNlIFhNTF9FTEVNRU5UX0RFQ0w6DQog ICAgY2FzZSBYTUxfQVRUUklCVVRFX0RFQ0w6DQogICAgY2FzZSBYTUxfRU5USVRZX0RFQ0w6DQog ICAgY2FzZSBYTUxfWElOQ0xVREVfU1RBUlQ6DQogICAgY2FzZSBYTUxfWElOQ0xVREVfRU5EOg0K CXJldHVybiAwOw0KICAgIH0NCg0KICAgIHJldHVybiAwOw0KfQ0KDQovKioNCiAqIHhtbERvY1dh bGtlck5vZGVUeXBlOg0KICogQGl0ZXI6ICB0aGUgeG1sRG9jV2Fsa2VyUHRyDQogKg0KICogR2V0 IHRoZSBub2RlIHR5cGUgb2YgdGhlIGN1cnJlbnQgbm9kZQ0KICogUmVmZXJlbmNlOg0KICogaHR0 cDovL2RvdGdudS5vcmcvcG5ldGxpYi1kb2MvU3lzdGVtL1htbC9YbWxOb2RlVHlwZS5odG1sDQog Kg0KICogUmV0dXJucyB0aGUgeG1sTm9kZVR5cGUgb2YgdGhlIGN1cnJlbnQgbm9kZSBvciAtMSBp biBjYXNlIG9mIGVycm9yDQogKi8NCmludA0KeG1sRG9jV2Fsa2VyTm9kZVR5cGUoeG1sRG9jV2Fs a2VyUHRyIGl0ZXIpDQp7DQogICAgeG1sTm9kZVB0ciBub2RlOw0KICAgIGlmIChpdGVyID09IDAp DQoJcmV0dXJuIC0xOw0KDQogICAgaWYgKGl0ZXItPmN1cm5vZGUgIT0gMCkNCglub2RlID0gaXRl ci0+Y3Vybm9kZTsNCiAgICBlbHNlDQoJbm9kZSA9IGl0ZXItPm5vZGU7DQoNCiAgICBpZiAobm9k ZSA9PSAwKQ0KCXJldHVybiAwOw0KDQogICAgc3dpdGNoKG5vZGUtPnR5cGUpIHsNCiAgICBjYXNl IFhNTF9FTEVNRU5UX05PREU6DQoJaWYgKChpdGVyLT5zdGF0ZSA9PSBYTUxfRFdBTEtfRU5EKSB8 fA0KCSAgICAoaXRlci0+c3RhdGUgPT0gWE1MX0RXQUxLX0JBQ0tUUkFDSykpDQoJICAgIHJldHVy biBYTUxfUkVBREVSX1RZUEVfRU5EX0VMRU1FTlQ7DQoJcmV0dXJuIFhNTF9SRUFERVJfVFlQRV9F TEVNRU5UOw0KDQogICAgY2FzZSBYTUxfTkFNRVNQQUNFX0RFQ0w6DQogICAgY2FzZSBYTUxfQVRU UklCVVRFX05PREU6DQoJcmV0dXJuIFhNTF9SRUFERVJfVFlQRV9BVFRSSUJVVEU7DQoNCiAgICBj YXNlIFhNTF9URVhUX05PREU6DQoJaWYgKHhtbElzQmxhbmtOb2RlKGl0ZXItPm5vZGUpKSB7DQoJ ICAgIGlmICh4bWxOb2RlR2V0U3BhY2VQcmVzZXJ2ZShpdGVyLT5ub2RlKSkNCgkJcmV0dXJuIFhN TF9SRUFERVJfVFlQRV9TSUdOSUZJQ0FOVF9XSElURVNQQUNFOw0KDQoJICAgIHJldHVybiBYTUxf UkVBREVSX1RZUEVfV0hJVEVTUEFDRTsNCgl9DQoJcmV0dXJuIFhNTF9SRUFERVJfVFlQRV9URVhU Ow0KDQogICAgY2FzZSBYTUxfQ0RBVEFfU0VDVElPTl9OT0RFOg0KCXJldHVybiBYTUxfUkVBREVS X1RZUEVfQ0RBVEE7DQoNCiAgICBjYXNlIFhNTF9FTlRJVFlfUkVGX05PREU6DQoJcmV0dXJuIFhN TF9SRUFERVJfVFlQRV9FTlRJVFlfUkVGRVJFTkNFOw0KDQogICAgY2FzZSBYTUxfRU5USVRZX05P REU6DQoJcmV0dXJuIFhNTF9SRUFERVJfVFlQRV9FTlRJVFk7DQoNCiAgICBjYXNlIFhNTF9QSV9O T0RFOg0KCXJldHVybiBYTUxfUkVBREVSX1RZUEVfUFJPQ0VTU0lOR19JTlNUUlVDVElPTjsNCg0K ICAgIGNhc2UgWE1MX0NPTU1FTlRfTk9ERToNCglyZXR1cm4gWE1MX1JFQURFUl9UWVBFX0NPTU1F TlQ7DQoNCiAgICBjYXNlIFhNTF9ET0NVTUVOVF9OT0RFOg0KICAgIGNhc2UgWE1MX0hUTUxfRE9D VU1FTlRfTk9ERToNCiNpZmRlZiBMSUJYTUxfRE9DQl9FTkFCTEVEDQogICAgY2FzZSBYTUxfRE9D Ql9ET0NVTUVOVF9OT0RFOg0KI2VuZGlmDQoJcmV0dXJuIFhNTF9SRUFERVJfVFlQRV9ET0NVTUVO VDsNCg0KICAgIGNhc2UgWE1MX0RPQ1VNRU5UX0ZSQUdfTk9ERToNCglyZXR1cm4gWE1MX1JFQURF Ul9UWVBFX0RPQ1VNRU5UX0ZSQUdNRU5UOw0KDQogICAgY2FzZSBYTUxfTk9UQVRJT05fTk9ERToN CglyZXR1cm4gWE1MX1JFQURFUl9UWVBFX05PVEFUSU9OOw0KDQogICAgY2FzZSBYTUxfRE9DVU1F TlRfVFlQRV9OT0RFOg0KICAgIGNhc2UgWE1MX0RURF9OT0RFOg0KCXJldHVybiBYTUxfUkVBREVS X1RZUEVfRE9DVU1FTlRfVFlQRTsNCg0KICAgIGNhc2UgWE1MX0VMRU1FTlRfREVDTDoNCiAgICBj YXNlIFhNTF9BVFRSSUJVVEVfREVDTDoNCiAgICBjYXNlIFhNTF9FTlRJVFlfREVDTDoNCiAgICBj YXNlIFhNTF9YSU5DTFVERV9TVEFSVDoNCiAgICBjYXNlIFhNTF9YSU5DTFVERV9FTkQ6DQoJcmV0 dXJuIFhNTF9SRUFERVJfVFlQRV9OT05FOw0KICAgIH0NCg0KICAgIHJldHVybiAtMTsNCn0NCg0K LyoqDQogKiB4bWxEb2NXYWxrZXJQcmVmaXg6DQogKiBAaXRlcjogIHRoZSB4bWxEb2NXYWxrZXJQ dHINCiAqDQogKiBBIHNob3J0aGFuZCByZWZlcmVuY2UgdG8gdGhlIG5hbWVzcGFjZSBhc3NvY2lh dGVkIHdpdGggdGhlIG5vZGUuDQogKg0KICogUmV0dXJucyB0aGUgcHJlZml4IG9yIE5VTEwgaWYg bm90IGF2YWlsYWJsZQ0KICovDQp4bWxDaGFyICoNCnhtbERvY1dhbGtlclByZWZpeCh4bWxEb2NX YWxrZXJQdHIgaXRlcikNCnsNCiAgICB4bWxOb2RlUHRyIG5vZGU7DQoNCiAgICBpZiAoKGl0ZXIg PT0gMCkgfHwgKGl0ZXItPm5vZGUgPT0gMCkgfHwgKGl0ZXItPm5vZGUtPm5zID09IDApKQ0KCXJl dHVybiAwOw0KDQogICAgaWYgKGl0ZXItPmN1cm5vZGUgIT0gTlVMTCkNCglub2RlID0gaXRlci0+ Y3Vybm9kZTsNCiAgICBlbHNlDQoJbm9kZSA9IGl0ZXItPm5vZGU7DQoNCiAgICBpZiAobm9kZS0+ dHlwZSA9PSBYTUxfTkFNRVNQQUNFX0RFQ0wpIHsNCgl4bWxOc1B0ciBucyA9ICh4bWxOc1B0cikg bm9kZTsNCg0KCWlmIChucy0+cHJlZml4ID09IDApDQoJICAgIHJldHVybiAwOw0KDQoJcmV0dXJu IHhtbFN0cmR1cChCQURfQ0FTVCAieG1sbnMiKTsNCiAgICB9DQoNCiAgICBpZiAoKG5vZGUtPnR5 cGUgIT0gWE1MX0VMRU1FTlRfTk9ERSkgJiYNCgkobm9kZS0+dHlwZSAhPSBYTUxfQVRUUklCVVRF X05PREUpKQ0KCXJldHVybiBOVUxMOw0KDQogICAgaWYgKChub2RlLT5ucyAhPSAwKSAmJiAobm9k ZS0+bnMtPnByZWZpeCAhPSAwKSkNCglyZXR1cm4geG1sU3RyZHVwKG5vZGUtPm5zLT5wcmVmaXgp Ow0KDQogICAgcmV0dXJuIDA7DQp9DQoNCi8qKg0KICogeG1sRG9jV2Fsa2VyTmFtZXNwYWNlVXJp Og0KICogQGl0ZXI6ICB0aGUgeG1sRG9jV2Fsa2VyUHRyDQogKg0KICogVGhlIFVSSSBkZWZpbmlu ZyB0aGUgbmFtZXNwYWNlIGFzc29jaWF0ZWQgd2l0aCB0aGUgbm9kZS4NCiAqDQogKiBSZXR1cm5z IHRoZSBuYW1lc3BhY2UgVVJJIG9yIE5VTEwgaWYgbm90IGF2YWlsYWJsZQ0KICovDQp4bWxDaGFy ICoNCnhtbERvY1dhbGtlck5hbWVzcGFjZVVyaSh4bWxEb2NXYWxrZXJQdHIgaXRlcikNCnsNCiAg ICB4bWxOb2RlUHRyIG5vZGU7DQoNCiAgICBpZiAoKGl0ZXIgPT0gMCkgfHwgKGl0ZXItPm5vZGUg PT0gMCkpDQoJcmV0dXJuIDA7DQoNCiAgICBpZiAoaXRlci0+Y3Vybm9kZSAhPSAwKQ0KCW5vZGUg PSBpdGVyLT5jdXJub2RlOw0KICAgIGVsc2UNCglub2RlID0gaXRlci0+bm9kZTsNCg0KICAgIGlm IChub2RlLT50eXBlID09IFhNTF9OQU1FU1BBQ0VfREVDTCkNCglyZXR1cm4geG1sU3RyZHVwKEJB RF9DQVNUICJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3htbG5zLyIpOw0KDQogICAgaWYgKChub2Rl LT50eXBlICE9IFhNTF9FTEVNRU5UX05PREUpICYmIChub2RlLT50eXBlICE9IFhNTF9BVFRSSUJV VEVfTk9ERSkpDQoJcmV0dXJuIDA7DQoNCiAgICBpZiAobm9kZS0+bnMgIT0gMCkNCglyZXR1cm4g eG1sU3RyZHVwKG5vZGUtPm5zLT5ocmVmKTsNCg0KICAgIHJldHVybiAwOw0KfQ0KDQovKioNCiAq IHhtbFRleHRSZWFkZXJCYXNlVXJpOg0KICogQGl0ZXI6ICB0aGUgeG1sRG9jV2Fsa2VyUHRyDQog Kg0KICogVGhlIGJhc2UgVVJJIG9mIHRoZSBub2RlLg0KICoNCiAqIFJldHVybnMgdGhlIGJhc2Ug VVJJIG9yIE5VTEwgaWYgbm90IGF2YWlsYWJsZQ0KICovDQp4bWxDaGFyICoNCnhtbERvY1dhbGtl ckJhc2VVcmkoeG1sRG9jV2Fsa2VyUHRyIGl0ZXIpDQp7DQogICAgaWYgKChpdGVyID09IDApIHx8 IChpdGVyLT5ub2RlID09IDApKQ0KCXJldHVybiAwOw0KDQogICAgcmV0dXJuIHhtbE5vZGVHZXRC YXNlKDAsIGl0ZXItPm5vZGUpOw0KfQ0KDQovKioNCiAqIHhtbERvY1dhbGtlclZhbHVlOg0KICog QGl0ZXI6ICB0aGUgeG1sRG9jV2Fsa2VyUHRyDQogKg0KICogUHJvdmlkZXMgdGhlIHRleHQgdmFs dWUgb2YgdGhlIG5vZGUgaWYgcHJlc2VudA0KICoNCiAqIFJldHVybnMgdGhlIHN0cmluZyBvciBO VUxMIGlmIG5vdCBhdmFpbGFibGUuIFRoZSByZXRzdWx0IG11c3QgYmUgZGVhbGxvY2F0ZWQNCiAq ICAgICB3aXRoIHhtbEZyZWUoKQ0KICovDQp4bWxDaGFyICoNCnhtbERvY1dhbGtlclZhbHVlKHht bERvY1dhbGtlclB0ciBpdGVyKQ0Kew0KICAgIHhtbE5vZGVQdHIgbm9kZTsNCiAgICBpZiAoKGl0 ZXIgPT0gMCkgfHwgKGl0ZXItPm5vZGUgPT0gMCkpDQoJcmV0dXJuIDA7DQoNCiAgICBpZiAoaXRl ci0+Y3Vybm9kZSAhPSAwKQ0KCW5vZGUgPSBpdGVyLT5jdXJub2RlOw0KICAgIGVsc2UNCglub2Rl ID0gaXRlci0+bm9kZTsNCg0KICAgIHN3aXRjaCAobm9kZS0+dHlwZSkgew0KICAgIGNhc2UgWE1M X05BTUVTUEFDRV9ERUNMOg0KCXJldHVybiB4bWxTdHJkdXAoKCh4bWxOc1B0cikgbm9kZSktPmhy ZWYpOw0KICAgIGNhc2UgWE1MX0FUVFJJQlVURV9OT0RFOg0KCXsNCgkgICAgeG1sQXR0clB0ciBh dHRyID0gKHhtbEF0dHJQdHIpIG5vZGU7DQoNCgkgICAgaWYgKGF0dHItPnBhcmVudCAhPSAwKQ0K CQlyZXR1cm4geG1sTm9kZUxpc3RHZXRTdHJpbmcoYXR0ci0+cGFyZW50LT5kb2MsIGF0dHItPmNo aWxkcmVuLCAxKTsNCgkgICAgZWxzZQ0KCQlyZXR1cm4geG1sTm9kZUxpc3RHZXRTdHJpbmcoMCwg YXR0ci0+Y2hpbGRyZW4sIDEpOw0KCX0NCglicmVhazsNCiAgICBjYXNlIFhNTF9URVhUX05PREU6 DQogICAgY2FzZSBYTUxfQ0RBVEFfU0VDVElPTl9OT0RFOg0KICAgIGNhc2UgWE1MX1BJX05PREU6 DQogICAgY2FzZSBYTUxfQ09NTUVOVF9OT0RFOg0KCWlmIChub2RlLT5jb250ZW50ICE9IDApDQoJ ICAgIHJldHVybiB4bWxTdHJkdXAobm9kZS0+Y29udGVudCk7DQogICAgZGVmYXVsdDoNCglicmVh azsNCiAgICB9DQogICAgcmV0dXJuKE5VTEwpOw0KfQ0KDQovKioNCiAqIHhtbERvY1dhbGtlckdl dEF0dHJpYnV0ZU5vOg0KICogQGl0ZXI6ICB0aGUgeG1sRG9jV2Fsa2VyUHRyDQogKiBAbm86IHRo ZSB6ZXJvLWJhc2VkIGluZGV4IG9mIHRoZSBhdHRyaWJ1dGUgcmVsYXRpdmUgdG8gdGhlIGNvbnRh aW5pbmcgZWxlbWVudA0KICoNCiAqIFByb3ZpZGVzIHRoZSB2YWx1ZSBvZiB0aGUgYXR0cmlidXRl IHdpdGggdGhlIHNwZWNpZmllZCBpbmRleCByZWxhdGl2ZQ0KICogdG8gdGhlIGNvbnRhaW5pbmcg ZWxlbWVudC4NCiAqDQogKiBSZXR1cm5zIGEgc3RyaW5nIGNvbnRhaW5pbmcgdGhlIHZhbHVlIG9m IHRoZSBzcGVjaWZpZWQgYXR0cmlidXRlLCBvciBOVUxMDQogKiAgICBpbiBjYXNlIG9mIGVycm9y LiBUaGUgc3RyaW5nIG11c3QgYmUgZGVhbGxvY2F0ZWQgYnkgdGhlIGNhbGxlci4NCiAqLw0KeG1s Q2hhciAqDQp4bWxEb2NXYWxrZXJHZXRBdHRyaWJ1dGVObyh4bWxEb2NXYWxrZXJQdHIgaXRlciwN CgkJCSAgIGludCBubykNCnsNCiAgICB4bWxDaGFyICpyZXQ7DQogICAgaW50IGk7DQogICAgeG1s QXR0clB0ciBjdXI7DQogICAgeG1sTnNQdHIgbnM7DQoNCiAgICBpZiAoKGl0ZXIgPT0gMCkgfHwg KGl0ZXItPm5vZGUgPT0gMCkgfHwgKGl0ZXItPmN1cm5vZGUgIT0gMCkgfHwNCgkoaXRlci0+bm9k ZS0+dHlwZSAhPSBYTUxfRUxFTUVOVF9OT0RFKSkNCglyZXR1cm4gMDsNCg0KICAgIG5zID0gaXRl ci0+bm9kZS0+bnNEZWY7DQogICAgZm9yIChpID0gMDsgaSA8IG5vICYmIG5zICE9IDA7IGkrKykN CglucyA9IG5zLT5uZXh0Ow0KDQogICAgaWYgKG5zICE9IDApDQoJcmV0dXJuKHhtbFN0cmR1cChu cy0+aHJlZikpOw0KDQogICAgY3VyID0gaXRlci0+bm9kZS0+cHJvcGVydGllczsNCiAgICBpZiAo Y3VyID09IDApDQoJcmV0dXJuIDA7DQoNCiAgICBmb3IgKDsgaSA8IG5vO2krKykgew0KCWN1ciA9 IGN1ci0+bmV4dDsNCglpZiAoY3VyID09IDApDQoJICAgIHJldHVybiAwOw0KICAgIH0NCg0KICAg IHJldCA9IHhtbE5vZGVMaXN0R2V0U3RyaW5nKGl0ZXItPm5vZGUtPmRvYywgY3VyLT5jaGlsZHJl biwgMSk7DQogICAgaWYgKHJldCA9PSAwKQ0KCXJldHVybih4bWxTdHJkdXAoKHhtbENoYXIgKiki IikpOw0KDQogICAgcmV0dXJuIHJldDsNCn0NCg0KLyoqDQogKiB4bWxEb2NXYWxrZXJHZXRBdHRy aWJ1dGU6DQogKiBAaXRlcjogIHRoZSB4bWxEb2NXYWxrZXJQdHINCiAqIEBuYW1lOiB0aGUgcXVh bGlmaWVkIG5hbWUgb2YgdGhlIGF0dHJpYnV0ZS4NCiAqDQogKiBQcm92aWRlcyB0aGUgdmFsdWUg b2YgdGhlIGF0dHJpYnV0ZSB3aXRoIHRoZSBzcGVjaWZpZWQgcXVhbGlmaWVkIG5hbWUuDQogKg0K ICogUmV0dXJucyBhIHN0cmluZyBjb250YWluaW5nIHRoZSB2YWx1ZSBvZiB0aGUgc3BlY2lmaWVk IGF0dHJpYnV0ZSwgb3IgTlVMTA0KICogICAgaW4gY2FzZSBvZiBlcnJvci4gVGhlIHN0cmluZyBt dXN0IGJlIGRlYWxsb2NhdGVkIGJ5IHRoZSBjYWxsZXIuDQogKi8NCnhtbENoYXIgKg0KeG1sRG9j V2Fsa2VyR2V0QXR0cmlidXRlKHhtbERvY1dhbGtlclB0ciBpdGVyLA0KCQkJIGNvbnN0IHhtbENo YXIgKm5hbWUpDQp7DQogICAgeG1sQ2hhciAqcHJlZml4ID0gMDsNCiAgICB4bWxDaGFyICpsb2Nh bG5hbWU7DQogICAgeG1sTnNQdHIgbnM7DQogICAgeG1sQ2hhciAqcmV0ID0gMDsNCg0KICAgIGlm ICgoaXRlciA9PSAwKSB8fCAoaXRlci0+bm9kZSA9PSAwKSB8fCAoaXRlci0+Y3Vybm9kZSAhPSAw KSB8fA0KCShpdGVyLT5ub2RlLT50eXBlICE9IFhNTF9FTEVNRU5UX05PREUpKQ0KCXJldHVybiAw Ow0KDQogICAgbG9jYWxuYW1lID0geG1sU3BsaXRRTmFtZTIobmFtZSwgJnByZWZpeCk7DQogICAg aWYgKGxvY2FsbmFtZSA9PSAwKQ0KCXJldHVybiB4bWxHZXRQcm9wKGl0ZXItPm5vZGUsIG5hbWUp Ow0KDQogICAgbnMgPSB4bWxTZWFyY2hOcyhpdGVyLT5ub2RlLT5kb2MsIGl0ZXItPm5vZGUsIHBy ZWZpeCk7DQogICAgaWYgKG5zICE9IDApDQoJcmV0ID0geG1sR2V0TnNQcm9wKGl0ZXItPm5vZGUs IGxvY2FsbmFtZSwgbnMtPmhyZWYpOw0KDQogICAgaWYgKGxvY2FsbmFtZSAhPSAwKQ0KCXhtbEZy ZWUobG9jYWxuYW1lKTsNCiAgICBpZiAocHJlZml4ICE9IDApDQoJeG1sRnJlZShwcmVmaXgpOw0K DQogICAgcmV0dXJuIHJldDsNCn0NCg0KLyoqDQogKiB4bWxEb2NXYWxrZXJHZXRBdHRyaWJ1dGVO czoNCiAqIEBpdGVyOiAgdGhlIHhtbERvY1dhbGtlclB0cg0KICogQGxvY2FsTmFtZTogdGhlIGxv Y2FsIG5hbWUgb2YgdGhlIGF0dHJpYnV0ZS4NCiAqIEBuYW1lc3BhY2VVUkk6IHRoZSBuYW1lc3Bh Y2UgVVJJIG9mIHRoZSBhdHRyaWJ1dGUuDQogKg0KICogUHJvdmlkZXMgdGhlIHZhbHVlIG9mIHRo ZSBzcGVjaWZpZWQgYXR0cmlidXRlDQogKg0KICogUmV0dXJucyBhIHN0cmluZyBjb250YWluaW5n IHRoZSB2YWx1ZSBvZiB0aGUgc3BlY2lmaWVkIGF0dHJpYnV0ZSwgb3IgTlVMTA0KICogICAgaW4g Y2FzZSBvZiBlcnJvci4gVGhlIHN0cmluZyBtdXN0IGJlIGRlYWxsb2NhdGVkIGJ5IHRoZSBjYWxs ZXIuDQogKi8NCnhtbENoYXIgKg0KeG1sRG9jV2Fsa2VyR2V0QXR0cmlidXRlTnMoeG1sRG9jV2Fs a2VyUHRyIGl0ZXIsDQoJCQkgICBjb25zdCB4bWxDaGFyICpsb2NhbE5hbWUsDQoJCQkgICBjb25z dCB4bWxDaGFyICpuYW1lc3BhY2VVUkkpDQp7DQogICAgaWYgKChpdGVyID09IDApIHx8IChpdGVy LT5ub2RlID09IDApIHx8IChpdGVyLT5ub2RlLT50eXBlICE9IFhNTF9FTEVNRU5UX05PREUpKQ0K CXJldHVybiAwOw0KDQogICAgcmV0dXJuIHhtbEdldE5zUHJvcChpdGVyLT5ub2RlLCBsb2NhbE5h bWUsIG5hbWVzcGFjZVVSSSk7DQp9DQoNCi8qKg0KICogeG1sRG9jV2Fsa2VyTG9va3VwTmFtZXNw YWNlOg0KICogQGl0ZXI6ICB0aGUgeG1sRG9jV2Fsa2VyUHRyDQogKiBAcHJlZml4OiB0aGUgcHJl Zml4IHdob3NlIG5hbWVzcGFjZSBVUkkgaXMgdG8gYmUgcmVzb2x2ZWQuIFRvIHJldHVybg0KICog ICAgICAgICAgdGhlIGRlZmF1bHQgbmFtZXNwYWNlLCBzcGVjaWZ5IE5VTEwNCiAqDQogKiBSZXNv bHZlcyBhIG5hbWVzcGFjZSBwcmVmaXggaW4gdGhlIHNjb3BlIG9mIHRoZSBjdXJyZW50IGVsZW1l bnQuDQogKg0KICogUmV0dXJucyBhIHN0cmluZyBjb250YWluaW5nIHRoZSBuYW1lc3BhY2UgVVJJ IHRvIHdoaWNoIHRoZSBwcmVmaXggbWFwcw0KICogICAgb3IgTlVMTCBpbiBjYXNlIG9mIGVycm9y LiBUaGUgc3RyaW5nIG11c3QgYmUgZGVhbGxvY2F0ZWQgYnkgdGhlIGNhbGxlci4NCiAqLw0KeG1s Q2hhciAqDQp4bWxEb2NXYWxrZXJMb29rdXBOYW1lc3BhY2UoeG1sRG9jV2Fsa2VyUHRyIGl0ZXIs DQoJCQkgICAgY29uc3QgeG1sQ2hhciAqcHJlZml4KQ0Kew0KICAgIHhtbE5zUHRyIG5zOw0KDQog ICAgaWYgKChpdGVyID09IDApIHx8IChpdGVyLT5ub2RlID09IDApKQ0KCXJldHVybiAwOw0KDQog ICAgbnMgPSB4bWxTZWFyY2hOcyhpdGVyLT5ub2RlLT5kb2MsIGl0ZXItPm5vZGUsIHByZWZpeCk7 DQogICAgaWYgKG5zID09IE5VTEwpDQoJcmV0dXJuKE5VTEwpOw0KICAgIHJldHVybih4bWxTdHJk dXAobnMtPmhyZWYpKTsNCn0NCg0KLyoqDQogKiB4bWxEb2NXYWxrZXJNb3ZlVG9BdHRyaWJ1dGVO bzoNCiAqIEBpdGVyOiAgdGhlIHhtbERvY1dhbGtlclB0cg0KICogQG5vOiB0aGUgemVyby1iYXNl ZCBpbmRleCBvZiB0aGUgYXR0cmlidXRlIHJlbGF0aXZlIHRvIHRoZSBjb250YWluaW5nDQogKiAg ICAgIGVsZW1lbnQuDQogKg0KICogTW92ZXMgdGhlIHBvc2l0aW9uIG9mIHRoZSBjdXJyZW50IGlu c3RhbmNlIHRvIHRoZSBhdHRyaWJ1dGUgd2l0aA0KICogdGhlIHNwZWNpZmllZCBpbmRleCByZWxh dGl2ZSB0byB0aGUgY29udGFpbmluZyBlbGVtZW50Lg0KICoNCiAqIFJldHVybnMgMSBpbiBjYXNl IG9mIHN1Y2Nlc3MsIC0xIGluIGNhc2Ugb2YgZXJyb3IsIDAgaWYgbm90IGZvdW5kDQogKi8NCmlu dA0KeG1sRG9jV2Fsa2VyTW92ZVRvQXR0cmlidXRlTm8oeG1sRG9jV2Fsa2VyUHRyIGl0ZXIsDQoJ CQkgICAgICBpbnQgbm8pDQp7DQogICAgaW50IGk7DQogICAgeG1sQXR0clB0ciBjdXI7DQogICAg eG1sTnNQdHIgbnM7DQoNCiAgICBpZiAoKGl0ZXIgPT0gMCkgfHwgKGl0ZXItPm5vZGUgPT0gMCkp DQoJcmV0dXJuIC0xOw0KDQogICAgaWYgKChpdGVyLT5zdGF0ZSA9PSBYTUxfRFdBTEtfTk9ORSkg fHwNCgkoaXRlci0+c3RhdGUgPT0gWE1MX0RXQUxLX0JBQ0tUUkFDSykgfHwNCgkoaXRlci0+c3Rh dGUgPT0gWE1MX0RXQUxLX0VORCkpDQoJcmV0dXJuIDA7DQoNCiAgICBpZiAoaXRlci0+bm9kZS0+ dHlwZSAhPSBYTUxfRUxFTUVOVF9OT0RFKSANCglyZXR1cm4gMDsNCg0KICAgIGl0ZXItPmN1cm5v ZGUgPSBOVUxMOw0KDQogICAgbnMgPSBpdGVyLT5ub2RlLT5uc0RlZjsNCiAgICBmb3IgKGkgPSAw OyBpIDwgbm8gJiYgbnMgIT0gTlVMTDsgaSsrKQ0KCW5zID0gbnMtPm5leHQ7DQoNCiAgICBpZiAo bnMgIT0gMCkgew0KCWl0ZXItPmN1cm5vZGUgPSAoeG1sTm9kZVB0cikgbnM7DQoJcmV0dXJuIDE7 DQogICAgfQ0KDQogICAgY3VyID0gaXRlci0+bm9kZS0+cHJvcGVydGllczsNCiAgICBpZiAoY3Vy ID09IDApDQoJcmV0dXJuIDA7DQoNCiAgICBmb3IgKDsgaSA8IG5vOyBpKyspIHsNCgljdXIgPSBj dXItPm5leHQ7DQoJaWYoY3VyID09IDApDQoJICAgIHJldHVybiAwOw0KICAgIH0NCg0KICAgIGl0 ZXItPmN1cm5vZGUgPSAoeG1sTm9kZVB0cikgY3VyOw0KICAgIHJldHVybiAxOw0KfQ0KDQovKioN CiAqIHhtbERvY1dhbGtlck1vdmVUb0F0dHJpYnV0ZToNCiAqIEBpdGVyOiAgdGhlIHhtbERvY1dh bGtlclB0cg0KICogQG5hbWU6IHRoZSBxdWFsaWZpZWQgbmFtZSBvZiB0aGUgYXR0cmlidXRlLg0K ICoNCiAqIE1vdmVzIHRoZSBwb3NpdGlvbiBvZiB0aGUgY3VycmVudCBpbnN0YW5jZSB0byB0aGUg YXR0cmlidXRlIHdpdGgNCiAqIHRoZSBzcGVjaWZpZWQgcXVhbGlmaWVkIG5hbWUuDQogKg0KICog UmV0dXJucyAxIGluIGNhc2Ugb2Ygc3VjY2VzcywgLTEgaW4gY2FzZSBvZiBlcnJvciwgMCBpZiBu b3QgZm91bmQNCiAqLw0KaW50DQp4bWxEb2NXYWxrZXJNb3ZlVG9BdHRyaWJ1dGUoeG1sRG9jV2Fs a2VyUHRyIGl0ZXIsDQoJCQkgICAgY29uc3QgeG1sQ2hhciAqbmFtZSkNCnsNCiAgICB4bWxDaGFy ICpwcmVmaXggPSBOVUxMOw0KICAgIHhtbENoYXIgKmxvY2FsbmFtZSA9IE5VTEw7DQogICAgeG1s TnNQdHIgbnM7DQogICAgeG1sQXR0clB0ciBwcm9wOw0KICAgIGludCByZXQgPSAwOw0KDQogICAg aWYgKChpdGVyID09IDApIHx8IChpdGVyLT5ub2RlID09IDApIHx8IChuYW1lID09IDApKQ0KCXJl dHVybiAtMTsNCg0KICAgIGlmICgoaXRlci0+c3RhdGUgPT0gWE1MX0RXQUxLX05PTkUpIHx8DQoJ KGl0ZXItPnN0YXRlID09IFhNTF9EV0FMS19CQUNLVFJBQ0spIHx8DQoJKGl0ZXItPnN0YXRlID09 IFhNTF9EV0FMS19FTkQpKQ0KCWdvdG8gbm90X2ZvdW5kOw0KDQogICAgaWYgKGl0ZXItPm5vZGUt PnR5cGUgIT0gWE1MX0VMRU1FTlRfTk9ERSkNCglnb3RvIG5vdF9mb3VuZDsNCg0KICAgIGxvY2Fs bmFtZSA9IHhtbFNwbGl0UU5hbWUyKG5hbWUsICZwcmVmaXgpOw0KICAgIGlmIChsb2NhbG5hbWUg PT0gMCkgew0KCWlmICh4bWxTdHJFcXVhbChuYW1lLCBCQURfQ0FTVCAieG1sbnMiKSkgew0KCSAg ICBucyA9IGl0ZXItPm5vZGUtPm5zRGVmOw0KCSAgICB3aGlsZSAobnMgIT0gMCkgew0KCQlpZiAo bnMtPnByZWZpeCA9PSAwKSB7DQoJCSAgICBpdGVyLT5jdXJub2RlID0gKHhtbE5vZGVQdHIpIG5z Ow0KCQkgICAgZ290byBmb3VuZDsNCgkJfQ0KCQlucyA9IG5zLT5uZXh0Ow0KCSAgICB9DQoNCgkg ICAgZ290byBub3RfZm91bmQ7DQoJfQ0KDQoJcHJvcCA9IGl0ZXItPm5vZGUtPnByb3BlcnRpZXM7 DQoJd2hpbGUgKHByb3AgIT0gMCkgew0KCSAgICBpZiAoeG1sU3RyRXF1YWwocHJvcC0+bmFtZSwg bmFtZSkgJiYNCgkJKChwcm9wLT5ucyA9PSBOVUxMKSB8fCAocHJvcC0+bnMtPnByZWZpeCA9PSBO VUxMKSkpIHsNCgkJaXRlci0+Y3Vybm9kZSA9ICh4bWxOb2RlUHRyKSBwcm9wOw0KCQlnb3RvIGZv dW5kOw0KCSAgICB9DQoJICAgIHByb3AgPSBwcm9wLT5uZXh0Ow0KCX0NCg0KCWdvdG8gbm90X2Zv dW5kOw0KICAgIH0NCg0KICAgIGlmICh4bWxTdHJFcXVhbChwcmVmaXgsIEJBRF9DQVNUICJ4bWxu cyIpKSB7DQoJbnMgPSBpdGVyLT5ub2RlLT5uc0RlZjsNCgl3aGlsZSAobnMgIT0gMCkgew0KCSAg ICBpZiAobnMtPnByZWZpeCAhPSBOVUxMICYmIHhtbFN0ckVxdWFsKG5zLT5wcmVmaXgsIGxvY2Fs bmFtZSkpIHsNCgkJaXRlci0+Y3Vybm9kZSA9ICh4bWxOb2RlUHRyKSBuczsNCgkJZ290byBmb3Vu ZDsNCgkgICAgfQ0KCSAgICBucyA9IG5zLT5uZXh0Ow0KCX0NCglnb3RvIG5vdF9mb3VuZDsNCiAg ICB9DQoNCiAgICBwcm9wID0gaXRlci0+bm9kZS0+cHJvcGVydGllczsNCiAgICB3aGlsZSAocHJv cCAhPSBOVUxMKSB7DQoJaWYgKHhtbFN0ckVxdWFsKHByb3AtPm5hbWUsIGxvY2FsbmFtZSkgJiYN CgkgICAgKHByb3AtPm5zICE9IE5VTEwpICYmIHhtbFN0ckVxdWFsKHByb3AtPm5zLT5wcmVmaXgs IHByZWZpeCkpIHsNCgkgICAgaXRlci0+Y3Vybm9kZSA9ICh4bWxOb2RlUHRyKSBwcm9wOw0KCSAg ICBnb3RvIGZvdW5kOw0KCX0NCglwcm9wID0gcHJvcC0+bmV4dDsNCiAgICB9DQoNCiAgICBpZiAo MCkgZm91bmQ6IHsNCglyZXQgPSAxOw0KICAgIH0NCiBub3RfZm91bmQ6DQogICAgDQogICAgaWYg KGxvY2FsbmFtZSAhPSAwKQ0KCXhtbEZyZWUobG9jYWxuYW1lKTsNCiAgICBpZiAocHJlZml4ICE9 IDApDQoJeG1sRnJlZShwcmVmaXgpOw0KICAgIHJldHVybiByZXQ7DQp9DQoNCi8qKg0KICogeG1s RG9jV2Fsa2VyTW92ZVRvQXR0cmlidXRlTnM6DQogKiBAaXRlcjogIHRoZSB4bWxEb2NXYWxrZXJQ dHINCiAqIEBsb2NhbE5hbWU6ICB0aGUgbG9jYWwgbmFtZSBvZiB0aGUgYXR0cmlidXRlLg0KICog QG5hbWVzcGFjZVVSSTogIHRoZSBuYW1lc3BhY2UgVVJJIG9mIHRoZSBhdHRyaWJ1dGUuDQogKg0K ICogTW92ZXMgdGhlIHBvc2l0aW9uIG9mIHRoZSBjdXJyZW50IGluc3RhbmNlIHRvIHRoZSBhdHRy aWJ1dGUgd2l0aCB0aGUNCiAqIHNwZWNpZmllZCBsb2NhbCBuYW1lIGFuZCBuYW1lc3BhY2UgVVJJ Lg0KICoNCiAqIFJldHVybnMgMSBpbiBjYXNlIG9mIHN1Y2Nlc3MsIC0xIGluIGNhc2Ugb2YgZXJy b3IsIDAgaWYgbm90IGZvdW5kDQogKi8NCmludA0KeG1sRG9jV2Fsa2VyTW92ZVRvQXR0cmlidXRl TnMoeG1sRG9jV2Fsa2VyUHRyIGl0ZXIsDQoJCQkgICAgICBjb25zdCB4bWxDaGFyICpsb2NhbE5h bWUsDQoJCQkgICAgICBjb25zdCB4bWxDaGFyICpuYW1lc3BhY2VVUkkpDQp7DQogICAgeG1sQXR0 clB0ciBwcm9wOw0KICAgIHhtbE5vZGVQdHIgbm9kZTsNCg0KICAgIGlmICgoaXRlciA9PSAwKSB8 fCAoaXRlci0+bm9kZSA9PSAwKSB8fCAobG9jYWxOYW1lID09IDApIHx8IChuYW1lc3BhY2VVUkkg PT0gMCkpDQoJcmV0dXJuIC0xOw0KDQogICAgaWYgKChpdGVyLT5zdGF0ZSA9PSBYTUxfRFdBTEtf Tk9ORSkgfHwNCgkoaXRlci0+c3RhdGUgPT0gWE1MX0RXQUxLX0JBQ0tUUkFDSykgfHwNCgkoaXRl ci0+c3RhdGUgPT0gWE1MX0RXQUxLX0VORCkpDQoJcmV0dXJuIDA7DQoNCiAgICBpZiAoaXRlci0+ bm9kZS0+dHlwZSAhPSBYTUxfRUxFTUVOVF9OT0RFKQ0KCXJldHVybiAwOw0KDQogICAgbm9kZSA9 IGl0ZXItPm5vZGU7DQoNCiAgICBwcm9wID0gbm9kZS0+cHJvcGVydGllczsNCiAgICB3aGlsZSAo cHJvcCAhPSBOVUxMKSB7DQoJaWYgKHhtbFN0ckVxdWFsKHByb3AtPm5hbWUsIGxvY2FsTmFtZSkg JiYNCgkgICAgKChwcm9wLT5ucyAhPSBOVUxMKSAmJiAoeG1sU3RyRXF1YWwocHJvcC0+bnMtPmhy ZWYsIG5hbWVzcGFjZVVSSSkpKSkgew0KCSAgICBpdGVyLT5jdXJub2RlID0gKHhtbE5vZGVQdHIp IHByb3A7DQoJICAgIHJldHVybiAxOw0KCX0NCg0KCXByb3AgPSBwcm9wLT5uZXh0Ow0KICAgIH0N Cg0KICAgIHJldHVybiAwOw0KfQ0KDQovKioNCiAqIHhtbERvY1dhbGtlck1vdmVUb0ZpcnN0QXR0 cmlidXRlOg0KICogQGl0ZXI6ICB0aGUgeG1sRG9jV2Fsa2VyUHRyDQogKg0KICogTW92ZXMgdGhl IHBvc2l0aW9uIG9mIHRoZSBjdXJyZW50IGluc3RhbmNlIHRvIHRoZSBmaXJzdCBhdHRyaWJ1dGUN CiAqIGFzc29jaWF0ZWQgd2l0aCB0aGUgY3VycmVudCBub2RlLg0KICoNCiAqIFJldHVybnMgMSBp biBjYXNlIG9mIHN1Y2Nlc3MsIC0xIGluIGNhc2Ugb2YgZXJyb3IsIDAgaWYgbm90IGZvdW5kDQog Ki8NCmludA0KeG1sRG9jV2Fsa2VyTW92ZVRvRmlyc3RBdHRyaWJ1dGUoeG1sRG9jV2Fsa2VyUHRy IGl0ZXIpDQp7DQogICAgaWYgKChpdGVyID09IDApIHx8IChpdGVyLT5ub2RlID09IDApKQ0KCXJl dHVybiAtMTsNCg0KICAgIGlmICgoaXRlci0+c3RhdGUgPT0gWE1MX0RXQUxLX05PTkUpIHx8DQoJ KGl0ZXItPnN0YXRlID09IFhNTF9EV0FMS19CQUNLVFJBQ0spIHx8DQoJKGl0ZXItPnN0YXRlID09 IFhNTF9EV0FMS19FTkQpKQ0KCXJldHVybiAwOw0KDQogICAgaWYgKGl0ZXItPm5vZGUtPnR5cGUg IT0gWE1MX0VMRU1FTlRfTk9ERSkNCglyZXR1cm4gMDsNCg0KICAgIGlmIChpdGVyLT5ub2RlLT5u c0RlZiAhPSBOVUxMKSB7DQoJaXRlci0+Y3Vybm9kZSA9ICh4bWxOb2RlUHRyKSBpdGVyLT5ub2Rl LT5uc0RlZjsNCglyZXR1cm4gMTsNCiAgICB9DQoNCiAgICBpZiAoaXRlci0+bm9kZS0+cHJvcGVy dGllcyAhPSBOVUxMKSB7DQoJaXRlci0+Y3Vybm9kZSA9ICh4bWxOb2RlUHRyKSBpdGVyLT5ub2Rl LT5wcm9wZXJ0aWVzOw0KCXJldHVybiAxOw0KICAgIH0NCg0KICAgIHJldHVybiAwOw0KfQ0KDQov KioNCiAqIHhtbERvY1dhbGtlck1vdmVUb05leHRBdHRyaWJ1dGU6DQogKiBAaXRlcjogIHRoZSB4 bWxEb2NXYWxrZXJQdHINCiAqDQogKiBNb3ZlcyB0aGUgcG9zaXRpb24gb2YgdGhlIGN1cnJlbnQg aW5zdGFuY2UgdG8gdGhlIG5leHQgYXR0cmlidXRlDQogKiBhc3NvY2lhdGVkIHdpdGggdGhlIGN1 cnJlbnQgbm9kZS4NCiAqDQogKiBSZXR1cm5zIDEgaW4gY2FzZSBvZiBzdWNjZXNzLCAtMSBpbiBj YXNlIG9mIGVycm9yLCAwIGlmIG5vdCBmb3VuZA0KICovDQppbnQNCnhtbERvY1dhbGtlck1vdmVU b05leHRBdHRyaWJ1dGUoeG1sRG9jV2Fsa2VyUHRyIGl0ZXIpDQp7DQogICAgaWYgKChpdGVyID09 IDApIHx8IChpdGVyLT5ub2RlID09IDApKQ0KCXJldHVybiAtMTsNCg0KICAgIGlmICgoaXRlci0+ c3RhdGUgPT0gWE1MX0RXQUxLX05PTkUpIHx8DQoJKGl0ZXItPnN0YXRlID09IFhNTF9EV0FMS19C QUNLVFJBQ0spIHx8DQoJKGl0ZXItPnN0YXRlID09IFhNTF9EV0FMS19FTkQpKQ0KCXJldHVybiAw Ow0KDQogICAgaWYgKGl0ZXItPm5vZGUtPnR5cGUgIT0gWE1MX0VMRU1FTlRfTk9ERSkNCglyZXR1 cm4gMDsNCiAgICBpZiAoaXRlci0+Y3Vybm9kZSA9PSBOVUxMKQ0KCXJldHVybih4bWxEb2NXYWxr ZXJNb3ZlVG9GaXJzdEF0dHJpYnV0ZShpdGVyKSk7DQoNCiAgICBpZiAoaXRlci0+Y3Vybm9kZS0+ dHlwZSA9PSBYTUxfTkFNRVNQQUNFX0RFQ0wpIHsNCgl4bWxOc1B0ciBucyA9ICh4bWxOc1B0cikg aXRlci0+Y3Vybm9kZTsNCglpZiAobnMtPm5leHQgIT0gTlVMTCkgew0KCSAgICBpdGVyLT5jdXJu b2RlID0gKHhtbE5vZGVQdHIpIG5zLT5uZXh0Ow0KCSAgICByZXR1cm4gMTsNCgl9DQoJaWYgKGl0 ZXItPm5vZGUtPnByb3BlcnRpZXMgIT0gTlVMTCkgew0KCSAgICBpdGVyLT5jdXJub2RlID0gKHht bE5vZGVQdHIpIGl0ZXItPm5vZGUtPnByb3BlcnRpZXM7DQoJICAgIHJldHVybiAxOw0KCX0NCg0K CXJldHVybiAwOw0KICAgIH0NCiAgICBlbHNlIGlmICgoaXRlci0+Y3Vybm9kZS0+dHlwZSA9PSBY TUxfQVRUUklCVVRFX05PREUpICYmDQoJICAgICAoaXRlci0+Y3Vybm9kZS0+bmV4dCAhPSBOVUxM KSkgew0KCWl0ZXItPmN1cm5vZGUgPSBpdGVyLT5jdXJub2RlLT5uZXh0Ow0KCXJldHVybiAxOw0K ICAgIH0NCg0KICAgIHJldHVybiAwOw0KfQ0KDQovKioNCiAqIHhtbERvY1dhbGtlck1vdmVUb0Vs ZW1lbnQ6DQogKiBAaXRlcjogIHRoZSB4bWxEb2NXYWxrZXJQdHINCiAqDQogKiBNb3ZlcyB0aGUg cG9zaXRpb24gb2YgdGhlIGN1cnJlbnQgaW5zdGFuY2UgdG8gdGhlIG5vZGUgdGhhdA0KICogY29u dGFpbnMgdGhlIGN1cnJlbnQgQXR0cmlidXRlICBub2RlLg0KICoNCiAqIFJldHVybnMgMSBpbiBj YXNlIG9mIHN1Y2Nlc3MsIC0xIGluIGNhc2Ugb2YgZXJyb3IsIDAgaWYgbm90IG1vdmVkDQogKi8N CmludA0KeG1sRG9jV2Fsa2VyTW92ZVRvRWxlbWVudCh4bWxEb2NXYWxrZXJQdHIgaXRlcikNCnsN CiAgICBpZiAoKGl0ZXIgPT0gMCkgfHwgKGl0ZXItPm5vZGUgPT0gMCkpDQoJcmV0dXJuIC0xOw0K DQogICAgaWYgKChpdGVyLT5zdGF0ZSA9PSBYTUxfRFdBTEtfTk9ORSkgfHwNCgkoaXRlci0+c3Rh dGUgPT0gWE1MX0RXQUxLX0JBQ0tUUkFDSykgfHwNCgkoaXRlci0+c3RhdGUgPT0gWE1MX0RXQUxL X0VORCkpDQoJcmV0dXJuIDA7DQoNCiAgICBpZiAoaXRlci0+bm9kZS0+dHlwZSAhPSBYTUxfRUxF TUVOVF9OT0RFKQ0KCXJldHVybiAwOw0KDQogICAgaWYgKGl0ZXItPmN1cm5vZGUgIT0gTlVMTCkg ew0KCWl0ZXItPmN1cm5vZGUgPSBOVUxMOw0KCXJldHVybiAxOw0KICAgIH0NCg0KICAgIHJldHVy biAwOw0KfQ0KDQovKioNCiAqIHhtbERvY1dhbGtlckN1cnJlbnROb2RlOg0KICogQGl0ZXI6ICB0 aGUgeG1sRG9jV2Fsa2VyUHRyDQogKg0KICogSGFja2luZyBpbnRlcmZhY2UgYWxsb3dpbmcgdG8g Z2V0IHRoZSB4bWxOb2RlUHRyIGNvcnJlcG9uZGluZyB0byB0aGUNCiAqIGN1cnJlbnQgbm9kZSBi ZWluZyBhY2Nlc3NlZCBieSB0aGUgeG1sRG9jV2Fsa2VyLg0KICoNCiAqIFJldHVybnMgdGhlIHht bE5vZGVQdHIgb3IgTlVMTCBpbiBjYXNlIG9mIGVycm9yLg0KICovDQp4bWxOb2RlUHRyDQp4bWxE b2NXYWxrZXJDdXJyZW50Tm9kZSh4bWxEb2NXYWxrZXJQdHIgaXRlcikNCnsNCiAgICBpZiAoaXRl ciA9PSAwKQ0KCXJldHVybiAwOw0KDQogICAgaWYgKGl0ZXItPmN1cm5vZGUgIT0gTlVMTCkNCgly ZXR1cm4gaXRlci0+Y3Vybm9kZTsNCg0KICAgIHJldHVybiBpdGVyLT5ub2RlOw0KfQ0KDQovKioN CiAqIHhtbERvY1dhbGtlckN1cnJlbnREb2M6DQogKiBAaXRlcjogIHRoZSB4bWxEb2NXYWxrZXJQ dHINCiAqDQogKiBIYWNraW5nIGludGVyZmFjZSBhbGxvd2luZyB0byBnZXQgdGhlIHhtbERvY1B0 ciBjb3JyZXBvbmRpbmcgdG8gdGhlDQogKiBjdXJyZW50IGRvY3VtZW50IGJlaW5nIGFjY2Vzc2Vk IGJ5IHRoZSB4bWxEb2NXYWxrZXIuDQogKg0KICogUmV0dXJucyB0aGUgeG1sRG9jUHRyIG9yIE5V TEwgaW4gY2FzZSBvZiBlcnJvci4NCiAqLw0KeG1sRG9jUHRyDQp4bWxEb2NXYWxrZXJDdXJyZW50 RG9jKHhtbERvY1dhbGtlclB0ciBpdGVyKQ0Kew0KICAgIGlmIChpdGVyID09IDApDQoJcmV0dXJu IDA7DQoNCiAgICByZXR1cm4gaXRlci0+ZG9jOw0KfQ0KDQovKioNCiAqIHhtbERvY1dhbGtlck5l eHQ6DQogKiBAaXRlcjogIHRoZSB4bWxEb2NXYWxrZXJQdHINCiAqDQogKiBTdGVwIHRvIHRoZSBu ZXh0IHNpYmxpbmcgb2YgdGhlIGN1cnJlbnQgbm9kZSBpbiBkb2N1bWVudCBvcmRlcg0KICoNCiAq IFJldHVybnMgMSBpZiBvaywgMCBpZiB0aGVyZSBhcmUgbm8gbW9yZSBub2Rlcywgb3IgLTEgaW4g Y2FzZSBvZiBlcnJvcg0KICovDQppbnQNCnhtbERvY1dhbGtlck5leHQoeG1sRG9jV2Fsa2VyUHRy IGl0ZXIpDQp7DQogICAgaWYgKChpdGVyID09IDApIHx8IChpdGVyLT5kb2MgPT0gMCkpDQogICAg cmV0dXJuIC0xOw0KDQogICAgaWYgKGl0ZXItPnN0YXRlID09IFhNTF9EV0FMS19FTkQpDQogICAg cmV0dXJuIDA7DQoNCiAgICBpZiAoaXRlci0+bm9kZSA9PSAwKQ0KICAgIHJldHVybiB4bWxEb2NX YWxrZXJTdGVwKGl0ZXIpOw0KDQogICAgaWYgKGl0ZXItPm5vZGUtPm5leHQgIT0gMCkgew0KICAg IGl0ZXItPm5vZGUgPSBpdGVyLT5ub2RlLT5uZXh0Ow0KICAgIGl0ZXItPnN0YXRlID0gWE1MX0RX QUxLX1NUQVJUOw0KICAgIHJldHVybiAxOw0KICAgIH0NCg0KICAgIHJldHVybiAwOw0KfQ0K ------=_NextPart_000_23B47_01C389C3.456C0140-- From veillard@redhat.com Fri Oct 3 09:31:33 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 3210C1841B for ; Fri, 3 Oct 2003 09:31:33 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h93DViQ10326; Fri, 3 Oct 2003 09:31:44 -0400 Date: Fri, 3 Oct 2003 09:31:44 -0400 From: Daniel Veillard To: GARNIER Pierre Cc: xml@gnome.org Subject: Re: [xml] Current line number and position with xmlTextReader API Message-ID: <20031003093144.L21001@redhat.com> Reply-To: veillard@redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from pgarnier@mega.com on Fri, Oct 03, 2003 at 02:41:07PM +0100 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Fri, Oct 03, 2003 at 02:41:07PM +0100, GARNIER Pierre wrote: > Hello, > > I'm using xmlTextReader API. > I would like to know the position of the current node in the document at any > moment of the read. > > I think that I can get the line number by calling : > nbline = xmlGetLineNo(xmlTextReaderCurrentNode(reader)); yes, that should work. > How can I get the position in the line? Is it possible? Hum, no, that's not stored in the tree :-\ Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From rrichards@ctindustries.net Fri Oct 3 09:43:46 2003 Return-Path: Delivered-To: xml@gnome.org Received: from phoebe.host4u.net (phoebe.host4u.net [209.150.128.26]) by mail.gnome.org (Postfix) with ESMTP id D73DD181DF for ; Fri, 3 Oct 2003 09:43:45 -0400 (EDT) Received: from ctdrob (dsta-aa203.pivot.net [66.186.171.203]) by phoebe.host4u.net (8.11.6/8.11.6) with SMTP id h93Dhq109256; Fri, 3 Oct 2003 08:43:52 -0500 Message-ID: <025201c389b4$8f9dfc00$f7dea8c0@cyberware.local> From: "Rob Richards" To: Cc: References: <074801c3888f$72d15c50$f7dea8c0@cyberware.local> <20031002021116.X21529@redhat.com> <00e301c388eb$4cae9db0$f7dea8c0@cyberware.local> <20031002124356.B21001@redhat.com> <032f01c38917$412c47e0$f7dea8c0@cyberware.local> <20031002154905.C21001@redhat.com> Subject: Re: [xml] xmlRemoveID patch Date: Fri, 3 Oct 2003 09:45:08 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_024F_01C38993.0831B8E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_024F_01C38993.0831B8E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit From: Daniel Veillard > Well if you have a new patch which works with CVS, please send it, though > creating that new xmlReaderFreeID() is the right solution. Attatched is the new patch. I was able to run the regression tests on a laptop and they appear to be fine. the changes include the following: xmlFreeProp - removed the checking for intSubset, extSubset and doc the doc is checked in xmlRemoveID and the others arent required to add an id - check is now just cur->parent != NULL and xmlIsID(..) xmlUnlinkNode - in the attribute block, xmlRemoveID was added as IDs need to be removed if an attribute is unlinked added xmlReaderFreeID function added a static removeID function which both xmlRemoveID and xmlReaderFreeID call since the code is the same other than the line on how to deal with the xmlIDPtr xmlTextReaderFreeProp - uses the xmlReaderFreeID function - did not change the test for intSubset or extSubset as it didnt seem that IDs could be added on the fly like in DOM. Let me know if anyone sees any issues with this patch. Thanks, Rob ------=_NextPart_000_024F_01C38993.0831B8E0 Content-Type: text/plain; name="libxml.diff.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="libxml.diff.txt" Index: tree.c =================================================================== RCS file: /cvs/gnome/gnome-xml/tree.c,v retrieving revision 1.281 diff -c -r1.281 tree.c *** tree.c 29 Sep 2003 18:02:37 -0000 1.281 --- tree.c 3 Oct 2003 12:56:50 -0000 *************** *** 1963,1974 **** xmlDeregisterNodeDefaultValue((xmlNodePtr)cur); /* Check for ID removal -> leading to invalid references ! */ ! if ((cur->parent != NULL) && (cur->parent->doc != NULL) && ! ((cur->parent->doc->intSubset != NULL) || ! (cur->parent->doc->extSubset != NULL))) { ! if (xmlIsID(cur->parent->doc, cur->parent, cur)) xmlRemoveID(cur->parent->doc, cur); - } if (cur->children != NULL) xmlFreeNodeList(cur->children); DICT_FREE(cur->name) xmlFree(cur); --- 1963,1970 ---- xmlDeregisterNodeDefaultValue((xmlNodePtr)cur); /* Check for ID removal -> leading to invalid references ! */ ! if (cur->parent != NULL && xmlIsID(cur->parent->doc, cur->parent, cur)) xmlRemoveID(cur->parent->doc, cur); if (cur->children != NULL) xmlFreeNodeList(cur->children); DICT_FREE(cur->name) xmlFree(cur); *************** *** 3365,3370 **** --- 3361,3368 ---- if (cur->type == XML_ATTRIBUTE_NODE) { if (parent->properties == (xmlAttrPtr) cur) parent->properties = ((xmlAttrPtr) cur)->next; + if (xmlIsID(cur->parent->doc, cur->parent, (xmlAttrPtr) cur)) + xmlRemoveID(cur->parent->doc, (xmlAttrPtr) cur); } else { if (parent->children == cur) parent->children = cur->next; Index: valid.c =================================================================== RCS file: /cvs/gnome/gnome-xml/valid.c,v retrieving revision 1.164 diff -c -r1.164 valid.c *** valid.c 2 Oct 2003 22:28:07 -0000 1.164 --- valid.c 3 Oct 2003 12:56:54 -0000 *************** *** 2388,2405 **** return(0); } ! /** ! * xmlRemoveID: ! * @doc: the document ! * @attr: the attribute ! * ! * Remove the given attribute from the ID table maintained internally. ! * ! * Returns -1 if the lookup failed and 0 otherwise ! */ ! int ! xmlRemoveID(xmlDocPtr doc, xmlAttrPtr attr) { ! xmlAttrPtr cur; xmlIDTablePtr table; xmlChar *ID; --- 2388,2395 ---- return(0); } ! static int removeID(xmlDocPtr doc, xmlAttrPtr attr, int isStream) { ! xmlIDPtr cur; xmlIDTablePtr table; xmlChar *ID; *************** *** 2410,2430 **** return(-1); if (attr == NULL) ! return(-1); ID = xmlNodeListGetString(doc, attr->children, 1); if (ID == NULL) ! return(-1); cur = xmlHashLookup(table, ID); ! if (cur != attr) { ! xmlFree(ID); ! return(-1); } ! xmlHashUpdateEntry(table, ID, NULL, (xmlHashDeallocator) xmlFreeID); xmlFree(ID); return(0); } /** * xmlGetID: * @doc: pointer to the document * @ID: the ID value --- 2400,2452 ---- return(-1); if (attr == NULL) ! return(-1); ID = xmlNodeListGetString(doc, attr->children, 1); if (ID == NULL) ! return(-1); cur = xmlHashLookup(table, ID); ! if (cur->attr == NULL || cur->attr != attr) { ! xmlFree(ID); ! return(-1); } ! if (isStream == 1) { ! cur->attr = NULL; ! } else { ! xmlHashRemoveEntry(table, ID, (xmlHashDeallocator) xmlFreeID); ! } xmlFree(ID); return(0); } /** + * xmlRemoveID: + * @doc: the document + * @attr: the attribute + * + * Remove the given attribute from the ID table maintained internally. + * + * Returns -1 if the lookup failed and 0 otherwise + */ + int + xmlRemoveID(xmlDocPtr doc, xmlAttrPtr attr) { + return removeID(doc, attr, 0); + } + + /** + * xmlReaderFreeID: + * @doc: the document + * @attr: the attribute + * + * Remove the given attribute from the ID table maintained internally. + * + * Returns -1 if the lookup failed and 0 otherwise + */ + int + xmlReaderFreeID(xmlDocPtr doc, xmlAttrPtr attr) { + return removeID(doc, attr, 1); + } + + /** * xmlGetID: * @doc: pointer to the document * @ID: the ID value Index: xmlreader.c =================================================================== RCS file: /cvs/gnome/gnome-xml/xmlreader.c,v retrieving revision 1.71 diff -c -r1.71 xmlreader.c *** xmlreader.c 1 Oct 2003 09:05:25 -0000 1.71 --- xmlreader.c 3 Oct 2003 12:56:57 -0000 *************** *** 185,191 **** ((cur->parent->doc->intSubset != NULL) || (cur->parent->doc->extSubset != NULL))) { if (xmlIsID(cur->parent->doc, cur->parent, cur)) ! xmlRemoveID(cur->parent->doc, cur); } if (cur->children != NULL) xmlTextReaderFreeNodeList(reader, cur->children); --- 185,191 ---- ((cur->parent->doc->intSubset != NULL) || (cur->parent->doc->extSubset != NULL))) { if (xmlIsID(cur->parent->doc, cur->parent, cur)) ! xmlReaderFreeID(cur->parent->doc, cur); } if (cur->children != NULL) xmlTextReaderFreeNodeList(reader, cur->children); Index: doc/libxml2-api.xml =================================================================== RCS file: /cvs/gnome/gnome-xml/doc/libxml2-api.xml,v retrieving revision 1.72 diff -c -r1.72 libxml2-api.xml *** doc/libxml2-api.xml 2 Oct 2003 22:28:08 -0000 1.72 --- doc/libxml2-api.xml 3 Oct 2003 12:57:18 -0000 *************** *** 948,953 **** --- 948,954 ---- + Index: include/libxml/valid.h =================================================================== RCS file: /cvs/gnome/gnome-xml/include/libxml/valid.h,v retrieving revision 1.45 diff -c -r1.45 valid.h *** include/libxml/valid.h 29 Sep 2003 13:20:22 -0000 1.45 --- include/libxml/valid.h 3 Oct 2003 12:57:19 -0000 *************** *** 244,249 **** --- 244,252 ---- XMLPUBFUN int XMLCALL xmlRemoveID (xmlDocPtr doc, xmlAttrPtr attr); + XMLPUBFUN int XMLCALL + xmlReaderFreeID (xmlDocPtr doc, + xmlAttrPtr attr); /* IDREFs */ XMLPUBFUN xmlRefPtr XMLCALL ------=_NextPart_000_024F_01C38993.0831B8E0-- From veillard@redhat.com Fri Oct 3 09:46:50 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 02F3F181DF for ; Fri, 3 Oct 2003 09:46:50 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h93Dl1J16688; Fri, 3 Oct 2003 09:47:01 -0400 Date: Fri, 3 Oct 2003 09:47:01 -0400 From: Daniel Veillard To: "Mickautsch, Alfred" Cc: xml@gnome.org Subject: Re: WG: [xml] WG: Document traversing interface for libxml2 Message-ID: <20031003094701.M21001@redhat.com> Reply-To: veillard@redhat.com References: <4F38C8B9DAB1014DBDCB29538BBFD6A1285080@pandora.schuler-ag.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <4F38C8B9DAB1014DBDCB29538BBFD6A1285080@pandora.schuler-ag.com>; from alfred.mickautsch@schuler-ag.com on Fri, Oct 03, 2003 at 03:30:24PM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Fri, Oct 03, 2003 at 03:30:24PM +0200, Mickautsch, Alfred wrote: > Thank you Bjorn, > > since I just sent a patch for the original to the list, here is your version with the patch I just sent. Okay, I had a quick glance at it, the code looks okay, some minor tweaking will be needed for integration, I will do this when my tree is back to a decent shape, thanks to you and Bjorn ! Bjorn, if you want an xmlWriter, I think I already said it was a good idea in the past, code welcome :-) Damn 2.6.0 will be very different from 2.5.x ... Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From pgarnier@mega.com Fri Oct 3 10:31:06 2003 Return-Path: Delivered-To: xml@gnome.org Received: from rio.mega.com (rio.mega.com [213.11.73.221]) by mail.gnome.org (Postfix) with ESMTP id B2AB518720 for ; Fri, 3 Oct 2003 10:31:05 -0400 (EDT) Received: from relay.mega.com by rio.mega.com via smtpd (for moniker.gnome.org [67.72.78.218]) with ESMTP; Fri, 3 Oct 2003 16:31:04 +0100 Received: from xor.mega.com ([194.3.176.3]) by relay with InterScan Messaging Security Suite; Fri, 03 Oct 2003 16:28:22 +0100 Received: from rio.fr.mega.com by xor.mega.com via smtpd (for relay.mega.com [192.168.167.9]) with ESMTP; Fri, 3 Oct 2003 16:31:00 +0100 Received: by RIO with Internet Mail Service (5.5.2653.19) id <4DBWBZ5W>; Fri, 3 Oct 2003 16:30:42 +0100 Message-ID: From: GARNIER Pierre To: "'veillard@redhat.com'" Cc: xml@gnome.org Subject: RE : [xml] Current line number and position with xmlTextReader AP I Date: Fri, 3 Oct 2003 16:30:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Thanks. Should it be an evolution? (store the position in the line) -----Message d'origine----- De : Daniel Veillard [mailto:veillard@redhat.com]=20 Envoy=E9 : vendredi 3 octobre 2003 14:32 =C0 : GARNIER Pierre Cc : xml@gnome.org Objet : Re: [xml] Current line number and position with xmlTextReader = API On Fri, Oct 03, 2003 at 02:41:07PM +0100, GARNIER Pierre wrote: > Hello, >=20 > I'm using xmlTextReader API. > I would like to know the position of the current node in the document = > at any moment of the read. >=20 > I think that I can get the line number by calling : > nbline =3D xmlGetLineNo(xmlTextReaderCurrentNode(reader)); yes, that should work. > How can I get the position in the line? Is it possible? Hum, no, that's not stored in the tree :-\ Daniel --=20 Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit = http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From Hans.Feder@gfk.de Fri Oct 3 11:40:40 2003 Return-Path: Delivered-To: xml@gnome.org Received: from dns2.gfk.de (dns2.gfk.de [212.114.252.99]) by mail.gnome.org (Postfix) with ESMTP id BB1DA18B55 for ; Fri, 3 Oct 2003 11:40:40 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by dns2.gfk.de (Postfix on SuSE SLES-7 (i386)) with ESMTP id A8C71722 for ; Fri, 3 Oct 2003 17:40:52 +0200 (CEST) Received: from gfk-smtp.gfk.de (gfk-smtp.gfk.de [10.10.4.46]) by dns2.gfk.de (Postfix on SuSE SLES-7 (i386)) with ESMTP id 72450717 for ; Fri, 3 Oct 2003 17:40:51 +0200 (CEST) To: xml@gnome.org X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: Hans.Feder@gfk.de Date: Fri, 3 Oct 2003 17:40:48 +0200 X-MIMETrack: Serialize by Router on GFK-SMTP/GFK/DE(Release 5.0.10 |March 22, 2002) at 03.10.2003 17:40:51 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Virus-Scanned: by AMaViS perl-11 Subject: [xml] Huge chunks in the callback function sax.characters Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hello, I'm going to parse large xml-files and therefore using SAX seems a goo= d idea. When I parse throught the file I got no more than 4000 bytes. I assume = this is the maximum of the xmlChar length. I don't find any hints whether in= the documentation nor in the mailing list how I can increase the buffersize= . Is there any possiblity to handle such huge chunks with libxml->sax? Thanks Hans _____________________________________________________________________ Diese E-Mail (ggf. nebst Anhang) enth=E4lt vertrauliche und/oder rechtl= ich gesch=FCtzte Informationen. Wenn Sie nicht der richtige Adressat sind o= der diese E-Mail irrt=FCmlich erhalten haben, informieren Sie bitte sofort = den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail (and any attachment/s) contains confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. _____________________________________________________________________ = From veillard@redhat.com Fri Oct 3 11:51:22 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 76A0718AC2 for ; Fri, 3 Oct 2003 11:51:22 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h93FpXu14798; Fri, 3 Oct 2003 11:51:33 -0400 Date: Fri, 3 Oct 2003 11:51:33 -0400 From: Daniel Veillard To: GARNIER Pierre Cc: xml@gnome.org Subject: Re: RE : [xml] Current line number and position with xmlTextReader AP I Message-ID: <20031003115132.N21001@redhat.com> Reply-To: veillard@redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from pgarnier@mega.com on Fri, Oct 03, 2003 at 04:30:42PM +0100 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Fri, Oct 03, 2003 at 04:30:42PM +0100, GARNIER Pierre wrote: > Thanks. > Should it be an evolution? (store the position in the line) no, there is no room for it in the xmlNode structure. The only way is to catch the error immediately in the callback and then check ctxt->input buffer for more details, assuming it's about error reporting. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From eday@obj-sys.com Fri Oct 3 11:52:20 2003 Return-Path: Delivered-To: xml@gnome.org Received: from malone.intellispace.net (malone.intellispace.net [160.79.145.141]) by mail.gnome.org (Postfix) with ESMTP id 9B04C18B14 for ; Fri, 3 Oct 2003 11:52:20 -0400 (EDT) Received: from objsys1 (66.9.62.72) by malone.intellispace.net (5.1.053) id 3F7301BA0017C183 for xml@gnome.org; Fri, 3 Oct 2003 11:52:12 -0400 Message-ID: <062701c389c7$23ceabb0$483e0942@objsys1> From: "Ed Day" To: Date: Fri, 3 Oct 2003 11:58:08 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0624_01C389A5.9CAC42D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [xml] Differences in DOM parsing on Windows and UNIX? Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_0624_01C389A5.9CAC42D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have been successfully using libxml2 in a Windows environment for = several months now. But now I am trying to port to UNIX (Solaris 8) and = it appears the DOM tree created in the two environments is different. = For the following simple XML schema specification:=20 On Windows, I get:=20 ELEMENT xsd:simpleType ATTRIBUTE name TEXT content=3DEmployeeNumber ELEMENT xsd:restriction ... On UNIX, I get:=20 ELEMENT xsd:simpleType ATTRIBUTE name TEXT content=3DEmployeeNumber TEXT content=3D =20 ELEMENT xsd:restriction ... Extra text nodes are inserted for whitespace. Is this a configuration = issue? If not, which version is correct? I used the standard out-of-the-box build procedure in both cases and = built from source code instead of using the pre-compiled binaries. Has = anyone else observed this behavior? It would be good to know before I = start digging into the code.=20 BTW: I am using version 2.5.11. Regards,=20 Ed Day ------=_NextPart_000_0624_01C389A5.9CAC42D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have been successfully using libxml2 = in a Windows=20 environment for several months now.  But now I am trying to port to = UNIX=20 (Solaris 8) and it appears the DOM tree created in the two environments = is=20 different.  For the following simple XML schema specification:=20
 
   <xsd:simpleType=20 name=3D"EmployeeNumber">
      = <xsd:restriction=20 base=3D"xsd:integer" minInclusive=3D"10"/>
  =20 </xsd:simpleType>
On Windows, I get:
 
    ELEMENT=20 xsd:simpleType
      ATTRIBUTE=20 name
       =20 TEXT
         =20 content=3DEmployeeNumber
      ELEMENT=20 xsd:restriction
     ...
 
On UNIX, I get:
 
    ELEMENT=20 xsd:simpleType
      ATTRIBUTE=20 name
       =20 TEXT
         =20 content=3DEmployeeNumber
     =20 TEXT
       =20 content=3D       =
     =20 ELEMENT xsd:restriction
    ...
 
Extra text nodes are inserted for = whitespace. =20 Is this a configuration issue?  If not, which version is=20 correct?
 
I used the standard out-of-the-box = build procedure=20 in both cases and built from source code instead of using the = pre-compiled=20 binaries.  Has anyone else observed this behavior?  It would = be good=20 to know before I start digging into the code.
 
BTW: I am using version = 2.5.11.
 
Regards,
 
Ed Day
 
------=_NextPart_000_0624_01C389A5.9CAC42D0-- From veillard@redhat.com Fri Oct 3 11:54:05 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 984CD18AC2 for ; Fri, 3 Oct 2003 11:54:04 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h93FsFm16453; Fri, 3 Oct 2003 11:54:15 -0400 Date: Fri, 3 Oct 2003 11:54:15 -0400 From: Daniel Veillard To: Hans.Feder@gfk.de Cc: xml@gnome.org Subject: Re: [xml] Huge chunks in the callback function sax.characters Message-ID: <20031003115415.O21001@redhat.com> Reply-To: veillard@redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from Hans.Feder@gfk.de on Fri, Oct 03, 2003 at 05:40:48PM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Fri, Oct 03, 2003 at 05:40:48PM +0200, Hans.Feder@gfk.de wrote: > Hello, > > I'm going to parse large xml-files and therefore using SAX seems a good > idea. > > When I parse throught the file I got no more than 4000 bytes. I assume this > is the maximum of the xmlChar length. I don't find any hints whether in the > documentation nor in the mailing list how I can increase the buffersize. > Is there any possiblity to handle such huge chunks with libxml->sax? You can't change the size. That's needed to avoid DOS attacks. You can handle large data, you just get multiple consecutive character callbacks instead. I think the Java SAX and expat SAX work the same way. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard@redhat.com Fri Oct 3 11:57:57 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 53FA218D6E for ; Fri, 3 Oct 2003 11:57:57 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h93Fw9v20429; Fri, 3 Oct 2003 11:58:09 -0400 Date: Fri, 3 Oct 2003 11:58:09 -0400 From: Daniel Veillard To: Ed Day Cc: xml@gnome.org Subject: Re: [xml] Differences in DOM parsing on Windows and UNIX? Message-ID: <20031003115809.P21001@redhat.com> Reply-To: veillard@redhat.com References: <062701c389c7$23ceabb0$483e0942@objsys1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <062701c389c7$23ceabb0$483e0942@objsys1>; from eday@obj-sys.com on Fri, Oct 03, 2003 at 11:58:08AM -0400 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Fri, Oct 03, 2003 at 11:58:08AM -0400, Ed Day wrote: > Extra text nodes are inserted for whitespace. Is this a configuration issue? If not, which version is correct? > > I used the standard out-of-the-box build procedure in both cases and built from source code instead of using the pre-compiled binaries. Has anyone else observed this behavior? It would be good to know before I start digging into the code. Hum, sounds like xmlKeepBlanksDefaultValue is wrongly initialized to 0 on your Windows build while it should be 1 as properly compiled on Unix. /** * xmlKeepBlanksDefaultValue: * * Global setting, indicate that the parser should keep all blanks * nodes found in the content * Activated by default, this is actually needed to have the parser * conformant to the XML Recommendation, however the option is kept * for some applications since this was libxml1 default behaviour. */ int xmlKeepBlanksDefaultValue = 1; see if your compiler miscompiled globals.c on Windows. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From Hans.Feder@gfk.de Fri Oct 3 12:59:08 2003 Return-Path: Delivered-To: xml@gnome.org Received: from dns2.gfk.de (dns2.gfk.de [212.114.252.99]) by mail.gnome.org (Postfix) with ESMTP id 9AA1018457; Fri, 3 Oct 2003 12:59:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by dns2.gfk.de (Postfix on SuSE SLES-7 (i386)) with ESMTP id C88D57B5; Fri, 3 Oct 2003 18:59:18 +0200 (CEST) Received: from gfk-smtp.gfk.de (gfk-smtp.gfk.de [10.10.4.46]) by dns2.gfk.de (Postfix on SuSE SLES-7 (i386)) with ESMTP id 9145D7B0; Fri, 3 Oct 2003 18:59:17 +0200 (CEST) Subject: Antwort: Re: [xml] Huge chunks in the callback function sax.characters To: veillard@redhat.com Cc: xml@gnome.org, xml-admin@gnome.org X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: Hans.Feder@gfk.de Date: Fri, 3 Oct 2003 18:59:14 +0200 X-MIMETrack: Serialize by Router on GFK-SMTP/GFK/DE(Release 5.0.10 |March 22, 2002) at 03.10.2003 18:59:17 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: by AMaViS perl-11 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Daniel, mercy. I should clean by glasses. Just for a test I made an extract from the xml-file with a very big chunk of data and ran it throught testSAX with the following result: SAX.setDocumentLocator() SAX.startDocument() SAX.startElement(tab) SAX.startElement(data, rows='83', cols='48') SAX.characters(35385,16630876.08,36965,85881,, 7863) SAX.characters(92.39,90,624,305.50,56.00,1654, 4000) SAX.characters(277453.52,14242854.95,50090,36, 4000) SAX.characters(1596.59,22188570.44,22044702.8, 4000) SAX.characters(8792.00,44,76,35.75,12.75,5554, 4000) SAX.characters(474.00,7,21,16.00,3.00,1966670, 4000) SAX.characters(,19900332.25,14155,2530397.20,, 929) SAX.endElement(data) SAX.endElement(tab) SAX.endDocument() As you can see, in the first function call of characters the length is 7863. Cool. I'm wondering a little bit. Anyway, thanks a lot for your help!!! Cheers Hans From veillard@redhat.com Fri Oct 3 19:59:38 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id F3F1318116 for ; Fri, 3 Oct 2003 19:59:37 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h93Nxnf23513; Fri, 3 Oct 2003 19:59:49 -0400 Date: Fri, 3 Oct 2003 19:59:49 -0400 From: Daniel Veillard To: "Mickautsch, Alfred" Cc: xml@gnome.org Subject: Re: WG: [xml] WG: Document traversing interface for libxml2 Message-ID: <20031003195949.R21001@redhat.com> Reply-To: veillard@redhat.com References: <4F38C8B9DAB1014DBDCB29538BBFD6A1285080@pandora.schuler-ag.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <4F38C8B9DAB1014DBDCB29538BBFD6A1285080@pandora.schuler-ag.com>; from alfred.mickautsch@schuler-ag.com on Fri, Oct 03, 2003 at 03:30:24PM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Fri, Oct 03, 2003 at 03:30:24PM +0200, Mickautsch, Alfred wrote: > Thank you Bjorn, > > since I just sent a patch for the original to the list, here is your version with the patch I just sent. Okay integrating it, I made the following changes: - passed both files though dos2unix to remove the CR/LF into LF only - included tree.h xmlversion.h from xmldwalk.h - kept xmlDocWalker structure private in xmldwalk.c - reformatting the header to use the new export conventions - I wonder how many of the function returning xmlChar * should actually not make a string allocation but return a const xmlChar * . Reusing the document dictionnary or building a new one for the reader if it doesn't exist should avoid mallocing/freeing new strings constantly while looking for data in the tree. To me it's a MUSTFIX before releasing 2.6.0 prime candidate are functions like xmlDocWalkerName - #define IN_LIBXML #include "libxml.h" standard libxml2 C module startup - made the code module conditional to LIBXML_WALKER_ENABLED - added a configuration option --with-walker The size once compiled is a bit less than 4KB, and considering how it may help people who are often lost walking the DOM tree, I think it's well worth adding it by default. The only points left are: - check what part of the api should really return const xmlChar * - is there anything needed to work on HTML documents, I don't think so, an htmlDocPtr is an xmlDocPtr so this should work - integrate the walker at the xmllint level and make regression tests for it, basically --walker --debug should output the same thing as --stream --debugand that should be fairly easy to verify, actually this would improve the test for the reader. - documentation, possibly as an extension to the existing xmlReader one - integration in the Windows (or other platform specific) makefiles I still have a fundamental question left which is: - shouldn't it be better from an API and implementation point of view to instead make the xmlDocWalker a "subclass" of the xmlReader, basically creating an xmlTextReader from an xmlDocPtr, adding the options to go forward and backward in that case and reuse most of the code from the xmlTextReader to reimplement the xmlDocWalker in just a slightly different way pros: - share code - less APIs entry points cons: - more complex implementation - the code ain't that big and this allows to configure the walker and/or the reader independantly. - some of the xmlTextReader API problems about const xmlChar * can be fixed in xmlDocWalker without ABI backward compatibility problems It seems to me that the cons wins a bit over the pros so that will probably make into 2.6.0 . I commited the current code in CVS. thanks a lot ! Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From alfred.mickautsch@schuler-ag.com Sat Oct 4 05:26:19 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail-relay1 (mail-relay1.schuler-ag.com [62.156.183.20]) by mail.gnome.org (Postfix) with ESMTP id 400CF18273 for ; Sat, 4 Oct 2003 05:26:19 -0400 (EDT) Received: from sbs-proxy-test.schuler-ag.com ([192.168.16.254]) by mail-relay1 with Microsoft SMTPSVC(6.0.3790.0); Sat, 4 Oct 2003 11:30:56 +0200 Received: from mail pickup service by sbs-proxy-test.schuler-ag.com with Microsoft SMTPSVC; Sat, 4 Oct 2003 11:26:31 +0200 x-gfisavedcharset: iso-8859-1 Content-Type: text/plain; charset="iso-8859-1" Received: from pandora.schuler-ag.com ([192.168.16.20]) by sbs-proxy-test.schuler-ag.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 4 Oct 2003 11:26:29 +0200 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: AW: WG: [xml] WG: Document traversing interface for libxml2 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Date: Sat, 4 Oct 2003 11:26:28 +0200 Message-ID: <4F38C8B9DAB1014DBDCB29538BBFD6A12E4E76@pandora.schuler-ag.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG: [xml] WG: Document traversing interface for libxml2 thread-index: AcOKCm+eyl2vPV9DTBSD91dmvm+tfgATuZXQ From: "Mickautsch, Alfred" To: X-OriginalArrivalTime: 04 Oct 2003 09:26:29.0181 (UTC) FILETIME=[974FAED0:01C38A59] Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: > I still have a fundamental question left which is: > - shouldn't it be better from an API and implementation=20 > point of view > to instead make the xmlDocWalker a "subclass" of the xmlReader, > basically creating an xmlTextReader from an xmlDocPtr,=20 > adding the=20 > options to go forward and backward in that case and reuse most of > the code from the xmlTextReader to reimplement the xmlDocWalker > in just a slightly different way > pros: > - share code > - less APIs entry points I find this idea very attractive. You could go even further and give the = xmlTextReader a callback function, say xmlGetNextElement, used = internally by xmlTextReaderRead so that one can, just by using another = xmlGetNextElement, process virtually any kind of input data (XML/HTML = files, DOM trees, config files, in-memory structured data,...). From veillard@redhat.com Sat Oct 4 06:47:41 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 9B4CC18519 for ; Sat, 4 Oct 2003 06:47:41 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h94Alrw18495; Sat, 4 Oct 2003 06:47:53 -0400 Date: Sat, 4 Oct 2003 06:47:53 -0400 From: Daniel Veillard To: "Mickautsch, Alfred" Cc: xml@gnome.org Subject: Re: AW: WG: [xml] WG: Document traversing interface for libxml2 Message-ID: <20031004064753.V21001@redhat.com> Reply-To: veillard@redhat.com References: <4F38C8B9DAB1014DBDCB29538BBFD6A12E4E76@pandora.schuler-ag.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <4F38C8B9DAB1014DBDCB29538BBFD6A12E4E76@pandora.schuler-ag.com>; from alfred.mickautsch@schuler-ag.com on Sat, Oct 04, 2003 at 11:26:28AM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Sat, Oct 04, 2003 at 11:26:28AM +0200, Mickautsch, Alfred wrote: > > I still have a fundamental question left which is: > > - shouldn't it be better from an API and implementation > > point of view > > to instead make the xmlDocWalker a "subclass" of the xmlReader, > > basically creating an xmlTextReader from an xmlDocPtr, > > adding the > > options to go forward and backward in that case and reuse most of > > the code from the xmlTextReader to reimplement the xmlDocWalker > > in just a slightly different way > > pros: > > - share code > > - less APIs entry points > I find this idea very attractive. You could go even further and give the xmlTextReader a callback function, say xmlGetNextElement, used internally by xmlTextReaderRead so that one can, just by using another xmlGetNextElement, process virtually any kind of input data (XML/HTML files, DOM trees, config files, in-memory structured data,...). Right, this makes some sense too, this actually gets really close to the C# interfaces if I understand correctly. An xmlWalker would then be a structure exposing a set of callbacks to do NextElement/PrevElement/... Kind of low level driver access to data, and the xmlTextReader offering a standard API on top of it. Maybe the existing code should be removed if we plan to go this way. Shuffling APIs is okay during the beta phase but once 2.6.0 is released, I must garantee API/ABI stability. Extending the base xmlTextReader to be able to process random data is an interesting idea but might take a bit of time to do right. I'm rather busy with other things planned for 2.6.0 (the TODO list is simply scary !) so if you (and Bjorn and others) want to work on it, fine, but I can't really focuse on that right now. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From patrick@gundla.ch Sun Oct 5 19:56:05 2003 Return-Path: Delivered-To: xml@gnome.org Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.185]) by mail.gnome.org (Postfix) with ESMTP id 59B1918759 for ; Sun, 5 Oct 2003 19:56:05 -0400 (EDT) Received: from [212.227.126.155] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1A6Ija-0003FS-00 for xml@gnome.org; Mon, 06 Oct 2003 01:56:18 +0200 Received: from [62.72.92.65] (helo=levana) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1A6Ija-0002hz-00 for xml@gnome.org; Mon, 06 Oct 2003 01:56:19 +0200 Received: from [192.168.1.2] (helo=schnee.local) by levana with esmtp (Exim 3.35 #1 (Debian)) id 1A6IjO-000105-00 for ; Mon, 06 Oct 2003 01:56:06 +0200 Received: from schnee.local (localhost [127.0.0.1]) by schnee.local (8.12.9/8.12.9) with ESMTP id h95NuGAU013073 for ; Mon, 6 Oct 2003 01:56:16 +0200 (CEST) Received: (from pg@localhost) by schnee.local (8.12.9/8.12.2/Submit) id h95NuGa9013072; Mon, 6 Oct 2003 01:56:16 +0200 (CEST) X-Authentication-Warning: schnee.local: pg set sender to patrick@gundla.ch using -f To: xml@gnome.org Organization: privat X-Lieblings-Musik: the_capricorns From: Patrick Gundlach Date: Mon, 06 Oct 2003 01:56:15 +0200 Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [xml] namespace xmllint error (libxml 2.5.11) Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Dear libxml/xmllint users, I have a simple xml file: pg$ cat foo.xml and a simple dtd: pg$ cat simple.dtd but validating with xmllint gives me an error: pg$ /opt/libxml2/2.5.11/bin/xmllint --noout --dtdvalid simple.dtd foo.xml foo.xml:3: Element simple content does not follow the DTD Expecting (foo)+, got (cd:foo ) Document foo.xml does not validate against simple.dtd Doing the same thing with libxml2 version 2.4.7 (linux) works fine. I am using MacOS X 10.2.6. Same error happened libxml2 2.5.4 installed via "fink", a package manager for OS X. I could not find anything in the archive/google. What am I doing wrong? Patrick -- You are your own rainbow! From morus@tanto-xipolis.de Mon Oct 6 02:31:54 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail.tanto-xipolis.de (mail.xipolis.net [213.61.178.42]) by mail.gnome.org (Postfix) with ESMTP id 4D1D1180F6 for ; Mon, 6 Oct 2003 02:31:54 -0400 (EDT) Received: from morus.xipolis.net (morus.xipolis.net [10.0.1.4]) by mail.tanto-xipolis.de (Postfix on SuSE Linux 7.3 (i386)) with ESMTP id 318D219B717 for ; Mon, 6 Oct 2003 08:32:07 +0200 (CEST) Received: (from morus@localhost) by morus.xipolis.net (8.11.6/8.11.6/SuSE Linux 0.5) id h966VeO30564; Mon, 6 Oct 2003 08:31:40 +0200 From: Morus Walter MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16257.3147.898535.304560@morus.xipolis.net> Date: Mon, 6 Oct 2003 08:31:39 +0200 To: xml@gnome.org Subject: Re: [xml] namespace xmllint error (libxml 2.5.11) In-Reply-To: References: X-Mailer: VM 6.95 under 21.4 (patch 4) "Artificial Intelligence" XEmacs Lucid Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Patrick Gundlach writes: [sample of xml document with namespace and dtd] > > Doing the same thing with libxml2 version 2.4.7 (linux) works fine. > That's surprising. Are you sure? Probably you used http://levana.de/foons as the default namespace. > I am using MacOS X 10.2.6. Same error happened libxml2 2.5.4 > installed via "fink", a package manager for OS X. I could not find > anything in the archive/google. > > What am I doing wrong? > DTD validation does not work with documents using namespaces. Use relaxNG (or the subset of XML schema libxml supports) or add the prefixes (and namespace attributes) to your dtd (which is a hack, since namespace prefixes should be meaningless outside the xml instance). James Clarks trang is a dtd to relaxNG converter, so you would just have to add the namespace to the relaxNG schema. HTH Morus From stephane.bidoul@softwareag.com Mon Oct 6 03:24:25 2003 Return-Path: Delivered-To: xml@gnome.org Received: from server8a.software-ag.de (server8a.software-ag.de [193.26.193.47]) by mail.gnome.org (Postfix) with ESMTP id 5F7911816B for ; Mon, 6 Oct 2003 03:24:24 -0400 (EDT) Received: from acsesbi by server8a.software-ag.de; (8.11.6/8.9.3) id h967ORX15909; Mon, 6 Oct 2003 09:24:27 +0200 From: "Stéphane Bidoul" To: "'Daniel Veillard'" Cc: Date: Mon, 6 Oct 2003 09:24:29 +0200 Message-ID: <000001c38bda$e31fcf70$c2590059@acsesbi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_01C38BEB.A6AEB9F0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [xml] windows configure patch Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C38BEB.A6AEB9F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Daniel, Here is the patch to configure 2.6.0 on windows. I added the new configuration options and legacy.c. I have not added xmldwalk.c yet, waiting for your decision about keeping it separate or integrating it into xmlreader.c (I'd vote for a single xmlReader interface, BTW). ...and many thanks for the hard work on error handling. -sbi ------=_NextPart_000_0001_01C38BEB.A6AEB9F0 Content-Type: application/octet-stream; name="win32.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="win32.diff" Index: Makefile.bcb=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= RCS file: /cvs/gnome/gnome-xml/win32/Makefile.bcb,v=0A= retrieving revision 1.2=0A= diff -c -r1.2 Makefile.bcb=0A= *** Makefile.bcb 29 Aug 2003 10:25:39 -0000 1.2=0A= --- Makefile.bcb 5 Oct 2003 19:04:34 -0000=0A= ***************=0A= *** 158,163 ****=0A= --- 158,164 ----=0A= $(XML_INTDIR)\hash.obj\=0A= $(XML_INTDIR)\HTMLparser.obj\=0A= $(XML_INTDIR)\HTMLtree.obj\=0A= + $(XML_INTDIR)\legacy.obj\=0A= $(XML_INTDIR)\list.obj\=0A= $(XML_INTDIR)\nanoftp.obj\=0A= $(XML_INTDIR)\nanohttp.obj\=0A= ***************=0A= *** 195,200 ****=0A= --- 196,202 ----=0A= $(XML_INTDIR_A)\hash.obj\=0A= $(XML_INTDIR_A)\HTMLparser.obj\=0A= $(XML_INTDIR_A)\HTMLtree.obj\=0A= + $(XML_INTDIR_A)\legacy.obj\=0A= $(XML_INTDIR_A)\list.obj\=0A= $(XML_INTDIR_A)\nanoftp.obj\=0A= $(XML_INTDIR_A)\nanohttp.obj\=0A= Index: Makefile.mingw=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= RCS file: /cvs/gnome/gnome-xml/win32/Makefile.mingw,v=0A= retrieving revision 1.11=0A= diff -c -r1.11 Makefile.mingw=0A= *** Makefile.mingw 28 Aug 2003 10:24:40 -0000 1.11=0A= --- Makefile.mingw 5 Oct 2003 19:04:34 -0000=0A= ***************=0A= *** 148,153 ****=0A= --- 148,154 ----=0A= $(XML_INTDIR)/hash.o\=0A= $(XML_INTDIR)/HTMLparser.o\=0A= $(XML_INTDIR)/HTMLtree.o\=0A= + $(XML_INTDIR)/legacy.o\=0A= $(XML_INTDIR)/list.o\=0A= $(XML_INTDIR)/nanoftp.o\=0A= $(XML_INTDIR)/nanohttp.o\=0A= ***************=0A= *** 187,192 ****=0A= --- 188,194 ----=0A= $(XML_INTDIR_A)/hash.o\=0A= $(XML_INTDIR_A)/HTMLparser.o\=0A= $(XML_INTDIR_A)/HTMLtree.o\=0A= + $(XML_INTDIR_A)/legacy.o\=0A= $(XML_INTDIR_A)/list.o\=0A= $(XML_INTDIR_A)/nanoftp.o\=0A= $(XML_INTDIR_A)/nanohttp.o\=0A= Index: Makefile.msvc=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= RCS file: /cvs/gnome/gnome-xml/win32/Makefile.msvc,v=0A= retrieving revision 1.14=0A= diff -c -r1.14 Makefile.msvc=0A= *** Makefile.msvc 28 Aug 2003 10:24:40 -0000 1.14=0A= --- Makefile.msvc 5 Oct 2003 19:04:35 -0000=0A= ***************=0A= *** 137,142 ****=0A= --- 137,143 ----=0A= $(XML_INTDIR)\hash.obj\=0A= $(XML_INTDIR)\HTMLparser.obj\=0A= $(XML_INTDIR)\HTMLtree.obj\=0A= + $(XML_INTDIR)\legacy.obj\=0A= $(XML_INTDIR)\list.obj\=0A= $(XML_INTDIR)\nanoftp.obj\=0A= $(XML_INTDIR)\nanohttp.obj\=0A= ***************=0A= *** 174,179 ****=0A= --- 175,181 ----=0A= $(XML_INTDIR_A)\hash.obj\=0A= $(XML_INTDIR_A)\HTMLparser.obj\=0A= $(XML_INTDIR_A)\HTMLtree.obj\=0A= + $(XML_INTDIR_A)\legacy.obj\=0A= $(XML_INTDIR_A)\list.obj\=0A= $(XML_INTDIR_A)\nanoftp.obj\=0A= $(XML_INTDIR_A)\nanohttp.obj\=0A= Index: configure.js=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= RCS file: /cvs/gnome/gnome-xml/win32/configure.js,v=0A= retrieving revision 1.21=0A= diff -c -r1.21 configure.js=0A= *** configure.js 24 Sep 2003 21:45:21 -0000 1.21=0A= --- configure.js 5 Oct 2003 19:04:35 -0000=0A= ***************=0A= *** 45,50 ****=0A= --- 45,58 ----=0A= var withMemDebug =3D false;=0A= var withSchemas =3D true;=0A= var withRegExps =3D true;=0A= + var withTree =3D true;=0A= + var withReader =3D true;=0A= + var withWalker =3D true;=0A= + var withPush =3D true;=0A= + var withValid =3D true;=0A= + var withSax1 =3D true;=0A= + var withLegacy =3D true;=0A= + var withOutput =3D true;=0A= var withPython =3D false;=0A= /* Win32 build options. */=0A= var dirSep =3D "\\";=0A= ***************=0A= *** 112,117 ****=0A= --- 120,133 ----=0A= txt +=3D " xml_debug: Enable XML debbugging module (" + (withDebug? = "yes" : "no") + ")\n";=0A= txt +=3D " mem_debug: Enable memory debugger (" + (withMemDebug? = "yes" : "no") + ")\n";=0A= txt +=3D " regexps: Enable regular expressions (" + (withRegExps? = "yes" : "no") + ")\n";=0A= + txt +=3D " tree: Enable tree api (" + (withTree? "yes" : "no") = + ")\n";=0A= + txt +=3D " reader: Enable xmlReader api (" + (withReader? "yes" = : "no") + ")\n";=0A= + txt +=3D " walker: Enable xmlDocWalker api (" + (withWalker? = "yes" : "no") + ")\n";=0A= + txt +=3D " push: Enable push api (" + (withPush? "yes" : "no") = + ")\n";=0A= + txt +=3D " valid: Enable DTD validation support (" + = (withValid? "yes" : "no") + ")\n";=0A= + txt +=3D " sax1: Enable SAX1 api (" + (withSax1? "yes" : "no") = + ")\n";=0A= + txt +=3D " legacy: Enable Deprecated api's (" + (withLegacy? = "yes" : "no") + ")\n";=0A= + txt +=3D " output: Enable serialization support (" + = (withOutput? "yes" : "no") + ")\n";=0A= txt +=3D " schemas: Enable XML Schema support (" + (withSchemas? = "yes" : "no") + ")\n";=0A= txt +=3D " python: Build Python bindings (" + (withPython? "yes" = : "no") + ")\n";=0A= txt +=3D "\nWin32 build options, default value given in = parentheses:\n\n";=0A= ***************=0A= *** 191,196 ****=0A= --- 207,220 ----=0A= vf.WriteLine("WITH_MEM_DEBUG=3D" + (withMemDebug? "1" : "0"));=0A= vf.WriteLine("WITH_SCHEMAS=3D" + (withSchemas? "1" : "0"));=0A= vf.WriteLine("WITH_REGEXPS=3D" + (withRegExps? "1" : "0"));=0A= + vf.WriteLine("WITH_TREE=3D" + (withTree? "1" : "0"));=0A= + vf.WriteLine("WITH_READER=3D" + (withReader? "1" : "0"));=0A= + vf.WriteLine("WITH_WALKER=3D" + (withWalker? "1" : "0"));=0A= + vf.WriteLine("WITH_PUSH=3D" + (withPush? "1" : "0"));=0A= + vf.WriteLine("WITH_VALID=3D" + (withValid? "1" : "0"));=0A= + vf.WriteLine("WITH_SAX1=3D" + (withSax1? "1" : "0"));=0A= + vf.WriteLine("WITH_LEGACY=3D" + (withLegacy? "1" : "0"));=0A= + vf.WriteLine("WITH_OUTPUT=3D" + (withOutput? "1" : "0"));=0A= vf.WriteLine("WITH_PYTHON=3D" + (withPython? "1" : "0"));=0A= vf.WriteLine("DEBUG=3D" + (buildDebug? "1" : "0"));=0A= vf.WriteLine("STATIC=3D" + (buildStatic? "1" : "0"));=0A= ***************=0A= *** 265,270 ****=0A= --- 289,310 ----=0A= of.WriteLine(s.replace(/\@WITH_SCHEMAS\@/, withSchemas? "1" : "0"));=0A= } else if (s.search(/\@WITH_REGEXPS\@/) !=3D -1) {=0A= of.WriteLine(s.replace(/\@WITH_REGEXPS\@/, withRegExps? "1" : "0"));=0A= + } else if (s.search(/\@WITH_TREE\@/) !=3D -1) {=0A= + of.WriteLine(s.replace(/\@WITH_TREE\@/, withTree? "1" : "0"));=0A= + } else if (s.search(/\@WITH_READER\@/) !=3D -1) {=0A= + of.WriteLine(s.replace(/\@WITH_READER\@/, withReader? "1" : "0"));=0A= + } else if (s.search(/\@WITH_WALKER\@/) !=3D -1) {=0A= + of.WriteLine(s.replace(/\@WITH_WALKER\@/, withWalker? "1" : "0"));=0A= + } else if (s.search(/\@WITH_PUSH\@/) !=3D -1) {=0A= + of.WriteLine(s.replace(/\@WITH_PUSH\@/, withPush? "1" : "0"));=0A= + } else if (s.search(/\@WITH_VALID\@/) !=3D -1) {=0A= + of.WriteLine(s.replace(/\@WITH_VALID\@/, withValid? "1" : "0"));=0A= + } else if (s.search(/\@WITH_SAX1\@/) !=3D -1) {=0A= + of.WriteLine(s.replace(/\@WITH_SAX1\@/, withSax1? "1" : "0"));=0A= + } else if (s.search(/\@WITH_LEGACY\@/) !=3D -1) {=0A= + of.WriteLine(s.replace(/\@WITH_LEGACY\@/, withLegacy? "1" : "0"));=0A= + } else if (s.search(/\@WITH_OUTPUT\@/) !=3D -1) {=0A= + of.WriteLine(s.replace(/\@WITH_OUTPUT\@/, withOutput? "1" : "0"));=0A= } else=0A= of.WriteLine(ln);=0A= }=0A= ***************=0A= *** 400,405 ****=0A= --- 440,461 ----=0A= withSchemas =3D strToBool(arg.substring(opt.length + 1, = arg.length));=0A= else if (opt =3D=3D "regexps")=0A= withRegExps =3D strToBool(arg.substring(opt.length + 1, = arg.length));=0A= + else if (opt =3D=3D "tree")=0A= + withTree =3D strToBool(arg.substring(opt.length + 1, arg.length));=0A= + else if (opt =3D=3D "reader")=0A= + withReader =3D strToBool(arg.substring(opt.length + 1, arg.length));=0A= + else if (opt =3D=3D "walker")=0A= + withWalker =3D strToBool(arg.substring(opt.length + 1, arg.length));=0A= + else if (opt =3D=3D "push")=0A= + withPush =3D strToBool(arg.substring(opt.length + 1, arg.length));=0A= + else if (opt =3D=3D "valid")=0A= + withValid =3D strToBool(arg.substring(opt.length + 1, arg.length));=0A= + else if (opt =3D=3D "sax1")=0A= + withSax1 =3D strToBool(arg.substring(opt.length + 1, arg.length));=0A= + else if (opt =3D=3D "legacy")=0A= + withLegacy =3D strToBool(arg.substring(opt.length + 1, arg.length));=0A= + else if (opt =3D=3D "output")=0A= + withOutput =3D strToBool(arg.substring(opt.length + 1, arg.length));=0A= else if (opt =3D=3D "python")=0A= withPython =3D strToBool(arg.substring(opt.length + 1, arg.length));=0A= else if (opt =3D=3D "compiler")=0A= ***************=0A= *** 521,526 ****=0A= --- 577,590 ----=0A= txtOut +=3D " Debugging module: " + boolToStr(withDebug) + "\n";=0A= txtOut +=3D " Memory debugging: " + boolToStr(withMemDebug) + "\n";=0A= txtOut +=3D " Regexp support: " + boolToStr(withRegExps) + "\n";=0A= + txtOut +=3D " Tree support: " + boolToStr(withTree) + "\n";=0A= + txtOut +=3D " Reader support: " + boolToStr(withReader) + "\n";=0A= + txtOut +=3D " Walker support: " + boolToStr(withWalker) + "\n";=0A= + txtOut +=3D " Push support: " + boolToStr(withPush) + "\n";=0A= + txtOut +=3D "Validation support: " + boolToStr(withValid) + "\n";=0A= + txtOut +=3D " SAX1 support: " + boolToStr(withSax1) + "\n";=0A= + txtOut +=3D " Legacy support: " + boolToStr(withLegacy) + "\n";=0A= + txtOut +=3D " Output support: " + boolToStr(withOutput) + "\n";=0A= txtOut +=3D "XML Schema support: " + boolToStr(withSchemas) + "\n";=0A= txtOut +=3D " Python bindings: " + boolToStr(withPython) + "\n";=0A= txtOut +=3D "\n";=0A= ------=_NextPart_000_0001_01C38BEB.A6AEB9F0-- From veillard@redhat.com Mon Oct 6 04:41:54 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 8C2E818100 for ; Mon, 6 Oct 2003 04:41:54 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h968g6p32113; Mon, 6 Oct 2003 04:42:06 -0400 Date: Mon, 6 Oct 2003 04:42:06 -0400 From: Daniel Veillard To: Morus Walter Cc: xml@gnome.org Subject: Re: [xml] namespace xmllint error (libxml 2.5.11) Message-ID: <20031006044206.Z21001@redhat.com> Reply-To: veillard@redhat.com References: <16257.3147.898535.304560@morus.xipolis.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <16257.3147.898535.304560@morus.xipolis.net>; from morus.walter@tanto-xipolis.de on Mon, Oct 06, 2003 at 08:31:39AM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Mon, Oct 06, 2003 at 08:31:39AM +0200, Morus Walter wrote: > Patrick Gundlach writes: > [sample of xml document with namespace and dtd] > > > > Doing the same thing with libxml2 version 2.4.7 (linux) works fine. > > > That's surprising. Are you sure? > Probably you used http://levana.de/foons as the default namespace. No, actually libxml2 was broken w.r.t. namespace processing when doing validation. This has been fixed since and the error is now reported. > > I am using MacOS X 10.2.6. Same error happened libxml2 2.5.4 > > installed via "fink", a package manager for OS X. I could not find > > anything in the archive/google. > > > > What am I doing wrong? > > > DTD validation does not work with documents using namespaces. Well it does work but DTD is not "namespace aware", and libxml2 wasn't conformant about that. Patrick, if your XML instance uses a namespace then the namespace prefix must be shown in the DTD too. > Use relaxNG (or the subset of XML schema libxml supports) or > add the prefixes (and namespace attributes) to your dtd right, fixing the DTD is the simplest thing to do. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard@redhat.com Mon Oct 6 05:00:11 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id BB34218206 for ; Mon, 6 Oct 2003 05:00:11 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h968s4d03348; Mon, 6 Oct 2003 04:54:04 -0400 Date: Mon, 6 Oct 2003 04:54:04 -0400 From: Daniel Veillard To: =?iso-8859-1?Q?St=E9phane_Bidoul?= Cc: xml@gnome.org Subject: Re: [xml] windows configure patch Message-ID: <20031006045404.A21001@redhat.com> Reply-To: veillard@redhat.com References: <000001c38bda$e31fcf70$c2590059@acsesbi> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <000001c38bda$e31fcf70$c2590059@acsesbi>; from stephane.bidoul@softwareag.com on Mon, Oct 06, 2003 at 09:24:29AM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Mon, Oct 06, 2003 at 09:24:29AM +0200, Stéphane Bidoul wrote: > Hi Daniel, > > Here is the patch to configure 2.6.0 on windows. > I added the new configuration options and legacy.c. Cool, applied and commited, thanks ! > I have not added xmldwalk.c yet, waiting for your decision > about keeping it separate or integrating it into xmlreader.c > (I'd vote for a single xmlReader interface, BTW). Hum, yes, I need to look more into it, but I'm still working on other things ATM. > ...and many thanks for the hard work on error handling. Damn it's far from finished. I just have the XML and HTML parsers cleaned up at this point. I'm tempted to add a new global "structured" error handler which would be used in preference to xmlGenericError() if defined. Something like an xmlStructuredError(void *user_data, xmlErrorPtr error); and add a parser context field to the xmlError structure. Then use that for the Python bindings to allow to build decent handling. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard@redhat.com Mon Oct 6 05:09:13 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id A3BE8188F7 for ; Mon, 6 Oct 2003 05:09:13 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9699Pq07576; Mon, 6 Oct 2003 05:09:25 -0400 Date: Mon, 6 Oct 2003 05:09:25 -0400 From: Daniel Veillard To: Bjorn Reese Cc: xml@gnome.org Subject: Re: [xml] RAW && NXT with strncmp() Message-ID: <20031006050925.B21001@redhat.com> Reply-To: veillard@redhat.com References: <001901c38822$1a668da0$2964a8c0@kvp> <20031001095055.G21529@redhat.com> <1065026851.2063.31.camel@stellifer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1065026851.2063.31.camel@stellifer>; from breese@mail1.stofanet.dk on Wed, Oct 01, 2003 at 06:47:31PM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, Oct 01, 2003 at 06:47:31PM +0200, Bjorn Reese wrote: > On Wed, 2003-10-01 at 15:50, Daniel Veillard wrote: > > > That I was looking at it this yesterday actually but I don't feel > > that confident about such a change, yet ... > > The libc string functions tend to be highly optimized. > > Time for informal benchmarking... [...] > I get roughly the same results if I change the content of 'buffer'. Well the problem is that informal benchmarking doesn't really reflect real life behaviour I did replace all tests for string comparisons using NXT(4) or more in parser.c, this is the diff between parser.c 1.323 and 1.322 in CVS. The results are on Red Hat Advanced server 2.1 Celeron 700 compiled with -g -O2: - size of parser.o text segment grew up from 78993 bytes to 80132 bytes - the command xmllint --noout --stream --timing --repeat test/valid/REC-xml-19980210.xml which exercise parsing an heterogenous document with a DTD, ran a tad bit slower, from 7280ms to 7355ms And making the change more generally for strings smaller than 4 bytes increased the size far too much. I also tested with a more recent version gcc version 3.2.2 20030222 on my Red Hat Linux 9 development machine and I see a similar impact. On Wed, Oct 01, 2003 at 04:44:14PM +0300, Igor Izvarin wrote: >For my opinion this change will improve the code readability and >maintenance, will reduce the source code size and object code size. Well I can agree about code lisibility, for maintainance, I'm not sure as those parts are unlikely to change. And for object code size and speed this is actually a penalty. So I'm not sure I will actually keep that change. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From patrick@gundla.ch Mon Oct 6 07:52:50 2003 Return-Path: Delivered-To: xml@gnome.org Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mail.gnome.org (Postfix) with ESMTP id 3193D18951 for ; Mon, 6 Oct 2003 07:52:50 -0400 (EDT) Received: from [212.227.126.155] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1A6TvE-0002qD-00 for xml@gnome.org; Mon, 06 Oct 2003 13:53:04 +0200 Received: from [62.72.92.79] (helo=levana) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1A6TvD-0002mZ-00 for xml@gnome.org; Mon, 06 Oct 2003 13:53:03 +0200 Received: from [192.168.1.2] (helo=schnee.local) by levana with esmtp (Exim 3.35 #1 (Debian)) id 1A6Tv0-0000bs-00 for ; Mon, 06 Oct 2003 13:52:50 +0200 Received: from schnee.local (localhost [127.0.0.1]) by schnee.local (8.12.9/8.12.9) with ESMTP id h96Bqx0v000896 for ; Mon, 6 Oct 2003 13:52:59 +0200 (CEST) Received: (from pg@localhost) by schnee.local (8.12.9/8.12.2/Submit) id h96BqxFL000895; Mon, 6 Oct 2003 13:52:59 +0200 (CEST) X-Authentication-Warning: schnee.local: pg set sender to patrick@gundla.ch using -f To: xml@gnome.org Organization: privat X-Lieblings-Musik: the_capricorns In-Reply-To: <16257.3147.898535.304560@morus.xipolis.net> (Morus Walter's message of "Mon, 6 Oct 2003 08:31:39 +0200") References: <16257.3147.898535.304560@morus.xipolis.net> From: Patrick Gundlach Date: Mon, 06 Oct 2003 13:52:58 +0200 Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [xml] Re: namespace xmllint error (libxml 2.5.11) Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Morus Walter writes: Hi, >> Doing the same thing with libxml2 version 2.4.7 (linux) works fine. >> > That's surprising. Are you sure? Absolutely. Tested more then once with two different documents. > DTD validation does not work with documents using namespaces. > Use relaxNG (or the subset of XML schema libxml supports) or > add the prefixes (and namespace attributes) to your dtd > (which is a hack, since namespace prefixes should be meaningless outside > the xml instance). OK, I think I'll add the namespace to the dtd first, but also look at relaxNG. BTW: as far as I can see (it's my first day of relaxNG) there are two ways to describe relaxNG: xml-syntax and short syntax. Are they both supported by libxml or is one prefered over the other? > James Clarks trang is a dtd to relaxNG converter, so you would just have to > add the namespace to the relaxNG schema. OK, I've found this and I'll give it a try when I don't succeed with manual translation of the dtd (I feel the urge to learn this stuff) Thanks for your answer and also to Daniel! Patrick -- You are your own rainbow! From alfred.mickautsch@schuler-ag.com Mon Oct 6 08:08:10 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail-relay1 (mail-relay1.schuler-ag.com [62.156.183.20]) by mail.gnome.org (Postfix) with ESMTP id 0F36718970 for ; Mon, 6 Oct 2003 08:08:10 -0400 (EDT) Received: from sbs-proxy-test.schuler-ag.com ([192.168.16.254]) by mail-relay1 with Microsoft SMTPSVC(6.0.3790.0); Mon, 6 Oct 2003 14:12:32 +0200 Received: from mail pickup service by sbs-proxy-test.schuler-ag.com with Microsoft SMTPSVC; Mon, 6 Oct 2003 14:08:22 +0200 x-gfisavedcharset: iso-8859-1 Content-Type: text/plain; charset="iso-8859-1" Received: from pandora.schuler-ag.com ([192.168.16.20]) by sbs-proxy-test.schuler-ag.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 6 Oct 2003 14:08:19 +0200 Content-Class: urn:content-classes:message Subject: AW: AW: WG: [xml] WG: Document traversing interface for libxml2 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Oct 2003 14:08:19 +0200 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Message-ID: <4F38C8B9DAB1014DBDCB29538BBFD6A12E4E78@pandora.schuler-ag.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: WG: [xml] WG: Document traversing interface for libxml2 thread-index: AcOKZPkUOmDNlzDBS7CDWuvhFQMkRwBllRRw From: "Mickautsch, Alfred" To: X-OriginalArrivalTime: 06 Oct 2003 12:08:19.0825 (UTC) FILETIME=[8821DE10:01C38C02] Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: =20 > Right, this makes some sense too, this actually gets really close > to the C# interfaces if I understand correctly. > An xmlWalker would then be a structure exposing a set of=20 > callbacks to do > NextElement/PrevElement/... Kind of low level driver access=20 > to data, and > the xmlTextReader offering a standard API on top of it. > Maybe the existing code should be removed if we plan to go this way. > Shuffling APIs is okay during the beta phase but once 2.6.0=20 > is released, Yes, I think this would be the better solution. > I must garantee API/ABI stability. Extending the base xmlTextReader to > be able to process random data is an interesting idea but might take > a bit of time to do right. I'm rather busy with other things planned > for 2.6.0 (the TODO list is simply scary !) so if you (and=20 > Bjorn and others) > want to work on it, fine, but I can't really focuse on that right now. I can work on the xmlWalker, but this will surely take some time, since, like you will have found out, I do not know very much about the = internals of libxml2. I am more the like of a libxml user. Besides I can work on it only on weekends. So the time schedule should not be very tight. And I do not have internet access at home, so my feedback to the list will be somewhat delayed when I am not at work. Regarding the coding style: can someone please tell me what parameters I must pass to indent for libxml2 code? Servus -- Alfred From veillard@redhat.com Mon Oct 6 08:11:37 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 5A59A18976 for ; Mon, 6 Oct 2003 08:11:37 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h96CBn530433; Mon, 6 Oct 2003 08:11:49 -0400 Date: Mon, 6 Oct 2003 08:11:49 -0400 From: Daniel Veillard To: Patrick Gundlach Cc: xml@gnome.org Subject: Re: [xml] Re: namespace xmllint error (libxml 2.5.11) Message-ID: <20031006081149.A30095@redhat.com> Reply-To: veillard@redhat.com References: <16257.3147.898535.304560@morus.xipolis.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from pg@levana.de on Mon, Oct 06, 2003 at 01:52:58PM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Mon, Oct 06, 2003 at 01:52:58PM +0200, Patrick Gundlach wrote: > BTW: as far as I can see (it's my first day of relaxNG) there are two > ways to describe relaxNG: xml-syntax and short syntax. Are they both > supported by libxml or is one prefered over the other? XML syntax only at the moment. I may add support for the compact syntax later, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard@redhat.com Mon Oct 6 08:14:00 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id EF1FB18976 for ; Mon, 6 Oct 2003 08:13:59 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h96CECP31353; Mon, 6 Oct 2003 08:14:12 -0400 Date: Mon, 6 Oct 2003 08:14:12 -0400 From: Daniel Veillard To: "Mickautsch, Alfred" Cc: xml@gnome.org Subject: Re: AW: AW: WG: [xml] WG: Document traversing interface for libxml2 Message-ID: <20031006081412.B30095@redhat.com> Reply-To: veillard@redhat.com References: <4F38C8B9DAB1014DBDCB29538BBFD6A12E4E78@pandora.schuler-ag.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <4F38C8B9DAB1014DBDCB29538BBFD6A12E4E78@pandora.schuler-ag.com>; from alfred.mickautsch@schuler-ag.com on Mon, Oct 06, 2003 at 02:08:19PM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Mon, Oct 06, 2003 at 02:08:19PM +0200, Mickautsch, Alfred wrote: > > Maybe the existing code should be removed if we plan to go this way. > > Shuffling APIs is okay during the beta phase but once 2.6.0 > > is released, > > Yes, I think this would be the better solution. okay > > I must garantee API/ABI stability. Extending the base xmlTextReader to > > be able to process random data is an interesting idea but might take > > a bit of time to do right. I'm rather busy with other things planned > > for 2.6.0 (the TODO list is simply scary !) so if you (and > > Bjorn and others) > > want to work on it, fine, but I can't really focuse on that right now. > > I can work on the xmlWalker, but this will surely take some time, since, > like you will have found out, I do not know very much about the internals > of libxml2. I am more the like of a libxml user. > Besides I can work on it only on weekends. So the time schedule should > not be very tight. > And I do not have internet access at home, so my feedback to the list > will be somewhat delayed when I am not at work. Okay, if you don't heard from me about it Friday, you can dedicate your next week-end to it :-) > Regarding the coding style: can someone please tell me what parameters > I must pass to indent for libxml2 code? I use the following: paphio:~ -> cat ~/bin/cb #!/bin/sh indent -bad -bap -bbb -bli4 -br -ce -brs -cs -i4 -l75 -lc75 -nut -sbi4 -psl -saf -sai -saw -sbi4 -ss -sc -cdw -cli4 -npcs -nbc paphio:~ -> Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From novak@merlot.ics.muni.cz Mon Oct 6 08:17:01 2003 Return-Path: Delivered-To: xml@gnome.org Received: from merlot.ics.muni.cz (merlot.ics.muni.cz [147.251.18.30]) by mail.gnome.org (Postfix) with ESMTP id C0F13187C9 for ; Mon, 6 Oct 2003 08:17:00 -0400 (EDT) Received: (from novak@localhost) by merlot.ics.muni.cz (8.11.7p1+Sun/8.11.6) id h96CHDR25805 for xml@gnome.org; Mon, 6 Oct 2003 14:17:13 +0200 (MEST) Date: Mon, 6 Oct 2003 14:17:13 +0200 From: Petr Novak To: xml@gnome.org Message-ID: <20031006121713.GA25542@merlot.ics.muni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.25i Subject: [xml] xmlValidityErrorFunc how-to? Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi all, can you advise me where to find some description about xmlValidityErrorFunc? There is ValidCtxt->warning = (xmlValidityErrorFunc) fprintf; in the xmllint.c but I need to call my own function if warning or error is occured. In documentation is only that the prototype of xmlValidityErrorFunc is (*xmlSchemaValidityErrorFunc) (void *ctx, const char *msg, ...); I can obtain error message in char* format, but I need validation context, because I need to know in whitch element the error was occured. So if I wrote the follow function it doesn't work: void test(xmlValidCtxtPtr ctx, const char *msg, void *el){ cout << ctx->node->name; } Can you advise me? Thanks -petrn -- Petr Novak, Liberouter Project (www.liberouter.org) E-mail: novak@merlot.ics.muni.cz From veillard@redhat.com Mon Oct 6 08:29:10 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id CC40E1898E for ; Mon, 6 Oct 2003 08:29:09 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h96CTLx02456; Mon, 6 Oct 2003 08:29:21 -0400 Date: Mon, 6 Oct 2003 08:29:21 -0400 From: Daniel Veillard To: Petr Novak Cc: xml@gnome.org Subject: Re: [xml] xmlValidityErrorFunc how-to? Message-ID: <20031006082921.D30095@redhat.com> Reply-To: veillard@redhat.com References: <20031006121713.GA25542@merlot.ics.muni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031006121713.GA25542@merlot.ics.muni.cz>; from novak@merlot.ics.muni.cz on Mon, Oct 06, 2003 at 02:17:13PM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Mon, Oct 06, 2003 at 02:17:13PM +0200, Petr Novak wrote: > Hi all, > can you advise me where to find some description about xmlValidityErrorFunc? > There is ValidCtxt->warning = (xmlValidityErrorFunc) fprintf; in the xmllint.c > but I need to call my own function if warning or error is occured. > > In documentation is only that the prototype of xmlValidityErrorFunc is > (*xmlSchemaValidityErrorFunc) (void *ctx, const char *msg, ...); > I can obtain error message in char* format, but I need validation context, > because I need to know in whitch element the error was occured. > > So if I wrote the follow function it doesn't work: > > void test(xmlValidCtxtPtr ctx, const char *msg, void *el){ > cout << ctx->node->name; > } > > Can you advise me? Look at the code in error.c implementing xmlParserValidityError() that will give you an idea of what you can do. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From patrick@gundla.ch Mon Oct 6 10:31:28 2003 Return-Path: Delivered-To: xml@gnome.org Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mail.gnome.org (Postfix) with ESMTP id 48C68189D5 for ; Mon, 6 Oct 2003 10:31:28 -0400 (EDT) Received: from [212.227.126.155] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1A6WOj-0006Zo-00; Mon, 06 Oct 2003 16:31:41 +0200 Received: from [62.72.92.65] (helo=levana) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1A6WOj-0002Bo-00; Mon, 06 Oct 2003 16:31:41 +0200 Received: from [192.168.1.2] (helo=schnee.local) by levana with esmtp (Exim 3.35 #1 (Debian)) id 1A6WOi-0000tu-00; Mon, 06 Oct 2003 16:31:40 +0200 Received: from schnee.local (localhost [127.0.0.1]) by schnee.local (8.12.9/8.12.9) with ESMTP id h96EVo0v001162; Mon, 6 Oct 2003 16:31:50 +0200 (CEST) Received: (from pg@localhost) by schnee.local (8.12.9/8.12.2/Submit) id h96EVonE001161; Mon, 6 Oct 2003 16:31:50 +0200 (CEST) X-Authentication-Warning: schnee.local: pg set sender to patrick@gundla.ch using -f To: xml@gnome.org Organization: privat X-Lieblings-Musik: the_capricorns In-Reply-To: <20031006081149.A30095@redhat.com> (Daniel Veillard's message of "Mon, 6 Oct 2003 08:11:49 -0400") References: <16257.3147.898535.304560@morus.xipolis.net> <20031006081149.A30095@redhat.com> From: Patrick Gundlach Date: Mon, 06 Oct 2003 16:31:50 +0200 Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [xml] Re: namespace xmllint error (libxml 2.5.11) Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi again, > XML syntax only at the moment. I may add support for the compact syntax > later, I did some tests, and I am confused. Sorry for my ignorance. Could anybody point out what I am doing wrong? interface.rng: -------------------------------------------------- version="1.0" encoding="UTF-8"?> -------------------------------------------------- simple.xml -------------------------------------------------- -------------------------------------------------- xmllint: -------------------------------------------------- xmllint --noout --relaxng interface.rng simple.xml RNG validity error: file simple.xml line 3 element interface Invalid attribute name for element interface simple.xml fails to validate -------------------------------------------------- From the tutorial at I assume that the above namespace syntax was right. Patrick -- You are your own rainbow! From morus@tanto-xipolis.de Mon Oct 6 10:51:01 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail.tanto-xipolis.de (mail.xipolis.net [213.61.178.42]) by mail.gnome.org (Postfix) with ESMTP id DFE451826A for ; Mon, 6 Oct 2003 10:51:00 -0400 (EDT) Received: from morus.xipolis.net (morus.xipolis.net [10.0.1.4]) by mail.tanto-xipolis.de (Postfix on SuSE Linux 7.3 (i386)) with ESMTP id 9FF3C19B722; Mon, 6 Oct 2003 16:51:12 +0200 (CEST) Received: (from morus@localhost) by morus.xipolis.net (8.11.6/8.11.6/SuSE Linux 0.5) id h96EokS08555; Mon, 6 Oct 2003 16:50:46 +0200 From: Morus Walter MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16257.33094.407660.736647@morus.xipolis.net> Date: Mon, 6 Oct 2003 16:50:46 +0200 To: xml@gnome.org Subject: Re: [xml] Re: namespace xmllint error (libxml 2.5.11) Cc: Patrick Gundlach In-Reply-To: References: <16257.3147.898535.304560@morus.xipolis.net> <20031006081149.A30095@redhat.com> X-Mailer: VM 6.95 under 21.4 (patch 4) "Artificial Intelligence" XEmacs Lucid Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Patrick Gundlach writes: > Hi again, > > > XML syntax only at the moment. I may add support for the compact syntax > > later, > > I did some tests, and I am confused. Sorry for my ignorance. Could > anybody point out what I am doing wrong? > [...] > you don't declare the name attribute for the interface element. In compact syntax your schema is default namespace = "http://www.pragma-ade.com/commands" element interface { element command { attribute name { text } }* } while you are trying to express default namespace = "http://www.pragma-ade.com/commands" element interface { attribute name { text }, element command { attribute name { text } }* } trang translates between compact and xml syntax and I prefer the compact syntax, which is easier to read. HTH Morus From alfred.mickautsch@schuler-ag.com Mon Oct 6 10:23:14 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail-relay1 (mail-relay1.schuler-ag.com [62.156.183.20]) by mail.gnome.org (Postfix) with ESMTP id 188F4182E5 for ; Mon, 6 Oct 2003 10:23:13 -0400 (EDT) Received: from sbs-proxy-test.schuler-ag.com ([192.168.16.254]) by mail-relay1 with Microsoft SMTPSVC(6.0.3790.0); Mon, 6 Oct 2003 16:27:34 +0200 Received: from mail pickup service by sbs-proxy-test.schuler-ag.com with Microsoft SMTPSVC; Mon, 6 Oct 2003 16:23:25 +0200 Content-Type: multipart/mixed; boundary="----=_NextPart_000_28BCC_01C38C26.2AF3EA20" Received: from pandora.schuler-ag.com ([192.168.16.20]) by sbs-proxy-test.schuler-ag.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 6 Oct 2003 16:23:23 +0200 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 6 Oct 2003 16:23:23 +0200 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Message-ID: <4F38C8B9DAB1014DBDCB29538BBFD6A1285084@pandora.schuler-ag.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: xmlTextWriter thread-index: AcOMFmp7MhHJYWxbShaMdw7qXdEZ1A== From: "Mickautsch, Alfred" To: X-OriginalArrivalTime: 06 Oct 2003 14:23:23.0555 (UTC) FILETIME=[6654EF30:01C38C15] Subject: [xml] xmlTextWriter Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_28BCC_01C38C26.2AF3EA20 x-gfisavedcharset: iso-8859-1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Well, this weekend I started to write the xmlTextWriter interface :-). It lacks the possibility to write DTD's, but I have to learn about DTD's = first, because I do not know how such a thing looks like (didn't need that). So you xml gurus out there: please look at the code and tell me what I did wrong, or what could be improved/added. (I hope the style is ok now). Servus -- Alfred=20 <> <>=20 -- Alfred Mickautsch schuler business solutions AG Karl-Berner-Str. 4 D-72285 Pfalzgrafenweiler tel: +49 (0)74 45 830-184 fax: +49 (0)74 45 830-349 e-mail: alfred.mickautsch@schuler-ag.com ------=_NextPart_000_28BCC_01C38C26.2AF3EA20 Content-Disposition: attachment; filename="xmlwriter.h" Content-Description: xmlwriter.h Content-Type: application/octet-stream; name="xmlwriter.h"; name="xmlwriter.h" Content-Transfer-Encoding: base64 Ci8qCiAqIHhtbHdyaXRlci5oIDogSW50ZXJmYWNlcywgY29uc3RhbnRzIGFuZCB0eXBlcyBvZiB0 aGUKICogdGV4dCB3cml0aW5nIEFQSS5mb3IgWE1MCiAqCiAqIEZvciBsaWNlbnNlIGFuZCBkaXNj bGFpbWVyIHNlZSB0aGUgbGljZW5zZSBhbmQgZGlzY2xhaW1lciBvZgogKiBsaWJ4bWwyLgogKgog KiBhbGZyZWRAbWlja2F1dHNjaC5kZQogKi8KCiNpZm5kZWYgX19YTUxfWE1MV1JJVEVSX0hfXwoj ZGVmaW5lIF9fWE1MX1hNTFdSSVRFUl9IX18KCiNpZmRlZiBfX2NwbHVzcGx1cwpleHRlcm4gIkMi IHsKI2VuZGlmCgojaW5jbHVkZSA8bGlieG1sL3htbElPLmg+CiNpbmNsdWRlIDxsaWJ4bWwvbGlz dC5oPgoKICAgIHR5cGVkZWYgZW51bSB7CiAgICAgICAgWE1MX1RFWFRXUklURVJfTk9ORSA9IDAs CiAgICAgICAgWE1MX1RFWFRXUklURVJfTkFNRSA9IDEsCiAgICAgICAgWE1MX1RFWFRXUklURVJf VEVYVCA9IDIsCgogICAgfSB4bWxUZXh0V3JpdGVyU3RhdGU7CgogICAgdHlwZWRlZiBzdHJ1Y3Qg X3htbFRleHRXcml0ZXJTdGFja0VudHJ5IHsKICAgICAgICB4bWxDaGFyICpuYW1lOwogICAgICAg IHhtbFRleHRXcml0ZXJTdGF0ZSBzdGF0ZTsKICAgIH0geG1sVGV4dFdyaXRlclN0YWNrRW50cnk7 CgogICAgdHlwZWRlZiBzdHJ1Y3QgX3htbFRleHRXcml0ZXIgewogICAgICAgIHhtbE91dHB1dEJ1 ZmZlclB0ciBvdXQ7IC8qIG91dHB1dCBidWZmZXIgKi8KICAgICAgICB4bWxMaXN0UHRyIG5vZGVz OyAgICAgICAvKiBlbGVtZW50IG5hbWUgc3RhY2sgKi8KICAgICAgICBpbnQgbGV2ZWw7CiAgICAg ICAgY2hhciBpbmRlbnQ7ICAgICAgICAgICAgLyogaW5kZW50IGFtb3VudCAqLwogICAgICAgIGNo YXIgaWNoYXI7ICAgICAgICAgICAgIC8qIGluZGVudCBjaGFyYWN0ZXIgKi8KICAgICAgICBjaGFy IHFjaGFyOyAgICAgICAgICAgICAvKiBjaGFyYWN0ZXIgdXNlZCBmb3IgcXVvdGluZyBhdHRyaWJ1 dGUgdmFsdWVzICovCiAgICB9IHhtbFRleHRXcml0ZXI7CgogICAgdHlwZWRlZiB4bWxUZXh0V3Jp dGVyICp4bWxUZXh0V3JpdGVyUHRyOwoKLyoKICogQ29uc3RydWN0b3JzICYgRGVzdHJ1Y3Rvcgog Ki8KICAgIHhtbFRleHRXcml0ZXJQdHIgeG1sTmV3VGV4dFdyaXRlcih4bWxPdXRwdXRCdWZmZXJQ dHIgb3V0KTsKICAgIHhtbFRleHRXcml0ZXJQdHIgeG1sTmV3VGV4dFdyaXRlckZpbGVuYW1lKGNv bnN0IGNoYXIgKnVyaSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGludCBjb21wcmVzc2lvbik7CiAgICB4bWxUZXh0V3JpdGVyUHRyIHhtbE5ld1RleHRXcml0 ZXJNZW1vcnkoeG1sQnVmZmVyUHRyIGJ1ZiwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBpbnQgY29tcHJlc3Npb24pOwogICAgdm9pZCB4bWxGcmVlVGV4dFdyaXRl cih4bWxUZXh0V3JpdGVyUHRyIHdyaXRlcik7CgovKgogKiBGdW5jdGlvbnMKICovCgoKLyoKICog RG9jdW1lbnQKICovCiAgICBpbnQgeG1sVGV4dFdyaXRlclN0YXJ0RG9jdW1lbnQoeG1sVGV4dFdy aXRlclB0ciB3cml0ZXIsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3Qg Y2hhciAqdmVyc2lvbiwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCBj aGFyICplbmNvZGluZywKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCBj aGFyICpzdGFuZGFsb25lKTsKICAgIGludCB4bWxUZXh0V3JpdGVyRW5kRG9jdW1lbnQoeG1sVGV4 dFdyaXRlclB0ciB3cml0ZXIpOwoKLyoKICogQ29tbWVudHMKICovCiAgICBpbnQgeG1sVGV4dFdy aXRlcldyaXRlRm9ybWF0Q29tbWVudCh4bWxUZXh0V3JpdGVyUHRyIHdyaXRlciwKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IGNoYXIgKmZvcm1hdCwgLi4uKTsK ICAgIGludCB4bWxUZXh0V3JpdGVyV3JpdGVWRm9ybWF0Q29tbWVudCh4bWxUZXh0V3JpdGVyUHRy IHdyaXRlciwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCBj aGFyICpmb3JtYXQsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdmFf bGlzdCBhcmdwdHIpOwogICAgaW50IHhtbFRleHRXcml0ZXJXcml0ZUNvbW1lbnQoeG1sVGV4dFdy aXRlclB0ciB3cml0ZXIsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4 bWxDaGFyICogdmFsdWUpOwoKLyoKICogRWxlbWVudHMKICovCiAgICBpbnQgeG1sVGV4dFdyaXRl clN0YXJ0RWxlbWVudCh4bWxUZXh0V3JpdGVyUHRyIHdyaXRlciwKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGNvbnN0IHhtbENoYXIgKiBuYW1lKTsKICAgIGludCB4bWxUZXh0V3Jp dGVyU3RhcnRFbGVtZW50TlMoeG1sVGV4dFdyaXRlclB0ciB3cml0ZXIsCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHhtbENoYXIgKiBwcmVmaXgsCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHhtbENoYXIgKiBuYW1lLAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICogbmFtZXNwYWNlVVJJKTsK ICAgIGludCB4bWxUZXh0V3JpdGVyRW5kRWxlbWVudCh4bWxUZXh0V3JpdGVyUHRyIHdyaXRlcik7 CgovKgogKiBFbGVtZW50IHRleHQKICovCiAgICBpbnQgeG1sVGV4dFdyaXRlcldyaXRlRm9ybWF0 U3RyaW5nKHhtbFRleHRXcml0ZXJQdHIgd3JpdGVyLAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBjb25zdCBjaGFyICpmb3JtYXQsIC4uLik7CiAgICBpbnQgeG1sVGV4dFdy aXRlcldyaXRlVkZvcm1hdFN0cmluZyh4bWxUZXh0V3JpdGVyUHRyIHdyaXRlciwKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IGNoYXIgKmZvcm1hdCwKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHZhX2xpc3QgYXJncHRyKTsKICAgIGlu dCB4bWxUZXh0V3JpdGVyV3JpdGVTdHJpbmcoeG1sVGV4dFdyaXRlclB0ciB3cml0ZXIsCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHhtbENoYXIgKiB2YWx1ZSk7CiAgICBp bnQgeG1sVGV4dFdyaXRlcldyaXRlU3RyaW5nTGVuKHhtbFRleHRXcml0ZXJQdHIgd3JpdGVyLAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICogdmFsdWUs IGludCBsZW4pOwoKLyoKICogRWxlbWVudCBhdHRyaWJ1dGVzCiAqLwogICAgaW50IHhtbFRleHRX cml0ZXJXcml0ZUZvcm1hdFByb3AoeG1sVGV4dFdyaXRlclB0ciB3cml0ZXIsCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICogbmFtZSwKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IGNoYXIgKmZvcm1hdCwgLi4uKTsKICAg IGludCB4bWxUZXh0V3JpdGVyV3JpdGVWRm9ybWF0UHJvcCh4bWxUZXh0V3JpdGVyUHRyIHdyaXRl ciwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICog bmFtZSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCBjaGFyICpm b3JtYXQsIHZhX2xpc3QgYXJncHRyKTsKICAgIGludCB4bWxUZXh0V3JpdGVyV3JpdGVQcm9wKHht bFRleHRXcml0ZXJQdHIgd3JpdGVyLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29u c3QgeG1sQ2hhciAqIG5hbWUsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4 bWxDaGFyICogdmFsdWUpOwogICAgaW50IHhtbFRleHRXcml0ZXJXcml0ZUZvcm1hdFByb3BOUyh4 bWxUZXh0V3JpdGVyUHRyIHdyaXRlciwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgY29uc3QgeG1sQ2hhciAqIHByZWZpeCwKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgY29uc3QgeG1sQ2hhciAqIG5hbWUsCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGNvbnN0IGNoYXIgKmZvcm1hdCwgLi4uKTsKICAgIGludCB4bWxUZXh0 V3JpdGVyV3JpdGVWRm9ybWF0UHJvcE5TKHhtbFRleHRXcml0ZXJQdHIgd3JpdGVyLAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgeG1sQ2hhciAqIHByZWZpeCwK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHhtbENoYXIgKiBu YW1lLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgY2hhciAq Zm9ybWF0LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdmFfbGlzdCBh cmdwdHIpOwogICAgaW50IHhtbFRleHRXcml0ZXJXcml0ZVByb3BOUyh4bWxUZXh0V3JpdGVyUHRy IHdyaXRlciwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgeG1sQ2hhciAq IHByZWZpeCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgeG1sQ2hhciAq IG5hbWUsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHhtbENoYXIgKiB2 YWx1ZSk7CgovKgogKiBFbGVtZW50IGNvbnZlbmllbmN5IGZ1bmN0aW9ucwogKi8KICAgIGludCB4 bWxUZXh0V3JpdGVyV3JpdGVGb3JtYXRFbGVtZW50KHhtbFRleHRXcml0ZXJQdHIgd3JpdGVyLAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgeG1sQ2hhciAqIG5h bWUsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCBjaGFyICpm b3JtYXQsIC4uLik7CiAgICBpbnQgeG1sVGV4dFdyaXRlcldyaXRlVkZvcm1hdEVsZW1lbnQoeG1s VGV4dFdyaXRlclB0ciB3cml0ZXIsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgY29uc3QgeG1sQ2hhciAqIG5hbWUsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgY29uc3QgY2hhciAqZm9ybWF0LAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHZhX2xpc3QgYXJncHRyKTsKICAgIGludCB4bWxUZXh0V3JpdGVyV3Jp dGVFbGVtZW50KHhtbFRleHRXcml0ZXJQdHIgd3JpdGVyLAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgY29uc3QgeG1sQ2hhciAqIG5hbWUsCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBjb25zdCB4bWxDaGFyICogdmFsdWUpOwogICAgaW50IHhtbFRleHRXcml0ZXJX cml0ZUZvcm1hdEVsZW1lbnROUyh4bWxUZXh0V3JpdGVyUHRyIHdyaXRlciwKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgeG1sQ2hhciAqIHByZWZpeCwKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgeG1sQ2hhciAqIG5h bWUsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHhtbENo YXIgKiBuYW1lc3BhY2VVUkksCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGNvbnN0IGNoYXIgKmZvcm1hdCwgLi4uKTsKICAgIGludCB4bWxUZXh0V3JpdGVyV3JpdGVW Rm9ybWF0RWxlbWVudE5TKHhtbFRleHRXcml0ZXJQdHIgd3JpdGVyLAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgeG1sQ2hhciAqIHByZWZpeCwKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHhtbENoYXIgKiBuYW1l LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgeG1sQ2hh ciAqIG5hbWVzcGFjZVVSSSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGNvbnN0IGNoYXIgKmZvcm1hdCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHZhX2xpc3QgYXJncHRyKTsKICAgIGludCB4bWxUZXh0V3JpdGVyV3JpdGVFbGVt ZW50TlMoeG1sVGV4dFdyaXRlclB0ciB3cml0ZXIsCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGNvbnN0IHhtbENoYXIgKiBwcmVmaXgsCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGNvbnN0IHhtbENoYXIgKiBuYW1lLAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICogbmFtZXNwYWNlVVJJLAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICogdmFsdWUpOwoKLyoKICogbWlz YwogKi8KICAgIGludCB4bWxUZXh0V3JpdGVyRmx1c2goeG1sVGV4dFdyaXRlclB0ciB3cml0ZXIp OwoKI2lmZGVmIF9fY3BsdXNwbHVzCn0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLy9l eHRlcm4gIkMiCiNlbmRpZgojZW5kaWYgICAgICAgICAgICAgICAgICAgICAgICAgIC8qIF9fWE1M X1hNTFdSSVRFUl9IX18gKi8K ------=_NextPart_000_28BCC_01C38C26.2AF3EA20 Content-Disposition: attachment; filename="xmlwriter.c" Content-Description: xmlwriter.c Content-Type: application/octet-stream; name="xmlwriter.c"; name="xmlwriter.c" Content-Transfer-Encoding: base64 Ci8qCiAqIHhtbHdyaXRlci5jOiBYTUwgdGV4dCB3cml0ZXIgaW1wbGVtZW50YXRpb24KICoKICog Rm9yIGxpY2Vuc2UgYW5kIGRpc2NsYWltZXIgc2VlIHRoZSBsaWNlbnNlIGFuZCBkaXNjbGFpbWVy IG9mCiAqIGxpYnhtbDIuCiAqCiAqIGFsZnJlZEBtaWNrYXV0c2NoLmRlCiAqLwoKI2luY2x1ZGUg PHN0cmluZy5oPgojaW5jbHVkZSA8c3RkYXJnLmg+CgojaW5jbHVkZSA8Li4vbGlieG1sLmg+CiNp bmNsdWRlIDxsaWJ4bWwveG1sbWVtb3J5Lmg+CiNpbmNsdWRlIDxsaWJ4bWwvcGFyc2VyLmg+Cgoj aW5jbHVkZSAieG1sd3JpdGVyLmgiCgpzdGF0aWMgdm9pZCB4bWxGcmVlVGV4dFdyaXRlclN0YWNr RW50cnkoeG1sTGlua1B0ciBsayk7CnN0YXRpYyBpbnQgeG1sQ21wVGV4dFdyaXRlclN0YWNrRW50 cnkoY29uc3Qgdm9pZCAqZGF0YTAsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgY29uc3Qgdm9pZCAqZGF0YTEpOwpzdGF0aWMgaW50IHhtbFRleHRXcml0ZXJXcml0ZU1lbUNh bGxiYWNrKHZvaWQgKmNvbnRleHQsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgY29uc3QgeG1sQ2hhciAqIHN0ciwgaW50IGxlbik7CnN0YXRpYyBpbnQgeG1sVGV4dFdy aXRlckNsb3NlTWVtQ2FsbGJhY2sodm9pZCAqY29udGV4dCk7CnN0YXRpYyB4bWxDaGFyICp4bWxU ZXh0V3JpdGVyVlNwcmludGYoY29uc3QgY2hhciAqZm9ybWF0LCB2YV9saXN0IGFyZ3B0cik7Cgov KioKICogeG1sTmV3VGV4dFdyaXRlcjoKICogQG91dDogIGFuIHhtbE91dHB1dEJ1ZmZlclB0cgog KgogKiBDcmVhdGUgYSBuZXcgeG1sTmV3VGV4dFdyaXRlciBzdHJ1Y3R1cmUgdXNpbmcgYW4geG1s T3V0cHV0QnVmZmVyUHRyCiAqCiAqIFJldHVybnMgdGhlIG5ldyB4bWxUZXh0V3JpdGVyUHRyIG9y IE5VTEwgaW4gY2FzZSBvZiBlcnJvcgogKi8KeG1sVGV4dFdyaXRlclB0cgp4bWxOZXdUZXh0V3Jp dGVyKHhtbE91dHB1dEJ1ZmZlclB0ciBvdXQpCnsKICAgIHhtbFRleHRXcml0ZXJQdHIgcmV0OwoK ICAgIHJldCA9ICh4bWxUZXh0V3JpdGVyUHRyKSB4bWxNYWxsb2Moc2l6ZW9mKHhtbFRleHRXcml0 ZXIpKTsKICAgIGlmIChyZXQgPT0gTlVMTCkgewogICAgICAgIHhtbEdlbmVyaWNFcnJvcih4bWxH ZW5lcmljRXJyb3JDb250ZXh0LAogICAgICAgICAgICAgICAgICAgICAgICAieG1sTmV3VGV4dFdy aXRlciA6IG91dCBvZiBtZW1vcnkhXG4iKTsKICAgICAgICByZXR1cm4gTlVMTDsKICAgIH0KICAg IG1lbXNldChyZXQsIDAsIChzaXplX3QpIHNpemVvZih4bWxUZXh0V3JpdGVyKSk7CgogICAgcmV0 LT5ub2RlcyA9IHhtbExpc3RDcmVhdGUoKHhtbExpc3REZWFsbG9jYXRvcikKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHhtbEZyZWVUZXh0V3JpdGVyU3RhY2tFbnRyeSwKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICh4bWxMaXN0RGF0YUNvbXBhcmUpCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB4bWxDbXBUZXh0V3JpdGVyU3RhY2tFbnRyeSk7CiAgICBpZiAocmV0 LT5ub2RlcyA9PSBOVUxMKSB7CiAgICAgICAgeG1sR2VuZXJpY0Vycm9yKHhtbEdlbmVyaWNFcnJv ckNvbnRleHQsCiAgICAgICAgICAgICAgICAgICAgICAgICJ4bWxOZXdUZXh0V3JpdGVyIDogb3V0 IG9mIG1lbW9yeSFcbiIpOwogICAgICAgIHhtbEZyZWUocmV0KTsKICAgICAgICByZXR1cm4gTlVM TDsKICAgIH0KCiAgICByZXQtPm91dCA9IG91dDsKICAgIHJldC0+cWNoYXIgPSAnIic7CgogICAg cmV0dXJuIHJldDsKfQoKLyoqCiAqIHhtbE5ld1RleHRXcml0ZXJGaWxlbmFtZToKICogQHVyaTog IHRoZSBVUkkgb2YgdGhlIHJlc291cmNlIGZvciB0aGUgb3V0cHV0CiAqIEBjb21wcmVzc2lvbjog IGNvbXByZXNzIHRoZSBvdXRwdXQ/CiAqCiAqIENyZWF0ZSBhIG5ldyB4bWxOZXdUZXh0V3JpdGVy IHN0cnVjdHVyZSB3aXRoIEB1cmkgYXMgb3V0cHV0CiAqCiAqIFJldHVybnMgdGhlIG5ldyB4bWxU ZXh0V3JpdGVyUHRyIG9yIE5VTEwgaW4gY2FzZSBvZiBlcnJvcgogKi8KeG1sVGV4dFdyaXRlclB0 cgp4bWxOZXdUZXh0V3JpdGVyRmlsZW5hbWUoY29uc3QgY2hhciAqdXJpLCBpbnQgY29tcHJlc3Np b24pCnsKICAgIHhtbFRleHRXcml0ZXJQdHIgcmV0OwogICAgeG1sT3V0cHV0QnVmZmVyUHRyIG91 dDsKCiAgICBvdXQgPSB4bWxPdXRwdXRCdWZmZXJDcmVhdGVGaWxlbmFtZSh1cmksIE5VTEwsIGNv bXByZXNzaW9uKTsKICAgIGlmIChvdXQgPT0gTlVMTCkgewogICAgICAgIHhtbEdlbmVyaWNFcnJv cih4bWxHZW5lcmljRXJyb3JDb250ZXh0LAogICAgICAgICAgICAgICAgICAgICAgICAieG1sTmV3 VGV4dFdyaXRlckZpbGVuYW1lIDogb3V0IG9mIG1lbW9yeSFcbiIpOwogICAgICAgIHJldHVybiBO VUxMOwogICAgfQoKICAgIHJldCA9IHhtbE5ld1RleHRXcml0ZXIob3V0KTsKICAgIGlmIChyZXQg PT0gTlVMTCkgewogICAgICAgIHhtbEdlbmVyaWNFcnJvcih4bWxHZW5lcmljRXJyb3JDb250ZXh0 LAogICAgICAgICAgICAgICAgICAgICAgICAieG1sTmV3VGV4dFdyaXRlckZpbGVuYW1lIDogb3V0 IG9mIG1lbW9yeSFcbiIpOwogICAgICAgIHhtbE91dHB1dEJ1ZmZlckNsb3NlKG91dCk7CiAgICAg ICAgcmV0dXJuIE5VTEw7CiAgICB9CgogICAgcmV0dXJuIHJldDsKfQoKLyoqCiAqIHhtbE5ld1Rl eHRXcml0ZXJNZW1vcnk6CiAqIEBidWY6ICB4bWxCdWZmZXJQdHIKICogQGNvbXByZXNzaW9uOiAg Y29tcHJlc3MgdGhlIG91dHB1dD8KICoKICogQ3JlYXRlIGEgbmV3IHhtbE5ld1RleHRXcml0ZXIg c3RydWN0dXJlIHdpdGggQGJ1ZiBhcyBvdXRwdXQKICogVE9ETzogaGFuZGxlIGNvbXByZXNzaW9u CiAqCiAqIFJldHVybnMgdGhlIG5ldyB4bWxUZXh0V3JpdGVyUHRyIG9yIE5VTEwgaW4gY2FzZSBv ZiBlcnJvcgogKi8KeG1sVGV4dFdyaXRlclB0cgp4bWxOZXdUZXh0V3JpdGVyTWVtb3J5KHhtbEJ1 ZmZlclB0ciBidWYsIGludCBjb21wcmVzc2lvbikKewogICAgeG1sVGV4dFdyaXRlclB0ciByZXQ7 CiAgICB4bWxPdXRwdXRCdWZmZXJQdHIgb3V0OwoKLyo6OnRvZG8gaGFuZGxlIGNvbXByZXNzaW9u ICovCiAgICBvdXQgPSB4bWxPdXRwdXRCdWZmZXJDcmVhdGVJTygoeG1sT3V0cHV0V3JpdGVDYWxs YmFjaykKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHhtbFRleHRXcml0ZXJXcml0 ZU1lbUNhbGxiYWNrLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKHhtbE91dHB1 dENsb3NlQ2FsbGJhY2spCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB4bWxUZXh0 V3JpdGVyQ2xvc2VNZW1DYWxsYmFjaywKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICh2b2lkICopIGJ1ZiwgTlVMTCk7CiAgICBpZiAob3V0ID09IE5VTEwpIHsKICAgICAgICB4bWxH ZW5lcmljRXJyb3IoeG1sR2VuZXJpY0Vycm9yQ29udGV4dCwKICAgICAgICAgICAgICAgICAgICAg ICAgInhtbE5ld1RleHRXcml0ZXJNZW1vcnkgOiBvdXQgb2YgbWVtb3J5IVxuIik7CiAgICAgICAg cmV0dXJuIE5VTEw7CiAgICB9CgogICAgcmV0ID0geG1sTmV3VGV4dFdyaXRlcihvdXQpOwogICAg aWYgKHJldCA9PSBOVUxMKSB7CiAgICAgICAgeG1sR2VuZXJpY0Vycm9yKHhtbEdlbmVyaWNFcnJv ckNvbnRleHQsCiAgICAgICAgICAgICAgICAgICAgICAgICJ4bWxOZXdUZXh0V3JpdGVyTWVtb3J5 IDogb3V0IG9mIG1lbW9yeSFcbiIpOwogICAgICAgIHhtbE91dHB1dEJ1ZmZlckNsb3NlKG91dCk7 CiAgICAgICAgcmV0dXJuIE5VTEw7CiAgICB9CgogICAgcmV0dXJuIHJldDsKfQoKLyoqCiAqIHht bEZyZWVUZXh0V3JpdGVyOgogKiBAd3JpdGVyOiAgdGhlIHhtbFRleHRXcml0ZXJQdHIKICoKICog RGVhbGxvY2F0ZSBhbGwgdGhlIHJlc291cmNlcyBhc3NvY2lhdGVkIHRvIHRoZSB3cml0ZXIKICov CnZvaWQKeG1sRnJlZVRleHRXcml0ZXIoeG1sVGV4dFdyaXRlclB0ciB3cml0ZXIpCnsKICAgIGlm ICh3cml0ZXIgPT0gTlVMTCkKICAgICAgICByZXR1cm47CgogICAgaWYgKHdyaXRlci0+b3V0ICE9 IE5VTEwpCiAgICAgICAgeG1sT3V0cHV0QnVmZmVyQ2xvc2Uod3JpdGVyLT5vdXQpOwoKICAgIGlm ICh3cml0ZXItPm5vZGVzICE9IE5VTEwpCiAgICAgICAgeG1sTGlzdERlbGV0ZSh3cml0ZXItPm5v ZGVzKTsKfQoKLyoqCiAqIHhtbFRleHRXcml0ZXJTdGFydERvY3VtZW50OgogKiBAd3JpdGVyOiAg dGhlIHhtbFRleHRXcml0ZXJQdHIKICogQHZlcnNpb246ICB0aGUgeG1sIHZlcnNpb24gKCIxLjAi KSBvciBOVUxMIGZvciBkZWZhdWx0ICgiMS4wIikKICogQGVuY29kaW5nOiAgdGhlIGVuY29kaW5n IG9yIE5VTEwgZm9yIGRlZmF1bHQKICogQHN0YW5kYWxvbmU6ICJ5ZXMiIG9yICJubyIgb3IgTlVM TCBmb3IgZGVmYXVsdAogKgogKiBTdGFydCBhIG5ldyB4bWwgZG9jdW1lbnQKICoKICogUmV0dXJu cyB0aGUgYnl0ZXMgd3JpdHRlbiAobWF5IGJlIDAgYmVjYXVzZSBvZiBidWZmZXJpbmcpIG9yIC0x IGluIGNhc2Ugb2YgZXJyb3IKICovCmludAp4bWxUZXh0V3JpdGVyU3RhcnREb2N1bWVudCh4bWxU ZXh0V3JpdGVyUHRyIHdyaXRlciwgY29uc3QgY2hhciAqdmVyc2lvbiwKICAgICAgICAgICAgICAg ICAgICAgICAgICAgY29uc3QgY2hhciAqZW5jb2RpbmcsIGNvbnN0IGNoYXIgKnN0YW5kYWxvbmUp CnsKICAgIGludCBjb3VudDsKICAgIGludCBzdW07CiAgICB4bWxDaGFyRW5jb2RpbmdIYW5kbGVy UHRyIGVuY29kZXI7CgogICAgaWYgKCh3cml0ZXIgPT0gTlVMTCkgfHwgKHdyaXRlci0+b3V0ID09 IE5VTEwpKQogICAgICAgIHJldHVybiAtMTsKCiAgICBlbmNvZGVyID0gMDsKICAgIGlmIChlbmNv ZGluZyAhPSBOVUxMKSB7CiAgICAgICAgZW5jb2RlciA9IHhtbEZpbmRDaGFyRW5jb2RpbmdIYW5k bGVyKGVuY29kaW5nKTsKICAgICAgICBpZiAoZW5jb2RlciA9PSBOVUxMKSB7CiAgICAgICAgICAg IHhtbEdlbmVyaWNFcnJvcih4bWxHZW5lcmljRXJyb3JDb250ZXh0LAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgInhtbFRleHRXcml0ZXJTdGFydERvY3VtZW50IDogb3V0IG9mIG1lbW9yeSFc biIpOwogICAgICAgICAgICByZXR1cm4gLTE7CiAgICAgICAgfQogICAgfQoKICAgIHdyaXRlci0+ b3V0LT5lbmNvZGVyID0gZW5jb2RlcjsKICAgIGlmIChlbmNvZGVyICE9IE5VTEwpIHsKICAgICAg ICB3cml0ZXItPm91dC0+Y29udiA9IHhtbEJ1ZmZlckNyZWF0ZVNpemUoNDAwMCk7CiAgICAgICAg eG1sQ2hhckVuY091dEZ1bmMoZW5jb2Rlciwgd3JpdGVyLT5vdXQtPmNvbnYsIE5VTEwpOwogICAg fSBlbHNlCiAgICAgICAgd3JpdGVyLT5vdXQtPmNvbnYgPSBOVUxMOwoKICAgIHN1bSA9IDA7CiAg ICBjb3VudCA9IHhtbE91dHB1dEJ1ZmZlcldyaXRlU3RyaW5nKHdyaXRlci0+b3V0LCAiPD94bWwg dmVyc2lvbj0iKTsKICAgIGlmIChjb3VudCA8IDApCiAgICAgICAgcmV0dXJuIC0xOwogICAgc3Vt ICs9IGNvdW50OwogICAgY291bnQgPSB4bWxPdXRwdXRCdWZmZXJXcml0ZSh3cml0ZXItPm91dCwg MSwgJndyaXRlci0+cWNoYXIpOwogICAgaWYgKGNvdW50IDwgMCkKICAgICAgICByZXR1cm4gLTE7 CiAgICBzdW0gKz0gY291bnQ7CiAgICBpZiAodmVyc2lvbiAhPSAwKQogICAgICAgIGNvdW50ID0g eG1sT3V0cHV0QnVmZmVyV3JpdGVTdHJpbmcod3JpdGVyLT5vdXQsIHZlcnNpb24pOwogICAgZWxz ZQogICAgICAgIGNvdW50ID0geG1sT3V0cHV0QnVmZmVyV3JpdGVTdHJpbmcod3JpdGVyLT5vdXQs ICIxLjAiKTsKICAgIGlmIChjb3VudCA8IDApCiAgICAgICAgcmV0dXJuIC0xOwogICAgc3VtICs9 IGNvdW50OwogICAgY291bnQgPSB4bWxPdXRwdXRCdWZmZXJXcml0ZSh3cml0ZXItPm91dCwgMSwg JndyaXRlci0+cWNoYXIpOwogICAgaWYgKGNvdW50IDwgMCkKICAgICAgICByZXR1cm4gLTE7CiAg ICBzdW0gKz0gY291bnQ7CiAgICBpZiAod3JpdGVyLT5vdXQtPmVuY29kZXIgIT0gMCkgewogICAg ICAgIGNvdW50ID0geG1sT3V0cHV0QnVmZmVyV3JpdGVTdHJpbmcod3JpdGVyLT5vdXQsICIgZW5j b2Rpbmc9Iik7CiAgICAgICAgaWYgKGNvdW50IDwgMCkKICAgICAgICAgICAgcmV0dXJuIC0xOwog ICAgICAgIHN1bSArPSBjb3VudDsKICAgICAgICBjb3VudCA9IHhtbE91dHB1dEJ1ZmZlcldyaXRl KHdyaXRlci0+b3V0LCAxLCAmd3JpdGVyLT5xY2hhcik7CiAgICAgICAgaWYgKGNvdW50IDwgMCkK ICAgICAgICAgICAgcmV0dXJuIC0xOwogICAgICAgIHN1bSArPSBjb3VudDsKICAgICAgICBjb3Vu dCA9CiAgICAgICAgICAgIHhtbE91dHB1dEJ1ZmZlcldyaXRlU3RyaW5nKHdyaXRlci0+b3V0LAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3cml0ZXItPm91dC0+ZW5jb2Rl ci0+bmFtZSk7CiAgICAgICAgaWYgKGNvdW50IDwgMCkKICAgICAgICAgICAgcmV0dXJuIC0xOwog ICAgICAgIHN1bSArPSBjb3VudDsKICAgICAgICBjb3VudCA9IHhtbE91dHB1dEJ1ZmZlcldyaXRl KHdyaXRlci0+b3V0LCAxLCAmd3JpdGVyLT5xY2hhcik7CiAgICAgICAgaWYgKGNvdW50IDwgMCkK ICAgICAgICAgICAgcmV0dXJuIC0xOwogICAgICAgIHN1bSArPSBjb3VudDsKICAgIH0KCiAgICBp ZiAoc3RhbmRhbG9uZSAhPSAwKSB7CiAgICAgICAgY291bnQgPSB4bWxPdXRwdXRCdWZmZXJXcml0 ZVN0cmluZyh3cml0ZXItPm91dCwgIiBzdGFuZGFsb25lPSIpOwogICAgICAgIGlmIChjb3VudCA8 IDApCiAgICAgICAgICAgIHJldHVybiAtMTsKICAgICAgICBzdW0gKz0gY291bnQ7CiAgICAgICAg Y291bnQgPSB4bWxPdXRwdXRCdWZmZXJXcml0ZSh3cml0ZXItPm91dCwgMSwgJndyaXRlci0+cWNo YXIpOwogICAgICAgIGlmIChjb3VudCA8IDApCiAgICAgICAgICAgIHJldHVybiAtMTsKICAgICAg ICBzdW0gKz0gY291bnQ7CiAgICAgICAgY291bnQgPSB4bWxPdXRwdXRCdWZmZXJXcml0ZVN0cmlu Zyh3cml0ZXItPm91dCwgc3RhbmRhbG9uZSk7CiAgICAgICAgaWYgKGNvdW50IDwgMCkKICAgICAg ICAgICAgcmV0dXJuIC0xOwogICAgICAgIHN1bSArPSBjb3VudDsKICAgICAgICBjb3VudCA9IHht bE91dHB1dEJ1ZmZlcldyaXRlKHdyaXRlci0+b3V0LCAxLCAmd3JpdGVyLT5xY2hhcik7CiAgICAg ICAgaWYgKGNvdW50IDwgMCkKICAgICAgICAgICAgcmV0dXJuIC0xOwogICAgICAgIHN1bSArPSBj b3VudDsKICAgIH0KCiAgICBjb3VudCA9IHhtbE91dHB1dEJ1ZmZlcldyaXRlU3RyaW5nKHdyaXRl ci0+b3V0LCAiPz5cbiIpOwogICAgaWYgKGNvdW50IDwgMCkKICAgICAgICByZXR1cm4gLTE7CiAg ICBzdW0gKz0gY291bnQ7CgogICAgcmV0dXJuIHN1bTsKfQoKLyoqCiAqIHhtbFRleHRXcml0ZXJF bmREb2N1bWVudDoKICogQHdyaXRlcjogIHRoZSB4bWxUZXh0V3JpdGVyUHRyCiAqCiAqIEVuZCBh biB4bWwgZG9jdW1lbnQuIEFsbCBvcGVuIGVsZW1lbnRzIGFyZSBjbG9zZWQKICoKICogUmV0dXJu cyB0aGUgYnl0ZXMgd3JpdHRlbiAobWF5IGJlIDAgYmVjYXVzZSBvZiBidWZmZXJpbmcpIG9yIC0x IGluIGNhc2Ugb2YgZXJyb3IKICovCmludAp4bWxUZXh0V3JpdGVyRW5kRG9jdW1lbnQoeG1sVGV4 dFdyaXRlclB0ciB3cml0ZXIpCnsKICAgIGludCBjb3VudDsKICAgIGludCBzdW07CiAgICB4bWxM aW5rUHRyIGxrOwogICAgeG1sVGV4dFdyaXRlclN0YWNrRW50cnkgKnA7CgogICAgaWYgKHdyaXRl ciA9PSBOVUxMKQogICAgICAgIHJldHVybiAtMTsKCiAgICBzdW0gPSAwOwogICAgd2hpbGUgKGxr ID0geG1sTGlzdEZyb250KHdyaXRlci0+bm9kZXMpKSB7CiAgICAgICAgcCA9ICh4bWxUZXh0V3Jp dGVyU3RhY2tFbnRyeSAqKSB4bWxMaW5rR2V0RGF0YShsayk7CiAgICAgICAgaWYgKHAgPT0gMCkK ICAgICAgICAgICAgYnJlYWs7CiAgICAgICAgY291bnQgPSB4bWxUZXh0V3JpdGVyRW5kRWxlbWVu dCh3cml0ZXIpOwogICAgICAgIGlmIChjb3VudCA8IDApCiAgICAgICAgICAgIHJldHVybiAtMTsK ICAgICAgICBzdW0gKz0gY291bnQ7CiAgICB9CgogICAgcmV0dXJuIHN1bTsKfQoKLyoqCiAqIHht bFRleHRXcml0ZXJXcml0ZUZvcm1hdENvbW1lbnQ6CiAqIEB3cml0ZXI6ICB0aGUgeG1sVGV4dFdy aXRlclB0cgogKiBAZm9ybWF0OiAgZm9ybWF0IHN0cmluZyAoc2VlIHByaW50ZikKICoKICogV3Jp dGUgYW4geG1sIGNvbW1lbnQuCiAqCiAqIFJldHVybnMgdGhlIGJ5dGVzIHdyaXR0ZW4gKG1heSBi ZSAwIGJlY2F1c2Ugb2YgYnVmZmVyaW5nKSBvciAtMSBpbiBjYXNlIG9mIGVycm9yCiAqLwppbnQK eG1sVGV4dFdyaXRlcldyaXRlRm9ybWF0Q29tbWVudCh4bWxUZXh0V3JpdGVyUHRyIHdyaXRlciwK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCBjaGFyICpmb3JtYXQsIC4uLikK ewogICAgaW50IHJjOwogICAgdmFfbGlzdCBhcDsKCiAgICB2YV9zdGFydChhcCwgZm9ybWF0KTsK CiAgICByYyA9IHhtbFRleHRXcml0ZXJXcml0ZVZGb3JtYXRDb21tZW50KHdyaXRlciwgZm9ybWF0 LCBhcCk7CgogICAgdmFfZW5kKGFwKTsKICAgIHJldHVybiByYzsKfQoKLyoqCiAqIHhtbFRleHRX cml0ZXJXcml0ZVZGb3JtYXRDb21tZW50OgogKiBAd3JpdGVyOiAgdGhlIHhtbFRleHRXcml0ZXJQ dHIKICogQGZvcm1hdDogIGZvcm1hdCBzdHJpbmcgKHNlZSBwcmludGYpCiAqIEBhcmdwdHI6ICBw b2ludGVyIHRvIHRoZSBmaXJzdCBtZW1iZXIgb2YgdGhlIHZhcmlhYmxlIGFyZ3VtZW50IGxpc3Qu CiAqCiAqIFdyaXRlIGFuIHhtbCBjb21tZW50LgogKgogKiBSZXR1cm5zIHRoZSBieXRlcyB3cml0 dGVuIChtYXkgYmUgMCBiZWNhdXNlIG9mIGJ1ZmZlcmluZykgb3IgLTEgaW4gY2FzZSBvZiBlcnJv cgogKi8KaW50CnhtbFRleHRXcml0ZXJXcml0ZVZGb3JtYXRDb21tZW50KHhtbFRleHRXcml0ZXJQ dHIgd3JpdGVyLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCBjaGFyICpm b3JtYXQsIHZhX2xpc3QgYXJncHRyKQp7CiAgICBpbnQgcmM7CiAgICB4bWxDaGFyICpidWY7Cgog ICAgaWYgKHdyaXRlciA9PSBOVUxMKQogICAgICAgIHJldHVybiAtMTsKCiAgICBidWYgPSB4bWxU ZXh0V3JpdGVyVlNwcmludGYoZm9ybWF0LCBhcmdwdHIpOwogICAgaWYgKGJ1ZiA9PSAwKQogICAg ICAgIHJldHVybiAwOwoKICAgIHJjID0geG1sVGV4dFdyaXRlcldyaXRlQ29tbWVudCh3cml0ZXIs IGJ1Zik7CgogICAgeG1sRnJlZShidWYpOwogICAgcmV0dXJuIHJjOwp9CgovKioKICogeG1sVGV4 dFdyaXRlcldyaXRlQ29tbWVudDoKICogQHdyaXRlcjogIHRoZSB4bWxUZXh0V3JpdGVyUHRyCiAq IEB2YWx1ZTogIGNvbW1lbnQgc3RyaW5nCiAqCiAqIFdyaXRlIGFuIHhtbCBjb21tZW50LgogKgog KiBSZXR1cm5zIHRoZSBieXRlcyB3cml0dGVuIChtYXkgYmUgMCBiZWNhdXNlIG9mIGJ1ZmZlcmlu Zykgb3IgLTEgaW4gY2FzZSBvZiBlcnJvcgogKi8KaW50CnhtbFRleHRXcml0ZXJXcml0ZUNvbW1l bnQoeG1sVGV4dFdyaXRlclB0ciB3cml0ZXIsIGNvbnN0IHhtbENoYXIgKiB2YWx1ZSkKewogICAg aW50IGNvdW50OwogICAgaW50IHN1bTsKICAgIHhtbExpbmtQdHIgbGs7CiAgICB4bWxUZXh0V3Jp dGVyU3RhY2tFbnRyeSAqcDsKICAgIHhtbENoYXIgKmJ1ZjsKCiAgICBpZiAoKHdyaXRlciA9PSBO VUxMKSB8fCAod3JpdGVyLT5vdXQgPT0gTlVMTCkpCiAgICAgICAgcmV0dXJuIC0xOwoKICAgIGlm ICh2YWx1ZSA9PSBOVUxMKQogICAgICAgIHJldHVybiAwOwoKICAgIHN1bSA9IDA7CiAgICBsayA9 IHhtbExpc3RGcm9udCh3cml0ZXItPm5vZGVzKTsKICAgIGlmIChsayAhPSAwKSB7CiAgICAgICAg cCA9ICh4bWxUZXh0V3JpdGVyU3RhY2tFbnRyeSAqKSB4bWxMaW5rR2V0RGF0YShsayk7CiAgICAg ICAgaWYgKHAgIT0gMCkgewogICAgICAgICAgICBzd2l0Y2ggKHAtPnN0YXRlKSB7CiAgICAgICAg ICAgICAgICBjYXNlIFhNTF9URVhUV1JJVEVSX05PTkU6CiAgICAgICAgICAgICAgICBjYXNlIFhN TF9URVhUV1JJVEVSX1RFWFQ6CiAgICAgICAgICAgICAgICAgICAgYnJlYWs7CiAgICAgICAgICAg ICAgICBjYXNlIFhNTF9URVhUV1JJVEVSX05BTUU6CiAgICAgICAgICAgICAgICAgICAgY291bnQg PSB4bWxPdXRwdXRCdWZmZXJXcml0ZVN0cmluZyh3cml0ZXItPm91dCwgIj4iKTsKICAgICAgICAg ICAgICAgICAgICBpZiAoY291bnQgPCAwKQogICAgICAgICAgICAgICAgICAgICAgICByZXR1cm4g LTE7CiAgICAgICAgICAgICAgICAgICAgc3VtICs9IGNvdW50OwogICAgICAgICAgICAgICAgICAg IHAtPnN0YXRlID0gWE1MX1RFWFRXUklURVJfVEVYVDsKICAgICAgICAgICAgICAgICAgICBicmVh azsKICAgICAgICAgICAgfQogICAgICAgIH0KICAgIH0KCiAgICBjb3VudCA9IHhtbE91dHB1dEJ1 ZmZlcldyaXRlU3RyaW5nKHdyaXRlci0+b3V0LCAiPCEtLSIpOwogICAgaWYgKGNvdW50IDwgMCkK ICAgICAgICByZXR1cm4gLTE7CiAgICBzdW0gKz0gY291bnQ7CiAgICBidWYgPSB4bWxFbmNvZGVF bnRpdGllc1JlZW50cmFudChOVUxMLCB2YWx1ZSk7CiAgICBpZiAoYnVmICE9IDApIHsKICAgICAg ICBjb3VudCA9IHhtbE91dHB1dEJ1ZmZlcldyaXRlU3RyaW5nKHdyaXRlci0+b3V0LCBidWYpOwog ICAgICAgIHhtbEZyZWUoYnVmKTsKICAgIH0gZWxzZQogICAgICAgIGNvdW50ID0geG1sT3V0cHV0 QnVmZmVyV3JpdGVTdHJpbmcod3JpdGVyLT5vdXQsIHZhbHVlKTsKICAgIGlmIChjb3VudCA8IDAp CiAgICAgICAgcmV0dXJuIC0xOwogICAgc3VtICs9IGNvdW50OwogICAgY291bnQgPSB4bWxPdXRw dXRCdWZmZXJXcml0ZVN0cmluZyh3cml0ZXItPm91dCwgIi0tPiIpOwogICAgaWYgKGNvdW50IDwg MCkKICAgICAgICByZXR1cm4gLTE7CiAgICBzdW0gKz0gY291bnQ7CgogICAgcmV0dXJuIHN1bTsK fQoKLyoqCiAqIHhtbFRleHRXcml0ZXJTdGFydEVsZW1lbnQ6CiAqIEB3cml0ZXI6ICB0aGUgeG1s VGV4dFdyaXRlclB0cgogKiBAbmFtZTogIGVsZW1lbnQgbmFtZQogKgogKiBTdGFydCBhbiB4bWwg ZWxlbWVudC4KICoKICogUmV0dXJucyB0aGUgYnl0ZXMgd3JpdHRlbiAobWF5IGJlIDAgYmVjYXVz ZSBvZiBidWZmZXJpbmcpIG9yIC0xIGluIGNhc2Ugb2YgZXJyb3IKICovCmludAp4bWxUZXh0V3Jp dGVyU3RhcnRFbGVtZW50KHhtbFRleHRXcml0ZXJQdHIgd3JpdGVyLCBjb25zdCB4bWxDaGFyICog bmFtZSkKewogICAgaW50IGNvdW50OwogICAgaW50IHN1bTsKICAgIHhtbExpbmtQdHIgbGs7CiAg ICB4bWxUZXh0V3JpdGVyU3RhY2tFbnRyeSAqcDsKCiAgICBpZiAoKHdyaXRlciA9PSBOVUxMKSB8 fCAobmFtZSA9PSBOVUxMKSB8fCAoKm5hbWUgPT0gJ1wwJykpCiAgICAgICAgcmV0dXJuIC0xOwoK ICAgIHN1bSA9IDA7CiAgICBsayA9IHhtbExpc3RGcm9udCh3cml0ZXItPm5vZGVzKTsKICAgIGlm IChsayAhPSAwKSB7CiAgICAgICAgcCA9ICh4bWxUZXh0V3JpdGVyU3RhY2tFbnRyeSAqKSB4bWxM aW5rR2V0RGF0YShsayk7CiAgICAgICAgaWYgKHAgIT0gMCkgewogICAgICAgICAgICBzd2l0Y2gg KHAtPnN0YXRlKSB7CiAgICAgICAgICAgICAgICBjYXNlIFhNTF9URVhUV1JJVEVSX05PTkU6CiAg ICAgICAgICAgICAgICAgICAgYnJlYWs7CiAgICAgICAgICAgICAgICBjYXNlIFhNTF9URVhUV1JJ VEVSX05BTUU6CiAgICAgICAgICAgICAgICAgICAgY291bnQgPSB4bWxPdXRwdXRCdWZmZXJXcml0 ZVN0cmluZyh3cml0ZXItPm91dCwgIj4iKTsKICAgICAgICAgICAgICAgICAgICBpZiAoY291bnQg PCAwKQogICAgICAgICAgICAgICAgICAgICAgICByZXR1cm4gLTE7CiAgICAgICAgICAgICAgICAg ICAgc3VtICs9IGNvdW50OwogICAgICAgICAgICAgICAgICAgIHAtPnN0YXRlID0gWE1MX1RFWFRX UklURVJfVEVYVDsKICAgICAgICAgICAgICAgICAgICBicmVhazsKICAgICAgICAgICAgfQogICAg ICAgIH0KICAgIH0KCiAgICBwID0gKHhtbFRleHRXcml0ZXJTdGFja0VudHJ5ICopCiAgICAgICAg eG1sTWFsbG9jKHNpemVvZih4bWxUZXh0V3JpdGVyU3RhY2tFbnRyeSkpOwogICAgaWYgKHAgPT0g MCkgewogICAgICAgIHhtbEdlbmVyaWNFcnJvcih4bWxHZW5lcmljRXJyb3JDb250ZXh0LAogICAg ICAgICAgICAgICAgICAgICAgICAieG1sVGV4dFdyaXRlclN0YXJ0RWxlbWVudCA6IG91dCBvZiBt ZW1vcnkhXG4iKTsKICAgICAgICByZXR1cm4gLTE7CiAgICB9CgogICAgcC0+bmFtZSA9IHhtbFN0 cmR1cChuYW1lKTsKICAgIGlmIChwLT5uYW1lID09IDApIHsKICAgICAgICB4bWxHZW5lcmljRXJy b3IoeG1sR2VuZXJpY0Vycm9yQ29udGV4dCwKICAgICAgICAgICAgICAgICAgICAgICAgInhtbFRl eHRXcml0ZXJTdGFydEVsZW1lbnQgOiBvdXQgb2YgbWVtb3J5IVxuIik7CiAgICAgICAgeG1sRnJl ZShwKTsKICAgICAgICByZXR1cm4gLTE7CiAgICB9CiAgICBwLT5zdGF0ZSA9IFhNTF9URVhUV1JJ VEVSX05BTUU7CgogICAgeG1sTGlzdFB1c2hGcm9udCh3cml0ZXItPm5vZGVzLCBwKTsKCiAgICBj b3VudCA9IHhtbE91dHB1dEJ1ZmZlcldyaXRlU3RyaW5nKHdyaXRlci0+b3V0LCAiPCIpOwogICAg aWYgKGNvdW50IDwgMCkKICAgICAgICByZXR1cm4gLTE7CiAgICBzdW0gKz0gY291bnQ7CiAgICBj b3VudCA9IHhtbE91dHB1dEJ1ZmZlcldyaXRlU3RyaW5nKHdyaXRlci0+b3V0LCBwLT5uYW1lKTsK ICAgIGlmIChjb3VudCA8IDApCiAgICAgICAgcmV0dXJuIC0xOwogICAgc3VtICs9IGNvdW50OwoK ICAgIHJldHVybiBzdW07Cn0KCi8qKgogKiB4bWxUZXh0V3JpdGVyU3RhcnRFbGVtZW50TlM6CiAq IEB3cml0ZXI6ICB0aGUgeG1sVGV4dFdyaXRlclB0cgogKiBAcHJlZml4OiAgbmFtZXNwYWNlIHBy ZWZpeCBvciBOVUxMCiAqIEBuYW1lOiAgZWxlbWVudCBuYW1lCiAqIEBuYW1lc3BhY2VVUkk6ICBu YW1lc3BhY2UgVVJJIG9yIE5VTEwKICoKICogU3RhcnQgYW4geG1sIGVsZW1lbnQgd2l0aCBuYW1l c3BhY2Ugc3VwcG9ydC4KICoKICogUmV0dXJucyB0aGUgYnl0ZXMgd3JpdHRlbiAobWF5IGJlIDAg YmVjYXVzZSBvZiBidWZmZXJpbmcpIG9yIC0xIGluIGNhc2Ugb2YgZXJyb3IKICovCmludAp4bWxU ZXh0V3JpdGVyU3RhcnRFbGVtZW50TlMoeG1sVGV4dFdyaXRlclB0ciB3cml0ZXIsCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICogcHJlZml4LCBjb25zdCB4bWxDaGFy ICogbmFtZSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHhtbENoYXIgKiBuYW1l c3BhY2VVUkkpCnsKICAgIGludCBjb3VudDsKICAgIGludCBzdW07CiAgICB4bWxDaGFyICpidWY7 CgogICAgaWYgKCh3cml0ZXIgPT0gTlVMTCkgfHwgKG5hbWUgPT0gTlVMTCkgfHwgKCpuYW1lID09 ICdcMCcpKQogICAgICAgIHJldHVybiAtMTsKCiAgICBidWYgPSAwOwogICAgaWYgKHByZWZpeCAh PSAwKSB7CiAgICAgICAgYnVmID0geG1sU3RyZHVwKHByZWZpeCk7CiAgICAgICAgYnVmID0geG1s U3RyY2F0KGJ1ZiwgIjoiKTsKICAgIH0KICAgIGJ1ZiA9IHhtbFN0cmNhdChidWYsIG5hbWUpOwoK ICAgIHN1bSA9IDA7CiAgICBjb3VudCA9IHhtbFRleHRXcml0ZXJTdGFydEVsZW1lbnQod3JpdGVy LCBidWYpOwogICAgeG1sRnJlZShidWYpOwogICAgaWYgKGNvdW50IDwgMCkKICAgICAgICByZXR1 cm4gLTE7CiAgICBzdW0gKz0gY291bnQ7CgogICAgaWYgKG5hbWVzcGFjZVVSSSAhPSAwKSB7CiAg ICAgICAgYnVmID0geG1sU3RyZHVwKCJ4bWxucyIpOwogICAgICAgIGlmIChwcmVmaXggIT0gMCkg ewogICAgICAgICAgICBidWYgPSB4bWxTdHJjYXQoYnVmLCAiOiIpOwogICAgICAgICAgICBidWYg PSB4bWxTdHJjYXQoYnVmLCBwcmVmaXgpOwogICAgICAgIH0KCiAgICAgICAgY291bnQgPSB4bWxU ZXh0V3JpdGVyV3JpdGVQcm9wKHdyaXRlciwgYnVmLCBuYW1lc3BhY2VVUkkpOwogICAgICAgIHht bEZyZWUoYnVmKTsKICAgICAgICBpZiAoY291bnQgPCAwKQogICAgICAgICAgICByZXR1cm4gLTE7 CiAgICAgICAgc3VtICs9IGNvdW50OwogICAgfQoKICAgIHJldHVybiBzdW07Cn0KCi8qKgogKiB4 bWxUZXh0V3JpdGVyRW5kRWxlbWVudDoKICogQHdyaXRlcjogIHRoZSB4bWxUZXh0V3JpdGVyUHRy CiAqCiAqIEVuZCB0aGUgY3VycmVudCB4bWwgZWxlbWVudC4KICoKICogUmV0dXJucyB0aGUgYnl0 ZXMgd3JpdHRlbiAobWF5IGJlIDAgYmVjYXVzZSBvZiBidWZmZXJpbmcpIG9yIC0xIGluIGNhc2Ug b2YgZXJyb3IKICovCmludAp4bWxUZXh0V3JpdGVyRW5kRWxlbWVudCh4bWxUZXh0V3JpdGVyUHRy IHdyaXRlcikKewogICAgaW50IGNvdW50OwogICAgaW50IHN1bTsKICAgIHhtbExpbmtQdHIgbGs7 CiAgICB4bWxUZXh0V3JpdGVyU3RhY2tFbnRyeSAqcDsKCiAgICBpZiAod3JpdGVyID09IE5VTEwp CiAgICAgICAgcmV0dXJuIC0xOwoKICAgIGxrID0geG1sTGlzdEZyb250KHdyaXRlci0+bm9kZXMp OwogICAgaWYgKGxrID09IDApCiAgICAgICAgcmV0dXJuIDA7CgogICAgcCA9ICh4bWxUZXh0V3Jp dGVyU3RhY2tFbnRyeSAqKSB4bWxMaW5rR2V0RGF0YShsayk7CiAgICBpZiAocCA9PSAwKQogICAg ICAgIHJldHVybiAwOwoKICAgIHN1bSA9IDA7CiAgICBzd2l0Y2ggKHAtPnN0YXRlKSB7CiAgICAg ICAgY2FzZSBYTUxfVEVYVFdSSVRFUl9OT05FOgogICAgICAgICAgICByZXR1cm4gMDsKICAgICAg ICBjYXNlIFhNTF9URVhUV1JJVEVSX05BTUU6CiAgICAgICAgICAgIGNvdW50ID0geG1sT3V0cHV0 QnVmZmVyV3JpdGVTdHJpbmcod3JpdGVyLT5vdXQsICIvPiIpOwogICAgICAgICAgICBpZiAoY291 bnQgPCAwKQogICAgICAgICAgICAgICAgcmV0dXJuIC0xOwogICAgICAgICAgICBzdW0gKz0gY291 bnQ7CiAgICAgICAgICAgIGJyZWFrOwogICAgICAgIGNhc2UgWE1MX1RFWFRXUklURVJfVEVYVDoK ICAgICAgICAgICAgY291bnQgPSB4bWxPdXRwdXRCdWZmZXJXcml0ZVN0cmluZyh3cml0ZXItPm91 dCwgIjwvIik7CiAgICAgICAgICAgIGlmIChjb3VudCA8IDApCiAgICAgICAgICAgICAgICByZXR1 cm4gLTE7CiAgICAgICAgICAgIHN1bSArPSBjb3VudDsKICAgICAgICAgICAgY291bnQgPSB4bWxP dXRwdXRCdWZmZXJXcml0ZVN0cmluZyh3cml0ZXItPm91dCwgcC0+bmFtZSk7CiAgICAgICAgICAg IGlmIChjb3VudCA8IDApCiAgICAgICAgICAgICAgICByZXR1cm4gLTE7CiAgICAgICAgICAgIHN1 bSArPSBjb3VudDsKICAgICAgICAgICAgY291bnQgPSB4bWxPdXRwdXRCdWZmZXJXcml0ZVN0cmlu Zyh3cml0ZXItPm91dCwgIj4iKTsKICAgICAgICAgICAgaWYgKGNvdW50IDwgMCkKICAgICAgICAg ICAgICAgIHJldHVybiAtMTsKICAgICAgICAgICAgc3VtICs9IGNvdW50OwogICAgICAgICAgICBi cmVhazsKICAgIH0KCiAgICB4bWxMaXN0UG9wRnJvbnQod3JpdGVyLT5ub2Rlcyk7CiAgICByZXR1 cm4gc3VtOwp9CgovKioKICogeG1sVGV4dFdyaXRlcldyaXRlRm9ybWF0U3RyaW5nOgogKiBAd3Jp dGVyOiAgdGhlIHhtbFRleHRXcml0ZXJQdHIKICogQGZvcm1hdDogIGZvcm1hdCBzdHJpbmcgKHNl ZSBwcmludGYpCiAqCiAqIFdyaXRlIGEgZm9ybWF0dGVkIHhtbCB0ZXh0LgogKgogKiBSZXR1cm5z IHRoZSBieXRlcyB3cml0dGVuIChtYXkgYmUgMCBiZWNhdXNlIG9mIGJ1ZmZlcmluZykgb3IgLTEg aW4gY2FzZSBvZiBlcnJvcgogKi8KaW50CnhtbFRleHRXcml0ZXJXcml0ZUZvcm1hdFN0cmluZyh4 bWxUZXh0V3JpdGVyUHRyIHdyaXRlciwgY29uc3QgY2hhciAqZm9ybWF0LAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgLi4uKQp7CiAgICBpbnQgcmM7CiAgICB2YV9saXN0IGFwOwoKICAg IHZhX3N0YXJ0KGFwLCBmb3JtYXQpOwoKICAgIHJjID0geG1sVGV4dFdyaXRlcldyaXRlVkZvcm1h dFN0cmluZyh3cml0ZXIsIGZvcm1hdCwgYXApOwoKICAgIHZhX2VuZChhcCk7CiAgICByZXR1cm4g cmM7Cn0KCi8qKgogKiB4bWxUZXh0V3JpdGVyV3JpdGVWRm9ybWF0U3RyaW5nOgogKiBAd3JpdGVy OiAgdGhlIHhtbFRleHRXcml0ZXJQdHIKICogQGZvcm1hdDogIGZvcm1hdCBzdHJpbmcgKHNlZSBw cmludGYpCiAqIEBhcmdwdHI6ICBwb2ludGVyIHRvIHRoZSBmaXJzdCBtZW1iZXIgb2YgdGhlIHZh cmlhYmxlIGFyZ3VtZW50IGxpc3QuCiAqCiAqIFdyaXRlIGEgZm9ybWF0dGVkIHhtbCB0ZXh0Lgog KgogKiBSZXR1cm5zIHRoZSBieXRlcyB3cml0dGVuIChtYXkgYmUgMCBiZWNhdXNlIG9mIGJ1ZmZl cmluZykgb3IgLTEgaW4gY2FzZSBvZiBlcnJvcgogKi8KaW50CnhtbFRleHRXcml0ZXJXcml0ZVZG b3JtYXRTdHJpbmcoeG1sVGV4dFdyaXRlclB0ciB3cml0ZXIsCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgY29uc3QgY2hhciAqZm9ybWF0LCB2YV9saXN0IGFyZ3B0cikKewogICAgaW50 IHJjOwogICAgeG1sQ2hhciAqYnVmOwoKICAgIGlmICh3cml0ZXIgPT0gTlVMTCkKICAgICAgICBy ZXR1cm4gLTE7CgogICAgYnVmID0geG1sVGV4dFdyaXRlclZTcHJpbnRmKGZvcm1hdCwgYXJncHRy KTsKICAgIGlmIChidWYgPT0gMCkKICAgICAgICByZXR1cm4gMDsKCiAgICByYyA9IHhtbFRleHRX cml0ZXJXcml0ZVN0cmluZyh3cml0ZXIsIGJ1Zik7CgogICAgeG1sRnJlZShidWYpOwogICAgcmV0 dXJuIHJjOwp9CgovKioKICogeG1sVGV4dFdyaXRlcldyaXRlU3RyaW5nOgogKiBAd3JpdGVyOiAg dGhlIHhtbFRleHRXcml0ZXJQdHIKICogQHZhbHVlOiAgdGV4dCBzdHJpbmcKICoKICogV3JpdGUg YW4geG1sIHRleHQuCiAqCiAqIFJldHVybnMgdGhlIGJ5dGVzIHdyaXR0ZW4gKG1heSBiZSAwIGJl Y2F1c2Ugb2YgYnVmZmVyaW5nKSBvciAtMSBpbiBjYXNlIG9mIGVycm9yCiAqLwppbnQKeG1sVGV4 dFdyaXRlcldyaXRlU3RyaW5nKHhtbFRleHRXcml0ZXJQdHIgd3JpdGVyLCBjb25zdCB4bWxDaGFy ICogdmFsdWUpCnsKICAgIGludCBjb3VudDsKICAgIGludCBzdW07CiAgICB4bWxMaW5rUHRyIGxr OwogICAgeG1sVGV4dFdyaXRlclN0YWNrRW50cnkgKnA7CiAgICB4bWxDaGFyICpidWY7CgogICAg aWYgKHdyaXRlciA9PSBOVUxMKQogICAgICAgIHJldHVybiAtMTsKCiAgICBsayA9IHhtbExpc3RG cm9udCh3cml0ZXItPm5vZGVzKTsKICAgIGlmIChsayA9PSAwKQogICAgICAgIHJldHVybiAwOwoK ICAgIHAgPSAoeG1sVGV4dFdyaXRlclN0YWNrRW50cnkgKikgeG1sTGlua0dldERhdGEobGspOwog ICAgaWYgKHAgPT0gMCkKICAgICAgICByZXR1cm4gMDsKCiAgICBzdW0gPSAwOwogICAgc3dpdGNo IChwLT5zdGF0ZSkgewogICAgICAgIGNhc2UgWE1MX1RFWFRXUklURVJfTk9ORToKICAgICAgICAg ICAgcmV0dXJuIDA7CiAgICAgICAgY2FzZSBYTUxfVEVYVFdSSVRFUl9OQU1FOgogICAgICAgICAg ICBjb3VudCA9IHhtbE91dHB1dEJ1ZmZlcldyaXRlU3RyaW5nKHdyaXRlci0+b3V0LCAiPiIpOwog ICAgICAgICAgICBpZiAoY291bnQgPCAwKQogICAgICAgICAgICAgICAgcmV0dXJuIC0xOwogICAg ICAgICAgICBzdW0gKz0gY291bnQ7CiAgICAgICAgICAgIHAtPnN0YXRlID0gWE1MX1RFWFRXUklU RVJfVEVYVDsKICAgICAgICAgICAgYnJlYWs7CiAgICAgICAgY2FzZSBYTUxfVEVYVFdSSVRFUl9U RVhUOgogICAgICAgICAgICBicmVhazsKICAgIH0KCiAgICBidWYgPSB4bWxFbmNvZGVFbnRpdGll c1JlZW50cmFudChOVUxMLCB2YWx1ZSk7CiAgICBpZiAoYnVmICE9IDApIHsKICAgICAgICBjb3Vu dCA9IHhtbE91dHB1dEJ1ZmZlcldyaXRlU3RyaW5nKHdyaXRlci0+b3V0LCBidWYpOwogICAgICAg IHhtbEZyZWUoYnVmKTsKICAgIH0gZWxzZQogICAgICAgIGNvdW50ID0geG1sT3V0cHV0QnVmZmVy V3JpdGVTdHJpbmcod3JpdGVyLT5vdXQsIHZhbHVlKTsKICAgIGlmIChjb3VudCA8IDApCiAgICAg ICAgcmV0dXJuIC0xOwogICAgc3VtICs9IGNvdW50OwoKICAgIHJldHVybiBzdW07Cn0KCi8qKgog KiB4bWxUZXh0V3JpdGVyV3JpdGVTdHJpbmc6CiAqIEB3cml0ZXI6ICB0aGUgeG1sVGV4dFdyaXRl clB0cgogKiBAdmFsdWU6ICB0ZXh0IHN0cmluZwogKiBAbGVuOiAgbGVuZ3RoIG9mIHRoZSB0ZXh0 IHN0cmluZwogKgogKiBXcml0ZSBhbiB4bWwgdGV4dC4KICogVE9ETzogd2hhdCBhYm91dCBlbnRp dGllcyBhbmQgc3BlY2lhbCBjaGFycz8/CiAqCiAqIFJldHVybnMgdGhlIGJ5dGVzIHdyaXR0ZW4g KG1heSBiZSAwIGJlY2F1c2Ugb2YgYnVmZmVyaW5nKSBvciAtMSBpbiBjYXNlIG9mIGVycm9yCiAq LwppbnQKeG1sVGV4dFdyaXRlcldyaXRlU3RyaW5nTGVuKHhtbFRleHRXcml0ZXJQdHIgd3JpdGVy LCBjb25zdCB4bWxDaGFyICogdmFsdWUsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnQg bGVuKQp7CiAgICBpbnQgY291bnQ7CiAgICBpbnQgc3VtOwogICAgeG1sTGlua1B0ciBsazsKICAg IHhtbFRleHRXcml0ZXJTdGFja0VudHJ5ICpwOwoKICAgIGlmICh3cml0ZXIgPT0gTlVMTCkKICAg ICAgICByZXR1cm4gLTE7CgogICAgbGsgPSB4bWxMaXN0RnJvbnQod3JpdGVyLT5ub2Rlcyk7CiAg ICBpZiAobGsgPT0gMCkKICAgICAgICByZXR1cm4gMDsKCiAgICBwID0gKHhtbFRleHRXcml0ZXJT dGFja0VudHJ5ICopIHhtbExpbmtHZXREYXRhKGxrKTsKICAgIGlmIChwID09IDApCiAgICAgICAg cmV0dXJuIDA7CgogICAgc3VtID0gMDsKICAgIHN3aXRjaCAocC0+c3RhdGUpIHsKICAgICAgICBj YXNlIFhNTF9URVhUV1JJVEVSX05PTkU6CiAgICAgICAgICAgIHJldHVybiAwOwogICAgICAgIGNh c2UgWE1MX1RFWFRXUklURVJfTkFNRToKICAgICAgICAgICAgY291bnQgPSB4bWxPdXRwdXRCdWZm ZXJXcml0ZVN0cmluZyh3cml0ZXItPm91dCwgIj4iKTsKICAgICAgICAgICAgaWYgKGNvdW50IDwg MCkKICAgICAgICAgICAgICAgIHJldHVybiAtMTsKICAgICAgICAgICAgc3VtICs9IGNvdW50Owog ICAgICAgICAgICBwLT5zdGF0ZSA9IFhNTF9URVhUV1JJVEVSX1RFWFQ7CiAgICAgICAgICAgIGJy ZWFrOwogICAgICAgIGNhc2UgWE1MX1RFWFRXUklURVJfVEVYVDoKICAgICAgICAgICAgYnJlYWs7 CiAgICB9CgogICAgY291bnQgPSB4bWxPdXRwdXRCdWZmZXJXcml0ZSh3cml0ZXItPm91dCwgbGVu LCB2YWx1ZSk7CiAgICBpZiAoY291bnQgPCAwKQogICAgICAgIHJldHVybiAtMTsKICAgIHN1bSAr PSBjb3VudDsKCiAgICByZXR1cm4gc3VtOwp9CgovKioKICogeG1sVGV4dFdyaXRlcldyaXRlRm9y bWF0UHJvcDoKICogQHdyaXRlcjogIHRoZSB4bWxUZXh0V3JpdGVyUHRyCiAqIEBuYW1lOiAgYXR0 cmlidXRlIG5hbWUKICogQGZvcm1hdDogIGZvcm1hdCBzdHJpbmcgKHNlZSBwcmludGYpCiAqCiAq IFdyaXRlIGEgZm9ybWF0dGVkIHhtbCBhdHRyaWJ1dGUuCiAqCiAqIFJldHVybnMgdGhlIGJ5dGVz IHdyaXR0ZW4gKG1heSBiZSAwIGJlY2F1c2Ugb2YgYnVmZmVyaW5nKSBvciAtMSBpbiBjYXNlIG9m IGVycm9yCiAqLwppbnQKeG1sVGV4dFdyaXRlcldyaXRlRm9ybWF0UHJvcCh4bWxUZXh0V3JpdGVy UHRyIHdyaXRlciwgY29uc3QgeG1sQ2hhciAqIG5hbWUsCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgY29uc3QgY2hhciAqZm9ybWF0LCAuLi4pCnsKICAgIGludCByYzsKICAgIHZhX2xpc3Qg YXA7CgogICAgdmFfc3RhcnQoYXAsIGZvcm1hdCk7CgogICAgcmMgPSB4bWxUZXh0V3JpdGVyV3Jp dGVWRm9ybWF0UHJvcCh3cml0ZXIsIG5hbWUsIGZvcm1hdCwgYXApOwoKICAgIHZhX2VuZChhcCk7 CiAgICByZXR1cm4gcmM7Cn0KCi8qKgogKiB4bWxUZXh0V3JpdGVyV3JpdGVWRm9ybWF0UHJvcDoK ICogQHdyaXRlcjogIHRoZSB4bWxUZXh0V3JpdGVyUHRyCiAqIEBuYW1lOiAgYXR0cmlidXRlIG5h bWUKICogQGZvcm1hdDogIGZvcm1hdCBzdHJpbmcgKHNlZSBwcmludGYpCiAqIEBhcmdwdHI6ICBw b2ludGVyIHRvIHRoZSBmaXJzdCBtZW1iZXIgb2YgdGhlIHZhcmlhYmxlIGFyZ3VtZW50IGxpc3Qu CiAqCiAqIFdyaXRlIGEgZm9ybWF0dGVkIHhtbCBhdHRyaWJ1dGUuCiAqCiAqIFJldHVybnMgdGhl IGJ5dGVzIHdyaXR0ZW4gKG1heSBiZSAwIGJlY2F1c2Ugb2YgYnVmZmVyaW5nKSBvciAtMSBpbiBj YXNlIG9mIGVycm9yCiAqLwppbnQKeG1sVGV4dFdyaXRlcldyaXRlVkZvcm1hdFByb3AoeG1sVGV4 dFdyaXRlclB0ciB3cml0ZXIsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHht bENoYXIgKiBuYW1lLCBjb25zdCBjaGFyICpmb3JtYXQsCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHZhX2xpc3QgYXJncHRyKQp7CiAgICBpbnQgcmM7CiAgICB4bWxDaGFyICpidWY7Cgog ICAgaWYgKHdyaXRlciA9PSBOVUxMKQogICAgICAgIHJldHVybiAtMTsKCiAgICBidWYgPSB4bWxU ZXh0V3JpdGVyVlNwcmludGYoZm9ybWF0LCBhcmdwdHIpOwogICAgaWYgKGJ1ZiA9PSAwKQogICAg ICAgIHJldHVybiAwOwoKICAgIHJjID0geG1sVGV4dFdyaXRlcldyaXRlUHJvcCh3cml0ZXIsIG5h bWUsIGJ1Zik7CgogICAgeG1sRnJlZShidWYpOwogICAgcmV0dXJuIHJjOwp9CgovKioKICogeG1s VGV4dFdyaXRlcldyaXRlUHJvcDoKICogQHdyaXRlcjogIHRoZSB4bWxUZXh0V3JpdGVyUHRyCiAq IEBuYW1lOiAgYXR0cmlidXRlIG5hbWUKICogQHZhbHVlOiAgYXR0cmlidXRlIHZhbHVlCiAqCiAq IFdyaXRlIGFuIHhtbCBhdHRyaWJ1dGUuCiAqCiAqIFJldHVybnMgdGhlIGJ5dGVzIHdyaXR0ZW4g KG1heSBiZSAwIGJlY2F1c2Ugb2YgYnVmZmVyaW5nKSBvciAtMSBpbiBjYXNlIG9mIGVycm9yCiAq LwppbnQKeG1sVGV4dFdyaXRlcldyaXRlUHJvcCh4bWxUZXh0V3JpdGVyUHRyIHdyaXRlciwgY29u c3QgeG1sQ2hhciAqIG5hbWUsCiAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgeG1sQ2hhciAq IHZhbHVlKQp7CiAgICBpbnQgY291bnQ7CiAgICBpbnQgc3VtOwogICAgeG1sTGlua1B0ciBsazsK ICAgIHhtbFRleHRXcml0ZXJTdGFja0VudHJ5ICpwOwogICAgeG1sQ2hhciAqYnVmOwoKICAgIGlm ICh3cml0ZXIgPT0gTlVMTCkKICAgICAgICByZXR1cm4gLTE7CgogICAgbGsgPSB4bWxMaXN0RnJv bnQod3JpdGVyLT5ub2Rlcyk7CiAgICBpZiAobGsgPT0gMCkKICAgICAgICByZXR1cm4gMDsKCiAg ICBwID0gKHhtbFRleHRXcml0ZXJTdGFja0VudHJ5ICopIHhtbExpbmtHZXREYXRhKGxrKTsKICAg IGlmIChwID09IDApCiAgICAgICAgcmV0dXJuIDA7CgogICAgc3VtID0gMDsKICAgIHN3aXRjaCAo cC0+c3RhdGUpIHsKICAgICAgICBjYXNlIFhNTF9URVhUV1JJVEVSX05PTkU6CiAgICAgICAgY2Fz ZSBYTUxfVEVYVFdSSVRFUl9URVhUOgogICAgICAgICAgICByZXR1cm4gMDsKICAgICAgICBjYXNl IFhNTF9URVhUV1JJVEVSX05BTUU6CiAgICAgICAgICAgIGJyZWFrOwogICAgfQoKICAgIGNvdW50 ID0geG1sT3V0cHV0QnVmZmVyV3JpdGVTdHJpbmcod3JpdGVyLT5vdXQsICIgIik7CiAgICBpZiAo Y291bnQgPCAwKQogICAgICAgIHJldHVybiAtMTsKICAgIHN1bSArPSBjb3VudDsKICAgIGNvdW50 ID0geG1sT3V0cHV0QnVmZmVyV3JpdGVTdHJpbmcod3JpdGVyLT5vdXQsIG5hbWUpOwogICAgaWYg KGNvdW50IDwgMCkKICAgICAgICByZXR1cm4gLTE7CiAgICBzdW0gKz0gY291bnQ7CiAgICBjb3Vu dCA9IHhtbE91dHB1dEJ1ZmZlcldyaXRlU3RyaW5nKHdyaXRlci0+b3V0LCAiPSIpOwogICAgaWYg KGNvdW50IDwgMCkKICAgICAgICByZXR1cm4gLTE7CiAgICBzdW0gKz0gY291bnQ7CiAgICBjb3Vu dCA9IHhtbE91dHB1dEJ1ZmZlcldyaXRlKHdyaXRlci0+b3V0LCAxLCAmd3JpdGVyLT5xY2hhcik7 CiAgICBpZiAoY291bnQgPCAwKQogICAgICAgIHJldHVybiAtMTsKICAgIHN1bSArPSBjb3VudDsK ICAgIGJ1ZiA9IHhtbEVuY29kZUVudGl0aWVzUmVlbnRyYW50KE5VTEwsIHZhbHVlKTsKICAgIGlm IChidWYgIT0gMCkgewogICAgICAgIGNvdW50ID0geG1sT3V0cHV0QnVmZmVyV3JpdGVTdHJpbmco d3JpdGVyLT5vdXQsIGJ1Zik7CiAgICAgICAgeG1sRnJlZShidWYpOwogICAgfSBlbHNlCiAgICAg ICAgY291bnQgPSB4bWxPdXRwdXRCdWZmZXJXcml0ZVN0cmluZyh3cml0ZXItPm91dCwgdmFsdWUp OwogICAgaWYgKGNvdW50IDwgMCkKICAgICAgICByZXR1cm4gLTE7CiAgICBzdW0gKz0gY291bnQ7 CiAgICBjb3VudCA9IHhtbE91dHB1dEJ1ZmZlcldyaXRlKHdyaXRlci0+b3V0LCAxLCAmd3JpdGVy LT5xY2hhcik7CiAgICBpZiAoY291bnQgPCAwKQogICAgICAgIHJldHVybiAtMTsKICAgIHN1bSAr PSBjb3VudDsKCiAgICByZXR1cm4gc3VtOwp9CgovKioKICogeG1sVGV4dFdyaXRlcldyaXRlRm9y bWF0UHJvcE5TOgogKiBAd3JpdGVyOiAgdGhlIHhtbFRleHRXcml0ZXJQdHIKICogQHByZWZpeDog IG5hbWVzcGFjZSBwcmVmaXgKICogQG5hbWU6ICBhdHRyaWJ1dGUgbmFtZQogKiBAZm9ybWF0OiAg Zm9ybWF0IHN0cmluZyAoc2VlIHByaW50ZikKICoKICogV3JpdGUgYSBmb3JtYXR0ZWQgeG1sIGF0 dHJpYnV0ZS53aXRoIG5hbWVzcGFjZSBzdXBwb3J0CiAqCiAqIFJldHVybnMgdGhlIGJ5dGVzIHdy aXR0ZW4gKG1heSBiZSAwIGJlY2F1c2Ugb2YgYnVmZmVyaW5nKSBvciAtMSBpbiBjYXNlIG9mIGVy cm9yCiAqLwppbnQKeG1sVGV4dFdyaXRlcldyaXRlRm9ybWF0UHJvcE5TKHhtbFRleHRXcml0ZXJQ dHIgd3JpdGVyLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgeG1sQ2hhciAq IHByZWZpeCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHhtbENoYXIgKiBu YW1lLCBjb25zdCBjaGFyICpmb3JtYXQsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAu Li4pCnsKICAgIGludCByYzsKICAgIHZhX2xpc3QgYXA7CgogICAgdmFfc3RhcnQoYXAsIGZvcm1h dCk7CgogICAgcmMgPSB4bWxUZXh0V3JpdGVyV3JpdGVWRm9ybWF0UHJvcE5TKHdyaXRlciwgcHJl Zml4LCBuYW1lLCBmb3JtYXQsIGFwKTsKCiAgICB2YV9lbmQoYXApOwogICAgcmV0dXJuIHJjOwp9 CgovKioKICogeG1sVGV4dFdyaXRlcldyaXRlVkZvcm1hdFByb3BOUzoKICogQHdyaXRlcjogIHRo ZSB4bWxUZXh0V3JpdGVyUHRyCiAqIEBwcmVmaXg6ICBuYW1lc3BhY2UgcHJlZml4CiAqIEBuYW1l OiAgYXR0cmlidXRlIG5hbWUKICogQGZvcm1hdDogIGZvcm1hdCBzdHJpbmcgKHNlZSBwcmludGYp CiAqIEBhcmdwdHI6ICBwb2ludGVyIHRvIHRoZSBmaXJzdCBtZW1iZXIgb2YgdGhlIHZhcmlhYmxl IGFyZ3VtZW50IGxpc3QuCiAqCiAqIFdyaXRlIGEgZm9ybWF0dGVkIHhtbCBhdHRyaWJ1dGUud2l0 aCBuYW1lc3BhY2Ugc3VwcG9ydAogKgogKiBSZXR1cm5zIHRoZSBieXRlcyB3cml0dGVuIChtYXkg YmUgMCBiZWNhdXNlIG9mIGJ1ZmZlcmluZykgb3IgLTEgaW4gY2FzZSBvZiBlcnJvcgogKi8KaW50 CnhtbFRleHRXcml0ZXJXcml0ZVZGb3JtYXRQcm9wTlMoeG1sVGV4dFdyaXRlclB0ciB3cml0ZXIs CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgeG1sQ2hhciAqIHByZWZpeCwK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICogbmFtZSwgY29u c3QgY2hhciAqZm9ybWF0LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHZhX2xpc3Qg YXJncHRyKQp7CiAgICBpbnQgcmM7CiAgICB4bWxDaGFyICpidWY7CgogICAgaWYgKHdyaXRlciA9 PSBOVUxMKQogICAgICAgIHJldHVybiAtMTsKCiAgICBidWYgPSB4bWxUZXh0V3JpdGVyVlNwcmlu dGYoZm9ybWF0LCBhcmdwdHIpOwogICAgaWYgKGJ1ZiA9PSAwKQogICAgICAgIHJldHVybiAwOwoK ICAgIHJjID0geG1sVGV4dFdyaXRlcldyaXRlUHJvcE5TKHdyaXRlciwgcHJlZml4LCBuYW1lLCBi dWYpOwoKICAgIHhtbEZyZWUoYnVmKTsKICAgIHJldHVybiByYzsKfQoKLyoqCiAqIHhtbFRleHRX cml0ZXJXcml0ZVByb3BOUzoKICogQHdyaXRlcjogIHRoZSB4bWxUZXh0V3JpdGVyUHRyCiAqIEBw cmVmaXg6ICBuYW1lc3BhY2UgcHJlZml4CiAqIEBuYW1lOiAgYXR0cmlidXRlIG5hbWUKICogQHZh bHVlOiAgYXR0cmlidXRlIHZhbHVlCiAqCiAqIFdyaXRlIGFuIHhtbCBhdHRyaWJ1dGUuCiAqCiAq IFJldHVybnMgdGhlIGJ5dGVzIHdyaXR0ZW4gKG1heSBiZSAwIGJlY2F1c2Ugb2YgYnVmZmVyaW5n KSBvciAtMSBpbiBjYXNlIG9mIGVycm9yCiAqLwppbnQKeG1sVGV4dFdyaXRlcldyaXRlUHJvcE5T KHhtbFRleHRXcml0ZXJQdHIgd3JpdGVyLCBjb25zdCB4bWxDaGFyICogcHJlZml4LAogICAgICAg ICAgICAgICAgICAgICAgICAgY29uc3QgeG1sQ2hhciAqIG5hbWUsIGNvbnN0IHhtbENoYXIgKiB2 YWx1ZSkKewogICAgaW50IGNvdW50OwogICAgaW50IHN1bTsKICAgIHhtbENoYXIgKmJ1ZjsKCiAg ICBpZiAoKHdyaXRlciA9PSBOVUxMKSB8fCAobmFtZSA9PSBOVUxMKSB8fCAoKm5hbWUgPT0gJ1ww JykpCiAgICAgICAgcmV0dXJuIC0xOwoKICAgIGJ1ZiA9IDA7CiAgICBpZiAocHJlZml4ICE9IDAp IHsKICAgICAgICBidWYgPSB4bWxTdHJkdXAocHJlZml4KTsKICAgICAgICBidWYgPSB4bWxTdHJj YXQoYnVmLCAiOiIpOwogICAgfQogICAgYnVmID0geG1sU3RyY2F0KGJ1ZiwgbmFtZSk7CgogICAg c3VtID0gMDsKICAgIGNvdW50ID0geG1sVGV4dFdyaXRlcldyaXRlUHJvcCh3cml0ZXIsIGJ1Ziwg dmFsdWUpOwogICAgeG1sRnJlZShidWYpOwogICAgaWYgKGNvdW50IDwgMCkKICAgICAgICByZXR1 cm4gLTE7CiAgICBzdW0gKz0gY291bnQ7CgogICAgcmV0dXJuIHN1bTsKfQoKLyoqCiAqIHhtbFRl eHRXcml0ZXJXcml0ZUZvcm1hdEVsZW1lbnQ6CiAqIEB3cml0ZXI6ICB0aGUgeG1sVGV4dFdyaXRl clB0cgogKiBAbmFtZTogIGF0dHJpYnV0ZSBuYW1lCiAqIEBmb3JtYXQ6ICBmb3JtYXQgc3RyaW5n IChzZWUgcHJpbnRmKQogKgogKiBXcml0ZSBhIGZvcm1hdHRlZCB4bWwgZWxlbWVudC4KICoKICog UmV0dXJucyB0aGUgYnl0ZXMgd3JpdHRlbiAobWF5IGJlIDAgYmVjYXVzZSBvZiBidWZmZXJpbmcp IG9yIC0xIGluIGNhc2Ugb2YgZXJyb3IKICovCmludAp4bWxUZXh0V3JpdGVyV3JpdGVGb3JtYXRF bGVtZW50KHhtbFRleHRXcml0ZXJQdHIgd3JpdGVyLAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGNvbnN0IHhtbENoYXIgKiBuYW1lLCBjb25zdCBjaGFyICpmb3JtYXQsCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgLi4uKQp7CiAgICBpbnQgcmM7CiAgICB2YV9saXN0IGFw OwoKICAgIHZhX3N0YXJ0KGFwLCBmb3JtYXQpOwoKICAgIHJjID0geG1sVGV4dFdyaXRlcldyaXRl VkZvcm1hdEVsZW1lbnQod3JpdGVyLCBuYW1lLCBmb3JtYXQsIGFwKTsKCiAgICB2YV9lbmQoYXAp OwogICAgcmV0dXJuIHJjOwp9CgovKioKICogeG1sVGV4dFdyaXRlcldyaXRlVkZvcm1hdEVsZW1l bnQ6CiAqIEB3cml0ZXI6ICB0aGUgeG1sVGV4dFdyaXRlclB0cgogKiBAbmFtZTogIGF0dHJpYnV0 ZSBuYW1lCiAqIEBmb3JtYXQ6ICBmb3JtYXQgc3RyaW5nIChzZWUgcHJpbnRmKQogKiBAYXJncHRy OiAgcG9pbnRlciB0byB0aGUgZmlyc3QgbWVtYmVyIG9mIHRoZSB2YXJpYWJsZSBhcmd1bWVudCBs aXN0LgogKgogKiBXcml0ZSBhIGZvcm1hdHRlZCB4bWwgZWxlbWVudC4KICoKICogUmV0dXJucyB0 aGUgYnl0ZXMgd3JpdHRlbiAobWF5IGJlIDAgYmVjYXVzZSBvZiBidWZmZXJpbmcpIG9yIC0xIGlu IGNhc2Ugb2YgZXJyb3IKICovCmludAp4bWxUZXh0V3JpdGVyV3JpdGVWRm9ybWF0RWxlbWVudCh4 bWxUZXh0V3JpdGVyUHRyIHdyaXRlciwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Y29uc3QgeG1sQ2hhciAqIG5hbWUsIGNvbnN0IGNoYXIgKmZvcm1hdCwKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgdmFfbGlzdCBhcmdwdHIpCnsKICAgIGludCByYzsKICAgIHhtbENo YXIgKmJ1ZjsKCiAgICBpZiAod3JpdGVyID09IE5VTEwpCiAgICAgICAgcmV0dXJuIC0xOwoKICAg IGJ1ZiA9IHhtbFRleHRXcml0ZXJWU3ByaW50Zihmb3JtYXQsIGFyZ3B0cik7CiAgICBpZiAoYnVm ID09IDApCiAgICAgICAgcmV0dXJuIDA7CgogICAgcmMgPSB4bWxUZXh0V3JpdGVyV3JpdGVFbGVt ZW50KHdyaXRlciwgbmFtZSwgYnVmKTsKCiAgICB4bWxGcmVlKGJ1Zik7CiAgICByZXR1cm4gcmM7 Cn0KCi8qKgogKiB4bWxUZXh0V3JpdGVyV3JpdGVFbGVtZW50OgogKiBAd3JpdGVyOiAgdGhlIHht bFRleHRXcml0ZXJQdHIKICogQG5hbWU6ICBhdHRyaWJ1dGUgbmFtZQogKiBAdmFsdWU6ICBhdHRy aWJ1dGUgdmFsdWUKICoKICogV3JpdGUgYW4geG1sIGVsZW1lbnQuCiAqCiAqIFJldHVybnMgdGhl IGJ5dGVzIHdyaXR0ZW4gKG1heSBiZSAwIGJlY2F1c2Ugb2YgYnVmZmVyaW5nKSBvciAtMSBpbiBj YXNlIG9mIGVycm9yCiAqLwppbnQKeG1sVGV4dFdyaXRlcldyaXRlRWxlbWVudCh4bWxUZXh0V3Jp dGVyUHRyIHdyaXRlciwgY29uc3QgeG1sQ2hhciAqIG5hbWUsCiAgICAgICAgICAgICAgICAgICAg ICAgICAgY29uc3QgeG1sQ2hhciAqIHZhbHVlKQp7CiAgICBpbnQgY291bnQ7CiAgICBpbnQgc3Vt OwoKICAgIHN1bSA9IDA7CiAgICBjb3VudCA9IHhtbFRleHRXcml0ZXJTdGFydEVsZW1lbnQod3Jp dGVyLCBuYW1lKTsKICAgIGlmIChjb3VudCA9PSAtMSkKICAgICAgICByZXR1cm4gLTE7CiAgICBz dW0gKz0gY291bnQ7CiAgICBjb3VudCA9IHhtbFRleHRXcml0ZXJXcml0ZVN0cmluZyh3cml0ZXIs IHZhbHVlKTsKICAgIGlmIChjb3VudCA9PSAtMSkKICAgICAgICByZXR1cm4gLTE7CiAgICBzdW0g Kz0gY291bnQ7CiAgICBjb3VudCA9IHhtbFRleHRXcml0ZXJFbmRFbGVtZW50KHdyaXRlcik7CiAg ICBpZiAoY291bnQgPT0gLTEpCiAgICAgICAgcmV0dXJuIC0xOwogICAgc3VtICs9IGNvdW50OwoK ICAgIHJldHVybiBzdW07Cn0KCi8qKgogKiB4bWxUZXh0V3JpdGVyV3JpdGVGb3JtYXRFbGVtZW50 TlM6CiAqIEB3cml0ZXI6ICB0aGUgeG1sVGV4dFdyaXRlclB0cgogKiBAcHJlZml4OiAgbmFtZXNw YWNlIHByZWZpeAogKiBAbmFtZTogIGF0dHJpYnV0ZSBuYW1lCiAqIEBuYW1lc3BhY2VVUkk6ICBu YW1lc3BhY2UgVVJJCiAqIEBmb3JtYXQ6ICBmb3JtYXQgc3RyaW5nIChzZWUgcHJpbnRmKQogKgog KiBXcml0ZSBhIGZvcm1hdHRlZCB4bWwgZWxlbWVudCB3aXRoIG5hbWVzcGFjZSBzdXBwb3J0Lgog KgogKiBSZXR1cm5zIHRoZSBieXRlcyB3cml0dGVuIChtYXkgYmUgMCBiZWNhdXNlIG9mIGJ1ZmZl cmluZykgb3IgLTEgaW4gY2FzZSBvZiBlcnJvcgogKi8KaW50CnhtbFRleHRXcml0ZXJXcml0ZUZv cm1hdEVsZW1lbnROUyh4bWxUZXh0V3JpdGVyUHRyIHdyaXRlciwKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGNvbnN0IHhtbENoYXIgKiBwcmVmaXgsCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICogbmFtZSwKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGNvbnN0IHhtbENoYXIgKiBuYW1lc3BhY2VVUkksCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBjb25zdCBjaGFyICpmb3JtYXQsIC4uLikKewogICAgaW50 IHJjOwogICAgdmFfbGlzdCBhcDsKCiAgICB2YV9zdGFydChhcCwgZm9ybWF0KTsKCiAgICByYyA9 IHhtbFRleHRXcml0ZXJXcml0ZVZGb3JtYXRFbGVtZW50TlMod3JpdGVyLCBwcmVmaXgsIG5hbWUs CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbmFtZXNwYWNlVVJJ LCBmb3JtYXQsIGFwKTsKCiAgICB2YV9lbmQoYXApOwogICAgcmV0dXJuIHJjOwp9CgovKioKICog eG1sVGV4dFdyaXRlcldyaXRlVkZvcm1hdEVsZW1lbnROUzoKICogQHdyaXRlcjogIHRoZSB4bWxU ZXh0V3JpdGVyUHRyCiAqIEBwcmVmaXg6ICBuYW1lc3BhY2UgcHJlZml4CiAqIEBuYW1lOiAgYXR0 cmlidXRlIG5hbWUKICogQG5hbWVzcGFjZVVSSTogIG5hbWVzcGFjZSBVUkkKICogQGZvcm1hdDog IGZvcm1hdCBzdHJpbmcgKHNlZSBwcmludGYpCiAqIEBhcmdwdHI6ICBwb2ludGVyIHRvIHRoZSBm aXJzdCBtZW1iZXIgb2YgdGhlIHZhcmlhYmxlIGFyZ3VtZW50IGxpc3QuCiAqCiAqIFdyaXRlIGEg Zm9ybWF0dGVkIHhtbCBlbGVtZW50IHdpdGggbmFtZXNwYWNlIHN1cHBvcnQuCiAqCiAqIFJldHVy bnMgdGhlIGJ5dGVzIHdyaXR0ZW4gKG1heSBiZSAwIGJlY2F1c2Ugb2YgYnVmZmVyaW5nKSBvciAt MSBpbiBjYXNlIG9mIGVycm9yCiAqLwppbnQKeG1sVGV4dFdyaXRlcldyaXRlVkZvcm1hdEVsZW1l bnROUyh4bWxUZXh0V3JpdGVyUHRyIHdyaXRlciwKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBjb25zdCB4bWxDaGFyICogcHJlZml4LAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGNvbnN0IHhtbENoYXIgKiBuYW1lLAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGNvbnN0IHhtbENoYXIgKiBuYW1lc3BhY2VVUkksCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgY29uc3QgY2hhciAqZm9ybWF0LCB2YV9saXN0IGFyZ3B0cikKewog ICAgaW50IHJjOwogICAgeG1sQ2hhciAqYnVmOwoKICAgIGlmICh3cml0ZXIgPT0gTlVMTCkKICAg ICAgICByZXR1cm4gLTE7CgogICAgYnVmID0geG1sVGV4dFdyaXRlclZTcHJpbnRmKGZvcm1hdCwg YXJncHRyKTsKICAgIGlmIChidWYgPT0gMCkKICAgICAgICByZXR1cm4gMDsKCiAgICByYyA9IHht bFRleHRXcml0ZXJXcml0ZUVsZW1lbnROUyh3cml0ZXIsIHByZWZpeCwgbmFtZSwgbmFtZXNwYWNl VVJJLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYnVmKTsKCiAgICB4bWxG cmVlKGJ1Zik7CiAgICByZXR1cm4gcmM7Cn0KCi8qKgogKiB4bWxUZXh0V3JpdGVyV3JpdGVFbGVt ZW50TlM6CiAqIEB3cml0ZXI6ICB0aGUgeG1sVGV4dFdyaXRlclB0cgogKiBAcHJlZml4OiAgbmFt ZXNwYWNlIHByZWZpeAogKiBAbmFtZTogIGF0dHJpYnV0ZSBuYW1lCiAqIEBuYW1lc3BhY2VVUkk6 ICBuYW1lc3BhY2UgVVJJCiAqIEB2YWx1ZTogIGF0dHJpYnV0ZSB2YWx1ZQogKgogKiBXcml0ZSBh biB4bWwgZWxlbWVudCB3aXRoIG5hbWVzcGFjZSBzdXBwb3J0LgogKgogKiBSZXR1cm5zIHRoZSBi eXRlcyB3cml0dGVuIChtYXkgYmUgMCBiZWNhdXNlIG9mIGJ1ZmZlcmluZykgb3IgLTEgaW4gY2Fz ZSBvZiBlcnJvcgogKi8KaW50CnhtbFRleHRXcml0ZXJXcml0ZUVsZW1lbnROUyh4bWxUZXh0V3Jp dGVyUHRyIHdyaXRlciwKICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHhtbENoYXIg KiBwcmVmaXgsIGNvbnN0IHhtbENoYXIgKiBuYW1lLAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgY29uc3QgeG1sQ2hhciAqIG5hbWVzcGFjZVVSSSwKICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGNvbnN0IHhtbENoYXIgKiB2YWx1ZSkKewogICAgaW50IGNvdW50OwogICAgaW50IHN1bTsK CiAgICBpZiAoKHdyaXRlciA9PSBOVUxMKSB8fCAobmFtZSA9PSBOVUxMKSB8fCAoKm5hbWUgPT0g J1wwJykpCiAgICAgICAgcmV0dXJuIC0xOwoKICAgIHN1bSA9IDA7CiAgICBjb3VudCA9CiAgICAg ICAgeG1sVGV4dFdyaXRlclN0YXJ0RWxlbWVudE5TKHdyaXRlciwgcHJlZml4LCBuYW1lLCBuYW1l c3BhY2VVUkkpOwogICAgaWYgKGNvdW50IDwgMCkKICAgICAgICByZXR1cm4gLTE7CiAgICBzdW0g Kz0gY291bnQ7CiAgICBjb3VudCA9IHhtbFRleHRXcml0ZXJXcml0ZVN0cmluZyh3cml0ZXIsIHZh bHVlKTsKICAgIGlmIChjb3VudCA9PSAtMSkKICAgICAgICByZXR1cm4gLTE7CiAgICBzdW0gKz0g Y291bnQ7CiAgICBjb3VudCA9IHhtbFRleHRXcml0ZXJFbmRFbGVtZW50KHdyaXRlcik7CiAgICBp ZiAoY291bnQgPT0gLTEpCiAgICAgICAgcmV0dXJuIC0xOwogICAgc3VtICs9IGNvdW50OwoKICAg IHJldHVybiBzdW07Cn0KCi8qKgogKiB4bWxUZXh0V3JpdGVyRmx1c2g6CiAqIEB3cml0ZXI6ICB0 aGUgeG1sVGV4dFdyaXRlclB0cgogKgogKiBGbHVzaCB0aGUgb3V0cHV0IGJ1ZmZlci4KICoKICog UmV0dXJucyB0aGUgYnl0ZXMgd3JpdHRlbiAobWF5IGJlIDAgYmVjYXVzZSBvZiBidWZmZXJpbmcp IG9yIC0xIGluIGNhc2Ugb2YgZXJyb3IKICovCmludAp4bWxUZXh0V3JpdGVyRmx1c2goeG1sVGV4 dFdyaXRlclB0ciB3cml0ZXIpCnsKICAgIGlmICh3cml0ZXIgPT0gTlVMTCkKICAgICAgICByZXR1 cm4gLTE7CgogICAgcmV0dXJuIHhtbE91dHB1dEJ1ZmZlckZsdXNoKHdyaXRlci0+b3V0KTsKfQoK Ci8qCiAqIG1pc2MKICovCgovKioKICogeG1sRnJlZVRleHRXcml0ZXJTdGFja0VudHJ5OgogKiBA bGs6ICB0aGUgeG1sTGlua1B0cgogKgogKiBGcmVlIGNhbGxiYWNrIGZvciB0aGUgeG1sTGlzdC4K ICovCnN0YXRpYyB2b2lkCnhtbEZyZWVUZXh0V3JpdGVyU3RhY2tFbnRyeSh4bWxMaW5rUHRyIGxr KQp7CiAgICB4bWxUZXh0V3JpdGVyU3RhY2tFbnRyeSAqcDsKCiAgICBwID0gKHhtbFRleHRXcml0 ZXJTdGFja0VudHJ5ICopIHhtbExpbmtHZXREYXRhKGxrKTsKICAgIGlmIChwID09IDApCiAgICAg ICAgcmV0dXJuOwoKICAgIGlmIChwLT5uYW1lICE9IDApCiAgICAgICAgeG1sRnJlZShwLT5uYW1l KTsKICAgIHhtbEZyZWUocCk7Cn0KCi8qKgogKiB4bWxDbXBUZXh0V3JpdGVyU3RhY2tFbnRyeToK ICogQGRhdGEwOiAgdGhlIGZpcnN0IGRhdGEKICogQGRhdGExOiAgdGhlIHNlY29uZCBkYXRhCiAq CiAqIENvbXBhcmUgY2FsbGJhY2sgZm9yIHRoZSB4bWxMaXN0LgogKgogKiBSZXR1cm5zIC0xLCAw LCAxCiAqLwpzdGF0aWMgaW50CnhtbENtcFRleHRXcml0ZXJTdGFja0VudHJ5KGNvbnN0IHZvaWQg KmRhdGEwLCBjb25zdCB2b2lkICpkYXRhMSkKewogICAgeG1sVGV4dFdyaXRlclN0YWNrRW50cnkg KnAwOwogICAgeG1sVGV4dFdyaXRlclN0YWNrRW50cnkgKnAxOwoKICAgIGlmIChkYXRhMCA9PSBk YXRhMSkKICAgICAgICByZXR1cm4gMDsKCiAgICBpZiAoZGF0YTAgPT0gMCkKICAgICAgICByZXR1 cm4gMTsKCiAgICBpZiAoZGF0YTEgPT0gMCkKICAgICAgICByZXR1cm4gLTE7CgogICAgcDAgPSAo eG1sVGV4dFdyaXRlclN0YWNrRW50cnkgKikgZGF0YTA7CiAgICBwMSA9ICh4bWxUZXh0V3JpdGVy U3RhY2tFbnRyeSAqKSBkYXRhMTsKCiAgICByZXR1cm4geG1sU3RyY21wKHAwLT5uYW1lLCBwMS0+ bmFtZSk7Cn0KCi8qKgogKiB4bWxUZXh0V3JpdGVyV3JpdGVNZW1DYWxsYmFjazoKICogQGNvbnRl eHQ6ICB0aGUgeG1sQnVmZmVyUHRyCiAqIEBzdHI6ICB0aGUgZGF0YSB0byB3cml0ZQogKiBAbGVu OiAgdGhlIGxlbmd0aCBvZiB0aGUgZGF0YQogKgogKiBXcml0ZSBjYWxsYmFjayBmb3IgdGhlIHht bE91dHB1dEJ1ZmZlciB3aXRoIHRhcmdldCB4bWxCdWZmZXIKICoKICogUmV0dXJucyAtMSwgMCwg MQogKi8Kc3RhdGljIGludAp4bWxUZXh0V3JpdGVyV3JpdGVNZW1DYWxsYmFjayh2b2lkICpjb250 ZXh0LCBjb25zdCB4bWxDaGFyICogc3RyLCBpbnQgbGVuKQp7CiAgICB4bWxCdWZmZXJQdHIgYnVm ID0gKHhtbEJ1ZmZlclB0cikgY29udGV4dDsKCiAgICB4bWxCdWZmZXJBZGQoYnVmLCBzdHIsIGxl bik7CgogICAgcmV0dXJuIGxlbjsKfQoKLyoqCiAqIHhtbFRleHRXcml0ZXJDbG9zZU1lbUNhbGxi YWNrOgogKiBAY29udGV4dDogIHRoZSB4bWxCdWZmZXJQdHIKICoKICogQ2xvc2UgY2FsbGJhY2sg Zm9yIHRoZSB4bWxPdXRwdXRCdWZmZXIgd2l0aCB0YXJnZXQgeG1sQnVmZmVyCiAqCiAqIFJldHVy bnMgLTEsIDAsIDEKICovCnN0YXRpYyBpbnQKeG1sVGV4dFdyaXRlckNsb3NlTWVtQ2FsbGJhY2so dm9pZCAqY29udGV4dCkKewogICAgcmV0dXJuIDA7Cn0KCi8qKgogKiB4bWxUZXh0V3JpdGVyVlNw cmludGY6CiAqIEBmb3JtYXQ6ICBzZWUgcHJpbnRmCiAqIEBhcmdwdHI6ICBwb2ludGVyIHRvIHRo ZSBmaXJzdCBtZW1iZXIgb2YgdGhlIHZhcmlhYmxlIGFyZ3VtZW50IGxpc3QuCiAqCiAqIFV0aWxp dHkgZnVuY3Rpb24gZm9yIGZvcm1hdHRlZCBvdXRwdXQKICoKICogUmV0dXJucyBhIG5ldyB4bWxD aGFyIGJ1ZmZlciB3aXRoIHRoZSBkYXRhIG9yIE5VTEwgb24gZXJyb3IuIFRoaXMgYnVmZmVyIG11 c3QgYmUgZnJlZWQuCiAqLwpzdGF0aWMgeG1sQ2hhciAqCnhtbFRleHRXcml0ZXJWU3ByaW50Zihj b25zdCBjaGFyICpmb3JtYXQsIHZhX2xpc3QgYXJncHRyKQp7CiAgICBpbnQgc2l6ZTsKICAgIHht bENoYXIgKmJ1ZjsKCiAgICBzaXplID0gQlVGU0laOwogICAgYnVmID0gKHhtbENoYXIgKikgeG1s TWFsbG9jKHNpemUpOwogICAgaWYgKGJ1ZiA9PSBOVUxMKSB7CiAgICAgICAgeG1sR2VuZXJpY0Vy cm9yKHhtbEdlbmVyaWNFcnJvckNvbnRleHQsCiAgICAgICAgICAgICAgICAgICAgICAgICJ4bWxU ZXh0V3JpdGVyVlNwcmludGYgOiBvdXQgb2YgbWVtb3J5IVxuIik7CiAgICAgICAgcmV0dXJuIE5V TEw7CiAgICB9CgogICAgd2hpbGUgKHZzbnByaW50ZigoY2hhciAqKSBidWYsIHNpemUsIGZvcm1h dCwgYXJncHRyKSA9PSAtMSkgewogICAgICAgIHhtbEZyZWUoYnVmKTsKICAgICAgICBzaXplICs9 IEJVRlNJWjsKICAgICAgICBidWYgPSAoeG1sQ2hhciAqKSB4bWxNYWxsb2Moc2l6ZSk7CiAgICAg ICAgaWYgKGJ1ZiA9PSBOVUxMKSB7CiAgICAgICAgICAgIHhtbEdlbmVyaWNFcnJvcih4bWxHZW5l cmljRXJyb3JDb250ZXh0LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgInhtbFRleHRXcml0 ZXJWU3ByaW50ZiA6IG91dCBvZiBtZW1vcnkhXG4iKTsKICAgICAgICAgICAgcmV0dXJuIE5VTEw7 CiAgICAgICAgfQogICAgfQoKICAgIHJldHVybiBidWY7Cn0K ------=_NextPart_000_28BCC_01C38C26.2AF3EA20-- From patrick@gundla.ch Mon Oct 6 11:37:50 2003 Return-Path: Delivered-To: xml@gnome.org Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mail.gnome.org (Postfix) with ESMTP id E9A08180EA for ; Mon, 6 Oct 2003 11:37:49 -0400 (EDT) Received: from [212.227.126.161] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1A6XQx-0001O7-00 for xml@gnome.org; Mon, 06 Oct 2003 17:38:03 +0200 Received: from [62.72.92.65] (helo=levana) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1A6XQw-0005YY-00 for xml@gnome.org; Mon, 06 Oct 2003 17:38:03 +0200 Received: from [192.168.1.2] (helo=schnee.local) by levana with esmtp (Exim 3.35 #1 (Debian)) id 1A6XLs-0000z4-00 for ; Mon, 06 Oct 2003 17:32:48 +0200 Received: from schnee.local (localhost [127.0.0.1]) by schnee.local (8.12.9/8.12.9) with ESMTP id h96FWw0v001228 for ; Mon, 6 Oct 2003 17:32:58 +0200 (CEST) Received: (from pg@localhost) by schnee.local (8.12.9/8.12.2/Submit) id h96FWwUo001227; Mon, 6 Oct 2003 17:32:58 +0200 (CEST) X-Authentication-Warning: schnee.local: pg set sender to patrick@gundla.ch using -f To: xml@gnome.org Organization: privat X-Lieblings-Musik: the_capricorns In-Reply-To: <16257.33094.407660.736647@morus.xipolis.net> (Morus Walter's message of "Mon, 6 Oct 2003 16:50:46 +0200") References: <16257.3147.898535.304560@morus.xipolis.net> <20031006081149.A30095@redhat.com> <16257.33094.407660.736647@morus.xipolis.net> From: Patrick Gundlach Date: Mon, 06 Oct 2003 17:32:58 +0200 Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [xml] Re: namespace xmllint error (libxml 2.5.11) Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Morus Walter writes: Hi, >> I did some tests, and I am confused. Sorry for my ignorance. Could >> anybody point out what I am doing wrong? > you don't declare the name attribute for the interface element. I should take a lesson "carefully read what is written on the screen." Thanks. > trang translates between compact and xml syntax and I prefer the > compact syntax, which is easier to read. I'll try trang. Sorry for the noise and thank you for the help. I'll be more careful next time. Patrick -- You are your own rainbow! From j.cranendonk@emaxx.nl Mon Oct 6 12:48:07 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail.emaxx.nl (mail.emaxx.nl [217.119.230.65]) by mail.gnome.org (Postfix) with ESMTP id EB093180EA for ; Mon, 6 Oct 2003 12:48:06 -0400 (EDT) Received: from dolphin.student.utwente.nl ([130.89.165.151] helo=dolphin2) by mail.emaxx.nl with smtp (Exim 3.22 #1) id 1A6YWw-0003Kx-00; Mon, 06 Oct 2003 18:48:18 +0200 Message-ID: <001801c38c2a$9f5a0da0$0200a8c0@student.utwente.nl> From: "Jeroen Cranendonk" To: "Mickautsch, Alfred" , References: <4F38C8B9DAB1014DBDCB29538BBFD6A1285084@pandora.schuler-ag.com> Subject: Re: [xml] xmlTextWriter Date: Mon, 6 Oct 2003 18:55:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Cool! ^-^ but slightly double work perhaps ? :) I made another start on a similar xml writer interface, I've mentioned it before on the mailinglist :) Currently it's slightly stalled because I'm waiting for the patches of another mailinglist member, but it prolly does partly the same as yours :) Thoug I haven't looked at your code yet , still glad to see someone else works on the idea too :) You can find my implementation for as far as it is at : http://dolphin.student.utwente.nl/xmlwriter/ Greetings, Jeroen Cranendonk >Well, this weekend I started to write the xmlTextWriter interface :-). >It lacks the possibility to write DTD's, but I have to learn about DTD's first, >because I do not know how such a thing looks like (didn't need that). >So you xml gurus out there: please look at the code and tell me what I >did wrong, or what could be improved/added. >(I hope the style is ok now). Servus -- Alfred From eday@obj-sys.com Mon Oct 6 14:52:52 2003 Return-Path: Delivered-To: xml@gnome.org Received: from malone.intellispace.net (malone.intellispace.net [160.79.145.141]) by mail.gnome.org (Postfix) with ESMTP id 5D73F18171 for ; Mon, 6 Oct 2003 14:52:52 -0400 (EDT) Received: from objsys1 (66.9.62.72) by malone.intellispace.net (5.1.053) id 3F7301BA001E7EDB for xml@gnome.org; Mon, 6 Oct 2003 14:52:42 -0400 Message-ID: <016101c38c3b$ef554d90$483e0942@objsys1> From: "Ed Day" To: References: <062701c389c7$23ceabb0$483e0942@objsys1> <20031003115809.P21001@redhat.com> Subject: Re: [xml] Differences in DOM parsing on Windows and UNIX? Date: Mon, 6 Oct 2003 14:59:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: In investigating this further, I found we built the Windows version without thread support and the UNIX version with thread support. I also found we were intentionally trying to turn blank text nodes off by making a call to "xmlKeepBlanksDefault(0)" to make the DOM tree easier to work with. Apparently this does not work in multi-threaded mode. There appears to be another call - "xmlThrDefKeepBlanksDefault" - that must be used in this case. But, this seems to be compiled out if threads are not enabled. We therefore ended up with the following initialization logic in our main code: #ifdef LIBXML_THREAD_ENABLED xmlThrDefKeepBlanksDefaultValue(0); #else xmlKeepBlanksDefault(0); #endif Kind of messy. It would seem this could be kept under the covers somewhere (or perhaps it is and we missed it). Regards, Ed Day ----- Original Message ----- From: "Daniel Veillard" To: "Ed Day" Cc: Sent: Friday, October 03, 2003 11:58 AM Subject: Re: [xml] Differences in DOM parsing on Windows and UNIX? > On Fri, Oct 03, 2003 at 11:58:08AM -0400, Ed Day wrote: > > Extra text nodes are inserted for whitespace. Is this a configuration issue? If not, which version is correct? > > > > I used the standard out-of-the-box build procedure in both cases and built from source code instead of using the pre-compiled binaries. Has anyone else observed this behavior? It would be good to know before I start digging into the code. > > Hum, sounds like xmlKeepBlanksDefaultValue is wrongly initialized to 0 > on your Windows build while it should be 1 as properly compiled on Unix. > /** > * xmlKeepBlanksDefaultValue: > * > * Global setting, indicate that the parser should keep all blanks > * nodes found in the content > * Activated by default, this is actually needed to have the parser > * conformant to the XML Recommendation, however the option is kept > * for some applications since this was libxml1 default behaviour. > */ > int xmlKeepBlanksDefaultValue = 1; > > see if your compiler miscompiled globals.c on Windows. > > Daniel > > -- > Daniel Veillard | Red Hat Network https://rhn.redhat.com/ > veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ > http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ > _______________________________________________ > xml mailing list, project page http://xmlsoft.org/ > xml@gnome.org > http://mail.gnome.org/mailman/listinfo/xml > From graham-libxml@simulcra.org Mon Oct 6 15:29:49 2003 Return-Path: Delivered-To: xml@gnome.org Received: from lamity.org (lamity.org [212.13.197.69]) by mail.gnome.org (Postfix) with SMTP id 55298180EA for ; Mon, 6 Oct 2003 15:29:47 -0400 (EDT) Received: (qmail 16294 invoked by uid 1001); 6 Oct 2003 19:29:58 -0000 Date: Mon, 6 Oct 2003 20:29:58 +0100 From: Graham Bennett To: xml@gnome.org Message-ID: <20031006192958.GC15331@lamity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Subject: [xml] patch for warning on solaris Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi all, I noticed a compilation warning coming from encoding.c, which happens because the native (not GNU) iconv on solaris (sensibly) takes a const char ** rather than a char ** as input. Here's a patch, but it's not complete as you'd need to check that solaris iconv is being used, not just that the platform is solaris. --- old/encoding.c Fri Aug 15 09:32:58 2003 +++ new/encoding.c Mon Oct 6 11:27:03 2003 @@ -2014,5 +2014,9 @@ int ret; +#if (defined(sun) || defined(__sun__)) && (defined __svr4__ || defined(__SVR4)) + ret = iconv(cd, &icv_in, &icv_inlen, &icv_out, &icv_outlen); +#else ret = iconv(cd, (char **) &icv_in, &icv_inlen, &icv_out, &icv_outlen); +#endif if (in != NULL) { *inlen -= icv_inlen; PS - does anyone know why GNU iconv has the input as a pointer to pointer to non-const char? cheers, Graham. -- Graham Bennett From stephane.bidoul@softwareag.com Mon Oct 6 17:48:18 2003 Return-Path: Delivered-To: xml@gnome.org Received: from server8a.software-ag.de (server8a.software-ag.de [193.26.193.47]) by mail.gnome.org (Postfix) with ESMTP id CAEA518339 for ; Mon, 6 Oct 2003 17:48:17 -0400 (EDT) Received: from acsesbi by server8a.software-ag.de; (8.11.6/8.9.3) id h96LmGX08107; Mon, 6 Oct 2003 23:48:16 +0200 From: "Stéphane Bidoul" To: Cc: Subject: RE: [xml] windows configure patch Date: Mon, 6 Oct 2003 23:47:04 +0200 Message-ID: <005101c38c53$914183f0$1467140a@acsesbi> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <20031006045404.A21001@redhat.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: > I'm tempted to add a new global "structured" error handler which > would be used in preference to xmlGenericError() if defined. Something > like an > xmlStructuredError(void *user_data, xmlErrorPtr error); > and add a parser context field to the xmlError structure. Then > use that for the Python bindings to allow to build decent handling. Can you elaborate on this context field in xmlError? You would use that context field instead of per parser context callbacks? -sbi From stephane.bidoul@softwareag.com Mon Oct 6 17:48:29 2003 Return-Path: Delivered-To: xml@gnome.org Received: from server8a.software-ag.de (server8a.software-ag.de [193.26.193.47]) by mail.gnome.org (Postfix) with ESMTP id 0C4C418339 for ; Mon, 6 Oct 2003 17:48:29 -0400 (EDT) Received: from acsesbi by server8a.software-ag.de; (8.11.6/8.9.3) id h96LmWX08218; Mon, 6 Oct 2003 23:48:38 +0200 From: "Stéphane Bidoul" To: "'Ed Day'" Cc: Subject: RE: [xml] Differences in DOM parsing on Windows and UNIX? Date: Mon, 6 Oct 2003 23:48:22 +0200 Message-ID: <005301c38c53$9ac9da80$1467140a@acsesbi> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <016101c38c3b$ef554d90$483e0942@objsys1> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: > In investigating this further, I found we built the Windows > version without > thread support and the UNIX version with thread support. I > also found we > were intentionally trying to turn blank text nodes off by > making a call to > "xmlKeepBlanksDefault(0)" to make the DOM tree easier to work with. > Apparently this does not work in multi-threaded mode. There > appears to be > another call - "xmlThrDefKeepBlanksDefault" - that must be > used in this > case. But, this seems to be compiled out if threads are not > enabled. We > therefore ended up with the following initialization logic in > our main code: > > #ifdef LIBXML_THREAD_ENABLED > xmlThrDefKeepBlanksDefaultValue(0); > #else > xmlKeepBlanksDefault(0); > #endif > > Kind of messy. It would seem this could be kept under the > covers somewhere > (or perhaps it is and we missed it). Globals are per threads when libxml2 is compiled --with-threads. xmlThrDefKeepBlanksDefaultValue sets the value for new threads that will be created later. xmlKeepBlanksDefault sets the value for the current thread only. Assuming you are doing that at program initialization, you should do #ifdef LIBXML_THREAD_ENABLED xmlKeepBlanksDefault(0); /* for the "main" thread */ xmlThrDefKeepBlanksDefaultValue(0); /* for other threads yet to be created */ #else xmlKeepBlanksDefault(0); #endif You can also avoid global defaults in most cases. I think you can set keepBlanks on the parser context. -sbi From veillard@redhat.com Mon Oct 6 19:47:21 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id EF017180E4 for ; Mon, 6 Oct 2003 19:47:20 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h96NlW600678; Mon, 6 Oct 2003 19:47:32 -0400 Date: Mon, 6 Oct 2003 19:47:32 -0400 From: Daniel Veillard To: =?iso-8859-1?Q?St=E9phane_Bidoul?= Cc: xml@gnome.org Subject: Re: [xml] windows configure patch Message-ID: <20031006194732.A31459@redhat.com> Reply-To: veillard@redhat.com References: <20031006045404.A21001@redhat.com> <005101c38c53$914183f0$1467140a@acsesbi> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <005101c38c53$914183f0$1467140a@acsesbi>; from stephane.bidoul@softwareag.com on Mon, Oct 06, 2003 at 11:47:04PM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Mon, Oct 06, 2003 at 11:47:04PM +0200, Stéphane Bidoul wrote: > > > I'm tempted to add a new global "structured" error handler which > > would be used in preference to xmlGenericError() if defined. Something > > like an > > xmlStructuredError(void *user_data, xmlErrorPtr error); > > and add a parser context field to the xmlError structure. Then > > use that for the Python bindings to allow to build decent handling. > > Can you elaborate on this context field in xmlError? > You would use that context field instead of per parser context callbacks? Not really, but suppose you register only a global error callback and not one per parser, this allows to look at the parser context anyway. If you use xmlReadFile(), you get an error, you didn't se a specific parser error handler, all you have is a callback on the global error handler, with the error information. Having the context infoamtion if available allows to check thing like the parsing state, even though you never saw that parser context before. it's redundant information if you have per parser callbacks. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From alfred.mickautsch@schuler-ag.com Tue Oct 7 06:27:39 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail-relay1 (mail-relay1.schuler-ag.com [62.156.183.20]) by mail.gnome.org (Postfix) with ESMTP id DE1C6188BC for ; Tue, 7 Oct 2003 06:27:38 -0400 (EDT) Received: from sbs-proxy-test.schuler-ag.com ([192.168.16.254]) by mail-relay1 with Microsoft SMTPSVC(6.0.3790.0); Tue, 7 Oct 2003 12:31:55 +0200 Received: from mail pickup service by sbs-proxy-test.schuler-ag.com with Microsoft SMTPSVC; Tue, 7 Oct 2003 12:27:51 +0200 x-gfisavedcharset: iso-8859-1 Content-Type: text/plain; charset="iso-8859-1" Received: from pandora.schuler-ag.com ([192.168.16.20]) by sbs-proxy-test.schuler-ag.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 7 Oct 2003 12:27:50 +0200 Content-Class: urn:content-classes:message Subject: AW: [xml] xmlTextWriter MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Oct 2003 12:27:50 +0200 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Message-ID: <4F38C8B9DAB1014DBDCB29538BBFD6A12E4E7A@pandora.schuler-ag.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [xml] xmlTextWriter thread-index: AcOMKaaQrzs+L5IeQca7wok2ywNHlwAhfdkw From: "Mickautsch, Alfred" To: X-OriginalArrivalTime: 07 Oct 2003 10:27:50.0661 (UTC) FILETIME=[A8E23350:01C38CBD] Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: > -----Urspr=FCngliche Nachricht----- > Von: Jeroen Cranendonk [mailto:j.cranendonk@emaxx.nl] > Gesendet: Montag, 6. Oktober 2003 18:55 > An: Mickautsch, Alfred; xml@gnome.org > Betreff: Re: [xml] xmlTextWriter >=20 >=20 > Cool! ^-^ >=20 > but slightly double work perhaps ? :) Amazing! After looking at your code and if I didn't know it better :) = I'd say I copied at least some parts from your code :-).=20 I even found a bug that we share in our code (I think it's a bug): the = xmlTextWriter allows for multiple xml prologs in the same document (you = can call xmlTextWriterWriteStartDocument after calling = xmlTextWriterWriteEndDocument), which in my opinion does not conform = with the xml standard. > I made another start on a similar xml writer interface, I've=20 > mentioned it > before on the mailinglist :) I am quite new on this list so I didn't know that you were working on = the same thing. =20 >=20 > Currently it's slightly stalled because I'm waiting for the patches of > another mailinglist member, > but it prolly does partly the same as yours :) >=20 > Thoug I haven't looked at your code yet , still glad to see=20 > someone else > works on the idea too :) Well, maybe I should stop the work on xmlTextWriter. I do not know, if = two slightly different aproaches are the best thing we should do. Servus -- Alfred From veillard@redhat.com Tue Oct 7 06:50:36 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id C6188181BB for ; Tue, 7 Oct 2003 06:50:35 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h97Aok405657; Tue, 7 Oct 2003 06:50:46 -0400 Date: Tue, 7 Oct 2003 06:50:46 -0400 From: Daniel Veillard To: "Mickautsch, Alfred" , Jeroen Cranendonk Cc: xml@gnome.org Subject: Re: AW: [xml] xmlTextWriter Message-ID: <20031007065046.C31459@redhat.com> Reply-To: veillard@redhat.com References: <4F38C8B9DAB1014DBDCB29538BBFD6A12E4E7A@pandora.schuler-ag.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <4F38C8B9DAB1014DBDCB29538BBFD6A12E4E7A@pandora.schuler-ag.com>; from alfred.mickautsch@schuler-ag.com on Tue, Oct 07, 2003 at 12:27:50PM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Tue, Oct 07, 2003 at 12:27:50PM +0200, Mickautsch, Alfred wrote: > > -----Ursprüngliche Nachricht----- > > Von: Jeroen Cranendonk [mailto:j.cranendonk@emaxx.nl] > > Gesendet: Montag, 6. Oktober 2003 18:55 > > An: Mickautsch, Alfred; xml@gnome.org > > Betreff: Re: [xml] xmlTextWriter > > > > > > Cool! ^-^ > > > > but slightly double work perhaps ? :) > > Amazing! After looking at your code and if I didn't know it better :) I'd say I copied at least some parts from your code :-). Okay, can we get a merged version ? Pick the best of both, assemble it put both of you as Copyright owners and we will integrate this, okay ? > I even found a bug that we share in our code (I think it's a > bug): the xmlTextWriter allows for multiple xml prologs in the same > document (you can call xmlTextWriterWriteStartDocument after calling > xmlTextWriterWriteEndDocument), which in my opinion does not conform > with the xml standard. Hum, the big problem is that if you serialize multiple documents on a single stream, an XML parser reading it has no way to detect the end of a document. This open the door to more troubles then it's useful IMHO. > I am quite new on this list so I didn't know that you were working on the same thing. Do not underestimate the search engine http://xmlsoft.org/search.php?query=xmlTextWriter allows to locate the threead where this was discussed http://mail.gnome.org/archives/xml/2003-May/msg00076.html > > Well, maybe I should stop the work on xmlTextWriter. I do not know, if two slightly different aproaches are the best thing we should do. No, no, don't stop now. Just make sure you end up with something which souns correct to both of you. Otherwise I will have to pick one and you don't want me to be the one deciding in an arbitrary manner :-) Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From eday@obj-sys.com Tue Oct 7 09:24:07 2003 Return-Path: Delivered-To: xml@gnome.org Received: from malone.intellispace.net (malone.intellispace.net [160.79.145.141]) by mail.gnome.org (Postfix) with ESMTP id 2F798181DC for ; Tue, 7 Oct 2003 09:24:07 -0400 (EDT) Received: from objsys1 (66.9.62.72) by malone.intellispace.net (5.1.053) id 3F7301BA0020A109; Tue, 7 Oct 2003 09:23:52 -0400 Message-ID: <029101c38cd7$2b5083a0$483e0942@objsys1> From: "Ed Day" To: =?iso-8859-1?Q?St=E9phane_Bidoul?= Cc: References: <005301c38c53$9ac9da80$1467140a@acsesbi> Subject: Re: [xml] Differences in DOM parsing on Windows and UNIX? Date: Tue, 7 Oct 2003 09:30:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi Stephane, As far as I know, I only have a main thread in my program. It is not multi-threaded. But "xmlKeepBlanksDefault(0)" did not turn off blanks in the main thread. Regards, Ed Day ----- Original Message ----- From: "Stéphane Bidoul" To: "'Ed Day'" Cc: Sent: Monday, October 06, 2003 5:48 PM Subject: RE: [xml] Differences in DOM parsing on Windows and UNIX? > > In investigating this further, I found we built the Windows > > version without > > thread support and the UNIX version with thread support. I > > also found we > > were intentionally trying to turn blank text nodes off by > > making a call to > > "xmlKeepBlanksDefault(0)" to make the DOM tree easier to work with. > > Apparently this does not work in multi-threaded mode. There > > appears to be > > another call - "xmlThrDefKeepBlanksDefault" - that must be > > used in this > > case. But, this seems to be compiled out if threads are not > > enabled. We > > therefore ended up with the following initialization logic in > > our main code: > > > > #ifdef LIBXML_THREAD_ENABLED > > xmlThrDefKeepBlanksDefaultValue(0); > > #else > > xmlKeepBlanksDefault(0); > > #endif > > > > Kind of messy. It would seem this could be kept under the > > covers somewhere > > (or perhaps it is and we missed it). > > Globals are per threads when libxml2 is compiled --with-threads. > xmlThrDefKeepBlanksDefaultValue sets the value for new threads > that will be created later. xmlKeepBlanksDefault sets the value > for the current thread only. Assuming you are doing that at > program initialization, you should do > > #ifdef LIBXML_THREAD_ENABLED > xmlKeepBlanksDefault(0); /* for the "main" thread */ > xmlThrDefKeepBlanksDefaultValue(0); /* for other threads yet to be > created */ > #else > xmlKeepBlanksDefault(0); > #endif > > You can also avoid global defaults in most cases. > I think you can set keepBlanks on the parser context. > > -sbi > > _______________________________________________ > xml mailing list, project page http://xmlsoft.org/ > xml@gnome.org > http://mail.gnome.org/mailman/listinfo/xml > From crandonkphin@tursiops.org Tue Oct 7 09:18:58 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail.tursiops.org (wsip-68-14-223-108.ph.ph.cox.net [68.14.223.108]) by mail.gnome.org (Postfix) with ESMTP id 2C247180F3 for ; Tue, 7 Oct 2003 09:18:58 -0400 (EDT) Received: from www.tursiops.org (localhost [127.0.0.1]) by mail.tursiops.org (8.12.8/8.12.8) with ESMTP id h97DKwpL004673 for ; Tue, 7 Oct 2003 06:20:58 -0700 From: "Jeroen Crandonk" To: xml@gnome.org Subject: Re: AW: [xml] xmlTextWriter Date: Tue, 7 Oct 2003 15:20:58 +0100 Message-Id: <20031007130813.M20868@www.tursiops.org> In-Reply-To: <20031007065046.C31459@redhat.com> References: <4F38C8B9DAB1014DBDCB29538BBFD6A12E4E7A@pandora.schuler-ag.com> <20031007065046.C31459@redhat.com> X-Mailer: Open WebMail 2.10 20030927 X-OriginatingIP: 193.67.10.106 (crandonkphin) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: > > Amazing! After looking at your code and if I didn't know it better :) I'd say I copied at least some parts from your code :-). > > Okay, can we get a merged version ? Pick the best of both, > assemble it put both of you as Copyright owners and we will > integrate this, okay ? I'm all for that option :) I haven't had time to have a proper look at your version yet, so can't say yet which parts should be used from which :) I like my api on the xml writer better cause that's the one I'm already using in my own programs using the xml writer ^-^ But that's easy to change really :) Like I said I was also waiting for some patches, would like to get those in before any integrating :) I still think we need a cvs somewhere for this thing btw. ^.^ > > I even found a bug that we share in our code (I think it's a > > bug): the xmlTextWriter allows for multiple xml prologs in the same > > document (you can call xmlTextWriterWriteStartDocument after calling > > xmlTextWriterWriteEndDocument), which in my opinion does not conform > > with the xml standard. > > Hum, the big problem is that if you serialize multiple documents > on a single stream, an XML parser reading it has no way to detect the > end of a document. This open the door to more troubles then it's > useful IMHO. I basicly just followed the .net specification I think :) which seems to allow it, but I'm not sure of that :) > > I am quite new on this list so I didn't know that you were working on the same thing. > > Do not underestimate the search engine > http://xmlsoft.org/search.php?query=xmlTextWriter > allows to locate the threead where this was discussed > http://mail.gnome.org/archives/xml/2003-May/msg00076.html Yup, read what I wrote on the topic ^-^ > > > > Well, maybe I should stop the work on xmlTextWriter. I do not know, if two slightly different aproaches are the best thing we should do. > > No, no, don't stop now. Just make sure you end up with something > which souns correct to both of you. Otherwise I will have to pick one > and you don't want me to be the one deciding in an arbitrary manner > :-) I agree! ^-^ I only started work on it in hopes that others would take the effort to finish it once they see the benefit of an xmlwriter :) I don't have much time to spend on it myself ^.^ So, lets see if we can come up with an integrating scheme ? :) If you think you can get any good bits from my code and make a single version with that that'll be fine with me too :) From a quick look I believe you didn't have arguments implemented yet ? Was interesting to see you did printf like functions btw. :) are those safe for overflows and such ? does any other part oflixml use printf like functions anyways ? Hope to hear of you soon again :) Jeroen Cranendonk. From eday@obj-sys.com Tue Oct 7 10:10:20 2003 Return-Path: Delivered-To: xml@gnome.org Received: from malone.intellispace.net (malone.intellispace.net [160.79.145.141]) by mail.gnome.org (Postfix) with ESMTP id 41AE618906 for ; Tue, 7 Oct 2003 10:10:20 -0400 (EDT) Received: from objsys1 (66.9.62.72) by malone.intellispace.net (5.1.053) id 3F7301BA0020D1B7 for xml@gnome.org; Tue, 7 Oct 2003 10:10:09 -0400 Message-ID: <02e201c38cdd$a2714860$483e0942@objsys1> From: "Ed Day" To: References: <005301c38c53$9ac9da80$1467140a@acsesbi> <029101c38cd7$2b5083a0$483e0942@objsys1> Subject: Re: [xml] Differences in DOM parsing on Windows and UNIX? Date: Tue, 7 Oct 2003 10:16:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: As a follow-up, I do not see why this logic cannot be embedded in xmlKeepBlanksDefault: int xmlKeepBlanksDefault(int val) { int old = xmlKeepBlanksDefaultValue; xmlKeepBlanksDefaultValue = val; xmlIndentTreeOutput = !val; /* add this here.. */ #ifdef LIBXML_THREAD_ENABLED xmlThrDefKeepBlanksDefaultValue(val); #endif return(old); } Is there any use case where it would make sense for the value to be different in the main thread then in the newly created threads? Regards, Ed Day ----- Original Message ----- From: "Ed Day" To: "Stéphane Bidoul" Cc: Sent: Tuesday, October 07, 2003 9:30 AM Subject: Re: [xml] Differences in DOM parsing on Windows and UNIX? > Hi Stephane, > > As far as I know, I only have a main thread in my program. It is not > multi-threaded. But "xmlKeepBlanksDefault(0)" did not turn off blanks in > the main thread. > > Regards, > > Ed Day > > ----- Original Message ----- > From: "Stéphane Bidoul" > To: "'Ed Day'" > Cc: > Sent: Monday, October 06, 2003 5:48 PM > Subject: RE: [xml] Differences in DOM parsing on Windows and UNIX? > > > > > In investigating this further, I found we built the Windows > > > version without > > > thread support and the UNIX version with thread support. I > > > also found we > > > were intentionally trying to turn blank text nodes off by > > > making a call to > > > "xmlKeepBlanksDefault(0)" to make the DOM tree easier to work with. > > > Apparently this does not work in multi-threaded mode. There > > > appears to be > > > another call - "xmlThrDefKeepBlanksDefault" - that must be > > > used in this > > > case. But, this seems to be compiled out if threads are not > > > enabled. We > > > therefore ended up with the following initialization logic in > > > our main code: > > > > > > #ifdef LIBXML_THREAD_ENABLED > > > xmlThrDefKeepBlanksDefaultValue(0); > > > #else > > > xmlKeepBlanksDefault(0); > > > #endif > > > > > > Kind of messy. It would seem this could be kept under the > > > covers somewhere > > > (or perhaps it is and we missed it). > > > > Globals are per threads when libxml2 is compiled --with-threads. > > xmlThrDefKeepBlanksDefaultValue sets the value for new threads > > that will be created later. xmlKeepBlanksDefault sets the value > > for the current thread only. Assuming you are doing that at > > program initialization, you should do > > > > #ifdef LIBXML_THREAD_ENABLED > > xmlKeepBlanksDefault(0); /* for the "main" thread */ > > xmlThrDefKeepBlanksDefaultValue(0); /* for other threads yet to > be > > created */ > > #else > > xmlKeepBlanksDefault(0); > > #endif > > > > You can also avoid global defaults in most cases. > > I think you can set keepBlanks on the parser context. > > > > -sbi > > > > _______________________________________________ > > xml mailing list, project page http://xmlsoft.org/ > > xml@gnome.org > > http://mail.gnome.org/mailman/listinfo/xml > > > > _______________________________________________ > xml mailing list, project page http://xmlsoft.org/ > xml@gnome.org > http://mail.gnome.org/mailman/listinfo/xml > From xml_user2003@yahoo.com Tue Oct 7 10:24:00 2003 Return-Path: Delivered-To: xml@gnome.org Received: from web20415.mail.yahoo.com (web20403.mail.yahoo.com [66.163.169.91]) by mail.gnome.org (Postfix) with SMTP id 7ED7018B06 for ; Tue, 7 Oct 2003 10:24:00 -0400 (EDT) Message-ID: <20031007142414.44256.qmail@web20415.mail.yahoo.com> Received: from [170.69.248.21] by web20403.mail.yahoo.com via HTTP; Tue, 07 Oct 2003 07:24:14 PDT Date: Tue, 7 Oct 2003 07:24:14 -0700 (PDT) From: XML User To: xml@gnome.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1191554565-1065536654=:44185" Subject: [xml] Segmentation fault - xmlNewDoc Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: --0-1191554565-1065536654=:44185 Content-Type: text/plain; charset=us-ascii Hi, I am using libXml to create an xml message and pass on the message to a webserver. Since I am sending the message as part of a GET request, I remove all the new line characters from the message. For this I am using a small helper function which removes all new line characters from the message. My problem is that the program works fine the first time, however if I try to construct another xml message I get a segmentation fault. If I do not do any newline character replacements within the xml string, everything works fine. Here is the function I am using char* constructMessage(const char *userName, const char* responsibility) { xmlDocPtr doc; xmlNodePtr tree, subtree,subsubtree; xmlChar* Message; int size; char* uid; uid = (char*)malloc(strlen(userName)*sizeof(char)); strcpy(uid,userName); encodeData(&uid); /*construct Message */ doc = xmlNewDoc("1.0"); doc->children = xmlNewDocNode(doc, NULL, "Message", NULL); xmlSetProp(doc->children,"MessageId",""); xmlSetProp(doc->children,"IntObjectFormat","Hierarchical"); xmlSetProp(doc->children,"MessageType","Integration Object"); xmlSetProp(doc->children,"IntObjectName","User Registration"); tree = xmlNewChild(doc->children, NULL, "Start_UserRegistration", NULL) subtree = xmlNewChild(tree, NULL, "UserRegistration", NULL); subsubtree = xmlNewChild(subtree, NULL, "FirstName", uid); subsubtree = xmlNewChild(subtree, NULL, "LastName", uid); subsubtree = xmlNewChild(subtree, NULL, "LoginName", uid); subsubtree = xmlNewChild(subtree, NULL, "ListOfUserRegistration_Responsibilit ", NULL); tree = subsubtree; subtree = xmlNewChild(tree, NULL, "UserRegistration_Responsibility", NULL); subsubtree = xmlNewChild(subtree, NULL, "Responsibility", responsibility); xmlDocDumpMemory(doc,&Message,&size); /*helper function*/ replaceChar(&Message,"\n",""); replaceChar(&Message," ","%20"); xmlFreeDoc(doc); free(uid); return (char*)Message; } Am I missing something? Thanks, Akshay. --------------------------------- Do you Yahoo!? The New Yahoo! Shopping - with improved product search --0-1191554565-1065536654=:44185 Content-Type: text/html; charset=us-ascii
Hi,
I am using libXml to create an xml message and pass on the message to a webserver. Since I am sending the message as part of a GET request, I remove all the new line characters from the message. For this I am using a small helper function which removes all new line characters from the message. My problem is that the program works fine the first time, however if I try to construct another xml message I get a segmentation fault. If I do not do any newline character replacements within the xml string, everything works fine.
 
Here is the function I am using
 
char* constructMessage(const char *userName,
                                  const char* responsibility)
{
  xmlDocPtr doc;
  xmlNodePtr tree, subtree,subsubtree;
  xmlChar* Message;
  int size;
  char* uid;
  uid = (char*)malloc(strlen(userName)*sizeof(char));
  strcpy(uid,userName);
  encodeData(&uid);
  /*construct Message */
  doc = xmlNewDoc("1.0");
  doc->children = xmlNewDocNode(doc, NULL, "Message", NULL);
  xmlSetProp(doc->children,"MessageId","");
  xmlSetProp(doc->children,"IntObjectFormat","Hierarchical");
  xmlSetProp(doc->children,"MessageType","Integration Object");
  xmlSetProp(doc->children,"IntObjectName","User Registration");
  tree = xmlNewChild(doc->children, NULL, "Start_UserRegistration", NULL)
  subtree = xmlNewChild(tree, NULL, "UserRegistration", NULL);
  subsubtree = xmlNewChild(subtree, NULL, "FirstName", uid);
  subsubtree = xmlNewChild(subtree, NULL, "LastName", uid);
  subsubtree = xmlNewChild(subtree, NULL, "LoginName", uid);
  subsubtree = xmlNewChild(subtree, NULL, "ListOfUserRegistration_Responsibilit
", NULL);
  tree = subsubtree;
  subtree = xmlNewChild(tree, NULL, "UserRegistration_Responsibility", NULL);
  subsubtree = xmlNewChild(subtree, NULL, "Responsibility", responsibility);
  xmlDocDumpMemory(doc,&Message,&size);
/*helper function*/
 replaceChar(&Message,"\n","");
 replaceChar(&Message," ","%20");
  xmlFreeDoc(doc);
  free(uid);
  return (char*)Message;
}
 
Am I missing something?
 
Thanks,
Akshay.
 
 
 
 
 
 
 
 

Do you Yahoo!?
The New Yahoo! Shopping - with improved product search --0-1191554565-1065536654=:44185-- From eday@obj-sys.com Tue Oct 7 10:48:19 2003 Return-Path: Delivered-To: xml@gnome.org Received: from malone.intellispace.net (malone.intellispace.net [160.79.145.141]) by mail.gnome.org (Postfix) with ESMTP id 9E91818851 for ; Tue, 7 Oct 2003 10:48:19 -0400 (EDT) Received: from objsys1 (66.9.62.72) by malone.intellispace.net (5.1.053) id 3F7301BA002107D7; Tue, 7 Oct 2003 10:48:08 -0400 Message-ID: <031a01c38ce2$f0569710$483e0942@objsys1> From: "Ed Day" To: "XML User" , References: <20031007142414.44256.qmail@web20415.mail.yahoo.com> Subject: Re: [xml] Segmentation fault - xmlNewDoc Date: Tue, 7 Oct 2003 10:54:41 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0317_01C38CC1.69391030" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_0317_01C38CC1.69391030 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Am I missing something? Sure, you are only allocating strlen chars for your uid. You need = strlen + 1 to account for the null terminator char if you are using = strcpy. Regards,=20 Ed Day ----- Original Message -----=20 From: XML User=20 To: xml@gnome.org=20 Sent: Tuesday, October 07, 2003 10:24 AM Subject: [xml] Segmentation fault - xmlNewDoc Hi, I am using libXml to create an xml message and pass on the message to = a webserver. Since I am sending the message as part of a GET request, I = remove all the new line characters from the message. For this I am using = a small helper function which removes all new line characters from the = message. My problem is that the program works fine the first time, = however if I try to construct another xml message I get a segmentation = fault. If I do not do any newline character replacements within the xml = string, everything works fine. Here is the function I am using char* constructMessage(const char *userName, const char* responsibility) { xmlDocPtr doc; xmlNodePtr tree, subtree,subsubtree; xmlChar* Message; int size; char* uid; uid =3D (char*)malloc(strlen(userName)*sizeof(char)); strcpy(uid,userName); encodeData(&uid); /*construct Message */ doc =3D xmlNewDoc("1.0"); doc->children =3D xmlNewDocNode(doc, NULL, "Message", NULL); xmlSetProp(doc->children,"MessageId",""); xmlSetProp(doc->children,"IntObjectFormat","Hierarchical"); xmlSetProp(doc->children,"MessageType","Integration Object"); xmlSetProp(doc->children,"IntObjectName","User Registration"); tree =3D xmlNewChild(doc->children, NULL, "Start_UserRegistration", = NULL) subtree =3D xmlNewChild(tree, NULL, "UserRegistration", NULL); subsubtree =3D xmlNewChild(subtree, NULL, "FirstName", uid); subsubtree =3D xmlNewChild(subtree, NULL, "LastName", uid); subsubtree =3D xmlNewChild(subtree, NULL, "LoginName", uid); subsubtree =3D xmlNewChild(subtree, NULL, = "ListOfUserRegistration_Responsibilit ", NULL); tree =3D subsubtree; subtree =3D xmlNewChild(tree, NULL, = "UserRegistration_Responsibility", NULL); subsubtree =3D xmlNewChild(subtree, NULL, "Responsibility", = responsibility); xmlDocDumpMemory(doc,&Message,&size); /*helper function*/ replaceChar(&Message,"\n",""); replaceChar(&Message," ","%20"); xmlFreeDoc(doc); free(uid); return (char*)Message; } Am I missing something? Thanks, Akshay. -------------------------------------------------------------------------= ----- Do you Yahoo!? The New Yahoo! Shopping - with improved product search ------=_NextPart_000_0317_01C38CC1.69391030 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
> Am I missing something?
 
Sure, you are only allocating strlen chars for your uid.  You = need=20 strlen + 1 to account for the null terminator char if you are using=20 strcpy.
 
Regards,
 
Ed Day
 
----- Original Message -----
From:=20 XML=20 User
Sent: Tuesday, October 07, 2003 = 10:24=20 AM
Subject: [xml] Segmentation = fault -=20 xmlNewDoc

Hi,
I am using libXml to create an xml message and pass on the = message to a=20 webserver. Since I am sending the message as part of a GET request, I = remove=20 all the new line characters from the message. For this I am using a = small=20 helper function which removes all new line characters from the = message. My=20 problem is that the program works fine the first time, however if I = try to=20 construct another xml message I get a segmentation fault. If I do not = do any=20 newline character replacements within the xml string, everything works = fine.
 
Here is the function I am using
 
char* constructMessage(const char=20 = *userName,
          = ;            =            =20 const char* responsibility)
{
  xmlDocPtr doc;
  = xmlNodePtr=20 tree, subtree,subsubtree;
  xmlChar* Message;
  int=20 size;
  char* uid;
  uid =3D = (char*)malloc(strlen(userName)*sizeof(char));
 =20 strcpy(uid,userName);
  encodeData(&uid);
  /*construct Message */
  doc =3D = xmlNewDoc("1.0");
 =20 doc->children =3D xmlNewDocNode(doc, NULL, "Message", = NULL);
 =20 xmlSetProp(doc->children,"MessageId","");
 =20 = xmlSetProp(doc->children,"IntObjectFormat","Hierarchical");
  = xmlSetProp(doc->children,"MessageType","Integration = Object");
 =20 xmlSetProp(doc->children,"IntObjectName","User = Registration");
 =20 tree =3D xmlNewChild(doc->children, NULL, "Start_UserRegistration", = NULL)
  subtree =3D xmlNewChild(tree, NULL, = "UserRegistration",=20 NULL);
  subsubtree =3D xmlNewChild(subtree, NULL, = "FirstName",=20 uid);
  subsubtree =3D xmlNewChild(subtree, NULL, "LastName",=20 uid);
  subsubtree =3D xmlNewChild(subtree, NULL, "LoginName", = uid);
  subsubtree =3D xmlNewChild(subtree, NULL,=20 "ListOfUserRegistration_Responsibilit
", NULL);
  tree =3D=20 subsubtree;
  subtree =3D xmlNewChild(tree, NULL,=20 "UserRegistration_Responsibility", NULL);
  subsubtree =3D=20 xmlNewChild(subtree, NULL, "Responsibility", = responsibility);
 =20 xmlDocDumpMemory(doc,&Message,&size);
/*helper function*/
=
 replaceChar(&Message,"\n","");
 replaceChar(&M= essage,"=20 ","%20");
  xmlFreeDoc(doc);
  free(uid);
  return=20 (char*)Message;
}
 
Am I missing something?
 
Thanks,
Akshay.
 
 
 
 
 
 
 
 

Do you Yahoo!?
The=20 New Yahoo! Shopping - with improved product=20 search ------=_NextPart_000_0317_01C38CC1.69391030-- From mark.itzcovitz@ntlworld.com Tue Oct 7 10:57:56 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mta05-svc.ntlworld.com (mta05-svc.ntlworld.com [62.253.162.45]) by mail.gnome.org (Postfix) with ESMTP id DBC67180DE for ; Tue, 7 Oct 2003 10:57:55 -0400 (EDT) Received: from [10.137.100.72] by mta05-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with SMTP id <20031007145808.NRTC2197.mta05-svc.ntlworld.com@[10.137.100.72]> for ; Tue, 7 Oct 2003 15:58:08 +0100 X-Originating-IP: [194.131.103.185] From: Mark Itzcovitz To: xml@gnome.org Subject: Re: [xml] Segmentation fault - xmlNewDoc Date: Tue, 7 Oct 2003 14:58:08 +0000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=____1065538688850_j9jxyBo.NY" Message-Id: <20031007145808.NRTC2197.mta05-svc.ntlworld.com@[10.137.100.72]> Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------=____1065538688850_j9jxyBo.NY Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Also xmlDocDumpMemory has told you how big your Message buffer is and then you make it bigger by translating spaces to %20 (unless of course replaceChar re-allocates the buffer, but you don't show that so I don't know). > _____ > > From: Ed Day [mailto:eday@obj-sys.com] > Sent: 07 October 2003 15:55 > To: XML User; xml@gnome.org > Subject: Re: [xml] Segmentation fault - xmlNewDoc > > > > > Am I missing something? > > > > Sure, you are only allocating strlen chars for your uid. You need strlen + > 1 to account for the null terminator char if you are using strcpy. > > > > Regards, > > > > Ed Day > > > > ----- Original Message ----- > > From: XML User > > To: xml@gnome.org > > Sent: Tuesday, October 07, 2003 10:24 AM > > Subject: [xml] Segmentation fault - xmlNewDoc > > > > Hi, > > I am using libXml to create an xml message and pass on the message to a > webserver. Since I am sending the message as part of a GET request, I remove > all the new line characters from the message. For this I am using a small > helper function which removes all new line characters from the message. My > problem is that the program works fine the first time, however if I try to > construct another xml message I get a segmentation fault. If I do not do any > newline character replacements within the xml string, everything works fine. > > > > Here is the function I am using > > > > char* constructMessage(const char *userName, > const char* responsibility) > { > xmlDocPtr doc; > xmlNodePtr tree, subtree,subsubtree; > xmlChar* Message; > int size; > char* uid; > > uid = (char*)malloc(strlen(userName)*sizeof(char)); > strcpy(uid,userName); > encodeData(&uid); > > /*construct Message */ > doc = xmlNewDoc("1.0"); > doc->children = xmlNewDocNode(doc, NULL, "Message", NULL); > xmlSetProp(doc->children,"MessageId",""); > xmlSetProp(doc->children,"IntObjectFormat","Hierarchical"); > xmlSetProp(doc->children,"MessageType","Integration Object"); > xmlSetProp(doc->children,"IntObjectName","User Registration"); > tree = xmlNewChild(doc->children, NULL, "Start_UserRegistration", NULL) > subtree = xmlNewChild(tree, NULL, "UserRegistration", NULL); > subsubtree = xmlNewChild(subtree, NULL, "FirstName", uid); > subsubtree = xmlNewChild(subtree, NULL, "LastName", uid); > subsubtree = xmlNewChild(subtree, NULL, "LoginName", uid); > subsubtree = xmlNewChild(subtree, NULL, > "ListOfUserRegistration_Responsibilit > ", NULL); > tree = subsubtree; > subtree = xmlNewChild(tree, NULL, "UserRegistration_Responsibility", > NULL); > subsubtree = xmlNewChild(subtree, NULL, "Responsibility", responsibility); > xmlDocDumpMemory(doc,&Message,&size); > > /*helper function*/ > > replaceChar(&Message,"\n",""); > replaceChar(&Message," ","%20"); > > xmlFreeDoc(doc); > free(uid); > return (char*)Message; > } > > > > Am I missing something? > > > > Thanks, > > Akshay. > > > > > > > > > > > > > > > > > > > _____ > > > Do you Yahoo!? > The > %2Csec%3Amail> New Yahoo! Shopping - with improved product search ----------------------------------------- Email provided by http://www.ntlhome.com/ ------=____1065538688850_j9jxyBo.NY Content-Type: text/html; name="reply" Content-Disposition: inline; filename="reply"

 

 

From: Ed Day [mailto:eday@obj-sys.com]
Sent: 07 October 2003 15:55
To: XML User; xml@gnome.org
Subject: Re: [xml] Segmentation fault - xmlNewDoc

 

> Am I missing something?

 

Sure, you are only allocating strlen chars for your uid.  You need strlen + 1 to account for the null terminator char if you are using strcpy.

 

Regards,

 

Ed Day

 

----- Original Message -----

From: XML User

Sent: Tuesday, October 07, 2003 10:24 AM

Subject: [xml] Segmentation fault - xmlNewDoc

 

Hi,

I am using libXml to create an xml message and pass on the message to a webserver. Since I am sending the message as part of a GET request, I remove all the new line characters from the message. For this I am using a small helper function which removes all new line characters from the message. My problem is that the program works fine the first time, however if I try to construct another xml message I get a segmentation fault. If I do not do any newline character replacements within the xml string, everything works fine.

 

Here is the function I am using

 

char* constructMessage(const char *userName,
                                  const char* responsibility)
{
  xmlDocPtr doc;
  xmlNodePtr tree, subtree,subsubtree;
  xmlChar* Message;
  int size;
  char* uid;

  uid = (char*)malloc(strlen(userName)*sizeof(char));
  strcpy(uid,userName);
  encodeData(&uid);

  /*construct Message */
  doc = xmlNewDoc("1.0");
  doc->children = xmlNewDocNode(doc, NULL, "Message", NULL);
  xmlSetProp(doc->children,"MessageId","");
  xmlSetProp(doc->children,"IntObjectFormat","Hierarchical");
  xmlSetProp(doc->children,"MessageType","Integration Object");
  xmlSetProp(doc->children,"IntObjectName","User Registration");
  tree = xmlNewChild(doc->children, NULL, "Start_UserRegistration", NULL)
  subtree = xmlNewChild(tree, NULL, "UserRegistration", NULL);
  subsubtree = xmlNewChild(subtree, NULL, "FirstName", uid);
  subsubtree = xmlNewChild(subtree, NULL, "LastName", uid);
  subsubtree = xmlNewChild(subtree, NULL, "LoginName", uid);
  subsubtree = xmlNewChild(subtree, NULL, "ListOfUserRegistration_Responsibilit
", NULL);
  tree = subsubtree;
  subtree = xmlNewChild(tree, NULL, "UserRegistration_Responsibility", NULL);
  subsubtree = xmlNewChild(subtree, NULL, "Responsibility", responsibility);
  xmlDocDumpMemory(doc,&Message,&size);

/*helper function*/

 replaceChar(&Message,"\n","");
 replaceChar(&Message," ","%20");

  xmlFreeDoc(doc);
  free(uid);
  return (char*)Message;
}

 

Am I missing something?

 

Thanks,

Akshay.

 

 

 

 

 

 

 

 

Do you Yahoo!?
The New Yahoo! Shopping - with improved product search


The information in this message is intended solely for the addressee and should be considered confidential. VISTA does not accept legal responsibility for the contents of this message and any statements contained herein which do not relate to the official business of VISTA are neither given nor endorsed by VISTA and are those of the individual and not of VISTA. This message has been scanned for viruses using the most current and reliable tools available and VISTA excludes all liability related to any viruses that might exist in any attachment or which may have been acquired in transit.
------=____1065538688850_j9jxyBo.NY-- From harringf@yahoo.com Tue Oct 7 11:19:26 2003 Return-Path: Delivered-To: xml@gnome.org Received: from web41015.mail.yahoo.com (web41015.mail.yahoo.com [66.218.93.14]) by mail.gnome.org (Postfix) with SMTP id CD84418B39 for ; Tue, 7 Oct 2003 11:19:25 -0400 (EDT) Message-ID: <20031007151935.95686.qmail@web41015.mail.yahoo.com> Received: from [12.8.123.244] by web41015.mail.yahoo.com via HTTP; Tue, 07 Oct 2003 08:19:35 PDT Date: Tue, 7 Oct 2003 08:19:35 -0700 (PDT) From: Harring Figueiredo To: xml@gnome.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [xml] Getting Error from the parser. Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Folks, I am parsing a document and would like to get the error returned by the xml parser. Example:Opening and ending tag mismatch: merge_filename line 6 and merge_file merge_file I am using the DOM. (i.e. opening the document with xmlParseFile(xml_file); I tried setting up the xmlSetGenericErrorFunc; howerver, the eroor message comes in "chunks" (calls the handle multiple times). Is there another way to do that, or am I doing it the correct way ? Thanks for any help. ===== ================================================================== Plese, don't send me any attachment in Micro$oft (.DOC, .PPT) format. Read http://www.fsf.org/philosophy/no-word-attachments.html Preferable attachments: .PDF, .HTML, .TXT Please, consider adding this text to Your email signature. Harring Figueiredo __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com From veillard@redhat.com Tue Oct 7 11:49:22 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 8F58418B78 for ; Tue, 7 Oct 2003 11:49:22 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h97FnZp04398; Tue, 7 Oct 2003 11:49:35 -0400 Date: Tue, 7 Oct 2003 11:49:34 -0400 From: Daniel Veillard To: Harring Figueiredo Cc: xml@gnome.org Subject: Re: [xml] Getting Error from the parser. Message-ID: <20031007114934.I31459@redhat.com> Reply-To: veillard@redhat.com References: <20031007151935.95686.qmail@web41015.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031007151935.95686.qmail@web41015.mail.yahoo.com>; from harringf@yahoo.com on Tue, Oct 07, 2003 at 08:19:35AM -0700 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Tue, Oct 07, 2003 at 08:19:35AM -0700, Harring Figueiredo wrote: > Folks, > > I am parsing a document and would like to get the error returned by the xml > parser. > > Example:Opening and ending tag mismatch: merge_filename line 6 and merge_file > merge_file > > I am using the DOM. (i.e. opening the document with > xmlParseFile(xml_file); > > > I tried setting up the xmlSetGenericErrorFunc; howerver, the eroor message > comes in "chunks" (calls the handle multiple times). > > Is there another way to do that, or am I doing it the correct way ? with xmlParseFile() it's not possible. You nedd either a lower level function or wait for 2.6.0 where this will be possible, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From xml_user2003@yahoo.com Tue Oct 7 11:52:47 2003 Return-Path: Delivered-To: xml@gnome.org Received: from web20415.mail.yahoo.com (web20403.mail.yahoo.com [66.163.169.91]) by mail.gnome.org (Postfix) with SMTP id 5992818B7F for ; Tue, 7 Oct 2003 11:52:45 -0400 (EDT) Message-ID: <20031007152646.67449.qmail@web20415.mail.yahoo.com> Received: from [170.69.248.21] by web20403.mail.yahoo.com via HTTP; Tue, 07 Oct 2003 08:26:46 PDT Date: Tue, 7 Oct 2003 08:26:46 -0700 (PDT) From: XML User Subject: Re: [xml] Segmentation fault - xmlNewDoc To: xml@gnome.org In-Reply-To: <20031007145808.NRTC2197.mta05-svc.ntlworld.com@[10.137.100.72]> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-825712278-1065540406=:63024" Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: --0-825712278-1065540406=:63024 Content-Type: text/plain; charset=us-ascii Hi, Thanks for your reply. I did the size of uid to userName+1. Also my replace char does reallocate the buffer size to accomodate the additional chars. Still the behavior I explained remains....the first time everything works fine, when I try to invoke constructMessage the second time, I get a segmentation fault. If I do not replace any chars in the xml string generated by the libxml toolkit, the program doesn't crash. BTW Here is my code for replaceChar() #define LINESIZE 4096 void replaceChar(char** data,char* oldChar,char* newChar) { int newStringIndex; char* nextIndex; int currIndex; char newString[LINESIZE]; if((nextIndex=(char *)strstr(*data,oldChar))==NULL) return; currIndex=0; newStringIndex = 0; while(nextIndex!=NULL) { strncpy(newString+newStringIndex,*data+currIndex,(nextIndex-*data)-currInd ex); newStringIndex+=(nextIndex-*data)-currIndex; strncpy(newString+newStringIndex,newChar,strlen(newChar)); newStringIndex+=strlen(newChar); currIndex = (nextIndex-*data)+strlen(oldChar); nextIndex = strstr(*data+currIndex,oldChar); } strcpy(newString+newStringIndex,*data+currIndex); *data =(char*)malloc((strlen(newString)+1)*sizeof(char)); strcpy(*data,newString); free(newString); free(nextIndex); } Mark Itzcovitz wrote: Also xmlDocDumpMemory has told you how big your Message buffer is and then you make it bigger by translating spaces to %20 (unless of course replaceChar re-allocates the buffer, but you don't show that so I don't know). > _____ > > From: Ed Day [mailto:eday@obj-sys.com] > Sent: 07 October 2003 15:55 > To: XML User; xml@gnome.org > Subject: Re: [xml] Segmentation fault - xmlNewDoc > > > > > Am I missing something? > > > > Sure, you are only allocating strlen chars for your uid. You need strlen + > 1 to account for the null terminator char if you are using strcpy. > > > > Regards, > > > > Ed Day > > > > ----- Original Message ----- > > From: XML User > > To: xml@gnome.org > > Sent: Tuesday, October 07, 2003 10:24 AM > > Subject: [xml] Segmentation fault - xmlNewDoc > > > > Hi, > > I am using libXml to create an xml message and pass on the message to a > webserver. Since I am sending the message as part of a GET request, I remove > all the new line characters from the message. For this I am using a small > helper function which removes all new line characters from the message. My > problem is that the program works fine the first time, however if I try to > construct another xml message I get a segmentation fault. If I do not do any > newline character replacements within the xml string, everything works fine. > > > > Here is the function I am using > > > > char* constructMessage(const char *userName, > const char* responsibility) > { > xmlDocPtr doc; > xmlNodePtr tree, subtree,subsubtree; > xmlChar* Message; > int size; > char* uid; > > uid = (char*)malloc(strlen(userName)*sizeof(char)); > strcpy(uid,userName); > encodeData(&uid); > > /*construct Message */ > doc = xmlNewDoc("1.0"); > doc->children = xmlNewDocNode(doc, NULL, "Message", NULL); > xmlSetProp(doc->children,"MessageId",""); > xmlSetProp(doc->children,"IntObjectFormat","Hierarchical"); > xmlSetProp(doc->children,"MessageType","Integration Object"); > xmlSetProp(doc->children,"IntObjectName","User Registration"); > tree = xmlNewChild(doc->children, NULL, "Start_UserRegistration", NULL) > subtree = xmlNewChild(tree, NULL, "UserRegistration", NULL); > subsubtree = xmlNewChild(subtree, NULL, "FirstName", uid); > subsubtree = xmlNewChild(subtree, NULL, "LastName", uid); > subsubtree = xmlNewChild(subtree, NULL, "LoginName", uid); > subsubtree = xmlNewChild(subtree, NULL, > "ListOfUserRegistration_Responsibilit > ", NULL); > tree = subsubtree; > subtree = xmlNewChild(tree, NULL, "UserRegistration_Responsibility", > NULL); > subsubtree = xmlNewChild(subtree, NULL, "Responsibility", responsibility); > xmlDocDumpMemory(doc,&Message,&size); > > /*helper function*/ > > replaceChar(&Message,"\n",""); > replaceChar(&Message," ","%20"); > > xmlFreeDoc(doc); > free(uid); > return (char*)Message; > } > > > > Am I missing something? > > > > Thanks, > > Akshay. > > > > > > > > > > > > > > > > > > > _____ > > > Do you Yahoo!? > The > > %2Csec%3Amail> New Yahoo! Shopping - with improved product search ----------------------------------------- Email provided by http://www.ntlhome.com/ v\:* {behavior:url(#default#VML);}o\:* {behavior:url(#default#VML);}w\:* {behavior:url(#default#VML);}.shape {behavior:url(#default#VML);}st1\:*{behavior:url(#default#ieooui) } --------------------------------- From: Ed Day [mailto:eday@obj-sys.com] Sent: 07 October 2003 15:55 To: XML User; xml@gnome.org Subject: Re: [xml] Segmentation fault - xmlNewDoc > Am I missing something? Sure, you are only allocating strlen chars for your uid. You need strlen + 1 to account for the null terminator char if you are using strcpy. Regards, Ed Day ----- Original Message ----- From: XML User To: xml@gnome.org Sent: Tuesday, October 07, 2003 10:24 AM Subject: [xml] Segmentation fault - xmlNewDoc Hi, I am using libXml to create an xml message and pass on the message to a webserver. Since I am sending the message as part of a GET request, I remove all the new line characters from the message. For this I am using a small helper function which removes all new line characters from the message. My problem is that the program works fine the first time, however if I try to construct another xml message I get a segmentation fault. If I do not do any newline character replacements within the xml string, everything works fine. Here is the function I am using char* constructMessage(const char *userName, const char* responsibility) { xmlDocPtr doc; xmlNodePtr tree, subtree,subsubtree; xmlChar* Message; int size; char* uid; uid = (char*)malloc(strlen(userName)*sizeof(char)); strcpy(uid,userName); encodeData(&uid); /*construct Message */ doc = xmlNewDoc("1.0"); doc->children = xmlNewDocNode(doc, NULL, "Message", NULL); xmlSetProp(doc->children,"MessageId",""); xmlSetProp(doc->children,"IntObjectFormat","Hierarchical"); xmlSetProp(doc->children,"MessageType","Integration Object"); xmlSetProp(doc->children,"IntObjectName","User Registration"); tree = xmlNewChild(doc->children, NULL, "Start_UserRegistration", NULL) subtree = xmlNewChild(tree, NULL, "UserRegistration", NULL); subsubtree = xmlNewChild(subtree, NULL, "FirstName", uid); subsubtree = xmlNewChild(subtree, NULL, "LastName", uid); subsubtree = xmlNewChild(subtree, NULL, "LoginName", uid); subsubtree = xmlNewChild(subtree, NULL, "ListOfUserRegistration_Responsibilit ", NULL); tree = subsubtree; subtree = xmlNewChild(tree, NULL, "UserRegistration_Responsibility", NULL); subsubtree = xmlNewChild(subtree, NULL, "Responsibility", responsibility); xmlDocDumpMemory(doc,&Message,&size); /*helper function*/ replaceChar(&Message,"\n",""); replaceChar(&Message," ","%20"); xmlFreeDoc(doc); free(uid); return (char*)Message; } Am I missing something? Thanks, Akshay. --------------------------------- Do you Yahoo!? The New Yahoo! Shopping - with improved product search --0-825712278-1065540406=:63024 Content-Type: text/html; charset=us-ascii
Hi,
Thanks for your reply. I did the size of uid to userName+1. Also my replace char does reallocate the buffer size to accomodate the additional chars. Still the behavior I explained remains....the first time everything works fine, when I try to invoke constructMessage the second time, I get a segmentation fault. If I do not replace any chars in the xml string generated by the libxml toolkit, the program doesn't crash.
 
 
BTW Here is my code for replaceChar()
 
#define LINESIZE 4096
void replaceChar(char** data,char* oldChar,char* newChar)
{
  int newStringIndex;
  char* nextIndex;
  int currIndex;
  char newString[LINESIZE];
  if((nextIndex=(char *)strstr(*data,oldChar))==NULL)
    return;
  currIndex=0;
  newStringIndex = 0;
  while(nextIndex!=NULL)
    {
      strncpy(newString+newStringIndex,*data+currIndex,(nextIndex-*data)-currInd
ex);
      newStringIndex+=(nextIndex-*data)-currIndex;
      strncpy(newString+newStringIndex,newChar,strlen(newChar));
      newStringIndex+=strlen(newChar);
      currIndex = (nextIndex-*data)+strlen(oldChar);
      nextIndex = strstr(*data+currIndex,oldChar);
    }
  strcpy(newString+newStringIndex,*data+currIndex);
  *data =(char*)malloc((strlen(newString)+1)*sizeof(char));
  strcpy(*data,newString);
  free(newString);
  free(nextIndex);
}


Mark Itzcovitz <mark.itzcovitz@ntlworld.com> wrote:
Also xmlDocDumpMemory has told you how big your Message buffer is and then you make it bigger by translating spaces to %20 (unless of course replaceChar re-allocates the buffer, but you don't show that so I don't know).
> _____
>
> From: Ed Day [mailto:eday@obj-sys.com]
> Sent: 07 October 2003 15:55
> To: XML User; xml@gnome.org
> Subject: Re: [xml] Segmentation fault - xmlNewDoc
>
>
>
> > Am I missing something?
>
>
>
> Sure, you are only allocating strlen chars for your uid. You need strlen +
> 1 to account for the null terminator char if you are using strcpy.
>
>
>
> Regards,
>
>
>
> Ed Day
>
>
>
> ----- Original Message -----
>
> From: XML User
>
> To: xml@gnome.org
>
> Sent: Tuesday, October 07, 2003 10:24 AM
>
> Subject: [xml] Segmentation fault - xmlNewDoc
>
>
>
> Hi,
>
> I am using libXml to create an xml message and pass on the message to a
> webserver. Since I am sending the message as part of a GET request, I remove
> all the new line characters from the message. For this I am using a small
> helper function which removes all new line characters from the message. My
> problem is that the program works fine the first time, however if I try to
> construct another xml message I get a segmentation fault. If I do not do any
> newline character replacements within the xml string, everything works fine.
>
>
>
> Here is the function I am using
>
>
>
> char* constructMessage(const char *userName,
> const char* responsibility)
> {
> xmlDocPtr doc;
> xmlNodePtr tree, subtree,subsubtree;
> xmlChar* Message;
> int size;
> char* uid;
>
> uid = (char*)malloc(strlen(userName)*sizeof(char));
> strcpy(uid,userName);
> encodeData(&uid);
>
> /*construct Message */
> doc = xmlNewDoc("1.0");
> doc->children = xmlNewDocNode(doc, NULL, "Message", NULL);
> xmlSetProp(doc->children,"MessageId","");
> xmlSetProp(doc->children,"IntObjectFormat","Hierarchical");
> xmlSetProp(doc->children,"MessageType","Integration Object");
> xmlSetProp(doc->children,"IntObjectName","User Registration");
> tree = xmlNewChild(doc->children, NULL, "Start_UserRegistration", NULL)
> subtree = xmlNewChild(tree, NULL, "UserRegistration", NULL);
> subsubtree = xmlNewChild(subtree, NULL, "FirstName", uid);
> subsubtree = xmlNewChild(subtree, NULL, "LastName", uid);
> subsubtree = xmlNewChild(subtree, NULL, "LoginName", uid);
> subsubtree = xmlNewChild(subtree, NULL,
> "ListOfUserRegistration_Responsibilit
> ", NULL);
> tree = subsubtree;
> subtree = xmlNewChild(tree, NULL, "UserRegistration_Responsibility",
> NULL);
> subsubtree = xmlNewChild(subtree, NULL, "Responsibility", responsibility);
> xmlDocDumpMemory(doc,&Message,&size);
>
> /*helper function*/
>
> replaceChar(&Message,"\n","");
> replaceChar(&Message," ","%20");
>
> xmlFreeDoc(doc);
> free(uid);
> return (char*)Message;
> }
>
>
>
> Am I missing something?
>
>
>
> Thanks,
>
> Akshay.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _____
>
>
> Do you Yahoo!?
> The
> > %2Csec%3Amail> New Yahoo! Shopping - with improved product search


-----------------------------------------
Email provided by http://www.ntlhome.com/

 

 

From: Ed Day [mailto:eday@obj-sys.com]
Sent: 07 October 2003 15:55
To: XML User; xml@gnome.org
Subject: Re: [xml] Segmentation fault - xmlNewDoc

 

> Am I missing something?

 

Sure, you are only allocating strlen chars for your uid.  You need strlen + 1 to account for the null terminator char if you are using strcpy.

 

Regards,

 

Ed Day

 

----- Original Message -----

From: XML User

Sent: Tuesday, October 07, 2003 10:24 AM

Subject: [xml] Segmentation fault - xmlNewDoc

 

Hi,

I am using libXml to create an xml message and pass on the message to a webserver. Since I am sending the message as part of a GET request, I remove all the new line characters from the message. For this I am using a small helper function which removes all new line characters from the message. My problem is that the program works fine the first time, however if I try to construct another xml message I get a segmentation fault. If I do not do any newline character replacements within the xml string, everything works fine.

 

Here is the function I am using

 

char* constructMessage(const char *userName,
                                  const char* responsibility)
{
  xmlDocPtr doc;
  xmlNodePtr tree, subtree,subsubtree;
  xmlChar* Message;
  int size;
  char* uid;

  uid = (char*)malloc(strlen(userName)*sizeof(char));
  strcpy(uid,userName);
  encodeData(&uid);

  /*construct Message */
  doc = xmlNewDoc("1.0");
  doc->children = xmlNewDocNode(doc, NULL, "Message", NULL);
  xmlSetProp(doc->children,"MessageId","");
  xmlSetProp(doc->children,"IntObjectFormat","Hierarchical");
  xmlSetProp(doc->children,"MessageType","Integration Object");
  xmlSetProp(doc->children,"IntObjectName","User Registration");
  tree = xmlNewChild(doc->children, NULL, "Start_UserRegistration", NULL)
  subtree = xmlNewChild(tree, NULL, "UserRegistration", NULL);
  subsubtree = xmlNewChild(subtree, NULL, "FirstName", uid);
  subsubtree = xmlNewChild(subtree, NULL, "LastName", uid);
  subsubtree = xmlNewChild(subtree, NULL, "LoginName", uid);
  subsubtree = xmlNewChild(subtree, NULL, "ListOfUserRegistration_Responsibilit
", NULL);
  tree = subsubtree;
  subtree = xmlNewChild(tree, NULL, "UserRegistration_Responsibility", NULL);
  subsubtree = xmlNewChild(subtree, NULL, "Responsibility", responsibility);
  xmlDocDumpMemory(doc,&Message,&size);

/*helper function*/

 replaceChar(&Message,"\n","");
 replaceChar(&Message," ","%20");

  xmlFreeDoc(doc);
  free(uid);
  return (char*)Message;
}

 

Am I missing something?

 

Thanks,

Akshay.

 

 

 

 

 

 

 

 

Do you Yahoo!?
The New Yahoo! Shopping - with improved product search --0-825712278-1065540406=:63024-- From swilliams@rinax.com Tue Oct 7 12:27:35 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail.nucleus.com (mail.nucleus.com [207.34.93.23]) by mail.gnome.org (Postfix) with ESMTP id 03175185EE for ; Tue, 7 Oct 2003 12:27:35 -0400 (EDT) Received: from rinax.com (unverified [205.206.148.171]) by mail.nucleus.com (Vircom SMTPRS 2.1.268) with ESMTP id ; Tue, 7 Oct 2003 10:27:39 -0600 Message-ID: <3F82E996.2080203@rinax.com> Date: Tue, 07 Oct 2003 10:28:06 -0600 From: Steve Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: XML User Cc: xml@gnome.org Subject: Re: [xml] Segmentation fault - xmlNewDoc References: <20031007152646.67449.qmail@web20415.mail.yahoo.com> In-Reply-To: <20031007152646.67449.qmail@web20415.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi, Is this your first C project using dynamically allocated memory?? 2 fundamental rules. only free memory that has been acquired by malloc only free memory once. Not sure if it's your problem or not, but you can't free newString, it's allocated on the stack. nextIndex NEVER has data assigned to it by malloc, so it should never be free'd. Without looking closely at the code, odds are you are free'ing a chunk of memory from another area of the program. You are not checking for overflow of the static newString buffer. XML User wrote: > Hi, > Thanks for your reply. I did the size of uid to userName+1. Also my > replace char does reallocate the buffer size to accomodate the > additional chars. Still the behavior I explained remains....the first > time everything works fine, when I try to invoke constructMessage the > second time, I get a segmentation fault. If I do not replace any chars > in the xml string generated by the libxml toolkit, the program doesn't > crash. > > > BTW Here is my code for replaceChar() > > #define LINESIZE 4096 > void replaceChar(char** data,char* oldChar,char* newChar) > { > int newStringIndex; > char* nextIndex; > int currIndex; > char newString[LINESIZE]; > if((nextIndex=(char *)strstr(*data,oldChar))==NULL) > return; > currIndex=0; > newStringIndex = 0; > while(nextIndex!=NULL) > { > > strncpy(newString+newStringIndex,*data+currIndex,(nextIndex-*data)-currInd > ex); > newStringIndex+=(nextIndex-*data)-currIndex; > strncpy(newString+newStringIndex,newChar,strlen(newChar)); > newStringIndex+=strlen(newChar); > currIndex = (nextIndex-*data)+strlen(oldChar); > nextIndex = strstr(*data+currIndex,oldChar); > } > strcpy(newString+newStringIndex,*data+currIndex); > *data =(char*)malloc((strlen(newString)+1)*sizeof(char)); > strcpy(*data,newString); > free(newString); > free(nextIndex); > } > > > */Mark Itzcovitz /* wrote: > > Also xmlDocDumpMemory has told you how big your Message buffer is > and then you make it bigger by translating spaces to %20 (unless > of course replaceChar re-allocates the buffer, but you don't show > that so I don't know). > > _____ > > > > From: Ed Day [mailto:eday@obj-sys.com] > > Sent: 07 October 2003 15:55 > > To: XML User; xml@gnome.org > > Subject: Re: [xml] Segmentation fault - xmlNewDoc > > > > > > > > > Am I missing something? > > > > > > > > Sure, you are only allocating strlen chars for your uid. You > need strlen + > > 1 to account for the null terminator char if you are using strcpy. > > > > > > > > Regards, > > > > > > > > Ed Day > > > > > > > > ----- Original Message ----- > > > > From: XML User > > > > To: xml@gnome.org > > > > Sent: Tuesday, October 07, 2003 10:24 AM > > > > Subject: [xml] Segmentation fault - xmlNewDoc > > > > > > > > Hi, > > > > I am using libXml to create an xml message and pass on the > message to a > > webserver. Since I am sending the message as part of a GET > request, I remove > > all the new line characters from the message. For this I am > using a small > > helper function which removes all new line characters from the > message. My > > problem is that the program works fine the first time, however > if I try to > > construct another xml message I get a segmentation fault. If I > do not do any > > newline character replacements within the xml string, everything > works fine. > > > > > > > > Here is the function I am using > > > > > > > > char* constructMessage(const char *userName, > > const char* responsibility) > > { > > xmlDocPtr doc; > > xmlNodePtr tree, subtree,subsubtree; > > xmlChar* Message; > > int size; > > char* uid; > > > > uid = (char*)malloc(strlen(userName)*sizeof(char)); > > strcpy(uid,userName); > > encodeData(&uid); > > > > /*construct Message */ > > doc = xmlNewDoc("1.0"); > > doc->children = xmlNewDocNode(doc, NULL, "Message", NULL); > > xmlSetProp(doc->children,"MessageId",""); > > xmlSetProp(doc->children,"IntObjectFormat","Hierarchical"); > > xmlSetProp(doc->children,"MessageType","Integration Object"); > > xmlSetProp(doc->children,"IntObjectName","User Registration"); > > tree = xmlNewChild(doc->children, NULL, > "Start_UserRegistration", NULL) > > subtree = xmlNewChild(tree, NULL, "UserRegistration", NULL); > > subsubtree = xmlNewChild(subtree, NULL, "FirstName", uid); > > subsubtree = xmlNewChild(subtree, NULL, "LastName", uid); > > subsubtree = xmlNewChild(subtree, NULL, "LoginName", uid); > > subsubtree = xmlNewChild(subtree, NULL, > > "ListOfUserRegistration_Responsibilit > > ", NULL); > > tree = subsubtree; > > subtree = xmlNewChild(tree, NULL, "UserRegistration_Responsibility", > > NULL); > > subsubtree = xmlNewChild(subtree, NULL, "Responsibility", > responsibility); > > xmlDocDumpMemory(doc,&Message,&size); > > > > /*helper function*/ > > > > replaceChar(&Message,"\n",""); > > replaceChar(&Message," ","%20"); > > > > xmlFreeDoc(doc); > > free(uid); > > return (char*)Message; > > } > > > > > > > > Am I missing something? > > > > > > > > Thanks, > > > > Akshay. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _____ > > > > > > Do you Yahoo!? > > The > > > %2Csec%3Amail> New Yahoo! Shopping - with improved product search > > > ----------------------------------------- > Email provided by http://www.ntlhome.com/ > > > > > > ------------------------------------------------------------------------ > > *From:* Ed Day [mailto:eday@obj-sys.com] > *Sent:* 07 October 2003 15:55 > *To:* XML User; xml@gnome.org > *Subject:* Re: [xml] Segmentation fault - xmlNewDoc > > > >> Am I missing something? > > > > Sure, you are only allocating strlen chars for your uid. You need > strlen + 1 to account for the null terminator char if you are > using strcpy. > > > > Regards, > > > > Ed Day > > > > ----- Original Message ----- > > *From:* XML User > > *To:* xml@gnome.org > > *Sent:* Tuesday, October 07, 2003 10:24 AM > > *Subject:* [xml] Segmentation fault - xmlNewDoc > > > > Hi, > > I am using libXml to create an xml message and pass on the > message to a webserver. Since I am sending the message as part > of a GET request, I remove all the new line characters from > the message. For this I am using a small helper function which > removes all new line characters from the message. My problem > is that the program works fine the first time, however if I > try to construct another xml message I get a segmentation > fault. If I do not do any newline character replacements > within the xml string, everything works fine. > > > > Here is the function I am using > > > > char* constructMessage(const char *userName, > const char* responsibility) > { > xmlDocPtr doc; > xmlNodePtr tree, subtree,subsubtree; > xmlChar* Message; > int size; > char* uid; > > uid = (char*)malloc(strlen(userName)*sizeof(char)); > strcpy(uid,userName); > encodeData(&uid); > > /*construct Message */ > doc = xmlNewDoc("1.0"); > doc->children = xmlNewDocNode(doc, NULL, "Message", NULL); > xmlSetProp(doc->children,"MessageId",""); > xmlSetProp(doc->children,"IntObjectFormat","Hierarchical"); > xmlSetProp(doc->children,"MessageType","Integration Object"); > xmlSetProp(doc->children,"IntObjectName","User Registration"); > tree = xmlNewChild(doc->children, NULL, > "Start_UserRegistration", NULL) > subtree = xmlNewChild(tree, NULL, "UserRegistration", NULL); > subsubtree = xmlNewChild(subtree, NULL, "FirstName", uid); > subsubtree = xmlNewChild(subtree, NULL, "LastName", uid); > subsubtree = xmlNewChild(subtree, NULL, "LoginName", uid); > subsubtree = xmlNewChild(subtree, NULL, > "ListOfUserRegistration_Responsibilit > ", NULL); > tree = subsubtree; > subtree = xmlNewChild(tree, NULL, > "UserRegistration_Responsibility", NULL); > subsubtree = xmlNewChild(subtree, NULL, "Responsibility", > responsibility); > xmlDocDumpMemory(doc,&Message,&size); > > /*helper function*/ > > replaceChar(&Message,"\n",""); > replaceChar(&Message," ","%20"); > > xmlFreeDoc(doc); > free(uid); > return (char*)Message; > } > > > > Am I missing something? > > > > Thanks, > > Akshay. > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > Do you Yahoo!? > The New Yahoo! Shopping > > - with improved product search From aospan@netup.ru Tue Oct 7 15:00:58 2003 Return-Path: Delivered-To: xml@gnome.org Received: from netup.ru (unknown [195.161.112.6]) by mail.gnome.org (Postfix) with ESMTP id 69120185C8 for ; Tue, 7 Oct 2003 15:00:58 -0400 (EDT) Received: from [81.13.30.134] (helo=support) by netup.ru with asmtp (Exim 4.22) id 1A6x5A-000Bar-5c for xml@gnome.org; Tue, 07 Oct 2003 23:01:16 +0400 Message-ID: <04b101c38d05$5f7c9960$8902010a@support> From: "Abylai Ospan" To: Date: Tue, 7 Oct 2003 23:01:11 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04AE_01C38D26.E66813C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [xml] Charset trouble Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_04AE_01C38D26.E66813C0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Hello, All ! Sorry for my pure english :) I have some trouble with html-forms contains russian letters. For = example, I see (using tcpdump) that all available browsers (Opera 5x, = Mozilla, IE 6x) send %D1%85 for russian letter "x" and for all russian = letter they send hex digits. How to convert this to native KOI8-R = Charset ? Or how to tell browser send form data in KOI8-R ? Or how to generate html-page using libxml/libxslt in KOI8-R charset = (I've read that only utf-8/16 output available) ? Help! wbr, Abylai Moscow, Russia ------=_NextPart_000_04AE_01C38D26.E66813C0 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
Hello, All !
 
Sorry for my pure english :)
I have some trouble with html-forms contains russian = letters.=20 For example, I see (using tcpdump) that all available browsers (Opera = 5x,=20 Mozilla, IE 6x) send %D1%85 for russian letter "x" and for all russian = letter=20 they send hex digits. How to convert this to native KOI8-R Charset=20 ?
Or how to tell browser send form data in KOI8-R = ?
Or how to generate html-page using libxml/libxslt in = KOI8-R=20 charset (I've read that only utf-8/16 output = available) ?
Help!
 
wbr, Abylai
Moscow, Russia
------=_NextPart_000_04AE_01C38D26.E66813C0-- From veillard@redhat.com Tue Oct 7 15:30:49 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 8C3DE18131 for ; Tue, 7 Oct 2003 15:30:49 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h97JV1c31011; Tue, 7 Oct 2003 15:31:01 -0400 Date: Tue, 7 Oct 2003 15:31:01 -0400 From: Daniel Veillard To: Abylai Ospan Cc: xml@gnome.org Subject: Re: [xml] Charset trouble Message-ID: <20031007153101.L31459@redhat.com> Reply-To: veillard@redhat.com References: <04b101c38d05$5f7c9960$8902010a@support> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <04b101c38d05$5f7c9960$8902010a@support>; from aospan@netup.ru on Tue, Oct 07, 2003 at 11:01:11PM +0400 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Tue, Oct 07, 2003 at 11:01:11PM +0400, Abylai Ospan wrote: > Or how to generate html-page using libxml/libxslt in KOI8-R charset (I've read that only utf-8/16 output available) ? make sure libxml2 is compiled with iconv support Use the encoding property of xsl:output element . See section 16 of the XSLT-1.0 specification. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From jsp@PKC.com Tue Oct 7 15:51:20 2003 Return-Path: Delivered-To: xml@gnome.org Received: from pkc.com (unknown [216.75.143.162]) by mail.gnome.org (Postfix) with ESMTP id 7384518131 for ; Tue, 7 Oct 2003 15:51:20 -0400 (EDT) Message-ID: <01abc66476c389c75309e46c6d4fce9b3f83193e@pkc.com> From: Jesse Pelton To: xml@gnome.org Date: Tue, 7 Oct 2003 15:51:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [xml] Windows threading issues Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Back in July, St=E9phane Bidoul and I developed a couple of patches to = address some Windows threading issues (see http://mail.gnome.org/archives/xml/2003-July/msg00301.html et al). = After he got back from vacation, Igor expressed his intent to commit them (both, = I think), but I think he forgot about them. I'm finally upgrading to the latest libxml, and the changes aren't there. Can these patches be committed? They still appear to be valid. (At = least, patch doesn't fail, and the resulting file compiles.) The second patch = must be applied over the first. From veillard@redhat.com Tue Oct 7 16:05:18 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 656F518561 for ; Tue, 7 Oct 2003 16:05:18 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h97K5TR18558; Tue, 7 Oct 2003 16:05:29 -0400 Date: Tue, 7 Oct 2003 16:05:29 -0400 From: Daniel Veillard To: Jesse Pelton Cc: xml@gnome.org Subject: Re: [xml] Windows threading issues Message-ID: <20031007160529.O31459@redhat.com> Reply-To: veillard@redhat.com References: <01abc66476c389c75309e46c6d4fce9b3f83193e@pkc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <01abc66476c389c75309e46c6d4fce9b3f83193e@pkc.com>; from jsp@PKC.com on Tue, Oct 07, 2003 at 03:51:20PM -0400 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Tue, Oct 07, 2003 at 03:51:20PM -0400, Jesse Pelton wrote: > Back in July, Stéphane Bidoul and I developed a couple of patches to address > some Windows threading issues (see > http://mail.gnome.org/archives/xml/2003-July/msg00301.html et al). After he > got back from vacation, Igor expressed his intent to commit them (both, I > think), but I think he forgot about them. I'm finally upgrading to the > latest libxml, and the changes aren't there. > > Can these patches be committed? They still appear to be valid. (At least, > patch doesn't fail, and the resulting file compiles.) The second patch must > be applied over the first. Okay, applied both, it seems they only affect Windows build with the TLS threads support. I will commit them later when my tree is back in shape, thanks Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From mgrushinskiy@comcast.net Wed Oct 8 01:02:39 2003 Return-Path: Delivered-To: xml@gnome.org Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mail.gnome.org (Postfix) with ESMTP id BE6EF18127 for ; Wed, 8 Oct 2003 01:02:39 -0400 (EDT) Received: from cc711577a (bgp535056bgs.ebrnsw01.nj.comcast.net[68.38.116.126]) by comcast.net (sccrmhc12) with SMTP id <20031008050253012004j3ije>; Wed, 8 Oct 2003 05:02:53 +0000 Message-ID: <001d01c38d59$7042fd30$8f00a8c0@cc711577a> From: "Mikhail Grushinskiy" To: Date: Wed, 8 Oct 2003 01:02:56 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01C38D37.E8D5A8A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [xml] Call to libxml developers Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_001A_01C38D37.E8D5A8A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello gentlemen, Thank you for great work on libxml2/libxslt! Really good job! I'm using libxml2/libxslt for quite a while now and it is very = impressive library. I'm hosting my little open source pet project on SourceForge. It is a general purpose command-line XML utility for = searching/editing/validating XML documents. It is based on libxml2/libxslt and written in C. Here is a link = http://xmlstar.sourceforge.net/ (and http://sourceforge.net/projects/xmlstar/) So far I'm writting it on my free time, so this project needs help :). I thought I might look for somebody on this list with libxml expertise,=20 who might like the idea and would be interested to help working on = something like this. Here is a link to some documentation which gives more details what this = project is about http://xmlstar.sourceforge.net/doc/xmlstarlet.pdf There are also many = other features=20 which would be nice to have in it (ex: XML diff, XML patch, etc) Your help is very much welcome! Let me know if you are interested to = join... Any other comments are welcome too :). Thanks, --Mikhail Grushinskiy XmlStarlet Command-Line XML Toolkit http://xmlstar.sourceforge.net/ =20 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.522 / Virus Database: 320 - Release Date: 9/29/2003 ------=_NextPart_000_001A_01C38D37.E8D5A8A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello gentlemen,
 
Thank you for great work on=20 libxml2/libxslt! Really good job!
I'm using libxml2/libxslt for = quite a while=20 now and it is very impressive library.
 
I'm hosting my little open = source pet=20 project on SourceForge.
It is a general purpose=20 command-line XML utility for searching/editing/validating XML=20 documents.
It is based on = libxml2/libxslt and=20 written in C. Here is a link http://xmlstar.sourceforge.net/
(and http://sourceforge.net/= projects/xmlstar/)
 
So far I'm writting it on my = free time, so=20 this project needs help :).
I thought I might look = for somebody=20 on this list with libxml expertise, =
who might like the idea and = would be=20 interested to help working on something like this.
Here is a link to some = documentation=20 which gives more details what this project is about
http://xmlstar= .sourceforge.net/doc/xmlstarlet.pdf There are also many other features =
which would be nice to have in = it (ex: XML=20 diff, XML patch, etc)
 
Your help is very much = welcome! Let me=20 know if you are interested to join...
Any other comments are welcome = too=20 :).
 
Thanks,
--Mikhail = Grushinskiy
 
XmlStarlet Command-Line XML=20 Toolkit
http://xmlstar.sourceforge.net/
 
 
 

---
Outgoing mail=20 is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: = 6.0.522 /=20 Virus Database: 320 - Release Date: = 9/29/2003
------=_NextPart_000_001A_01C38D37.E8D5A8A0-- From stephane.bidoul@softwareag.com Wed Oct 8 03:54:37 2003 Return-Path: Delivered-To: xml@gnome.org Received: from server8a.software-ag.de (server8a.software-ag.de [193.26.193.47]) by mail.gnome.org (Postfix) with ESMTP id ED2D6183B3 for ; Wed, 8 Oct 2003 03:54:36 -0400 (EDT) Received: from acsesbi by server8a.software-ag.de; (8.11.6/8.9.3) id h987slF09423; Wed, 8 Oct 2003 09:54:47 +0200 From: "Stéphane Bidoul" To: "'Ed Day'" Cc: Subject: RE: [xml] Differences in DOM parsing on Windows and UNIX? Date: Wed, 8 Oct 2003 09:48:55 +0200 Message-ID: <007101c38d71$7ae450f0$3614200a@acsesbi> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <029101c38cd7$2b5083a0$483e0942@objsys1> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: > Hi Stephane, > > As far as I know, I only have a main thread in my program. It is not > multi-threaded. But "xmlKeepBlanksDefault(0)" did not turn > off blanks in > the main thread. That's strange. Can you come up with a short program that illustrates the issue? Thanks. -sbi From stephane.bidoul@softwareag.com Wed Oct 8 04:11:16 2003 Return-Path: Delivered-To: xml@gnome.org Received: from server8a.software-ag.de (server8a.software-ag.de [193.26.193.47]) by mail.gnome.org (Postfix) with ESMTP id 6B45F181AC for ; Wed, 8 Oct 2003 04:11:15 -0400 (EDT) Received: from acsesbi by server8a.software-ag.de; (8.11.6/8.9.3) id h988BQF11617; Wed, 8 Oct 2003 10:11:26 +0200 From: "Stéphane Bidoul" To: "'Ed Day'" Cc: Subject: RE: [xml] Differences in DOM parsing on Windows and UNIX? Date: Wed, 8 Oct 2003 10:11:39 +0200 Message-ID: <007601c38d73$ce572940$3614200a@acsesbi> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <02e201c38cdd$a2714860$483e0942@objsys1> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: > As a follow-up, I do not see why this logic cannot be embedded in > xmlKeepBlanksDefault: > > int > xmlKeepBlanksDefault(int val) { > int old = xmlKeepBlanksDefaultValue; > > xmlKeepBlanksDefaultValue = val; > xmlIndentTreeOutput = !val; > > /* add this here.. */ > #ifdef LIBXML_THREAD_ENABLED > xmlThrDefKeepBlanksDefaultValue(val); > #endif > > return(old); > } > > Is there any use case where it would make sense for the value to be > different in the main thread then in the newly created threads? Maybe, maybe not. In any case, that would change the behaviour of the API. I raised a similar issue, for different reasons... and I ended up implementing the xmlThrDefXXX because that was what the community favoured. -sbi From alfred.mickautsch@schuler-ag.com Wed Oct 8 04:38:31 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail-relay1 (mail-relay1.schuler-ag.com [62.156.183.20]) by mail.gnome.org (Postfix) with ESMTP id 7B8D618288 for ; Wed, 8 Oct 2003 04:38:31 -0400 (EDT) Received: from sbs-proxy-test.schuler-ag.com ([192.168.16.254]) by mail-relay1 with Microsoft SMTPSVC(6.0.3790.0); Wed, 8 Oct 2003 10:42:41 +0200 Received: from mail pickup service by sbs-proxy-test.schuler-ag.com with Microsoft SMTPSVC; Wed, 8 Oct 2003 10:38:44 +0200 x-gfisavedcharset: iso-8859-1 Content-Type: text/plain; charset="iso-8859-1" Received: from pandora.schuler-ag.com ([192.168.16.20]) by sbs-proxy-test.schuler-ag.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 8 Oct 2003 10:38:42 +0200 Content-Class: urn:content-classes:message Subject: AW: AW: [xml] xmlTextWriter MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Date: Wed, 8 Oct 2003 10:38:42 +0200 Message-ID: <4F38C8B9DAB1014DBDCB29538BBFD6A12E4E7B@pandora.schuler-ag.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [xml] xmlTextWriter thread-index: AcOM2UofUnXY5wtbQ6itKYYdz11yowADNJuA From: "Mickautsch, Alfred" To: X-OriginalArrivalTime: 08 Oct 2003 08:38:42.0314 (UTC) FILETIME=[942D7EA0:01C38D77] Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: > > Okay, can we get a merged version ? Pick the best of both,=20 > > assemble it put both of you as Copyright owners and we will=20 > > integrate this, okay ? >=20 > I'm all for that option :) I haven't had time to have a=20 > proper look at your=20 > version yet, so can't say yet which parts should be used from which :) Ok with me. >=20 > I like my api on the xml writer better cause that's the one=20 > I'm already using=20 > in my own programs using the xml writer ^-^ This is only normal. I'm thinking the same about my implementation :-)) >=20 > But that's easy to change really :) >=20 > Like I said I was also waiting for some patches, would like=20 > to get those in=20 > before any integrating :) I can wait :-) >=20 > I still think we need a cvs somewhere for this thing btw. ^.^ >=20 > > > I even found a bug that we share in our code (I think it's a > > > bug): the xmlTextWriter allows for multiple xml prologs=20 > in the same > > > document (you can call xmlTextWriterWriteStartDocument=20 > after calling > > > xmlTextWriterWriteEndDocument), which in my opinion does=20 > not conform > > > with the xml standard. > >=20 > > Hum, the big problem is that if you serialize multiple documents > > on a single stream, an XML parser reading it has no way to=20 > detect the > > end of a document. This open the door to more troubles then it's > > useful IMHO. >=20 > I basicly just followed the .net specification I think :)=20 > which seems to=20 > allow it, but I'm not sure of that :) I checked it with http://www.w3.org/TR/REC-xml and it seems to me that it is as I said. > Yup, read what I wrote on the topic ^-^ Done :-) >=20 > So, lets see if we can come up with an integrating scheme ? :) > If you think you can get any good bits from my code and make=20 > a single version=20 > with that that'll be fine with me too :) Let's try. >=20 > From a quick look I believe you didn't have arguments=20 > implemented yet ? Did you mean attributes? In that case I did implement them (the = functions called xmlTextWriterWriteProp and so on). >=20 > Was interesting to see you did printf like functions btw. :)=20 > are those safe=20 > for overflows and such ? They use vsnprintf internally, so they are safe for buffer overflows. I = did a little searching and found out that vsnprintf isn't very portable = (different implementations return different values for the same errors). = So I will have to fix that. Output truncating if the buffer is too small is still a problem, so I = will have to call vsnprintf in a loop until it returns a value less than = the size of the buffer. And if vsnprintf returns a negative value, errno should be checked, of = course... you never know what errors you can get :-( >=20 > does any other part oflixml use printf like functions anyways ? I saw an xmlStrPrintf mentioned on the list not so long ago (obviously) = :) Servus -- Alfred From veillard@redhat.com Wed Oct 8 04:47:30 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 2C59F182B6 for ; Wed, 8 Oct 2003 04:47:30 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h988lgQ06376; Wed, 8 Oct 2003 04:47:42 -0400 Date: Wed, 8 Oct 2003 04:47:42 -0400 From: Daniel Veillard To: "Mickautsch, Alfred" Cc: xml@gnome.org Subject: Re: AW: AW: [xml] xmlTextWriter Message-ID: <20031008044742.R31459@redhat.com> Reply-To: veillard@redhat.com References: <4F38C8B9DAB1014DBDCB29538BBFD6A12E4E7B@pandora.schuler-ag.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <4F38C8B9DAB1014DBDCB29538BBFD6A12E4E7B@pandora.schuler-ag.com>; from alfred.mickautsch@schuler-ag.com on Wed, Oct 08, 2003 at 10:38:42AM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, Oct 08, 2003 at 10:38:42AM +0200, Mickautsch, Alfred wrote: > > Was interesting to see you did printf like functions btw. :) > > are those safe > > for overflows and such ? > > They use vsnprintf internally, so they are safe for buffer overflows. I did a little searching and found out that vsnprintf isn't very portable (different implementations return different values for the same errors). So I will have to fix that. > Output truncating if the buffer is too small is still a problem, so I will have to call vsnprintf in a loop until it returns a value less than the size of the buffer. > And if vsnprintf returns a negative value, errno should be checked, of course... you never know what errors you can get :-( > > > > > does any other part oflixml use printf like functions anyways ? > > I saw an xmlStrPrintf mentioned on the list not so long ago (obviously) :) We use the TRIO set of *printf reimplementation for platforms where they are not available. So there should be no portability issues, it's already dealt with. I'm not sure what your problems are in practice. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From alfred.mickautsch@schuler-ag.com Wed Oct 8 05:12:43 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail-relay1 (mail-relay1.schuler-ag.com [62.156.183.20]) by mail.gnome.org (Postfix) with ESMTP id 5158E183C7 for ; Wed, 8 Oct 2003 05:12:43 -0400 (EDT) Received: from sbs-proxy-test.schuler-ag.com ([192.168.16.254]) by mail-relay1 with Microsoft SMTPSVC(6.0.3790.0); Wed, 8 Oct 2003 11:16:53 +0200 Received: from mail pickup service by sbs-proxy-test.schuler-ag.com with Microsoft SMTPSVC; Wed, 8 Oct 2003 11:12:56 +0200 x-gfisavedcharset: iso-8859-1 Content-Type: text/plain; charset="iso-8859-1" Received: from pandora.schuler-ag.com ([192.168.16.20]) by sbs-proxy-test.schuler-ag.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 8 Oct 2003 11:12:53 +0200 Content-Class: urn:content-classes:message Subject: AW: AW: AW: [xml] xmlTextWriter MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Date: Wed, 8 Oct 2003 11:12:53 +0200 Message-ID: <4F38C8B9DAB1014DBDCB29538BBFD6A12E4E7C@pandora.schuler-ag.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: AW: [xml] xmlTextWriter thread-index: AcONeNgrhhoVeAfjTlKa4wqvJbx2gwAAvaJw From: "Mickautsch, Alfred" To: X-OriginalArrivalTime: 08 Oct 2003 09:12:53.0294 (UTC) FILETIME=[5AA834E0:01C38D7C] Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: > -----Urspr=FCngliche Nachricht----- > Von: Daniel Veillard [mailto:veillard@redhat.com] ... >=20 > We use the TRIO set of *printf reimplementation for platforms where > they are not available. So there should be no portability issues, it's > already dealt with. I'm not sure what your problems are in practice. >=20 The problem is not with platforms where the *printf functions are not = available, but with those on which they exist. For example see the difference between the ANSI C language C9X draft and = the M$ documentation: C9X: [#3] The vsnprintf function returns the number of characters that would have been written had n been sufficiently large, not counting the terminating null character, or a negative value if an encoding error occurred. Thus, the null- terminated output has been completely written if and only if the returned value is nonnegative and less than n. M$: _vsnprintf and _vsnwprintf return the number of characters written, not = including the terminating null character, or a negative value if an = output error occurs. For _vsnprintf, if the number of bytes to write = exceeds buffer, then count bytes are written and -1 is returned. See what I mean? And there exist other variations too. Servus -- Alfred From veillard@redhat.com Wed Oct 8 06:37:17 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id CFE92186B5 for ; Wed, 8 Oct 2003 06:37:16 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h98AbTf10741; Wed, 8 Oct 2003 06:37:29 -0400 Date: Wed, 8 Oct 2003 06:37:29 -0400 From: Daniel Veillard To: "Mickautsch, Alfred" Cc: xml@gnome.org Subject: Re: AW: AW: AW: [xml] xmlTextWriter Message-ID: <20031008063729.T31459@redhat.com> Reply-To: veillard@redhat.com References: <4F38C8B9DAB1014DBDCB29538BBFD6A12E4E7C@pandora.schuler-ag.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <4F38C8B9DAB1014DBDCB29538BBFD6A12E4E7C@pandora.schuler-ag.com>; from alfred.mickautsch@schuler-ag.com on Wed, Oct 08, 2003 at 11:12:53AM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, Oct 08, 2003 at 11:12:53AM +0200, Mickautsch, Alfred wrote: > M$: > _vsnprintf and _vsnwprintf return the number of characters written, not including the terminating null character, or a negative value if an output error occurs. For _vsnprintf, if the number of bytes to write exceeds buffer, then count bytes are written and -1 is returned. > > See what I mean? And there exist other variations too. yes, that's called a broken infrastructure... get a real vsnprintf, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From crandonkphin@tursiops.org Wed Oct 8 06:03:01 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail.tursiops.org (wsip-68-14-223-108.ph.ph.cox.net [68.14.223.108]) by mail.gnome.org (Postfix) with ESMTP id E403218542 for ; Wed, 8 Oct 2003 06:03:00 -0400 (EDT) Received: from www.tursiops.org (localhost [127.0.0.1]) by mail.tursiops.org (8.12.8/8.12.8) with ESMTP id h999595k003475; Thu, 9 Oct 2003 02:05:11 -0700 From: "Jeroen Crandonk" To: "Mickautsch, Alfred" , Subject: Re: AW: AW: [xml] xmlTextWriter Date: Thu, 9 Oct 2003 11:05:09 +0100 Message-Id: <20031009090038.M83967@www.tursiops.org> In-Reply-To: <4F38C8B9DAB1014DBDCB29538BBFD6A12E4E7B@pandora.schuler-ag.com> References: <4F38C8B9DAB1014DBDCB29538BBFD6A12E4E7B@pandora.schuler-ag.com> X-Mailer: Open WebMail 2.10 20030927 X-OriginatingIP: 193.67.10.106 (crandonkphin) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: ---------- Original Message ----------- From: "Mickautsch, Alfred" > > > > From a quick look I believe you didn't have arguments > > implemented yet ? > > Did you mean attributes? In that case I did implement them (the > functions called xmlTextWriterWriteProp and so on). > Yes, I meant attributes, didn't recofnize the WriteProp function cause I called it differently I think :) I do suggest you follow the naming scheme from the .NET API the xmlReader and writer are based upon, you can find the urls to it in the text file I put at: http://dolphin.student.utwente.nl/xmlwriter/xmlwriter.txt Or just look at: http://dotgnu.org/pnetlib-doc/ http://dotgnu.org/pnetlib-doc/System/Xml/XmlWriter.html http://dotgnu.org/pnetlib-doc/System/Xml/XmlTextWriter.html This to keep things consistent :) I believe they use StartAttribute etc. instead of WriteProp there :) Greets, Jeroen Cranendonk From ovz@yahoo.com Wed Oct 8 18:06:17 2003 Return-Path: Delivered-To: xml@gnome.org Received: from web11603.mail.yahoo.com (web11603.mail.yahoo.com [216.136.172.55]) by mail.gnome.org (Postfix) with SMTP id 42B6E18102 for ; Wed, 8 Oct 2003 18:06:17 -0400 (EDT) Message-ID: <20031008220630.3563.qmail@web11603.mail.yahoo.com> Received: from [81.17.128.210] by web11603.mail.yahoo.com via HTTP; Wed, 08 Oct 2003 15:06:30 PDT Date: Wed, 8 Oct 2003 15:06:30 -0700 (PDT) From: "Oleg V. Zhilin" To: xml@gnome.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [xml] Linker problem for static lib for win32 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi all, I've created win32 build of libxml2-2.5.11 for VS.NET myself. The only problem, I'm expriencing constantly is linker's warning, seemingly harmless one CommonFileManager1.obj : warning LNK4049: locally defined symbol _xmlFree imported Does anybody know how to work it around? ===== WBR Oleg V. Zhilin ovz@yahoo.com __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com From shaunm@gnome.org Wed Oct 8 20:22:09 2003 Return-Path: Delivered-To: xml@gnome.org Received: from wolfram.com (wri-dns0.wolfram.com [140.177.205.10]) by mail.gnome.org (Postfix) with ESMTP id C19451842B for ; Wed, 8 Oct 2003 20:22:08 -0400 (EDT) Received: from shaunmlx.wolfram.com (shaunmlx.wolfram.com [140.177.4.220]) by wolfram.com (8.11.2/8.11.2) with ESMTP id h990MKo22526; Wed, 8 Oct 2003 19:22:21 -0500 Subject: Re: [xml] Call to libxml developers From: Shaun McCance To: Mikhail Grushinskiy Cc: xml@gnome.org In-Reply-To: <001d01c38d59$7042fd30$8f00a8c0@cc711577a> References: <001d01c38d59$7042fd30$8f00a8c0@cc711577a> Content-Type: text/plain Message-Id: <1065658940.27558.11.camel@shaunmlx.wolfram.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 08 Oct 2003 19:22:20 -0500 Content-Transfer-Encoding: 7bit Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi Mikhael, I've had similar code for the last couple of months, and it's just incredibly useful. I've been meaning to polish it and package it for public consumption, but I haven't had the time. Since it seems you've already managed to package up something release-worthy, there's no need for me to duplicate the effort. As I have time, I'll hack useful features in and fix any bugs that might be annoying me. I can't really commit myself to the project, since I'm already pretty busy with GNOME stuff. But you can anticipate a couple of evening code-binges worth of patches from me. Thanks for you work. This sort of thing is desperately needed. -- Shaun On Wed, 2003-10-08 at 00:02, Mikhail Grushinskiy wrote: > Hello gentlemen, > > Thank you for great work on libxml2/libxslt! Really good job! > I'm using libxml2/libxslt for quite a while now and it is very > impressive library. > > I'm hosting my little open source pet project on SourceForge. > It is a general purpose command-line XML utility for > searching/editing/validating XML documents. > It is based on libxml2/libxslt and written in C. Here is a link > http://xmlstar.sourceforge.net/ > (and http://sourceforge.net/projects/xmlstar/) > > So far I'm writting it on my free time, so this project needs help :). > I thought I might look for somebody on this list with libxml > expertise, > who might like the idea and would be interested to help working on > something like this. > Here is a link to some documentation which gives more details what > this project is about > http://xmlstar.sourceforge.net/doc/xmlstarlet.pdf There are also many > other features > which would be nice to have in it (ex: XML diff, XML patch, etc) > > Your help is very much welcome! Let me know if you are interested to > join... > Any other comments are welcome too :). > > Thanks, > --Mikhail Grushinskiy > > XmlStarlet Command-Line XML Toolkit > http://xmlstar.sourceforge.net/ > > > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.522 / Virus Database: 320 - Release Date: 9/29/2003 From Mark_Vakoc@jdedwards.com Thu Oct 9 00:23:44 2003 Return-Path: Delivered-To: xml@gnome.org Received: from ns1.jdedwards.com (ns1.jdedwards.com [199.166.248.147]) by mail.gnome.org (Postfix) with ESMTP id B2DC11846A for ; Thu, 9 Oct 2003 00:23:43 -0400 (EDT) Received: from denvscans3.jdedwards.com ([10.0.14.77]) by ns1.jdedwards.com (8.11.6/8.9.1) with SMTP id h994Nus02142; Wed, 8 Oct 2003 22:23:56 -0600 Received: from 10.0.14.87 by denvscans3.jdedwards.com (InterScan E-Mail VirusWall NT); Wed, 08 Oct 2003 22:23:56 -0600 Received: from denmails3.jdedwards.com ([10.0.14.80]) by densmtps1.jdedwards.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 8 Oct 2003 22:23:56 -0600 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [xml] Linker problem for static lib for win32 Date: Wed, 8 Oct 2003 22:23:55 -0600 Message-ID: <09B3671D58690A4193A7F8F15F416B23FF2789@denmails3.jdedwards.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [xml] Linker problem for static lib for win32 Thread-Index: AcON68jD5kJquHrjTX6AL3rqTHb1lgAMQHmg From: "Vakoc, Mark" To: "Oleg V. Zhilin" , X-OriginalArrivalTime: 09 Oct 2003 04:23:56.0206 (UTC) FILETIME=[275C44E0:01C38E1D] Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Well I've had this same warning with VC 6 for years (probably literally) and it hasn't caused any problems so I've simply ignored it. Check how xmlFree is declared but I can attest to things performing as intended even with the warning. I also get the error on xmlMalloc (probably xmlRealloc too but I don't use that in my code). Good answer, huh!? -----Original Message----- From: Oleg V. Zhilin [mailto:ovz@yahoo.com]=20 Sent: Wednesday, October 08, 2003 4:07 PM To: xml@gnome.org Subject: [xml] Linker problem for static lib for win32 Hi all, I've created win32 build of libxml2-2.5.11 for VS.NET myself. The only problem, I'm expriencing constantly is linker's warning, seemingly harmless one CommonFileManager1.obj : warning LNK4049: locally defined symbol _xmlFree imported Does anybody know how to work it around? =3D=3D=3D=3D=3D WBR Oleg V. Zhilin ovz@yahoo.com __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com _______________________________________________ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml From mh@glandium.org Thu Oct 9 00:43:03 2003 Return-Path: Delivered-To: xml@gnome.org Received: from vaio.glandium.org (i61-195-247-171.us.catvmics.ne.jp [61.195.247.171]) by mail.gnome.org (Postfix) with ESMTP id 7C63D181EA for ; Thu, 9 Oct 2003 00:42:57 -0400 (EDT) Received: from localhost ([127.0.0.1]) by vaio.glandium.org with esmtp (Exim 3.36 #1 (Debian)) id 1A7SdZ-0000KD-00 for ; Thu, 09 Oct 2003 13:42:53 +0900 From: Mike Hommey Organization: glandium To: Date: Wed, 8 Oct 2003 19:58:13 +0900 User-Agent: KMail/1.5.3 MIME-Version: 1.0 Message-Id: <200310081931.32279.mh@glandium.org> Content-Type: Multipart/Mixed; boundary="Boundary-00=_F3+g/X7XTQqiWeu" Subject: [xml] Autotools stuff in libxml2 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: --Boundary-00=_F3+g/X7XTQqiWeu Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi libxml2 developpers, I'm the new maintainer of the libxml2 package for the Debian GNU/Linux=20 distribution and would have a tiny little request before release of libxml2. It would be nice to somewhat update autotools stuff by doing the following : =2D Rename configure.in to configure.ac (configure.in is deprecated in late= st=20 versions of autoconf) =2D Remove acconfig.h (acconfig.h is deprecated in latest versions of autoc= onf) =2D Apply the attached patch to configure.ac (to "fix" the "lack" of acconf= ig.h) =2D Run autoreconf (latest version preferred) =2D Run automake (latest version preferred) =2D Run libtoolize --force (latest version preferred) At least, a libtoolize --force would be appreciable, because latest version= s=20 of libtools fix some detection breakage on some "unusual" architecture, and= =20 that will prevent me to have to do it on my side ;) Thanks Mike PS: BTW, are you aware of the tons of "comparison is always (true|false) du= e=20 to limited range of data type" warnings when compiling with all warnings=20 enabled ? =2D-=20 "I have sampled every language, french is my favorite. Fantastic language, especially to curse with. Nom de dieu de putain de bordel de merde de saloperie de connard d'encul=E9 de ta m=E8re. It's like wiping your ass with silk! I love it." -- The Merovingian, in the Matrix Reloaded --Boundary-00=_F3+g/X7XTQqiWeu Content-Type: text/x-diff; charset="iso-8859-1"; name="configure.ac.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="configure.ac.patch" --- ../libxml2-2.6.0beta3.orig/configure.in 2003-09-25 21:37:20.000000000 +0900 +++ configure.ac 2003-10-08 19:15:31.000000000 +0900 @@ -61,7 +61,7 @@ else AC_CHECK_HEADERS(zlib.h, AC_CHECK_LIB(z, gzread,[ - AC_DEFINE(HAVE_LIBZ) + AC_DEFINE([HAVE_LIBZ], [], [Have compression library]) if test "x${Z_DIR}" != "x"; then Z_CFLAGS="-I${Z_DIR}/include" Z_LIBS="-L${Z_DIR}/lib -lz" @@ -191,7 +191,7 @@ AC_MSG_RESULT(int *) SOCKLEN_T=int],[ AC_MSG_WARN(could not determine)])])]) -AC_DEFINE_UNQUOTED(SOCKLEN_T, $SOCKLEN_T) +AC_DEFINE_UNQUOTED(SOCKLEN_T, $SOCKLEN_T, [Determine what socket length (socklen_t) data type is]) dnl ***********************Checking for availability of IPv6******************* @@ -211,7 +211,7 @@ AC_MSG_RESULT($have_ipv6) if test $have_ipv6 = yes; then - AC_DEFINE(SUPPORT_IP6) + AC_DEFINE([SUPPORT_IP6], [], [Support for IPv6]) have_getaddrinfo=no AC_CHECK_FUNC(getaddrinfo, have_getaddrinfo=yes) @@ -222,7 +222,7 @@ fi if test $have_getaddrinfo = yes; then - AC_DEFINE(HAVE_GETADDRINFO) + AC_DEFINE([HAVE_GETADDRINFO], [], [Define if getaddrinfo is there]) fi fi fi @@ -231,10 +231,10 @@ dnl Checks for isnan in libm if not in libc AC_CHECK_FUNC(isnan, , AC_CHECK_LIB(m, isnan, - [AC_DEFINE(HAVE_ISNAN)])) + [AC_DEFINE([HAVE_ISNAN],[], [Define if isnan is there])])) -AC_CHECK_FUNC(isinf, AC_DEFINE(HAVE_ISINF) , AC_CHECK_LIB(m, isinf, - [AC_DEFINE(HAVE_ISINF)])) +AC_CHECK_FUNC(isinf, AC_DEFINE([HAVE_ISINF], [], [Define if isinf is there]) , AC_CHECK_LIB(m, isinf, + [AC_DEFINE([HAVE_ISINF], [], [Define if isinf is there])])) XML_LIBDIR='-L${libdir}' XML_INCLUDEDIR='-I${includedir}/libxml2' @@ -434,8 +434,8 @@ AC_CHECK_HEADER(pthread.h, AC_CHECK_LIB(pthread, pthread_join,[ THREAD_LIBS="-lpthread" - AC_DEFINE(HAVE_LIBPTHREAD) - AC_DEFINE(HAVE_PTHREAD_H) + AC_DEFINE([HAVE_LIBPTHREAD], [], [Define if pthread library is there (-lpthread)]) + AC_DEFINE([HAVE_PTHREAD_H], [], [Define if is there]) WITH_THREADS="1"])) if test "$WITH_THREADS" = "1" ; then @@ -469,11 +469,11 @@ AC_CHECK_HEADER(readline/history.h, AC_CHECK_LIB(history, append_history,[ RDL_LIBS="-lhistory" - AC_DEFINE(HAVE_LIBHISTORY)])) + AC_DEFINE([HAVE_LIBHISTORY], [], [Define if history library is there (-lhistory)])])) AC_CHECK_HEADER(readline/readline.h, AC_CHECK_LIB(readline, readline,[ RDL_LIBS="-lreadline $RDL_LIBS $tcap" - AC_DEFINE(HAVE_LIBREADLINE)], , $tcap)) + AC_DEFINE([HAVE_LIBREADLINE], [], [Define if readline library is there (-lreadline)])], , $tcap)) if test -n "$RDL_DIR" -a -n "$RDL_LIBS"; then CPPFLAGS="$CPPFLAGS -I${RDL_DIR}/include" RDL_LIBS="-L${RDL_DIR}/lib $RDL_LIBS" --Boundary-00=_F3+g/X7XTQqiWeu-- From mgrushinskiy@comcast.net Thu Oct 9 01:09:58 2003 Return-Path: Delivered-To: xml@gnome.org Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mail.gnome.org (Postfix) with ESMTP id 7471B181EA; Thu, 9 Oct 2003 01:09:58 -0400 (EDT) Received: from cc711577a (bgp535056bgs.ebrnsw01.nj.comcast.net[68.38.116.126]) by comcast.net (sccrmhc13) with SMTP id <2003100905101201600a8epge>; Thu, 9 Oct 2003 05:10:12 +0000 Message-ID: <008201c38e23$a2257830$8f00a8c0@cc711577a> From: "Mikhail Grushinskiy" To: "Shaun McCance" Cc: References: <001d01c38d59$7042fd30$8f00a8c0@cc711577a> <1065658940.27558.11.camel@shaunmlx.wolfram.com> Subject: Re: [xml] Call to libxml developers Date: Thu, 9 Oct 2003 01:10:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Thanks, Shaun. Perfect! Please, join XmlStarlet mailing list (low activity) http://lists.sourceforge.net/lists/listinfo/xmlstar-devel so we can discuss it there. You can also use SourceForge forums http://sourceforge.net/forum/?group_id=66612 or e-mail me directly. --Mikhail ----- Original Message ----- From: "Shaun McCance" To: "Mikhail Grushinskiy" Cc: Sent: Wednesday, October 08, 2003 8:22 PM Subject: Re: [xml] Call to libxml developers > Hi Mikhael, > > I've had similar code for the last couple of months, and it's just > incredibly useful. I've been meaning to polish it and package it for > public consumption, but I haven't had the time. Since it seems you've > already managed to package up something release-worthy, there's no need > for me to duplicate the effort. > > As I have time, I'll hack useful features in and fix any bugs that might > be annoying me. I can't really commit myself to the project, since I'm > already pretty busy with GNOME stuff. But you can anticipate a couple > of evening code-binges worth of patches from me. > > Thanks for you work. This sort of thing is desperately needed. > > -- > Shaun > > On Wed, 2003-10-08 at 00:02, Mikhail Grushinskiy wrote: > > Hello gentlemen, > > > > Thank you for great work on libxml2/libxslt! Really good job! > > I'm using libxml2/libxslt for quite a while now and it is very > > impressive library. > > > > I'm hosting my little open source pet project on SourceForge. > > It is a general purpose command-line XML utility for > > searching/editing/validating XML documents. > > It is based on libxml2/libxslt and written in C. Here is a link > > http://xmlstar.sourceforge.net/ > > (and http://sourceforge.net/projects/xmlstar/) > > > > So far I'm writting it on my free time, so this project needs help :). > > I thought I might look for somebody on this list with libxml > > expertise, > > who might like the idea and would be interested to help working on > > something like this. > > Here is a link to some documentation which gives more details what > > this project is about > > http://xmlstar.sourceforge.net/doc/xmlstarlet.pdf There are also many > > other features > > which would be nice to have in it (ex: XML diff, XML patch, etc) > > > > Your help is very much welcome! Let me know if you are interested to > > join... > > Any other comments are welcome too :). > > > > Thanks, > > --Mikhail Grushinskiy > > > > XmlStarlet Command-Line XML Toolkit > > http://xmlstar.sourceforge.net/ > > > > > > > > --- > > Outgoing mail is certified Virus Free. > > Checked by AVG anti-virus system (http://www.grisoft.com). > > Version: 6.0.522 / Virus Database: 320 - Release Date: 9/29/2003 > > _______________________________________________ > xml mailing list, project page http://xmlsoft.org/ > xml@gnome.org > http://mail.gnome.org/mailman/listinfo/xml --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.524 / Virus Database: 321 - Release Date: 10/6/2003 From aleksey@aleksey.com Thu Oct 9 02:25:57 2003 Return-Path: Delivered-To: xml@gnome.org Received: from shell.aleksey.com (dsl081-246-064.sfo1.dsl.speakeasy.net [64.81.246.64]) by mail.gnome.org (Postfix) with ESMTP id D94A118157 for ; Thu, 9 Oct 2003 02:25:56 -0400 (EDT) Received: from aleksey.com (unknown [192.168.1.63]) by shell.aleksey.com (Postfix) with ESMTP id 16C0AB5BD; Wed, 8 Oct 2003 23:26:10 -0700 (PDT) Message-ID: <3F84FF7F.8080003@aleksey.com> Date: Wed, 08 Oct 2003 23:26:07 -0700 From: Aleksey Sanin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, ru MIME-Version: 1.0 To: Mike Hommey Cc: xml@gnome.org Subject: Re: [xml] Autotools stuff in libxml2 References: <200310081931.32279.mh@glandium.org> In-Reply-To: <200310081931.32279.mh@glandium.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Mike, I understand that you would like to bring LibXML2 to the latest and greatest autotools but what are the minimum autotools versions that support all these changes? I think that it would be very sad if as a result of this LibXML2 would not compile on older systems. I would suggest to carefully evaluate the tradeoffs before doing this change. Aleksey >It would be nice to somewhat update autotools stuff by doing the following : > > > .... From wbrack@mmm.com.hk Thu Oct 9 03:21:37 2003 Return-Path: Delivered-To: xml@gnome.org Received: from delightful.com.hk (adsl-63-204-84-206.dsl.sktn01.pacbell.net [63.204.84.206]) by mail.gnome.org (Postfix) with ESMTP id C6295184B4 for ; Thu, 9 Oct 2003 03:21:35 -0400 (EDT) Received: from delightful.com.hk (localhost [127.0.0.1]) by delightful.com.hk (8.12.9/8.12.9) with SMTP id h997LnVq032317 for ; Thu, 9 Oct 2003 00:21:49 -0700 Received: from 219.78.248.9 (SquirrelMail authenticated user wbrack) by www.delightful.com.hk with HTTP; Thu, 9 Oct 2003 15:21:49 +0800 (HKT) Message-ID: <4031.219.78.248.9.1065684109.squirrel@www.delightful.com.hk> In-Reply-To: <3F84FF7F.8080003@aleksey.com> References: <200310081931.32279.mh@glandium.org> <3F84FF7F.8080003@aleksey.com> Date: Thu, 9 Oct 2003 15:21:49 +0800 (HKT) Subject: Re: [xml] Autotools stuff in libxml2 From: "William M. Brack" To: xml@gnome.org User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Aleksey Sanin said: > Mike, > > I understand that you would like to bring LibXML2 to the latest and > greatest autotools > but what are the minimum autotools versions that support all these > changes? > I think that it would be very sad if as a result of this LibXML2 > would > not compile on older > systems. I would suggest to carefully evaluate the tradeoffs before > doing this change. > > > Aleksey > >>It would be nice to somewhat update autotools stuff by doing the >> following : >> >> >> .... I am also a strong supporter of going with the latest and greatest, but Aleksey's point is a good one. Of course, there must be some limits to how long the library must cater for older versions of the auto* routines. At the moment, I believe we are trying to at least maintain compatibility with autoconf-2.13 and automake-1.4. Mike, could you save me a little time and let me know which of your requested changes would maintain compatibility within that constraint? Also, with regard to your "P.S.", I don't get any such warnings on my system (x86 gentoo, gcc-3.2.3), but I seem to remember seeing some on either the Alpha or the HP, because of the way some validation macros check for unicode even though the argument is an unsigned char. Which library version are you referring to, which compiler, and which architecture? Also, what compiler flags are you using (when testing I'm using -g -O -pedantic -W -Wunused -Wimplicit -Wreturn-type -Wswitch -Wcomment -Wtrigraphs -Wformat -Wchar-subscripts -Wuninitialized -Wparentheses -Wshadow -Wpointer-arith -Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wredundant-decls)? Regards, Bill From mh@glandium.org Thu Oct 9 03:22:02 2003 Return-Path: Delivered-To: xml@gnome.org Received: from vaio.glandium.org (unknown [202.215.53.66]) by mail.gnome.org (Postfix) with ESMTP id 8213C184B4 for ; Thu, 9 Oct 2003 03:22:01 -0400 (EDT) Received: from localhost ([127.0.0.1]) by vaio.glandium.org with esmtp (Exim 3.36 #1 (Debian)) id 1A7V7b-0006Ft-00 for ; Thu, 09 Oct 2003 16:22:03 +0900 From: Mike Hommey Organization: glandium To: xml@gnome.org Subject: Re: [xml] Autotools stuff in libxml2 Date: Thu, 9 Oct 2003 16:22:01 +0900 User-Agent: KMail/1.5.3 References: <200310081931.32279.mh@glandium.org> <3F84FF7F.8080003@aleksey.com> In-Reply-To: <3F84FF7F.8080003@aleksey.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200310091622.01694.mh@glandium.org> Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thursday 09 October 2003 15:26, Aleksey Sanin wrote: > Mike, > > I understand that you would like to bring LibXML2 to the latest and > greatest autotools > but what are the minimum autotools versions that support all these change= s? > I think that it would be very sad if as a result of this LibXML2 would > not compile on older > systems. > I would suggest to carefully evaluate the tradeoffs before > doing this change. You can still run the autoreconf and libtoolize without updating configure.= in=20 nor removing acconfig.h, autoreconf will only complain about founding some= =20 old deprecated stuff, but will still handle it. OTOH (and fortunately), you don't need autotools to be installed on the=20 machine you build libxml2 on, so it is not a problem, except if someone tri= es=20 to hack configure.ac a bit, which is not supposed to be happening every day= ,=20 or more precisely, i don't see any reason for someone hacking a configure.a= c=20 not to use the appropriate version of autoconf. As I said in my mail, at least libtoolize would be a good thing (it is usua= lly=20 a good thing to run it sometimes to update config.guess and others); the=20 other stuff is only an extra. BTW, libtoolize --force --copy could be preferrable to libtoolize --force, = it=20 will copy config.guess and others, instead of linking to the system ones=20 (which is not really a problem by itself, but may be annoying for cvs=20 commiting). Regards Mike =2D-=20 "I have sampled every language, french is my favorite. Fantastic language, especially to curse with. Nom de dieu de putain de bordel de merde de saloperie de connard d'encul=E9 de ta m=E8re. It's like wiping your ass with silk! I love it." -- The Merovingian, in the Matrix Reloaded From mh@glandium.org Thu Oct 9 03:58:38 2003 Return-Path: Delivered-To: xml@gnome.org Received: from vaio.glandium.org (unknown [202.215.53.66]) by mail.gnome.org (Postfix) with ESMTP id 7E3F718401 for ; Thu, 9 Oct 2003 03:58:38 -0400 (EDT) Received: from localhost ([127.0.0.1]) by vaio.glandium.org with esmtp (Exim 3.36 #1 (Debian)) id 1A7Vh3-0006M0-00 for ; Thu, 09 Oct 2003 16:58:41 +0900 From: Mike Hommey Organization: glandium To: xml@gnome.org Subject: Re: [xml] Autotools stuff in libxml2 Date: Thu, 9 Oct 2003 16:58:41 +0900 User-Agent: KMail/1.5.3 References: <200310081931.32279.mh@glandium.org> <3F84FF7F.8080003@aleksey.com> <4031.219.78.248.9.1065684109.squirrel@www.delightful.com.hk> In-Reply-To: <4031.219.78.248.9.1065684109.squirrel@www.delightful.com.hk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200310091658.41378.mh@glandium.org> Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thursday 09 October 2003 16:21, William M. Brack wrote: > I am also a strong supporter of going with the latest and greatest, > but Aleksey's point is a good one. Of course, there must be some > limits to how long the library must cater for older versions of the > auto* routines. At the moment, I believe we are trying to at least > maintain compatibility with autoconf-2.13 and automake-1.4. > > Mike, could you save me a little time and let me know which of your > requested changes would maintain compatibility within that > constraint? I'll come back to you when I'll have time to take a look into it. > Also, with regard to your "P.S.", I don't get any such warnings on > my system (x86 gentoo, gcc-3.2.3), but I seem to remember seeing > some on either the Alpha or the HP, because of the way some > validation macros check for unicode even though the argument is an > unsigned char. Which library version are you referring to, which > compiler, and which architecture? Also, what compiler flags are you > using (when testing I'm using -g -O -pedantic -W -Wunused -Wimplicit > -Wreturn-type -Wswitch -Wcomment -Wtrigraphs -Wformat > -Wchar-subscripts -Wuninitialized -Wparentheses -Wshadow > -Wpointer-arith -Wcast-align -Wwrite-strings -Waggregate-return > -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline > -Wredundant-decls)? =2Dg -O2 -Wall, and I get these warnings on all architectures, including x8= 6. Regards, Mike =2D-=20 "I have sampled every language, french is my favorite. Fantastic language, especially to curse with. Nom de dieu de putain de bordel de merde de saloperie de connard d'encul=E9 de ta m=E8re. It's like wiping your ass with silk! I love it." -- The Merovingian, in the Matrix Reloaded From christop@charm.net Thu Oct 9 16:16:38 2003 Return-Path: Delivered-To: xml@gnome.org Received: from hampden.charm.net (hampden.charm.net [207.114.0.146]) by mail.gnome.org (Postfix) with ESMTP id 3F3F01B592 for ; Thu, 9 Oct 2003 15:51:43 -0400 (EDT) Received: from christop-209.143.91.188.charm.net (christop-209.143.91.188.charm.net [209.143.91.188]) (authenticated bits=0) by hampden.charm.net (8.12.9p2/8.12.9/LNSG+ORDB+SCOP+NJABL+RSL+SBL+DSBL) with ESMTP id h99Jpu90092480; Thu, 9 Oct 2003 15:51:56 -0400 (EDT) (envelope-from christop@charm.net) Subject: Re: [xml] RAW && NXT with strncmp() From: Chris Anderson To: veillard@redhat.com Cc: xml@gnome.org In-Reply-To: <20031006050925.B21001@redhat.com> References: <001901c38822$1a668da0$2964a8c0@kvp> <20031001095055.G21529@redhat.com> <1065026851.2063.31.camel@stellifer> <20031006050925.B21001@redhat.com> Content-Type: multipart/mixed; boundary="=-ti+Xwe1NJgwmY5RWS5m7" Message-Id: <1065729540.27221.87.camel@kayak.charm.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.3.99 (Preview Release) Date: 09 Oct 2003 15:59:00 -0400 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: --=-ti+Xwe1NJgwmY5RWS5m7 Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, 2003-10-06 at 05:09, Daniel Veillard wrote: > On Wed, Oct 01, 2003 at 04:44:14PM +0300, Igor Izvarin wrote: > >For my opinion this change will improve the code readability and > >maintenance, will reduce the source code size and object code size. > > Well I can agree about code lisibility, for maintainance, I'm not > sure as those parts are unlikely to change. And for object code size > and speed this is actually a penalty. > > So I'm not sure I will actually keep that change. I messed with how memcmp works, trying a couple of different things like comparing shorts and integers instead of chars (x86 allows unaligned access w/penalty). All work slightly slower than just comparing chars. I believe the memcmp is slower because it moves the chars from immediate operands to another memory reference. How's this for a compromise, not quite as pretty, but still somewhat readable: ! if (memcmp(CUR_PTR, "input->cur[(val)] #define CUR_PTR ctxt->input->cur + #define CMP4( s, c1, c2, c3, c4 ) \ + ( ((unsigned char *) s)[ 0 ] == c1 && ((unsigned char *) s)[ 1 ] == c2 && \ + ((unsigned char *) s)[ 2 ] == c3 && ((unsigned char *) s)[ 3 ] == c4 ) + #define CMP5( s, c1, c2, c3, c4, c5 ) \ + ( CMP4( s, c1, c2, c3, c4 ) && ((unsigned char *) s)[ 4 ] == c5 ) + #define CMP6( s, c1, c2, c3, c4, c5, c6 ) \ + ( CMP5( s, c1, c2, c3, c4, c5 ) && ((unsigned char *) s)[ 5 ] == c6 ) + #define CMP7( s, c1, c2, c3, c4, c5, c6, c7 ) \ + ( CMP6( s, c1, c2, c3, c4, c5, c6 ) && ((unsigned char *) s)[ 6 ] == c7 ) + #define CMP8( s, c1, c2, c3, c4, c5, c6, c7, c8 ) \ + ( CMP7( s, c1, c2, c3, c4, c5, c6, c7 ) && ((unsigned char *) s)[ 7 ] == c8 ) + #define CMP9( s, c1, c2, c3, c4, c5, c6, c7, c8, c9 ) \ + ( CMP8( s, c1, c2, c3, c4, c5, c6, c7, c8 ) && \ + ((unsigned char *) s)[ 8 ] == c9 ) + #define CMP10( s, c1, c2, c3, c4, c5, c6, c7, c8, c9, c10 ) \ + ( CMP9( s, c1, c2, c3, c4, c5, c6, c7, c8, c9 ) && \ + ((unsigned char *) s)[ 9 ] == c10 ) + #define SKIP(val) do { \ ctxt->nbChars += (val),ctxt->input->cur += (val),ctxt->input->col+=(val); \ if (*ctxt->input->cur == '%') xmlParserHandlePEReference(ctxt); \ *************** *** 1766,1772 **** } if ((entity->etype == XML_EXTERNAL_PARAMETER_ENTITY) && ! (memcmp(CUR_PTR, "etype == XML_EXTERNAL_PARAMETER_ENTITY) && ! (CMP5(CUR_PTR, '<', '?', 'x', 'm', 'l' )) && (IS_BLANK(NXT(5)))) { xmlParseTextDecl(ctxt); } } else { *************** *** 3707,3713 **** SHRINK; *publicID = NULL; ! if (memcmp(CUR_PTR, "SYSTEM", 6) == 0) { SKIP(6); if (!IS_BLANK(CUR)) { xmlFatalErrMsg(ctxt, XML_ERR_SPACE_REQUIRED, --- 3726,3732 ---- SHRINK; *publicID = NULL; ! if (CMP6(CUR_PTR, 'S', 'Y', 'S', 'T', 'E', 'M')) { SKIP(6); if (!IS_BLANK(CUR)) { xmlFatalErrMsg(ctxt, XML_ERR_SPACE_REQUIRED, *************** *** 3718,3724 **** if (URI == NULL) { xmlFatalErr(ctxt, XML_ERR_URI_REQUIRED, NULL); } ! } else if (memcmp(CUR_PTR, "PUBLIC", 6) == 0) { SKIP(6); if (!IS_BLANK(CUR)) { xmlFatalErrMsg(ctxt, XML_ERR_SPACE_REQUIRED, --- 3737,3743 ---- if (URI == NULL) { xmlFatalErr(ctxt, XML_ERR_URI_REQUIRED, NULL); } ! } else if (CMP6(CUR_PTR, 'P', 'U', 'B', 'L', 'I', 'C')) { SKIP(6); if (!IS_BLANK(CUR)) { xmlFatalErrMsg(ctxt, XML_ERR_SPACE_REQUIRED, *************** *** 4115,4121 **** xmlChar *Pubid; xmlChar *Systemid; ! if (memcmp(CUR_PTR, "input; SHRINK; SKIP(10); --- 4134,4140 ---- xmlChar *Pubid; xmlChar *Systemid; ! if (CMP10(CUR_PTR, '<', '!', 'N', 'O', 'T', 'A', 'T', 'I', 'O', 'N')) { xmlParserInputPtr input = ctxt->input; SHRINK; SKIP(10); *************** *** 4194,4200 **** int skipped; GROW; ! if (memcmp(CUR_PTR, "input; SHRINK; SKIP(8); --- 4213,4219 ---- int skipped; GROW; ! if (CMP8(CUR_PTR, '<', '!', 'E', 'N', 'T', 'I', 'T', 'Y')) { xmlParserInputPtr input = ctxt->input; SHRINK; SKIP(8); *************** *** 4332,4338 **** "Space required before 'NDATA'\n"); } SKIP_BLANKS; ! if (memcmp(CUR_PTR, "NDATA", 5) == 0) { SKIP(5); if (!IS_BLANK(CUR)) { xmlFatalErrMsg(ctxt, XML_ERR_SPACE_REQUIRED, --- 4351,4357 ---- "Space required before 'NDATA'\n"); } SKIP_BLANKS; ! if (CMP5(CUR_PTR, 'N', 'D', 'A', 'T', 'A')) { SKIP(5); if (!IS_BLANK(CUR)) { xmlFatalErrMsg(ctxt, XML_ERR_SPACE_REQUIRED, *************** *** 4449,4464 **** xmlChar *ret; *value = NULL; ! if (memcmp(CUR_PTR, "#REQUIRED", 9) == 0) { SKIP(9); return(XML_ATTRIBUTE_REQUIRED); } ! if (memcmp(CUR_PTR, "#IMPLIED", 8) == 0) { SKIP(8); return(XML_ATTRIBUTE_IMPLIED); } val = XML_ATTRIBUTE_NONE; ! if (memcmp(CUR_PTR, "#FIXED", 6) == 0) { SKIP(6); val = XML_ATTRIBUTE_FIXED; if (!IS_BLANK(CUR)) { --- 4468,4483 ---- xmlChar *ret; *value = NULL; ! if (CMP9(CUR_PTR, '#', 'R', 'E', 'Q', 'U', 'I', 'R', 'E', 'D')) { SKIP(9); return(XML_ATTRIBUTE_REQUIRED); } ! if (CMP8(CUR_PTR, '#', 'I', 'M', 'P', 'L', 'I', 'E', 'D')) { SKIP(8); return(XML_ATTRIBUTE_IMPLIED); } val = XML_ATTRIBUTE_NONE; ! if (CMP6(CUR_PTR, '#', 'F', 'I', 'X', 'E', 'D')) { SKIP(6); val = XML_ATTRIBUTE_FIXED; if (!IS_BLANK(CUR)) { *************** *** 4600,4606 **** int xmlParseEnumeratedType(xmlParserCtxtPtr ctxt, xmlEnumerationPtr *tree) { ! if (memcmp(CUR_PTR, "NOTATION", 8) == 0) { SKIP(8); if (!IS_BLANK(CUR)) { xmlFatalErrMsg(ctxt, XML_ERR_SPACE_REQUIRED, --- 4619,4625 ---- int xmlParseEnumeratedType(xmlParserCtxtPtr ctxt, xmlEnumerationPtr *tree) { ! if (CMP8(CUR_PTR, 'N', 'O', 'T', 'A', 'T', 'I', 'O', 'N')) { SKIP(8); if (!IS_BLANK(CUR)) { xmlFatalErrMsg(ctxt, XML_ERR_SPACE_REQUIRED, *************** *** 4665,4692 **** int xmlParseAttributeType(xmlParserCtxtPtr ctxt, xmlEnumerationPtr *tree) { SHRINK; ! if (memcmp(CUR_PTR, "CDATA", 5) == 0) { SKIP(5); return(XML_ATTRIBUTE_CDATA); ! } else if (memcmp(CUR_PTR, "IDREFS", 6) == 0) { SKIP(6); return(XML_ATTRIBUTE_IDREFS); ! } else if (memcmp(CUR_PTR, "IDREF", 5) == 0) { SKIP(5); return(XML_ATTRIBUTE_IDREF); } else if ((RAW == 'I') && (NXT(1) == 'D')) { SKIP(2); return(XML_ATTRIBUTE_ID); ! } else if (memcmp(CUR_PTR, "ENTITY", 6) == 0) { SKIP(6); return(XML_ATTRIBUTE_ENTITY); ! } else if (memcmp(CUR_PTR, "ENTITIES", 8) == 0) { SKIP(8); return(XML_ATTRIBUTE_ENTITIES); ! } else if (memcmp(CUR_PTR, "NMTOKENS", 8) == 0) { SKIP(8); return(XML_ATTRIBUTE_NMTOKENS); ! } else if (memcmp(CUR_PTR, "NMTOKEN", 7) == 0) { SKIP(7); return(XML_ATTRIBUTE_NMTOKEN); } --- 4684,4711 ---- int xmlParseAttributeType(xmlParserCtxtPtr ctxt, xmlEnumerationPtr *tree) { SHRINK; ! if (CMP5(CUR_PTR, 'C', 'D', 'A', 'T', 'A')) { SKIP(5); return(XML_ATTRIBUTE_CDATA); ! } else if (CMP6(CUR_PTR, 'I', 'D', 'R', 'E', 'F', 'S')) { SKIP(6); return(XML_ATTRIBUTE_IDREFS); ! } else if (CMP5(CUR_PTR, 'I', 'D', 'R', 'E', 'F')) { SKIP(5); return(XML_ATTRIBUTE_IDREF); } else if ((RAW == 'I') && (NXT(1) == 'D')) { SKIP(2); return(XML_ATTRIBUTE_ID); ! } else if (CMP6(CUR_PTR, 'E', 'N', 'T', 'I', 'T', 'Y')) { SKIP(6); return(XML_ATTRIBUTE_ENTITY); ! } else if (CMP8(CUR_PTR, 'E', 'N', 'T', 'I', 'T', 'I', 'E', 'S')) { SKIP(8); return(XML_ATTRIBUTE_ENTITIES); ! } else if (CMP8(CUR_PTR, 'N', 'M', 'T', 'O', 'K', 'E', 'N', 'S')) { SKIP(8); return(XML_ATTRIBUTE_NMTOKENS); ! } else if (CMP7(CUR_PTR, 'N', 'M', 'T', 'O', 'K', 'E', 'N')) { SKIP(7); return(XML_ATTRIBUTE_NMTOKEN); } *************** *** 4710,4716 **** const xmlChar *attrName; xmlEnumerationPtr tree; ! if (memcmp(CUR_PTR, "input; SKIP(9); --- 4729,4735 ---- const xmlChar *attrName; xmlEnumerationPtr tree; ! if (CMP9(CUR_PTR, '<', '!', 'A', 'T', 'T', 'L', 'I', 'S', 'T')) { xmlParserInputPtr input = ctxt->input; SKIP(9); *************** *** 4855,4861 **** const xmlChar *elem = NULL; GROW; ! if (memcmp(CUR_PTR, "#PCDATA", 7) == 0) { SKIP(7); SKIP_BLANKS; SHRINK; --- 4874,4880 ---- const xmlChar *elem = NULL; GROW; ! if (CMP7(CUR_PTR, '#', 'P', 'C', 'D', 'A', 'T', 'A')) { SKIP(7); SKIP_BLANKS; SHRINK; *************** *** 5237,5243 **** NEXT; GROW; SKIP_BLANKS; ! if (memcmp(CUR_PTR, "#PCDATA", 7) == 0) { tree = xmlParseElementMixedContentDecl(ctxt, inputid); res = XML_ELEMENT_TYPE_MIXED; } else { --- 5256,5262 ---- NEXT; GROW; SKIP_BLANKS; ! if (CMP7(CUR_PTR, '#', 'P', 'C', 'D', 'A', 'T', 'A')) { tree = xmlParseElementMixedContentDecl(ctxt, inputid); res = XML_ELEMENT_TYPE_MIXED; } else { *************** *** 5269,5275 **** xmlElementContentPtr content = NULL; GROW; ! if (memcmp(CUR_PTR, "input; SKIP(9); --- 5288,5294 ---- xmlElementContentPtr content = NULL; GROW; ! if (CMP9(CUR_PTR, '<', '!', 'E', 'L', 'E', 'M', 'E', 'N', 'T')) { xmlParserInputPtr input = ctxt->input; SKIP(9); *************** *** 5291,5297 **** "Space required after the element name\n"); } SKIP_BLANKS; ! if (memcmp(CUR_PTR, "EMPTY", 5) == 0) { SKIP(5); /* * Element must always be empty. --- 5310,5316 ---- "Space required after the element name\n"); } SKIP_BLANKS; ! if (CMP5(CUR_PTR, 'E', 'M', 'P', 'T', 'Y')) { SKIP(5); /* * Element must always be empty. *************** *** 5365,5371 **** xmlParseConditionalSections(xmlParserCtxtPtr ctxt) { SKIP(3); SKIP_BLANKS; ! if (memcmp(CUR_PTR, "INCLUDE", 7) == 0) { SKIP(7); SKIP_BLANKS; if (RAW != '[') { --- 5384,5390 ---- xmlParseConditionalSections(xmlParserCtxtPtr ctxt) { SKIP(3); SKIP_BLANKS; ! if (CMP7(CUR_PTR, 'I', 'N', 'C', 'L', 'U', 'D', 'E')) { SKIP(7); SKIP_BLANKS; if (RAW != '[') { *************** *** 5416,5422 **** "Leaving INCLUDE Conditional Section\n"); } ! } else if (memcmp(CUR_PTR, "IGNORE", 6) == 0) { int state; xmlParserInputState instate; int depth = 0; --- 5435,5441 ---- "Leaving INCLUDE Conditional Section\n"); } ! } else if (CMP6(CUR_PTR, 'I', 'G', 'N', 'O', 'R', 'E')) { int state; xmlParserInputState instate; int depth = 0; *************** *** 5555,5561 **** /* * We know that 'errNo == XML_ERR_UNSUPPORTED_ENCODING) { /* --- 5643,5649 ---- const xmlChar *SystemID) { xmlDetectSAX2(ctxt); GROW; ! if (CMP5(CUR_PTR, '<', '?', 'x', 'm', 'l')) { xmlParseTextDecl(ctxt); if (ctxt->errNo == XML_ERR_UNSUPPORTED_ENCODING) { /* *************** *** 5981,5987 **** input = xmlNewEntityInputStream(ctxt, ent); xmlPushInput(ctxt, input); if ((ent->etype == XML_EXTERNAL_GENERAL_PARSED_ENTITY) && ! (memcmp(CUR_PTR, "errNo == XML_ERR_UNSUPPORTED_ENCODING) { /* --- 6000,6006 ---- input = xmlNewEntityInputStream(ctxt, ent); xmlPushInput(ctxt, input); if ((ent->etype == XML_EXTERNAL_GENERAL_PARSED_ENTITY) && ! (CMP5(CUR_PTR, '<', '?', 'x', 'm', 'l')) && (IS_BLANK(NXT(5)))) { xmlParseTextDecl(ctxt); if (ctxt->errNo == XML_ERR_UNSUPPORTED_ENCODING) { /* *************** *** 6437,6443 **** input = xmlNewEntityInputStream(ctxt, entity); xmlPushInput(ctxt, input); if ((entity->etype == XML_EXTERNAL_PARAMETER_ENTITY) && ! (memcmp(CUR_PTR, "errNo == --- 6456,6462 ---- input = xmlNewEntityInputStream(ctxt, entity); xmlPushInput(ctxt, input); if ((entity->etype == XML_EXTERNAL_PARAMETER_ENTITY) && ! (CMP5(CUR_PTR, '<', '?', 'x', 'm', 'l')) && (IS_BLANK(NXT(5)))) { xmlParseTextDecl(ctxt); if (ctxt->errNo == *************** *** 7988,7994 **** int count = 0; /* Check 2.6.0 was NXT(0) not RAW */ ! if (memcmp(CUR_PTR, "inSubset = 1; xmlParseDocTypeDecl(ctxt); --- 8842,8848 ---- * (doctypedecl Misc*)? */ GROW; ! if (CMP9(CUR_PTR, '<', '!', 'D', 'O', 'C', 'T', 'Y', 'P', 'E')) { ctxt->inSubset = 1; xmlParseDocTypeDecl(ctxt); *************** *** 8947,8953 **** * Check for the XMLDecl in the Prolog. */ GROW; ! if ((memcmp(CUR_PTR, " Delivered-To: xml@gnome.org Received: from pkc.com (unknown [216.75.143.162]) by mail.gnome.org (Postfix) with ESMTP id 0477119594 for ; Thu, 9 Oct 2003 15:39:02 -0400 (EDT) Message-ID: From: Jesse Pelton To: "'veillard@redhat.com'" Cc: xml@gnome.org Subject: RE: [xml] Windows threading issues Date: Thu, 9 Oct 2003 15:39:14 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_59661186a039de1a53a0fa5cb34b0e20" Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --=_59661186a039de1a53a0fa5cb34b0e20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks. I've just found a problem with those patches: threads.c won't = build on Windows if threading is enabled but compiler TLS is not, = LIBXML_STATIC is defined, and LIBXML_STATIC_FOR_DLL is not. (Got that?) Attached is a third patch to fix the problem. I think I got this = right, but Stephane, holler if you think otherwise! > -----Original Message----- > From: Daniel Veillard [mailto:veillard@redhat.com]=20 > Sent: Tuesday, October 07, 2003 4:05 PM > To: Jesse Pelton > Cc: xml@gnome.org > Subject: Re: [xml] Windows threading issues >=20 >=20 > On Tue, Oct 07, 2003 at 03:51:20PM -0400, Jesse Pelton wrote: > > Back in July, St=E9phane Bidoul and I developed a couple of=20 > patches to address > > some Windows threading issues (see > > http://mail.gnome.org/archives/xml/2003-July/msg00301.html=20 > et al). After he > > got back from vacation, Igor expressed his intent to commit=20 > them (both, I > > think), but I think he forgot about them. I'm finally=20 > upgrading to the > > latest libxml, and the changes aren't there. > >=20 > > Can these patches be committed? They still appear to be=20 > valid. (At least, > > patch doesn't fail, and the resulting file compiles.) The=20 > second patch must > > be applied over the first. >=20 > Okay, applied both, it seems they only affect Windows build with = the > TLS threads support. I will commit them later when my tree is=20 > back in shape, --=_59661186a039de1a53a0fa5cb34b0e20 Content-Type: application/octet-stream; name="diff.out" Content-Disposition: attachment; filename="diff.out" --- threads.c Thu Oct 09 15:30:11 2003 +++ threads2.c Tue Oct 07 15:47:13 2003 @@ -539,7 +539,7 @@ #ifdef DEBUG_THREADS xmlGenericError(xmlGenericErrorContext, "xmlInitThreads()\n"); #endif -#if defined(HAVE_WIN32_THREADS) && !defined(HAVE_COMPILER_TLS) && (!defined(LIBXML_STATIC) || defined(LIBXML_STATIC_FOR_DLL)) +#if defined(HAVE_WIN32_THREADS) && !defined(HAVE_COMPILER_TLS) InitializeCriticalSection(&cleanup_helpers_cs); #endif } @@ -556,7 +556,7 @@ #ifdef DEBUG_THREADS xmlGenericError(xmlGenericErrorContext, "xmlCleanupThreads()\n"); #endif -#if defined(HAVE_WIN32_THREADS) && !defined(HAVE_COMPILER_TLS) && (!defined(LIBXML_STATIC) || defined(LIBXML_STATIC_FOR_DLL)) +#if defined(HAVE_WIN32_THREADS) && !defined(HAVE_COMPILER_TLS) if (globalkey != TLS_OUT_OF_INDEXES) { xmlGlobalStateCleanupHelperParams * p; EnterCriticalSection(&cleanup_helpers_cs); --=_59661186a039de1a53a0fa5cb34b0e20-- From veillard@redhat.com Thu Oct 9 17:41:35 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id ED343181C1 for ; Thu, 9 Oct 2003 17:41:34 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h99LfVD04185; Thu, 9 Oct 2003 17:41:31 -0400 Date: Thu, 9 Oct 2003 17:41:31 -0400 From: Daniel Veillard To: Chris Anderson Cc: xml@gnome.org Subject: Re: [xml] RAW && NXT with strncmp() Message-ID: <20031009174121.A29460@redhat.com> Reply-To: veillard@redhat.com References: <001901c38822$1a668da0$2964a8c0@kvp> <20031001095055.G21529@redhat.com> <1065026851.2063.31.camel@stellifer> <20031006050925.B21001@redhat.com> <1065729540.27221.87.camel@kayak.charm.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1065729540.27221.87.camel@kayak.charm.net>; from christop@charm.net on Thu, Oct 09, 2003 at 03:59:00PM -0400 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, Oct 09, 2003 at 03:59:00PM -0400, Chris Anderson wrote: > On Mon, 2003-10-06 at 05:09, Daniel Veillard wrote: > > > On Wed, Oct 01, 2003 at 04:44:14PM +0300, Igor Izvarin wrote: > > >For my opinion this change will improve the code readability and > > >maintenance, will reduce the source code size and object code size. > > > > Well I can agree about code lisibility, for maintainance, I'm not > > sure as those parts are unlikely to change. And for object code size > > and speed this is actually a penalty. > > > > So I'm not sure I will actually keep that change. > > I messed with how memcmp works, trying a couple of different things like > comparing shorts and integers instead of chars (x86 allows unaligned > access w/penalty). All work slightly slower than just comparing chars. > I believe the memcmp is slower because it moves the chars from immediate > operands to another memory reference. How's this for a compromise, not > quite as pretty, but still somewhat readable: > > ! if (memcmp(CUR_PTR, " > --- > > ! if (CMP9(CUR_PTR, '<', '!', 'D', 'O', 'C', 'T', 'Y', 'P', 'E')) Sounds a decent way to get back at the old code while improving the readability, I will probably apply and test this once I'm done with the error handling changes, thanks, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard@redhat.com Thu Oct 9 17:43:12 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id C37DC184E8 for ; Thu, 9 Oct 2003 17:42:36 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h99LgnW04917; Thu, 9 Oct 2003 17:42:49 -0400 Date: Thu, 9 Oct 2003 17:42:48 -0400 From: Daniel Veillard To: Jesse Pelton Cc: xml@gnome.org Subject: Re: [xml] Windows threading issues Message-ID: <20031009174248.B29460@redhat.com> Reply-To: veillard@redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from jsp@PKC.com on Thu, Oct 09, 2003 at 03:39:14PM -0400 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, Oct 09, 2003 at 03:39:14PM -0400, Jesse Pelton wrote: > Thanks. I've just found a problem with those patches: threads.c won't build > on Windows if threading is enabled but compiler TLS is not, LIBXML_STATIC is > defined, and LIBXML_STATIC_FOR_DLL is not. (Got that?) No, but I trust the fact that you got a problem :-) > Attached is a third patch to fix the problem. I think I got this right, but > Stephane, holler if you think otherwise! Stephane, I'm waiting for your feedback to commit that, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From novak@merlot.ics.muni.cz Fri Oct 10 06:58:58 2003 Return-Path: Delivered-To: xml@gnome.org Received: from merlot.ics.muni.cz (merlot.ics.muni.cz [147.251.18.30]) by mail.gnome.org (Postfix) with ESMTP id 314ED181A0 for ; Fri, 10 Oct 2003 06:58:58 -0400 (EDT) Received: (from novak@localhost) by merlot.ics.muni.cz (8.11.7p1+Sun/8.11.6) id h9AAxBp12240 for xml@gnome.org; Fri, 10 Oct 2003 12:59:11 +0200 (MEST) Date: Fri, 10 Oct 2003 12:59:11 +0200 From: Petr Novak To: xml@gnome.org Subject: Re: [xml] xmlValidityErrorFunc how-to? Message-ID: <20031010105911.GA12134@merlot.ics.muni.cz> References: <20031006121713.GA25542@merlot.ics.muni.cz> <20031006082921.D30095@redhat.com> <20031007151818.GA4142@merlot.ics.muni.cz> <20031007114805.H31459@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031007114805.H31459@redhat.com> User-Agent: Mutt/1.3.25i Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: I have still problem with obtain information where orror (or warning) was occured during validation. If I use ValidCtct->error = (xmlValidityErrorFunc) my_function; then I obtain xmlValidCtxt.userData section, error message as a "formated string" in const char * type and next data determined by formated string. But I need to obtain pointer to the node whitch is invalid. If I tried assign the whole validation context to its own userData and tried to read current node (I thing that it may be the node in whitch the error was occured), it returned NULL in all pointer items (node etc.) or 0 in int items(nodeNr etc). I founded nothing in error.c. So, is any way how to obtain pointer to xmlNode in whitch error was occured during validation? (not only string with error message with element name) -petrn -- Petr Novak, Liberouter Project (www.liberouter.org) E-mail: novak@merlot.ics.muni.cz From veillard@redhat.com Fri Oct 10 07:20:32 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 99146188BC for ; Fri, 10 Oct 2003 07:20:32 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9ABKjl18500; Fri, 10 Oct 2003 07:20:45 -0400 Date: Fri, 10 Oct 2003 07:20:45 -0400 From: Daniel Veillard To: Petr Novak Cc: xml@gnome.org Subject: Re: [xml] xmlValidityErrorFunc how-to? Message-ID: <20031010072045.D29460@redhat.com> Reply-To: veillard@redhat.com References: <20031006121713.GA25542@merlot.ics.muni.cz> <20031006082921.D30095@redhat.com> <20031007151818.GA4142@merlot.ics.muni.cz> <20031007114805.H31459@redhat.com> <20031010105911.GA12134@merlot.ics.muni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031010105911.GA12134@merlot.ics.muni.cz>; from novak@merlot.ics.muni.cz on Fri, Oct 10, 2003 at 12:59:11PM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Fri, Oct 10, 2003 at 12:59:11PM +0200, Petr Novak wrote: > So, is any way how to obtain pointer to xmlNode in whitch error was occured > during validation? (not only string with error message with element name) Currently it's hard, you'd have to work with the parser context too and do a lot of guessing. In 2.6.0 it will be provided by the error reporting framework, check CVS if you want to see the new code. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From kost@imn.htwk-leipzig.de Fri Oct 10 10:12:53 2003 Return-Path: Delivered-To: xml@gnome.org Received: from imn.htwk-leipzig.de (david.imn.htwk-leipzig.de [141.57.9.1]) by mail.gnome.org (Postfix) with ESMTP id 45AA918467 for ; Fri, 10 Oct 2003 10:12:53 -0400 (EDT) Received: from imn.htwk-leipzig.de (krishna [141.57.8.37]) by imn.htwk-leipzig.de (8.9.1/8.9.1) with ESMTP id QAA10776 for ; Fri, 10 Oct 2003 16:12:56 +0200 (MET DST) Message-ID: <3F86BE42.2040909@imn.htwk-leipzig.de> Date: Fri, 10 Oct 2003 16:12:18 +0200 From: Stefan Kost Organization: HTWK Leipzig User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: xml@gnome.org X-Enigmail-Version: 0.76.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [xml] documentation: @@Interfaces@@ in http://www.xmlsoft.org/namespaces.html Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: hi daniel, in http://www.xmlsoft.org/namespaces.html as well in the generated docs in the source.tar.gz are the strings @@Interfaces@@ @@Examples@@ Did something went wrong there or is this intentional? Stefan -- \|/ Stefan Kost <@ @> private business +-oOO-(_)-OOo------------------------------------------------------ - - - - - | __ Address Simildenstr. 5 HTWK Leipzig, Fb IMN, Postfach 301166 | /// 04277 Leipzig 04277 Leipzig | __ /// Germany Germany | \\\/// Phone +49341 2253538 +49341 30766101 | \__/ EMail st_kost_at_gmx.net kost_at_imn.htwk-leipzig.de | WWW www.sonicpulse.de www.imn.htwk-leipzig.de/~kost/about.html ===-=-=--=---=---------------------------------- - - - - - From veillard@redhat.com Fri Oct 10 10:42:28 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 9FED5183AC for ; Fri, 10 Oct 2003 10:42:28 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9AEgbS07641; Fri, 10 Oct 2003 10:42:37 -0400 Date: Fri, 10 Oct 2003 10:42:37 -0400 From: Daniel Veillard To: Stefan Kost Cc: xml@gnome.org Subject: Re: [xml] documentation: @@Interfaces@@ in http://www.xmlsoft.org/namespaces.html Message-ID: <20031010104237.F29460@redhat.com> Reply-To: veillard@redhat.com References: <3F86BE42.2040909@imn.htwk-leipzig.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3F86BE42.2040909@imn.htwk-leipzig.de>; from kost@imn.htwk-leipzig.de on Fri, Oct 10, 2003 at 04:12:18PM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Fri, Oct 10, 2003 at 04:12:18PM +0200, Stefan Kost wrote: > hi daniel, > > in http://www.xmlsoft.org/namespaces.html as well in the generated docs in the > source.tar.gz are the strings > @@Interfaces@@ > @@Examples@@ > > Did something went wrong there or is this intentional? I never finished writing those parts :-\ Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From seefeld@sympatico.ca Fri Oct 10 16:22:47 2003 Return-Path: Delivered-To: xml@gnome.org Received: from Orthosoft.ca (unknown [216.208.232.2]) by mail.gnome.org (Postfix) with SMTP id 6884D18129 for ; Fri, 10 Oct 2003 16:22:47 -0400 (EDT) Message-ID: Date: Fri, 10 Oct 2003 16:28:14 -0400 From: Stefan Seefeld MIME-Version: 1.0 To: xml@gnome.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [xml] decoding uris Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: hello, I'm reading in an xml file, and interpreting some URLs (with the 'file://' scheme) as local file name so I can open it. libxml2 offers the function xmlURIUnescapeString, which takes a 'char *', not 'xmlChar *'. How Should I generate a local filename from an xml attribute ? (The filename may or may not itself contain unicode...Windows allows unicode filenames). Thanks, Stefan From veillard@redhat.com Fri Oct 10 17:22:55 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id EB6C0183EE for ; Fri, 10 Oct 2003 17:22:54 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9ALN9H00696 for xml@gnome.org; Fri, 10 Oct 2003 17:23:09 -0400 Date: Fri, 10 Oct 2003 17:23:09 -0400 From: Daniel Veillard To: xml@gnome.org Message-ID: <20031010172309.H29460@redhat.com> Reply-To: veillard@redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Subject: [xml] Release of libxml2-2.6.0beta5 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: I have made available a new beta release at ftp://xmlsoft.org/test/ The beta5 includes all the big changes I expect to get in the final release next week: - the new SAX2 API - the new xmlReadxxx APIs - the new error handling code (see the new APIs in xmlerror.h) - grow doc, node and attributes element with a field for type informations I have upgraded my machine with that version it seems to not break the ABI as far as I can tell. - there is still a number of small things to cleanup - the DocReader and xmlWriter APIs are still uncertain for 2.6.0 I will decide beginning of next week what to do with those. - fix the python interfaces to provide the new APIs Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From mh@glandium.org Sat Oct 11 01:08:32 2003 Return-Path: Delivered-To: xml@gnome.org Received: from vaio.glandium.org (i61-195-247-171.us.catvmics.ne.jp [61.195.247.171]) by mail.gnome.org (Postfix) with ESMTP id A3E6618367 for ; Sat, 11 Oct 2003 01:08:32 -0400 (EDT) Received: from localhost ([127.0.0.1]) by vaio.glandium.org with esmtp (Exim 3.36 #1 (Debian)) id 1A8Bzh-0000gF-00 for ; Sat, 11 Oct 2003 14:08:45 +0900 From: Mike Hommey Organization: glandium To: xml@gnome.org Subject: Re: [xml] Autotools stuff in libxml2 Date: Thu, 9 Oct 2003 18:15:55 +0900 User-Agent: KMail/1.5.3 References: <200310081931.32279.mh@glandium.org> <4031.219.78.248.9.1065684109.squirrel@www.delightful.com.hk> <200310091658.41378.mh@glandium.org> In-Reply-To: <200310091658.41378.mh@glandium.org> MIME-Version: 1.0 Content-Disposition: inline X-UID: 210 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200310091815.55692.mh@glandium.org> Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thursday 09 October 2003 16:58, Mike Hommey wrote: > On Thursday 09 October 2003 16:21, William M. Brack wrote: > > I am also a strong supporter of going with the latest and greatest, > > but Aleksey's point is a good one. Of course, there must be some > > limits to how long the library must cater for older versions of the > > auto* routines. At the moment, I believe we are trying to at least > > maintain compatibility with autoconf-2.13 and automake-1.4. > > > > Mike, could you save me a little time and let me know which of your > > requested changes would maintain compatibility within that > > constraint? > > I'll come back to you when I'll have time to take a look into it. I don't know if that is due to my coexisting autoconf 2.5 and 2.13, but=20 autoheader 2.13 complains that it wants a 2.5 version of autoconf with or=20 without the patch applied... so it seems to me that the autoconf 2.13=20 compatibility is already broken. (also note that using autoreconf2.13 on=20 pristine source returns error about missing files that the patched version= =20 doesn't) Anyway, the patch doesn't break compatibility with automake 1.4. And for libtool, it is not supposed to break anything, but Murphy's law cou= ld=20 be hiding out there ;) Regards, Mike =2D-=20 "I have sampled every language, french is my favorite. Fantastic language, especially to curse with. Nom de dieu de putain de bordel de merde de saloperie de connard d'encul=E9 de ta m=E8re. It's like wiping your ass with silk! I love it." -- The Merovingian, in the Matrix Reloaded From mh@glandium.org Sat Oct 11 01:21:10 2003 Return-Path: Delivered-To: xml@gnome.org Received: from vaio.glandium.org (i61-195-247-171.us.catvmics.ne.jp [61.195.247.171]) by mail.gnome.org (Postfix) with ESMTP id A1E0518367 for ; Sat, 11 Oct 2003 01:21:10 -0400 (EDT) Received: from localhost ([127.0.0.1]) by vaio.glandium.org with esmtp (Exim 3.36 #1 (Debian)) id 1A8CBF-0000oQ-00; Sat, 11 Oct 2003 14:20:41 +0900 From: Mike Hommey Organization: glandium To: Stefan Kost Subject: Re: [xml] Autotools stuff in libxml2 Date: Sat, 11 Oct 2003 14:20:35 +0900 User-Agent: KMail/1.5.3 References: <200310081931.32279.mh@glandium.org> <3F86DD8F.40303@imn.htwk-leipzig.de> In-Reply-To: <3F86DD8F.40303@imn.htwk-leipzig.de> Cc: xml@gnome.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200310111420.35356.mh@glandium.org> Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: [CCing back to the list ;) ] On Saturday 11 October 2003 01:25, Stefan Kost wrote: > > - Rename configure.in to configure.ac (configure.in is deprecated in > > latest versions of autoconf) > > that will probably remain, as it is not good to rename files which are > under cvs control. IMHO it is really a shame that they even did choose a > new name. What is possible to do is to add a configure.ac file and delete the=20 configure.in file. This has the main problem of loosing history for the new= =20 file, but you still have history for the old one, even if it's removed. This is the "clean" way of doing things with cvs. > to the others: > using more recent version of the autotools does not affect the users, only > developers (of libxml2) need to be aware of it. That's right. Mike =2D-=20 "I have sampled every language, french is my favorite. Fantastic language, especially to curse with. Nom de dieu de putain de bordel de merde de saloperie de connard d'encul=E9 de ta m=E8re. It's like wiping your ass with silk! I love it." -- The Merovingian, in the Matrix Reloaded From malcolm@commsecure.com.au Sat Oct 11 03:29:13 2003 Return-Path: Delivered-To: xml@gnome.org Received: from commsecure.com.au (CommSecureAustPtyLtd.sb1.optus.net.au [203.202.148.106]) by mail.gnome.org (Postfix) with ESMTP id 851DC1811F for ; Sat, 11 Oct 2003 03:29:12 -0400 (EDT) Received: from sunhill.commsecure.com.au (sunhill.commsecure.com.au [172.16.15.1]) by commsecure.com.au (8.11.6/8.11.6) with ESMTP id h9B7TM705054 for ; Sat, 11 Oct 2003 17:29:22 +1000 Received: from dialin-03.commsecure.com.au (dialin-03.commsecure.com.au [172.16.14.3]) by sunhill.commsecure.com.au (8.11.6/8.11.6) with ESMTP id h9B7TOO28977 for ; Sat, 11 Oct 2003 17:29:24 +1000 Subject: Re: AW: AW: AW: [xml] xmlTextWriter From: Malcolm Tredinnick To: xml@gnome.org In-Reply-To: <20031008063729.T31459@redhat.com> References: <4F38C8B9DAB1014DBDCB29538BBFD6A12E4E7C@pandora.schuler-ag.com> <20031008063729.T31459@redhat.com> Content-Type: text/plain Message-Id: <1065857350.4624.26.camel@quirm.tredinnick.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3.99 Date: Sat, 11 Oct 2003 17:29:11 +1000 Content-Transfer-Encoding: 7bit Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, 2003-10-08 at 20:37, Daniel Veillard wrote: > On Wed, Oct 08, 2003 at 11:12:53AM +0200, Mickautsch, Alfred wrote: > > M$: > > _vsnprintf and _vsnwprintf return the number of characters written, not including the terminating null character, or a negative value if an output error occurs. For _vsnprintf, if the number of bytes to write exceeds buffer, then count bytes are written and -1 is returned. > > > > See what I mean? And there exist other variations too. > > yes, that's called a broken infrastructure... get a real vsnprintf, That's a little harsh. :-) The return value of vsnprintf was changed in C99 (compared to C89). It's something that really needs to be checked in configure.in (basically it could return the current glibc number, the current Microsoft number or -1, like older glibc's did -- although I'm not sure what standard the latter behaviour was following). The vsnprintf and snprintf functions are really ugly to work with portably, since you really want to be able to assume a C99-compatible compiler, but that is often unrealistic. Cheers, Malcolm From stephane.bidoul@softwareag.com Sat Oct 11 05:44:58 2003 Return-Path: Delivered-To: xml@gnome.org Received: from server8a.software-ag.de (server8a.software-ag.de [193.26.193.47]) by mail.gnome.org (Postfix) with ESMTP id 7158E181C8 for ; Sat, 11 Oct 2003 05:44:57 -0400 (EDT) Received: from acsesbi by server8a.software-ag.de; (8.11.6/8.9.3) id h9B9iuF19900; Sat, 11 Oct 2003 11:44:56 +0200 From: "Stephane Bidoul" To: , "'Jesse Pelton'" Cc: Subject: RE: [xml] Windows threading issues Date: Sat, 11 Oct 2003 11:43:36 +0200 Message-ID: <000001c38fdc$5444adb0$0c67140a@acsesbi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_01C38FED.17D21190" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <20031009174248.B29460@redhat.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C38FED.17D21190 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Well, actually I had something similar already applied on my tree, but I had lost track of that issue. Jesse's patch is reversed but otherwise looks okay to me. I attach the cvs diff. -sbi > -----Original Message----- > From: xml-admin@gnome.org [mailto:xml-admin@gnome.org]On Behalf Of > Daniel Veillard > Sent: 09 October, 2003 23:43 > To: Jesse Pelton > Cc: xml@gnome.org > Subject: Re: [xml] Windows threading issues > > > On Thu, Oct 09, 2003 at 03:39:14PM -0400, Jesse Pelton wrote: > > Thanks. I've just found a problem with those patches: > threads.c won't build > > on Windows if threading is enabled but compiler TLS is not, > LIBXML_STATIC is > > defined, and LIBXML_STATIC_FOR_DLL is not. (Got that?) > > No, but I trust the fact that you got a problem :-) > > > Attached is a third patch to fix the problem. I think I > got this right, but > > Stephane, holler if you think otherwise! > > Stephane, I'm waiting for your feedback to commit that, > > Daniel > > -- > Daniel Veillard | Red Hat Network https://rhn.redhat.com/ > veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ _______________________________________________ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml ------=_NextPart_000_0001_01C38FED.17D21190 Content-Type: application/octet-stream; name="threads.c.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="threads.c.diff" Index: threads.c=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= RCS file: /cvs/gnome/gnome-xml/threads.c,v=0A= retrieving revision 1.23=0A= diff -c -r1.23 threads.c=0A= *** threads.c 7 Oct 2003 21:25:08 -0000 1.23=0A= --- threads.c 11 Oct 2003 09:28:51 -0000=0A= ***************=0A= *** 541,547 ****=0A= #ifdef DEBUG_THREADS=0A= xmlGenericError(xmlGenericErrorContext, "xmlInitThreads()\n");=0A= #endif=0A= ! #if defined(HAVE_WIN32_THREADS) && !defined(HAVE_COMPILER_TLS)=0A= InitializeCriticalSection(&cleanup_helpers_cs);=0A= #endif=0A= }=0A= --- 541,547 ----=0A= #ifdef DEBUG_THREADS=0A= xmlGenericError(xmlGenericErrorContext, "xmlInitThreads()\n");=0A= #endif=0A= ! #if defined(HAVE_WIN32_THREADS) && !defined(HAVE_COMPILER_TLS) && = (!defined(LIBXML_STATIC) || defined(LIBXML_STATIC_FOR_DLL))=0A= InitializeCriticalSection(&cleanup_helpers_cs);=0A= #endif=0A= }=0A= ***************=0A= *** 558,564 ****=0A= #ifdef DEBUG_THREADS=0A= xmlGenericError(xmlGenericErrorContext, "xmlCleanupThreads()\n");=0A= #endif=0A= ! #if defined(HAVE_WIN32_THREADS) && !defined(HAVE_COMPILER_TLS)=0A= if (globalkey !=3D TLS_OUT_OF_INDEXES) {=0A= xmlGlobalStateCleanupHelperParams * p;=0A= EnterCriticalSection(&cleanup_helpers_cs);=0A= --- 558,564 ----=0A= #ifdef DEBUG_THREADS=0A= xmlGenericError(xmlGenericErrorContext, "xmlCleanupThreads()\n");=0A= #endif=0A= ! #if defined(HAVE_WIN32_THREADS) && !defined(HAVE_COMPILER_TLS) && = (!defined(LIBXML_STATIC) || defined(LIBXML_STATIC_FOR_DLL))=0A= if (globalkey !=3D TLS_OUT_OF_INDEXES) {=0A= xmlGlobalStateCleanupHelperParams * p;=0A= EnterCriticalSection(&cleanup_helpers_cs);=0A= ------=_NextPart_000_0001_01C38FED.17D21190-- From breese@mail1.stofanet.dk Sat Oct 11 05:48:13 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mx03.stofanet.dk (mx03.stofanet.dk [212.10.30.233]) by mail.gnome.org (Postfix) with ESMTP id 38CAC181C8 for ; Sat, 11 Oct 2003 05:48:13 -0400 (EDT) Received: from 3e6b23de.rev.stofanet.dk ([62.107.35.222]) by mx03.stofanet.dk with esmtp (Exim 4.22) id 1A8GMN-0007NN-1b for xml@gnome.org; Sat, 11 Oct 2003 11:48:27 +0200 From: Bjorn Reese To: xml@gnome.org In-Reply-To: <1065857350.4624.26.camel@quirm.tredinnick.org> References: <4F38C8B9DAB1014DBDCB29538BBFD6A12E4E7C@pandora.schuler-ag.com> <20031008063729.T31459@redhat.com> <1065857350.4624.26.camel@quirm.tredinnick.org> Content-Type: text/plain Organization: Hyperspace Academy Message-Id: <1065865853.2060.24.camel@stellifer> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 11 Oct 2003 11:50:54 +0200 Content-Transfer-Encoding: 7bit Subject: [xml] vsnprintf (was: xmlTextWriter) Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Sat, 2003-10-11 at 09:29, Malcolm Tredinnick wrote: > That's a little harsh. :-) The return value of vsnprintf was changed in > C99 (compared to C89). It's something that really needs to be checked in snprintf/vsnprintf were first standardized in UNIX98 and later in C99, which probably explains (a) the lack of these functions on certain platforms, and (b) their different behavior on older platforms that do implement them. From veillard@redhat.com Sat Oct 11 05:49:22 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 761581820E for ; Sat, 11 Oct 2003 05:49:22 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9B9nYF00877; Sat, 11 Oct 2003 05:49:34 -0400 Date: Sat, 11 Oct 2003 05:49:34 -0400 From: Daniel Veillard To: Malcolm Tredinnick Cc: xml@gnome.org Subject: Re: AW: AW: AW: [xml] xmlTextWriter Message-ID: <20031011054934.J29460@redhat.com> Reply-To: veillard@redhat.com References: <4F38C8B9DAB1014DBDCB29538BBFD6A12E4E7C@pandora.schuler-ag.com> <20031008063729.T31459@redhat.com> <1065857350.4624.26.camel@quirm.tredinnick.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1065857350.4624.26.camel@quirm.tredinnick.org>; from malcolm@commsecure.com.au on Sat, Oct 11, 2003 at 05:29:11PM +1000 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Sat, Oct 11, 2003 at 05:29:11PM +1000, Malcolm Tredinnick wrote: > On Wed, 2003-10-08 at 20:37, Daniel Veillard wrote: > > yes, that's called a broken infrastructure... get a real vsnprintf, > > That's a little harsh. :-) okay :-) > The return value of vsnprintf was changed in > C99 (compared to C89). It's something that really needs to be checked in > configure.in (basically it could return the current glibc number, the > current Microsoft number or -1, like older glibc's did -- although I'm > not sure what standard the latter behaviour was following). > > The vsnprintf and snprintf functions are really ugly to work with > portably, since you really want to be able to assume a C99-compatible > compiler, but that is often unrealistic. it might be simpler to simply ignore the return value for length computation and simply walk the string from the copy point up to the end (0 or len reached). Anyway snprintf is really expensive as a function it should be avoided as much as possible, the cost of the string scan is probably neglectible compared to the function itself for small to medium strings. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard@redhat.com Sat Oct 11 06:02:01 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 0299C1812D for ; Sat, 11 Oct 2003 06:02:01 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9BA2BB03899; Sat, 11 Oct 2003 06:02:11 -0400 Date: Sat, 11 Oct 2003 06:02:11 -0400 From: Daniel Veillard To: Mike Hommey Cc: xml@gnome.org Subject: Re: [xml] Autotools stuff in libxml2 Message-ID: <20031011060211.K29460@redhat.com> Reply-To: veillard@redhat.com References: <200310081931.32279.mh@glandium.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200310081931.32279.mh@glandium.org>; from mh@glandium.org on Wed, Oct 08, 2003 at 07:58:13PM +0900 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, Oct 08, 2003 at 07:58:13PM +0900, Mike Hommey wrote: > Hi libxml2 developpers, > > I'm the new maintainer of the libxml2 package for the Debian GNU/Linux > distribution and would have a tiny little request before release of libxml2. > It would be nice to somewhat update autotools stuff by doing the following : > > - Rename configure.in to configure.ac (configure.in is deprecated in latest > versions of autoconf) > - Remove acconfig.h (acconfig.h is deprecated in latest versions of autoconf) > - Apply the attached patch to configure.ac (to "fix" the "lack" of acconfig.h) > - Run autoreconf (latest version preferred) > - Run automake (latest version preferred) > - Run libtoolize --force (latest version preferred) Now what is this gonna break ??? The standard way to initialize the auto* stuff in libxml2 is to run autogen.sh (it's the Gnome way of doing things). I applied the patch anyway but to configure.in, no reason it would not work > At least, a libtoolize --force would be appreciable, because latest versions > of libtools fix some detection breakage on some "unusual" architecture, and > that will prevent me to have to do it on my side ;) autogen.sh runs "libtoolize --copy --force", I do that at least once a week, and always when I bump the version in configure.in, precisely because autogen.sh is the way to rebuild the auto* from the configure.in . > PS: BTW, are you aware of the tons of "comparison is always (true|false) due > to limited range of data type" warnings when compiling with all warnings > enabled ? Apparently the optimizer got smarter and defeat a cast I made to avoid the warnings on older versions. This will be fixed at some point. This is totally harmless. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard@redhat.com Sat Oct 11 06:20:29 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 2C6E51820D for ; Sat, 11 Oct 2003 06:20:29 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9BAKem08683; Sat, 11 Oct 2003 06:20:40 -0400 Date: Sat, 11 Oct 2003 06:20:40 -0400 From: Daniel Veillard To: Stephane Bidoul Cc: "'Jesse Pelton'" , xml@gnome.org Subject: Re: [xml] Windows threading issues Message-ID: <20031011062040.L29460@redhat.com> Reply-To: veillard@redhat.com References: <20031009174248.B29460@redhat.com> <000001c38fdc$5444adb0$0c67140a@acsesbi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <000001c38fdc$5444adb0$0c67140a@acsesbi>; from stephane.bidoul@softwareag.com on Sat, Oct 11, 2003 at 11:43:36AM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Sat, Oct 11, 2003 at 11:43:36AM +0200, Stephane Bidoul wrote: > Well, actually I had something similar already applied > on my tree, but I had lost track of that issue. > > Jesse's patch is reversed but otherwise looks okay to me. > I attach the cvs diff. Okay, applied, thanks ! Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard@redhat.com Sat Oct 11 06:52:16 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id EC2E31812D for ; Sat, 11 Oct 2003 06:52:15 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9BAqT214973; Sat, 11 Oct 2003 06:52:29 -0400 Date: Sat, 11 Oct 2003 06:52:28 -0400 From: Daniel Veillard To: Bjorn Reese Cc: xml@gnome.org Subject: Re: [xml] vsnprintf (was: xmlTextWriter) Message-ID: <20031011065228.M29460@redhat.com> Reply-To: veillard@redhat.com References: <4F38C8B9DAB1014DBDCB29538BBFD6A12E4E7C@pandora.schuler-ag.com> <20031008063729.T31459@redhat.com> <1065857350.4624.26.camel@quirm.tredinnick.org> <1065865853.2060.24.camel@stellifer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1065865853.2060.24.camel@stellifer>; from breese@mail1.stofanet.dk on Sat, Oct 11, 2003 at 11:50:54AM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Sat, Oct 11, 2003 at 11:50:54AM +0200, Bjorn Reese wrote: > On Sat, 2003-10-11 at 09:29, Malcolm Tredinnick wrote: > > > That's a little harsh. :-) The return value of vsnprintf was changed in > > C99 (compared to C89). It's something that really needs to be checked in > > snprintf/vsnprintf were first standardized in UNIX98 and later in > C99, which probably explains (a) the lack of these functions on > certain platforms, and (b) their different behavior on older > platforms that do implement them. okay, my bad, that time it's not Microsoft fault. Mea culpa ! Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From stephane.bidoul@softwareag.com Sat Oct 11 06:59:36 2003 Return-Path: Delivered-To: xml@gnome.org Received: from server8a.software-ag.de (server8a.software-ag.de [193.26.193.47]) by mail.gnome.org (Postfix) with ESMTP id D37F91812D for ; Sat, 11 Oct 2003 06:59:35 -0400 (EDT) Received: from acsesbi by server8a.software-ag.de; (8.11.6/8.9.3) id h9BAxmF25343; Sat, 11 Oct 2003 12:59:48 +0200 From: "Stéphane Bidoul" To: "'Ed Day'" Cc: Subject: RE: [xml] Differences in DOM parsing on Windows and UNIX? Date: Sat, 11 Oct 2003 12:59:44 +0200 Message-ID: <002301c38fe6$c8d024c0$0c67140a@acsesbi> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <05f901c38e75$e9f8a450$483e0942@objsys1> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: > Well, there is not that much to it. When the code was as follows: > > xmlInitParser(); > xmlKeepBlanksDefault(0); > xmlLineNumbersDefault(1); // set line numbers > > pXmlDoc = xmlParseFile (fileSpec); > > if (0 == pXmlDoc) { > printf ("Error parsing XML file\n"); > return 1; > } > > xmlCleanupParser(); > > I got the blank nodes. When I changed it to: > > xmlInitParser(); > #ifdef LIBXML_THREAD_ENABLED > xmlThrDefKeepBlanksDefaultValue(0); > #else > xmlKeepBlanksDefault(0); > #endif > xmlLineNumbersDefault(1); // set line numbers > > pXmlDoc = xmlParseFile (fileSpec); > > if (0 == pXmlDoc) { > printf ("Error parsing XML file\n"); > return 1; > } > > xmlCleanupParser(); > > They went away. I really don't see why it would be different for xmlKeepBlanksDefault and xmlLineNumbersDefault: all globals are treated equally in libxml (I'm pretty sure, because that code is actually generated). You should check again, IMHO. > It really should not be necessary for me to have to deal with > a #define like > LIBXML_THREAD_ENABLED in my mainline code. If your program has only one thread, you don't need to. Just have a look at xmllint.c: it only does xmlKeepBlanksDefault(0) and that does not depend on LIBXML_THREAD_ENABLED. Assume test.xml: ]> ~>xmllint --noblanks test.xml ]> If your program has several threads, either do xmlThrDefKeepBlanksDefaultValue() before creating your threads or do xmlKeepBlanksDefault() in each thread. -sbi From veillard@redhat.com Sat Oct 11 07:12:03 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 019401812D for ; Sat, 11 Oct 2003 07:12:02 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9BBC2w19053; Sat, 11 Oct 2003 07:12:02 -0400 Date: Sat, 11 Oct 2003 07:12:02 -0400 From: Daniel Veillard To: =?iso-8859-1?Q?St=E9phane_Bidoul?= Cc: "'Ed Day'" , xml@gnome.org Subject: Re: [xml] Differences in DOM parsing on Windows and UNIX? Message-ID: <20031011071202.N29460@redhat.com> Reply-To: veillard@redhat.com References: <05f901c38e75$e9f8a450$483e0942@objsys1> <002301c38fe6$c8d024c0$0c67140a@acsesbi> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <002301c38fe6$c8d024c0$0c67140a@acsesbi>; from stephane.bidoul@softwareag.com on Sat, Oct 11, 2003 at 12:59:44PM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Sat, Oct 11, 2003 at 12:59:44PM +0200, Stéphane Bidoul wrote: > If your program has only one thread, you don't need to. > Just have a look at xmllint.c: it only > does xmlKeepBlanksDefault(0) and that does not > depend on LIBXML_THREAD_ENABLED. [...] > If your program has several threads, either > do xmlThrDefKeepBlanksDefaultValue() before creating > your threads or do xmlKeepBlanksDefault() in each thread. The proper way post 2.6.0 will simply to use the xmlReadxxx API and pass the correct flags for this specific parsing. The use of the global variables are an evil hack, it was the simplest way at the time, but really that's bad and migrating to the new APIs is far far cleaner. The xmlReadxxx functions will *not* use the global variables, per thread or not, it's quite a saner API, this should avoid this whole mess. When you parse a document the code launching the parse is the one who knows what is the expected options, not some initialization step, previous parsing, external library or concurent thread, who might have a different need and changed the default. I actually already migrated xmllint to the new code. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From aliban@gmx.net Sat Oct 11 19:47:46 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mail.gnome.org (Postfix) with SMTP id 74F1F180E6 for ; Sat, 11 Oct 2003 19:47:46 -0400 (EDT) Received: (qmail 25035 invoked by uid 65534); 11 Oct 2003 23:48:00 -0000 Received: from pD9E5041D.dip.t-dialin.net (EHLO bastian) (217.229.4.29) by mail.gmx.net (mp023) with SMTP; 12 Oct 2003 01:48:00 +0200 X-Authenticated: #4984851 From: aliban@gmx.net To: xml@gnome.org Date: Sun, 12 Oct 2003 01:48:31 +0200 MIME-Version: 1.0 Message-ID: <3F88B2EF.9631.3378A2@localhost> Priority: normal X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Subject: [xml] libxml socket stream Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: hi. over a socket stream i receive a document. the document is very big and might need houres to get transmitted. i think xmlreader should be used for this. my problem is this. as i want to parse "on the flow" i have to pass any received buffer to the reader. whatever it can occure that a node is not transferred in one socket receive call therefor the reader might receive a string that is not xml- finsihed. like this: first recv: how to pass this "on the flow" to the reader? do i have to store it in a temporary buffer? I also need to know, can it happen that reader is currently working (and using readers buffer) while new data is recv over the socket - the socket would try to append the data to the readers buffer while reader is using it... how to suspend the reader? From veillard@redhat.com Sun Oct 12 06:19:37 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 6401A18297 for ; Sun, 12 Oct 2003 06:19:37 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9CAJm519344; Sun, 12 Oct 2003 06:19:48 -0400 Date: Sun, 12 Oct 2003 06:19:48 -0400 From: Daniel Veillard To: aliban@gmx.net Cc: xml@gnome.org Subject: Re: [xml] libxml socket stream Message-ID: <20031012061948.V29460@redhat.com> Reply-To: veillard@redhat.com References: <3F88B2EF.9631.3378A2@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3F88B2EF.9631.3378A2@localhost>; from aliban@gmx.net on Sun, Oct 12, 2003 at 01:48:31AM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Sun, Oct 12, 2003 at 01:48:31AM +0200, aliban@gmx.net wrote: > hi. over a socket stream i receive a document. the document is very > big and might need houres to get transmitted. i think xmlreader > should be used for this. > > my problem is this. as i want to parse "on the flow" i have to pass > any received buffer to the reader. whatever it can occure that a node > is not transferred in one socket receive call therefor the reader > might receive a string that is not xml- finsihed. if you need dedicated I/O processing then build your custom input layer with xmlParserInputBufferCreateIO() > I also need to know, can it happen that reader is currently working > (and using readers buffer) while new data is recv over the socket - > the socket would try to append the data to the readers buffer while > reader is using it... > > how to suspend the reader? Well you can't, the programming model of the reader is precisely that the part of the code which does the scanning is the one controlling the processing flow. If you want something callback based, then use SAX, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From vr@vrgraphics.ru Sun Oct 12 07:12:52 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail.nis.nnov.su (mail.nis.nnov.su [212.67.0.18]) by mail.gnome.org (Postfix) with ESMTP id EBBE0180F5 for ; Sun, 12 Oct 2003 07:12:51 -0400 (EDT) Received: from silver (ipdl032.nis.nnov.su [212.67.4.32]) by mail.nis.nnov.su (8.12.10/8.12.10) with ESMTP id h9CBD3Uv007059 for ; Sun, 12 Oct 2003 15:13:05 +0400 From: "vassily ragosin" To: Date: Sun, 12 Oct 2003 15:09:49 +0400 Message-ID: <000701c390b1$5bd6f0d0$0301a8c0@silver> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1123 Subject: [xml] processing PI in libxml Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: hello gnomes, can someone please give some hints on how do I replace PIs in the parsed document tree (xmlDoc) with some xml nodes I want. In other words, I have an xml as a result of xsl transformation, that has some processing instructions in it, which I want to process further and replace them with xml. resourcefully yours, vassily mailto:vr[at]vrgraphics.ru pgp key id 0x92B4A97C From aliban@gmx.net Sun Oct 12 07:28:52 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by mail.gnome.org (Postfix) with SMTP id 1B96F18268 for ; Sun, 12 Oct 2003 07:28:52 -0400 (EDT) Received: (qmail 16957 invoked by uid 65534); 12 Oct 2003 11:29:06 -0000 Received: from p50803750.dip.t-dialin.net (EHLO bastian) (80.128.55.80) by mail.gmx.net (mp009) with SMTP; 12 Oct 2003 13:29:06 +0200 X-Authenticated: #4984851 From: aliban@gmx.net To: xml@gnome.org Date: Sun, 12 Oct 2003 13:29:43 +0200 MIME-Version: 1.0 Subject: Re: [xml] libxml socket stream Message-ID: <3F895747.21965.6CC362@localhost> Priority: normal X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: ok, sorry. here again. ok, i thought about it. i would like to do it like this: as the xmlParserInputBufferCreateIO() is limited to a special maximum amount of readers at one time (15) i would use xmlParserInputBufferPush() each time my socket recvs data and reader is not working... if reader is currently working data will waiting in socket and get fetched later.. the reader will read data until there come an error by an unfinished tag for example or the last node was done successfully... whatever the hope is that the reader will stay at the same position as befor the error/last success happened. thus i can simply xmlParserInputBufferPush() the missing but finally recvd data and continue reading. reader would then do the error node again and everything would be fine. well, do you think this would work? On 12 Oct 2003 at 6:19, Daniel Veillard wrote: > On Sun, Oct 12, 2003 at 01:48:31AM +0200, aliban@gmx.net wrote: > > hi. over a socket stream i receive a document. the document is very > > big and might need houres to get transmitted. i think xmlreader should > > be used for this. > > > > my problem is this. as i want to parse "on the flow" i have to pass > > any received buffer to the reader. whatever it can occure that a node > > is not transferred in one socket receive call therefor the reader > > might receive a string that is not xml- finsihed. > > if you need dedicated I/O processing then build your custom > input layer with > xmlParserInputBufferCreateIO() > > > I also need to know, can it happen that reader is currently working > > (and using readers buffer) while new data is recv over the socket - > > the socket would try to append the data to the readers buffer while > > reader is using it... > > > > how to suspend the reader? > > Well you can't, the programming model of the reader is precisely > that the part of the code which does the scanning is the one controlling > the processing flow. If you want something callback based, then use SAX, > > Daniel > > -- > Daniel Veillard | Red Hat Network https://rhn.redhat.com/ > veillard@redhat.com | libxml GNOME XML XSLT toolkit > http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine > http://rpmfind.net/ > From veillard@redhat.com Sun Oct 12 15:35:55 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id B0B7E188C6 for ; Sun, 12 Oct 2003 15:35:55 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9CJa7O12427; Sun, 12 Oct 2003 15:36:07 -0400 Date: Sun, 12 Oct 2003 15:36:07 -0400 From: Daniel Veillard To: aliban@gmx.net Cc: xml@gnome.org Subject: Re: [xml] libxml socket stream Message-ID: <20031012153607.X29460@redhat.com> Reply-To: veillard@redhat.com References: <3F895747.21965.6CC362@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3F895747.21965.6CC362@localhost>; from aliban@gmx.net on Sun, Oct 12, 2003 at 01:29:43PM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Sun, Oct 12, 2003 at 01:29:43PM +0200, aliban@gmx.net wrote: > ok, sorry. here again. > > ok, i thought about it. > > i would like to do it like this: > as the xmlParserInputBufferCreateIO() is limited to a special maximum > amount of readers at one time (15) i would use What do you mean ? I do not understand. I don't know any such limitation internally. > xmlParserInputBufferPush() > each time my socket recvs data and reader is not working... if reader > is > currently working data will waiting in socket and get fetched later.. > > the reader will read data until there come an error by an unfinished > tag > for example or the last node was done successfully... > > whatever the hope is that the reader will stay at the same position > as befor the error/last success happened. thus i can simply > xmlParserInputBufferPush() the missing but finally recvd data and > continue reading. reader would then do the error node again and > everything would be fine. > well, do you think this would work? No idea. I don't understand what you're trying to do. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard@redhat.com Sun Oct 12 15:41:38 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id C0F221813E for ; Sun, 12 Oct 2003 15:41:38 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9CJfJE13555; Sun, 12 Oct 2003 15:41:19 -0400 Date: Sun, 12 Oct 2003 15:41:19 -0400 From: Daniel Veillard To: vassily ragosin Cc: xml@gnome.org Subject: Re: [xml] processing PI in libxml Message-ID: <20031012154119.Y29460@redhat.com> Reply-To: veillard@redhat.com References: <000701c390b1$5bd6f0d0$0301a8c0@silver> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <000701c390b1$5bd6f0d0$0301a8c0@silver>; from vr@vrgraphics.ru on Sun, Oct 12, 2003 at 03:09:49PM +0400 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Sun, Oct 12, 2003 at 03:09:49PM +0400, vassily ragosin wrote: > hello gnomes, > > can someone please give some hints on how do I replace PIs in the parsed > document tree (xmlDoc) with some xml nodes I want. > In other words, I have an xml as a result of xsl transformation, that has > some processing instructions in it, which I want to process further and > replace them with xml. Have you checked the tree API ? http://xmlsoft.org/html/libxml-tree.html#xmlNewPI there is a number of APIs there to do this kind of things Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From vr@vrgraphics.ru Sun Oct 12 18:26:29 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail.nis.nnov.su (mail.nis.nnov.su [212.67.0.18]) by mail.gnome.org (Postfix) with ESMTP id DE10E1818D for ; Sun, 12 Oct 2003 18:26:28 -0400 (EDT) Received: from silver (ipdl030.nis.nnov.su [212.67.4.30]) by mail.nis.nnov.su (8.12.10/8.12.10) with ESMTP id h9CMQ0IT017717 for ; Mon, 13 Oct 2003 02:26:22 +0400 From: "vassily ragosin" To: Subject: RE: [xml] processing PI in libxml Date: Mon, 13 Oct 2003 02:22:40 +0400 Message-ID: <000401c3910f$75cafc80$0301a8c0@silver> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <20031012154119.Y29460@redhat.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1123 Importance: Normal Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: hi, > > can someone please give some hints on how do I replace PIs in the > > parsed document tree (xmlDoc) with some xml nodes I want. > > Have you checked the tree API ? > http://xmlsoft.org/html/libxml-tree.html#xmlNewPI > there is a number of APIs there to do this kind of things xmlNewPI does just the oppposite to what I want. I have PIs in my xmlDoc, and I want to replace them for some generated xml, if target matches. Would navigating throught the tree node by node and using xmlReplaceNode be the right way to do it or there is more simple way of doing it? resourcefully yours, vassily mailto:vr[at]vrgraphics.ru pgp key id 0x92B4A97C From cmnagarajan@yahoo.com Mon Oct 13 06:08:27 2003 Return-Path: Delivered-To: xml@gnome.org Received: from web11806.mail.yahoo.com (web11806.mail.yahoo.com [216.136.172.160]) by mail.gnome.org (Postfix) with SMTP id 9D4AE181DE for ; Mon, 13 Oct 2003 06:08:26 -0400 (EDT) Message-ID: <20031013100841.99804.qmail@web11806.mail.yahoo.com> Received: from [202.54.131.172] by web11806.mail.yahoo.com via HTTP; Mon, 13 Oct 2003 03:08:41 PDT Date: Mon, 13 Oct 2003 03:08:41 -0700 (PDT) From: Madhavan Nagarajan To: xml@gnome.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-150825546-1066039721=:97101" Subject: [xml] Validity of document Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: --0-150825546-1066039721=:97101 Content-Type: text/plain; charset=us-ascii Hi, I am using xmlValidateDtd() to validate my XML document against the DTD. I used the same code as it is in xmllint.c. Validation fails but I found the value of 'valid' (Temporary validity result) in xmlValidCtxt structure to be 1. What does this imply? Also the same document gets validated succesfully when I used NSGML parser. Did I miss anything? Pls. provide your suggestions. Thanks and Regards, Nagarajan --------------------------------- Do you Yahoo!? The New Yahoo! Shopping - with improved product search --0-150825546-1066039721=:97101 Content-Type: text/html; charset=us-ascii
Hi,
 
I am using xmlValidateDtd() to validate my XML document against the DTD. I used the same code as it is in xmllint.c. Validation fails but I found the value of 'valid' (Temporary validity result) in xmlValidCtxt structure to be 1. What does this imply?
 
Also the same document gets validated succesfully when I used NSGML parser.
 
Did I miss anything? Pls. provide your suggestions.
 
Thanks and Regards,
Nagarajan

Do you Yahoo!?
The New Yahoo! Shopping - with improved product search --0-150825546-1066039721=:97101-- From veillard@redhat.com Mon Oct 13 06:28:17 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id EA5D718325 for ; Mon, 13 Oct 2003 06:28:16 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9DASUA04838; Mon, 13 Oct 2003 06:28:30 -0400 Date: Mon, 13 Oct 2003 06:28:30 -0400 From: Daniel Veillard To: Madhavan Nagarajan Cc: xml@gnome.org Subject: Re: [xml] Validity of document Message-ID: <20031013062830.B29460@redhat.com> Reply-To: veillard@redhat.com References: <20031013100841.99804.qmail@web11806.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031013100841.99804.qmail@web11806.mail.yahoo.com>; from cmnagarajan@yahoo.com on Mon, Oct 13, 2003 at 03:08:41AM -0700 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Mon, Oct 13, 2003 at 03:08:41AM -0700, Madhavan Nagarajan wrote: > Hi, > > I am using xmlValidateDtd() to validate my XML document against the DTD. I used the same code as it is in xmllint.c. Validation fails but I found the value of 'valid' (Temporary validity result) in xmlValidCtxt structure to be 1. What does this imply? This should not happen except for the fact that xmlValidateDtd() is not okay if the document has an internal subset. Provide a reproductible test case which exhibit the problem with xmllint, see guidelines at http://xmlsoft.org/bugs.html Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From oliverst@online.de Mon Oct 13 07:09:48 2003 Return-Path: Delivered-To: xml@gnome.org Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mail.gnome.org (Postfix) with ESMTP id E9EAF184CF for ; Mon, 13 Oct 2003 07:09:47 -0400 (EDT) Received: from [212.227.126.202] (helo=mrvnet.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1A90aQ-0001Hl-00 for xml@gnome.org; Mon, 13 Oct 2003 13:10:02 +0200 Received: from [172.23.4.131] (helo=config4.kundenserver.de) by mrvnet.kundenserver.de with esmtp (Exim 3.35 #1) id 1A90aQ-0005lJ-00 for xml@gnome.org; Mon, 13 Oct 2003 13:10:02 +0200 Received: from www-data by config4.kundenserver.de with local (Exim 3.35 #1 (Debian)) id 1A90aQ-0003WK-00 for ; Mon, 13 Oct 2003 13:10:02 +0200 To: From: Message-Id: <5074873$10660430933f8a86d5ed8cf4.12893472@config4.schlund.de> X-Binford: 6100 (more power) X-Originating-From: 5074873 X-Mailer: Webmail X-Routing: DE X-Received: from config4 by 213.252.152.112 with HTTP id 5074873 for xml@gnome.org; Mon, 13 Oct 2003 13:08:01 +0200 Content-Type: text/plain; charset="iso-8859-1" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Priority: 3 Date: Mon, 13 Oct 2003 13:08:01 +0200 Subject: [xml] Problem in valid.c Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Do not define "LIBXML_REGEXP_ENABLED" and you get an compiler error in valid.c:4951, which says, that there aren't enough parameters to call the function. From veillard@redhat.com Mon Oct 13 07:43:27 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 3642218683 for ; Mon, 13 Oct 2003 07:43:27 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9DBhfO30475; Mon, 13 Oct 2003 07:43:41 -0400 Date: Mon, 13 Oct 2003 07:43:41 -0400 From: Daniel Veillard To: oliverst@online.de Cc: xml@gnome.org Subject: Re: [xml] Problem in valid.c Message-ID: <20031013074341.D29460@redhat.com> Reply-To: veillard@redhat.com References: <5074873$10660430933f8a86d5ed8cf4.12893472@config4.schlund.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <5074873$10660430933f8a86d5ed8cf4.12893472@config4.schlund.de>; from oliverst@online.de on Mon, Oct 13, 2003 at 01:08:01PM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Mon, Oct 13, 2003 at 01:08:01PM +0200, oliverst@online.de wrote: > > Do not define "LIBXML_REGEXP_ENABLED" and you get an compiler error in > valid.c:4951, which says, that there aren't enough parameters to call > the function. line 4951 is #else /* LIBXML_REGEXP_ENABLED */ for me, so which function call ? what version ? Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From wbrack@mmm.com.hk Mon Oct 13 10:58:43 2003 Return-Path: Delivered-To: xml@gnome.org Received: from delightful.com.hk (adsl-63-204-84-206.dsl.sktn01.pacbell.net [63.204.84.206]) by mail.gnome.org (Postfix) with ESMTP id 9CCAA1894F for ; Mon, 13 Oct 2003 10:58:42 -0400 (EDT) Received: from delightful.com.hk (localhost [127.0.0.1]) by delightful.com.hk (8.12.9/8.12.9) with SMTP id h9DEwuVq007483 for ; Mon, 13 Oct 2003 07:58:56 -0700 Received: from 219.78.248.9 (SquirrelMail authenticated user wbrack) by www.delightful.com.hk with HTTP; Mon, 13 Oct 2003 22:58:56 +0800 (HKT) Message-ID: <3265.219.78.248.9.1066057136.squirrel@www.delightful.com.hk> In-Reply-To: <20031013074341.D29460@redhat.com> References: <5074873$10660430933f8a86d5ed8cf4.12893472@config4.schlund.de> <20031013074341.D29460@redhat.com> Date: Mon, 13 Oct 2003 22:58:56 +0800 (HKT) Subject: Re: [xml] Problem in valid.c From: "William M. Brack" To: xml@gnome.org User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Daniel Veillard said: > On Mon, Oct 13, 2003 at 01:08:01PM +0200, oliverst@online.de wrote: >> >> Do not define "LIBXML_REGEXP_ENABLED" and you get an compiler >> error in >> valid.c:4951, which says, that there aren't enough parameters to >> call >> the function. > > line 4951 is > #else /* LIBXML_REGEXP_ENABLED */ > for me, so which function call ? what version ? > > Daniel Ah, the problems with line numbers (CVS is a moving target) - I think this refers to current (as of an hour or two ago) CVS valid.c line 4978, a call to xmlErrValidWarning, with a wrong number of arguments :-/ Bill From veillard@redhat.com Mon Oct 13 11:11:19 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 3BC8D1839D for ; Mon, 13 Oct 2003 11:11:19 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9DFBQB25158; Mon, 13 Oct 2003 11:11:26 -0400 Date: Mon, 13 Oct 2003 11:11:26 -0400 From: Daniel Veillard To: "William M. Brack" Cc: xml@gnome.org Subject: Re: [xml] Problem in valid.c Message-ID: <20031013111126.G29460@redhat.com> Reply-To: veillard@redhat.com References: <5074873$10660430933f8a86d5ed8cf4.12893472@config4.schlund.de> <20031013074341.D29460@redhat.com> <3265.219.78.248.9.1066057136.squirrel@www.delightful.com.hk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3265.219.78.248.9.1066057136.squirrel@www.delightful.com.hk>; from wbrack@mmm.com.hk on Mon, Oct 13, 2003 at 10:58:56PM +0800 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Mon, Oct 13, 2003 at 10:58:56PM +0800, William M. Brack wrote: > Ah, the problems with line numbers (CVS is a moving target) - I > think this refers to current (as of an hour or two ago) CVS valid.c > line 4978, a call to xmlErrValidWarning, with a wrong number of > arguments :-/ yeah, fixed now. Compiling the valid code without regexp, forces to use the old DTD validation code, this may not be such a good idea there was problems with that code. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From eday@obj-sys.com Mon Oct 13 13:12:33 2003 Return-Path: Delivered-To: xml@gnome.org Received: from malone.intellispace.net (malone.intellispace.net [160.79.145.141]) by mail.gnome.org (Postfix) with ESMTP id 0B6A1181DF for ; Mon, 13 Oct 2003 13:12:33 -0400 (EDT) Received: from objsys1 (66.9.62.72) by malone.intellispace.net (5.1.053) id 3F87140F00062D97; Mon, 13 Oct 2003 13:12:12 -0400 Message-ID: <013101c391ae$1bae4a50$483e0942@objsys1> From: "Ed Day" To: =?iso-8859-1?Q?St=E9phane_Bidoul?= Cc: References: <002301c38fe6$c8d024c0$0c67140a@acsesbi> Subject: Re: [xml] Differences in DOM parsing on Windows and UNIX? Date: Mon, 13 Oct 2003 13:19:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: The problem appears to be that xmlIsMainThread does not work on Solaris. I put the following diag messages into the code: #ifdef HAVE_PTHREAD_H result = (mainthread == pthread_self()); printf ("mainthread = %x, pthread_self() = %x, result = %d\n", mainthread, pthread_self(), result); return (result); /* return(mainthread == pthread_self()); */ ... The result of this printf is as follows: mainthread = 0, pthread_self() = 1, result = 0 Regards, Ed Day ----- Original Message ----- From: "Stéphane Bidoul" To: "'Ed Day'" Cc: Sent: Saturday, October 11, 2003 6:59 AM Subject: RE: [xml] Differences in DOM parsing on Windows and UNIX? > > Well, there is not that much to it. When the code was as follows: > > > > xmlInitParser(); > > xmlKeepBlanksDefault(0); > > xmlLineNumbersDefault(1); // set line numbers > > > > pXmlDoc = xmlParseFile (fileSpec); > > > > if (0 == pXmlDoc) { > > printf ("Error parsing XML file\n"); > > return 1; > > } > > > > xmlCleanupParser(); > > > > I got the blank nodes. When I changed it to: > > > > xmlInitParser(); > > #ifdef LIBXML_THREAD_ENABLED > > xmlThrDefKeepBlanksDefaultValue(0); > > #else > > xmlKeepBlanksDefault(0); > > #endif > > xmlLineNumbersDefault(1); // set line numbers > > > > pXmlDoc = xmlParseFile (fileSpec); > > > > if (0 == pXmlDoc) { > > printf ("Error parsing XML file\n"); > > return 1; > > } > > > > xmlCleanupParser(); > > > > They went away. > > I really don't see why it would be different for xmlKeepBlanksDefault > and xmlLineNumbersDefault: all globals are treated equally > in libxml (I'm pretty sure, because that code is actually generated). > You should check again, IMHO. > > > It really should not be necessary for me to have to deal with > > a #define like > > LIBXML_THREAD_ENABLED in my mainline code. > > If your program has only one thread, you don't need to. > Just have a look at xmllint.c: it only > does xmlKeepBlanksDefault(0) and that does not > depend on LIBXML_THREAD_ENABLED. > > Assume test.xml: > > > > ]> > > > > > ~>xmllint --noblanks test.xml > > > > ]> > > > If your program has several threads, either > do xmlThrDefKeepBlanksDefaultValue() before creating > your threads or do xmlKeepBlanksDefault() in each thread. > > -sbi > > _______________________________________________ > xml mailing list, project page http://xmlsoft.org/ > xml@gnome.org > http://mail.gnome.org/mailman/listinfo/xml > From breese@mail1.stofanet.dk Mon Oct 13 13:34:32 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mx02.stofanet.dk (mx02.stofanet.dk [212.10.30.232]) by mail.gnome.org (Postfix) with ESMTP id A40D5186A3 for ; Mon, 13 Oct 2003 13:34:31 -0400 (EDT) Received: from 3e6b23de.rev.stofanet.dk ([62.107.35.222]) by mx02.stofanet.dk with esmtp (Exim 4.22) id 1A96ak-0007co-0b for xml@gnome.org; Mon, 13 Oct 2003 19:34:46 +0200 From: Bjorn Reese To: xml@gnome.org Content-Type: text/plain Organization: Hyperspace Academy Message-Id: <1066066640.2059.5.camel@stellifer> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 13 Oct 2003 19:37:20 +0200 Content-Transfer-Encoding: 7bit Subject: [xml] Makefile.am patch Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Minor patch for Makefile.am (against 2-2.6.0beta6) --- Makefile.am~ Thu Oct 9 15:54:56 2003 +++ Makefile.am Mon Oct 13 10:48:46 2003 @@ -27,7 +27,7 @@ catalog.c globals.c threads.c c14n.c \ xmlregexp.c xmlschemas.c xmlschemastypes.c xmlunicode.c \ triostr.c trio.c xmlreader.c relaxng.c dict.c SAX2.c \ - legacy.c walker.c + legacy.c xmldwalk.c else libxml2_la_SOURCES = SAX.c entities.c encoding.c error.c parserInternals.c \ parser.c tree.c hash.c list.c xmlIO.c xmlmemory.c uri.c \ From veillard@redhat.com Mon Oct 13 15:47:17 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 5D5E61812C for ; Mon, 13 Oct 2003 15:47:17 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9DJlUO25335; Mon, 13 Oct 2003 15:47:30 -0400 Date: Mon, 13 Oct 2003 15:47:30 -0400 From: Daniel Veillard To: Bjorn Reese Cc: xml@gnome.org Subject: Re: [xml] Makefile.am patch Message-ID: <20031013154730.I29460@redhat.com> Reply-To: veillard@redhat.com References: <1066066640.2059.5.camel@stellifer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1066066640.2059.5.camel@stellifer>; from breese@mail1.stofanet.dk on Mon, Oct 13, 2003 at 07:37:20PM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Mon, Oct 13, 2003 at 07:37:20PM +0200, Bjorn Reese wrote: > Minor patch for Makefile.am (against 2-2.6.0beta6) Oops, right, commited ! thanks, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From Steve.Ball@zveno.com Mon Oct 13 20:11:54 2003 Return-Path: Delivered-To: xml@gnome.org Received: from waycool.zveno.com (static-ctb0236.webone.com.au [210.9.242.36]) by mail.gnome.org (Postfix) with ESMTP id 69D251813E for ; Mon, 13 Oct 2003 20:11:53 -0400 (EDT) Received: from zveno.com (pbook [192.168.0.4]) by waycool.zveno.com (8.12.8/8.12.8) with ESMTP id h9E1f0WI020578 for ; Tue, 14 Oct 2003 11:41:12 +1000 Message-ID: <3F8B3F93.5040500@zveno.com> Date: Tue, 14 Oct 2003 10:13:07 +1000 From: Steve Ball Reply-To: Steve.Ball@zveno.com Organization: Zveno Pty Ltd User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: xml@gnome.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [xml] RFE: Schema-validation API Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: The WXS module in libxml2-2.5.11 provides an interface to schema-validate an instance document, given the schema document as either a URL or in a memory buffer. However, in my project I already have the schema document as a xmlDocPtr object (ie. it is already parsed as an XML document). At the moment my code serializes the schema document into a memory buffer and then passes that buffer to xmlSchemaNewMemParserCtxt. This routine then re-parses the document. Accordingly, my RFE is to have a new API that accepts the schema document as an xmlDocPtr. Something like: xmlSchemaParserCtxtPtr xmlSchemaNewDocParserCtxt (xmlDocPtr doc); The code would be fairly straight-forward, in fact almost trivial. I can do the implementation and submit it as a patch if desired. I note that RNG validation already has a similar interface. Cheers, Steve Ball -- Steve Ball | XSLT Standard Library | Training & Seminars Zveno Pty Ltd | Web Tcl Complete | XML XSL Schemas http://www.zveno.com/ | TclXML TclDOM | Tcl, Web Development Steve.Ball@zveno.com +---------------------------+--------------------- Ph. +61 2 6242 4099 | Mobile (0413) 594 462 | Fax +61 2 6242 4099 From mh@glandium.org Tue Oct 14 01:35:26 2003 Return-Path: Delivered-To: xml@gnome.org Received: from vaio.glandium.org (i61-195-247-171.us.catvmics.ne.jp [61.195.247.171]) by mail.gnome.org (Postfix) with ESMTP id B0A941859D for ; Tue, 14 Oct 2003 01:35:25 -0400 (EDT) Received: from localhost ([127.0.0.1]) by vaio.glandium.org with esmtp (Exim 3.36 #1 (Debian)) id 1A9HqN-0001oa-00 for ; Tue, 14 Oct 2003 14:35:39 +0900 From: Mike Hommey Organization: glandium To: xml@gnome.org Subject: Re: [xml] Autotools stuff in libxml2 Date: Tue, 14 Oct 2003 14:35:37 +0900 User-Agent: KMail/1.5.3 References: <200310081931.32279.mh@glandium.org> <20031011060211.K29460@redhat.com> In-Reply-To: <20031011060211.K29460@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200310141435.37532.mh@glandium.org> Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Saturday 11 October 2003 19:02, Daniel Veillard wrote: > Now what is this gonna break ??? The standard way to initialize > the auto* stuff in libxml2 is to run autogen.sh (it's the Gnome way > of doing things). I guess autogen.sh may be doing the same thing... > I applied the patch anyway but to configure.in, no reason it would > not work Thanks > autogen.sh runs "libtoolize --copy --force", I do that at least > once a week, and always when I bump the version in configure.in, > precisely because autogen.sh is the way to rebuild the auto* from > the configure.in . Then that just means you are not using the very last autotools & libtool ;) > > PS: BTW, are you aware of the tons of "comparison is always (true|false) > > due to limited range of data type" warnings when compiling with all > > warnings enabled ? > > Apparently the optimizer got smarter and defeat a cast I made to > avoid the warnings on older versions. This will be fixed at some point. > This is totally harmless. Okay, thanks. Mike =2D-=20 "I have sampled every language, french is my favorite. Fantastic language, especially to curse with. Nom de dieu de putain de bordel de merde de saloperie de connard d'encul=E9 de ta m=E8re. It's like wiping your ass with silk! I love it." -- The Merovingian, in the Matrix Reloaded From veillard@redhat.com Tue Oct 14 03:42:18 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 7F5FF1837C for ; Tue, 14 Oct 2003 03:42:18 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9E7gQ918229; Tue, 14 Oct 2003 03:42:26 -0400 Date: Tue, 14 Oct 2003 03:42:26 -0400 From: Daniel Veillard To: Steve Ball Cc: xml@gnome.org Subject: Re: [xml] RFE: Schema-validation API Message-ID: <20031014034211.N29460@redhat.com> Reply-To: veillard@redhat.com References: <3F8B3F93.5040500@zveno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3F8B3F93.5040500@zveno.com>; from Steve.Ball@zveno.com on Tue, Oct 14, 2003 at 10:13:07AM +1000 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Tue, Oct 14, 2003 at 10:13:07AM +1000, Steve Ball wrote: > The WXS module in libxml2-2.5.11 provides an interface > to schema-validate an instance document, given the schema > document as either a URL or in a memory buffer. > However, in my project I already have the schema document > as a xmlDocPtr object (ie. it is already parsed as an XML document). > At the moment my code serializes the schema document into > a memory buffer and then passes that buffer to > xmlSchemaNewMemParserCtxt. This routine then re-parses the > document. > > Accordingly, my RFE is to have a new API that accepts the > schema document as an xmlDocPtr. Something like: > > xmlSchemaParserCtxtPtr xmlSchemaNewDocParserCtxt (xmlDocPtr doc); > > The code would be fairly straight-forward, in fact almost > trivial. I can do the implementation and submit it as a > patch if desired. Yep, should be trivial to add this entry point, I take patches :) Still I'm a bit scared that you use the Schemas implementation, I suppose it all depends on the schemas you actually use, if simple enough you may not hit any bug. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From stephane.bidoul@softwareag.com Tue Oct 14 09:24:17 2003 Return-Path: Delivered-To: xml@gnome.org Received: from server8a.software-ag.de (server8a.software-ag.de [193.26.193.47]) by mail.gnome.org (Postfix) with ESMTP id 2AB5418348 for ; Tue, 14 Oct 2003 09:24:17 -0400 (EDT) Received: from acsesbi by server8a.software-ag.de; (8.11.6/8.9.3) id h9EDOTF18348; Tue, 14 Oct 2003 15:24:29 +0200 From: "Stéphane Bidoul" To: "'Ed Day'" Cc: Subject: RE: [xml] Differences in DOM parsing on Windows and UNIX? Date: Tue, 14 Oct 2003 15:24:35 +0200 Message-ID: <002401c39256$85448990$3514200a@acsesbi> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <013101c391ae$1bae4a50$483e0942@objsys1> Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: I can't test on Solaris. Any chance you can trace what's going on in xmlOnceInit(), where mainthread is initialized? -sbi > -----Original Message----- > From: Ed Day [mailto:eday@obj-sys.com] > Sent: 13 October, 2003 19:19 > To: Stéphane Bidoul > Cc: xml@gnome.org > Subject: Re: [xml] Differences in DOM parsing on Windows and UNIX? > > > The problem appears to be that xmlIsMainThread does not work > on Solaris. I > put the following diag messages into the code: > > #ifdef HAVE_PTHREAD_H > result = (mainthread == pthread_self()); > printf ("mainthread = %x, pthread_self() = %x, result = %d\n", > mainthread, pthread_self(), result); > return (result); > /* return(mainthread == pthread_self()); */ > ... > > The result of this printf is as follows: > > mainthread = 0, pthread_self() = 1, result = 0 > > Regards, > > Ed Day > > ----- Original Message ----- > From: "Stéphane Bidoul" > To: "'Ed Day'" > Cc: > Sent: Saturday, October 11, 2003 6:59 AM > Subject: RE: [xml] Differences in DOM parsing on Windows and UNIX? > > > > > Well, there is not that much to it. When the code was as follows: > > > > > > xmlInitParser(); > > > xmlKeepBlanksDefault(0); > > > xmlLineNumbersDefault(1); // set line numbers > > > > > > pXmlDoc = xmlParseFile (fileSpec); > > > > > > if (0 == pXmlDoc) { > > > printf ("Error parsing XML file\n"); > > > return 1; > > > } > > > > > > xmlCleanupParser(); > > > > > > I got the blank nodes. When I changed it to: > > > > > > xmlInitParser(); > > > #ifdef LIBXML_THREAD_ENABLED > > > xmlThrDefKeepBlanksDefaultValue(0); > > > #else > > > xmlKeepBlanksDefault(0); > > > #endif > > > xmlLineNumbersDefault(1); // set line numbers > > > > > > pXmlDoc = xmlParseFile (fileSpec); > > > > > > if (0 == pXmlDoc) { > > > printf ("Error parsing XML file\n"); > > > return 1; > > > } > > > > > > xmlCleanupParser(); > > > > > > They went away. > > > > I really don't see why it would be different for > xmlKeepBlanksDefault > > and xmlLineNumbersDefault: all globals are treated equally > > in libxml (I'm pretty sure, because that code is actually > generated). > > You should check again, IMHO. > > > > > It really should not be necessary for me to have to deal with > > > a #define like > > > LIBXML_THREAD_ENABLED in my mainline code. > > > > If your program has only one thread, you don't need to. > > Just have a look at xmllint.c: it only > > does xmlKeepBlanksDefault(0) and that does not > > depend on LIBXML_THREAD_ENABLED. > > > > Assume test.xml: > > > > > > > > > ]> > > > > > > > > > > ~>xmllint --noblanks test.xml > > > > > > > > > ]> > > > > > > If your program has several threads, either > > do xmlThrDefKeepBlanksDefaultValue() before creating > > your threads or do xmlKeepBlanksDefault() in each thread. > > > > -sbi > > > > _______________________________________________ > > xml mailing list, project page http://xmlsoft.org/ > > xml@gnome.org > > http://mail.gnome.org/mailman/listinfo/xml > > From rothwell@holly-springs.nc.us Tue Oct 14 15:35:07 2003 Return-Path: Delivered-To: xml@gnome.org Received: from ns.holly-springs.nc.us (NS.HOLLY-SPRINGS.NC.US [207.198.61.36]) by mail.gnome.org (Postfix) with ESMTP id 5E0CB18B09 for ; Tue, 14 Oct 2003 15:35:07 -0400 (EDT) Received: from holly-springs.nc.us (gwe.abanes.org [216.54.200.242]) (authenticated bits=0) by ns.holly-springs.nc.us (8.12.8/8.12.8) with ESMTP id h9EJEpij019189 for ; Tue, 14 Oct 2003 15:14:51 -0400 Message-ID: <3F8C4FF4.1000101@holly-springs.nc.us> Date: Tue, 14 Oct 2003 15:35:16 -0400 From: Michael Rothwell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: xml@gnome.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [xml] WBXML -- "Binary XML" Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: WAP Binary XML Content Format http://www.w3.org/TR/wbxml/ It would be interesting for LibXML to support wbxml. People occasionally ask if the in-memory tree format can be saved to disk as a chunk. This wouldn't be exactly that, but something like it. From veillard@redhat.com Tue Oct 14 17:55:23 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 0B7781853C for ; Tue, 14 Oct 2003 17:55:23 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9ELtbH30682; Tue, 14 Oct 2003 17:55:37 -0400 Date: Tue, 14 Oct 2003 17:55:37 -0400 From: Daniel Veillard To: Michael Rothwell Cc: xml@gnome.org Subject: Re: [xml] WBXML -- "Binary XML" Message-ID: <20031014175537.W29460@redhat.com> Reply-To: veillard@redhat.com References: <3F8C4FF4.1000101@holly-springs.nc.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3F8C4FF4.1000101@holly-springs.nc.us>; from rothwell@holly-springs.nc.us on Tue, Oct 14, 2003 at 03:35:16PM -0400 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Tue, Oct 14, 2003 at 03:35:16PM -0400, Michael Rothwell wrote: > > WAP Binary XML Content Format > http://www.w3.org/TR/wbxml/ > > It would be interesting for LibXML to support wbxml. People occasionally > ask if the in-memory tree format can be saved to disk as a chunk. This > wouldn't be exactly that, but something like it. Sorry, I very reluctant toward "Binary XML" in general and the WAP version is probably the worse I can think of (tokenization based on a predefined XML vocabulary !) If people have a need for "saving the in-memory tree format", then they can come here and try to argue, they better have good reasons to do such a thing, but so far I really not convinced. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From liam@holoweb.net Tue Oct 14 20:16:48 2003 Return-Path: Delivered-To: xml@gnome.org Received: from dirk.holoweb.net (unknown [216.94.134.20]) by mail.gnome.org (Postfix) with ESMTP id 2E949180F8 for ; Tue, 14 Oct 2003 20:16:48 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by dirk.holoweb.net (Postfix) with ESMTP id 83D0C6A1EC for ; Tue, 14 Oct 2003 20:15:29 -0400 (EDT) Subject: Re: [xml] WBXML -- "Binary XML" From: "Liam R. E. Quin" To: xml@gnome.org In-Reply-To: <20031014175537.W29460@redhat.com> References: <3F8C4FF4.1000101@holly-springs.nc.us> <20031014175537.W29460@redhat.com> Content-Type: text/plain Organization: W3C Message-Id: <1066176908.6341.69.camel@lapper> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4-9mdk Date: Tue, 14 Oct 2003 20:15:08 -0400 Content-Transfer-Encoding: 7bit Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Tue, 2003-10-14 at 17:55, Daniel Veillard wrote: > Sorry, I very reluctant toward "Binary XML" in general [...] We (W3C) just held a workshop on the subject of binary interchange of XML Information Set Items... the results will be public at the end of October. I think it is fair to say there is no consensus right now on a single binary format, but, if there is a consensus, it's that it's not WAP :-) Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ From craigberry@mac.com Tue Oct 14 23:34:16 2003 Return-Path: Delivered-To: xml@gnome.org Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.84]) by mail.gnome.org (Postfix) with ESMTP id 65E95181B8 for ; Tue, 14 Oct 2003 23:34:16 -0400 (EDT) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id h9F3cWfX005158; Tue, 14 Oct 2003 20:38:32 -0700 (PDT) Received: from [64.24.114.122] (dialup-67.73.150.167.dial1.chicago1.level3.net [67.73.150.167]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 3.0) with ESMTP id h9F3YQbo013231; Tue, 14 Oct 2003 20:34:27 -0700 (PDT) Mime-Version: 1.0 X-Sender: craigberry@mail.mac.com Message-Id: Date: Tue, 14 Oct 2003 22:34:21 -0500 To: xml@gnome.org From: "Craig A. Berry" Cc: breese@mail1.stofanet.dk Content-Type: multipart/mixed; boundary="============_-1145933619==_============" Subject: [xml] [PATCH] minor VMS build update Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: --============_-1145933619==_============ Content-Type: text/plain; charset="us-ascii" This is against a recent CVS snapshot and mostly just updates the list of files that get built. I've cc'd Bjorn because the first hunk also tweaks trionan.c, where trio_fpclassify has been #ifdef'd out of existence (as has its prototype in trionan.h) but this one reference to it in the STANDALONE case was still present. Replacing it with the TRIO_FPCLASSIFY macro as I've done may or may not be the right thing to do as there could in principle be platforms where the macro is not defined and there is no fallback. -- ________________________________________ Craig A. Berry mailto:craigberry@mac.com "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser --============_-1145933619==_============ Content-Id: Content-Type: multipart/appledouble; boundary="============_-1145933619==_D============" --============_-1145933619==_D============ Content-Transfer-Encoding: base64 Content-Type: application/applefile; name="%vmsxml.patch" Content-Disposition: attachment; filename="%vmsxml.patch" ; modification-date="Tue, 14 Oct 2003 21:30:32 -0500" AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAADAAAAPgAAAAwAAAAJAAAASgAAACAA AAAIAAAAagAAABB2bXN4bWwucGF0Y2gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAcfJ3gHHyd4S20MAAcfNn0= --============_-1145933619==_D============ Content-Type: application/octet-stream; name="vmsxml.patch" Content-Disposition: attachment; filename="vmsxml.patch" Content-Transfer-Encoding: base64 LS0tIHRyaW9uYW4uYzstMAlUaHUgQXVnIDE0IDAyOjMxOjExIDIwMDMKKysrIHRyaW9u YW4uYwlUdWUgT2N0IDE0IDIwOjM5OjU1IDIwMDMKQEAgLTc5OCw3ICs3OTgsNyBAQAog ICBwcmludGYoIiUtNnM6ICVzICUtMTVzICVnXG4iLAogCSBwcmVmaXgsCiAJIHRyaW9f c2lnbmJpdChudW1iZXIpID8gIi0iIDogIisiLAotCSBnZXRDbGFzc2lmaWNhdGlvbih0 cmlvX2ZwY2xhc3NpZnkobnVtYmVyKSksCisJIGdldENsYXNzaWZpY2F0aW9uKFRSSU9f RlBDTEFTU0lGWShudW1iZXIpKSwKIAkgbnVtYmVyKTsKIH0KIAotLS0gdm1zL2J1aWxk X2xpYnhtbC5jb207LTAJU2F0IEFwciAyNiAwMjozMzoxMCAyMDAzCisrKyB2bXMvYnVp bGRfbGlieG1sLmNvbQlUdWUgT2N0IDE0IDIwOjQyOjU1IDIwMDMKQEAgLTE1LDcgKzE1 LDkgQEAKICQhIENoYW5nZSBIaXN0b3J5CiAkISAtLS0tLS0tLS0tLS0tLQogJCEgQ29t bWFuZCBmaWxlIGF1dGhvciA6IEpvaG4gQSBGb3RoZXJpbmdoYW0gKGphZkBqYWZzb2Z0 LmNvbSkKLSQhIFVwZGF0ZSBoaXN0b3J5ICAgICAgOiAyNSBBcHJpbCAyMDAzCQlDcmFp ZyBCZXJyeSAoY3JhaWdiZXJyeUBtYWMuY29tKQorJCEgVXBkYXRlIGhpc3RvcnkgICAg ICA6IDEzIE9jdG9iZXIgMjAwMwlDcmFpZyBCZXJyeSAoY3JhaWdiZXJyeUBtYWMuY29t KQorJCEJCQkgbW9yZSBuZXcgbW9kdWxlIGFkZGl0aW9ucworJCEgICAgICAgICAgICAg ICAgICAgICA6IDI1IEFwcmlsIDIwMDMJCUNyYWlnIEJlcnJ5IChjcmFpZ2JlcnJ5QG1h Yy5jb20pCiAkIQkJCSBhZGRlZCB4bWxyZWFkZXIuYyBhbmQgcmVsYXhuZy5jIHRvIHNv dXJjZSBsaXN0CiAkISAJCSAgICAgICA6IDI4IFNlcHRlbWJlciAyMDAyCUNyYWlnIEJl cnJ5IChjcmFpZ2JlcnJ5QG1hYy5jb20pCiAkIQkJCSB1cGRhdGVkIHRvIHdvcmsgd2l0 aCBjdXJyZW50IHNvdXJjZXMKQEAgLTQ2LDcgKzQ4LDggQEAKICQgICBzb3VyY2VzID0g c291cmNlcyArICIgeHBvaW50ZXIuYyB4aW5jbHVkZS5jIG5hbm9odHRwLmMgbmFub2Z0 cC5jICIKICQgICBzb3VyY2VzID0gc291cmNlcyArICIgRE9DQnBhcnNlci5jIGNhdGFs b2cuYyBnbG9iYWxzLmMgdGhyZWFkcy5jIGMxNG4uYyAiCiAkICAgc291cmNlcyA9IHNv dXJjZXMgKyAiIHhtbHJlZ2V4cC5jIHhtbHNjaGVtYXMuYyB4bWxzY2hlbWFzdHlwZXMu YyB4bWx1bmljb2RlLmMgIgotJCAgIHNvdXJjZXMgPSBzb3VyY2VzICsgIiB0cmlvc3Ry LmMgdHJpby5jIHhtbHJlYWRlci5jIHJlbGF4bmcuYyIKKyQgICBzb3VyY2VzID0gc291 cmNlcyArICIgdHJpb3N0ci5jIHRyaW8uYyB4bWxyZWFkZXIuYyByZWxheG5nLmMgZGlj dC5jIFNBWDIuYyIKKyQgICBzb3VyY2VzID0gc291cmNlcyArICIgbGVnYWN5LmMgeG1s ZHdhbGsuYyBjaHZhbGlkLmMiCiAkIQogJCEtIGxpc3Qgb2YgbWFpbiBtb2R1bGVzIHRv IGNvbXBpbGUgYW5kIGxpbmsuICBDb21wYXJlIHRoaXMgbGlzdCB0byB0aGUKICQhICBk ZWZpbml0aW9uIG9mIGJpbl9QUk9HUkFNUyBpbiBNQUtFRklMRS5JTgpAQCAtNTYsOCAr NTksOCBAQAogJCEtIGxpc3Qgb2YgdGVzdCBtb2R1bGVzIHRvIGNvbXBpbGUgYW5kIGxp bmsuICBDb21wYXJlIHRoaXMgbGlzdCB0byB0aGUKICQhICBkZWZpbml0aW9uIG9mIG5v aW5zdF9QUk9HUkFNUyBpbiBNQUtFRklMRS4KICQhCi0kICAgbm9pbnN0X1BST0dSQU1T ID0gInRlc3RTY2hlbWFzIHRlc3RTQVggdGVzdEhUTUwgdGVzdFhQYXRoIHRlc3RVUkkg dGVzdERvY2Jvb2sgIiAtCi0gICAgICAgICAgICAgICAgKyAidGVzdFRocmVhZHMgdGVz dEMxNE4gdGVzdEF1dG9tYXRhIHRlc3RSZWdleHAiCiskICAgbm9pbnN0X1BST0dSQU1T ID0gInRlc3RTY2hlbWFzIHRlc3RSZWxheCB0ZXN0U0FYIHRlc3RIVE1MIHRlc3RYUGF0 aCB0ZXN0VVJJICIgLQorICAgICAgICAgICAgICAgICsgInRlc3RUaHJlYWRzIHRlc3RD MTROIHRlc3RBdXRvbWF0YSB0ZXN0UmVnZXhwIHRlc3RSZWFkZXIiCiAkIQogJCEtIHNl dCB1cCBidWlsZCBsb2dpY2FscyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLVwKICQhCg== --============_-1145933619==_D============-- --============_-1145933619==_============-- From veillard@redhat.com Wed Oct 15 04:13:31 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 69C991814E for ; Wed, 15 Oct 2003 04:13:31 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9F8Djs08660; Wed, 15 Oct 2003 04:13:45 -0400 Date: Wed, 15 Oct 2003 04:13:45 -0400 From: Daniel Veillard To: "Liam R. E. Quin" Cc: xml@gnome.org Subject: Re: [xml] WBXML -- "Binary XML" Message-ID: <20031015041345.X29460@redhat.com> Reply-To: veillard@redhat.com References: <3F8C4FF4.1000101@holly-springs.nc.us> <20031014175537.W29460@redhat.com> <1066176908.6341.69.camel@lapper> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1066176908.6341.69.camel@lapper>; from liam@holoweb.net on Tue, Oct 14, 2003 at 08:15:08PM -0400 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Tue, Oct 14, 2003 at 08:15:08PM -0400, Liam R. E. Quin wrote: > On Tue, 2003-10-14 at 17:55, Daniel Veillard wrote: > > Sorry, I very reluctant toward "Binary XML" in general > [...] > > We (W3C) just held a workshop on the subject of binary interchange of > XML Information Set Items... the results will be public at the end > of October. > > I think it is fair to say there is no consensus right now on a single > binary format, but, if there is a consensus, it's that it's not WAP :-) Right, though the use case suggested might be very different: "in-memory tree format can be saved to disk as a chunk" it seems to me that this doesn't necessary requires any interchange, but rather a way to avoid processing costs. Libxml2 has no database back-end, that mean the data must be kept in memory or is purely volatile. Hard to tell what is really at stake, hence my request to get direct feedback here, I will of course read your conclusions from the workshop :-) But some of the use cases like avoiding to reparse a large document to extract a fragment or being able to process documents as tree even if they don't fit in the virtual memory are IMHO better solved by ways to plug a database back-end than by trying to serialize a binary result. Of course it's all a matter of perspective, a database table and indexes are binaries entities, but they are not XML, and from a libxml2 perspective it becomes an API problem, not a format one, which I feel quite more comfortable with. Yours, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From oliverst@online.de Wed Oct 15 04:37:49 2003 Return-Path: Delivered-To: xml@gnome.org Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mail.gnome.org (Postfix) with ESMTP id 815AE1823B for ; Wed, 15 Oct 2003 04:37:49 -0400 (EDT) Received: from [212.227.126.202] (helo=mrvnet.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1A9hAS-00070s-00 for xml@gnome.org; Wed, 15 Oct 2003 10:38:04 +0200 Received: from [172.23.4.134] (helo=config7.kundenserver.de) by mrvnet.kundenserver.de with esmtp (Exim 3.35 #1) id 1A9hAS-0007MO-00 for xml@gnome.org; Wed, 15 Oct 2003 10:38:04 +0200 Received: from www-data by config7.kundenserver.de with local (Exim 3.35 #1 (Debian)) id 1A9hAS-00058D-00 for ; Wed, 15 Oct 2003 10:38:04 +0200 To: From: Message-Id: <5074873$10662065463f8d0552d23dd4.44535502@config7.schlund.de> X-Binford: 6100 (more power) X-Originating-From: 5074873 X-Mailer: Webmail X-Routing: DE X-Received: from config7 by 213.252.152.112 with HTTP id 5074873 for xml@gnome.org; Wed, 15 Oct 2003 10:36:01 +0200 Content-Type: text/plain; charset="iso-8859-1" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Priority: 3 Date: Wed, 15 Oct 2003 10:36:01 +0200 Subject: [xml] Access Violation when using TLS Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: I had problems with a native threads libxml2 (after the DLL I used the libxml2 in was removed from memory, the process, that called the DLL got Access Violations), so I tried the TLS compiled one and I didn't ran into those problems anymore. But now it crashes with an Access Violation in threads.c:381 in the function xmlGetGlobalState() after being called from globals.c:73, the initial call was xmlParseMemory(). Did anyone happen to have a similar problem? I am using the libxml2 2.5.11. Haven't tried it with 2.6.0beta6 yet... From veillard@redhat.com Wed Oct 15 04:42:03 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 726291823B for ; Wed, 15 Oct 2003 04:42:03 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9F8gHa17195; Wed, 15 Oct 2003 04:42:17 -0400 Date: Wed, 15 Oct 2003 04:42:17 -0400 From: Daniel Veillard To: "Craig A. Berry" Cc: xml@gnome.org, breese@mail1.stofanet.dk Subject: Re: [xml] [PATCH] minor VMS build update Message-ID: <20031015044217.A16905@redhat.com> Reply-To: veillard@redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from craigberry@mac.com on Tue, Oct 14, 2003 at 10:34:21PM -0500 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Tue, Oct 14, 2003 at 10:34:21PM -0500, Craig A. Berry wrote: > This is against a recent CVS snapshot and mostly just updates the > list of files that get built. Thanks ! Applied and commited, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From shiguo.qin@sw-linux.com Wed Oct 15 04:35:46 2003 Return-Path: Delivered-To: xml@gnome.org Received: from nut.sw-linux.com (unknown [202.153.106.250]) by mail.gnome.org (Postfix) with ESMTP id D06B71823B for ; Wed, 15 Oct 2003 04:35:45 -0400 (EDT) Received: from [220.196.129.9] (helo=qsg) by nut.sw-linux.com with asmtp (Exim 3.35 #1 (Debian)) id 1A9h8R-0005YU-00 for ; Wed, 15 Oct 2003 16:35:59 +0800 Message-ID: <001401c392f7$09171170$950aa8c0@qsg> Reply-To: =?utf-8?B?6KaD5aOr5Zu9?= From: =?utf-8?B?6KaD5aOr5Zu9?= To: Date: Wed, 15 Oct 2003 16:33:38 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C3933A.166AF380" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4927.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Subject: [xml] about xmlNodeListGetString,about how to recognize Chinese? Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C3933A.166AF380 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 aGksYWxsDQoNCkkgaGF2ZSBhIENoaW5lc2UgeG1sIGZpbGUuRm9yIGV4YW1wbGU6DQoNCjw/eG1s IHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IkdCMjMxMiIgPz4NCjxzbXN4bWw+DQogPHNtcz4NCiAg PHBob25lPjEzODE0MDQ2OTI2PC9waG9uZT4NCiAgPG1zZz5ISe+8jOS9oOWlveOAgui/meaYr1NN UyBERU1P5rWL6K+VSeOAgjwvbXNnPg0KIDwvc21zPg0KPC9zbXN4bWw+DQoNCndoZW4gaSB1c2Ug eG1sTm9kZUxpc3RHZXRTdHJpbmcsaSBnb3QgYW4gdW5ub3JtYWwgdmFsdWUgb2YgbXNnIGlzIHVu bm9ybWFsIG51bWJlci5pIGp1c3Qgd2FudCB0byBrbm93IHRoZSBvcmdpbmFsIGluZm9ybWF0aW9u KEhJ77yM5L2g5aW944CC6L+Z5pivU01TIERFTU/mtYvor5VJ44CCKSxzbyB3aGF0IGNhbiBpIGRv ID8NCg0KZ3JlZXQhDQoNClNoaWd1byBRaW4NCg== ------=_NextPart_000_0011_01C3933A.166AF380 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0 Zi04IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA1LjAw LjM4MDkuMTgwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxC T0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPmhpLGFsbDwvRk9OVD48L0RJ Vj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkkgaGF2ZSBhIENoaW5lc2UgeG1sIGZpbGUuRm9y IGV4YW1wbGU6PC9ESVY+DQo8RElWPjxCUj4mbHQ7P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5n PSJHQjIzMTIiIA0KPyZndDs8QlI+Jmx0O3Ntc3htbCZndDs8QlI+Jm5ic3A7Jmx0O3NtcyZndDs8 QlI+Jm5ic3A7Jm5ic3A7Jmx0O3Bob25lJmd0OzEzODE0MDQ2OTI2Jmx0Oy9waG9uZSZndDs8QlI+ Jm5ic3A7Jm5ic3A7Jmx0O21zZyZndDtISe+8jOS9oOWlveOAgui/meaYr1NNUyANCkRFTU/mtYvo r5VJ44CCJmx0Oy9tc2cmZ3Q7PEJSPiZuYnNwOyZsdDsvc21zJmd0OzxCUj4mbHQ7L3Ntc3htbCZn dDs8L0RJVj4NCjxESVY+PEJSPndoZW4gaSB1c2UgeG1sTm9kZUxpc3RHZXRTdHJpbmcsaSBnb3Qg YW4gdW5ub3JtYWwgdmFsdWUgb2YgbXNnIGlzIA0KdW5ub3JtYWwgbnVtYmVyLmkganVzdCB3YW50 IHRvIGtub3cgdGhlIG9yZ2luYWwgaW5mb3JtYXRpb24oSEnvvIzkvaDlpb3jgILov5nmmK9TTVMg DQpERU1P5rWL6K+VSeOAgiksc28gd2hhdCBjYW4gaSBkbyA/PC9ESVY+DQo8RElWPiZuYnNwOzwv RElWPg0KPERJVj5ncmVldCE8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPlNoaWd1byBR aW48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0011_01C3933A.166AF380-- From oliverst@online.de Wed Oct 15 04:47:47 2003 Return-Path: Delivered-To: xml@gnome.org Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.189]) by mail.gnome.org (Postfix) with ESMTP id 2B82F1864B for ; Wed, 15 Oct 2003 04:47:47 -0400 (EDT) Received: from [212.227.126.200] (helo=mrvnet.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1A9hK6-0002vB-00 for xml@gnome.org; Wed, 15 Oct 2003 10:48:02 +0200 Received: from [172.23.4.145] (helo=config18.kundenserver.de) by mrvnet.kundenserver.de with esmtp (Exim 3.35 #1) id 1A9hK6-0005n7-00 for xml@gnome.org; Wed, 15 Oct 2003 10:48:02 +0200 Received: from www-data by config18.kundenserver.de with local (Exim 3.35 #1 (Debian)) id 1A9hK5-0002xl-00 for ; Wed, 15 Oct 2003 10:48:01 +0200 To: Subject: Re: [xml] Access Violation when using TLS From: Message-Id: <5074873$10662072573f8d0819da94d5.36609467@config18.schlund.de> X-Binford: 6100 (more power) X-Originating-From: 5074873 X-Mailer: Webmail X-Routing: DE X-Received: from config18 by 213.252.152.112 with HTTP id 5074873 for xml@gnome.org; Wed, 15 Oct 2003 10:46:01 +0200 Content-Type: text/plain; charset="iso-8859-1" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Priority: 3 Date: Wed, 15 Oct 2003 10:46:01 +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: I just tried it with the 2.6.0beta6 (and the missing argument fix to be able to compilt it) and it now crashes in the same file, the same function and the the initial call was also xmlParseMemory as well. It just crashes in line 397 now. I am using MSVC6, libxml2 2.6.0beta6 (plus the mentioned fix), iconv included, static build and TLS threads. From veillard@redhat.com Wed Oct 15 04:53:09 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id C7D8318BF8 for ; Wed, 15 Oct 2003 04:53:08 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9F8rIj21154; Wed, 15 Oct 2003 04:53:18 -0400 Date: Wed, 15 Oct 2003 04:53:18 -0400 From: Daniel Veillard To: shiguo.qin@sw-linux.com Cc: xml@gnome.org Subject: Re: [xml] about xmlNodeListGetString,about how to recognize Chinese? Message-ID: <20031015045318.B16905@redhat.com> Reply-To: veillard@redhat.com References: <001401c392f7$09171170$950aa8c0@qsg> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <001401c392f7$09171170$950aa8c0@qsg>; from shiguo.qin@sw-linux.com on Wed, Oct 15, 2003 at 04:33:38PM +0800 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, Oct 15, 2003 at 04:33:38PM +0800, ??? wrote: > hi,all > > I have a Chinese xml file.For example: > > > > > 13814046926 > HI，你好。这是SMS DEMO测试I。 > > > > when i use xmlNodeListGetString,i got an unnormal value of msg is unnormal number.i just want to know the orginal information(HI，你好。这是SMS DEMO测试I。),so what can i do ? You will get UTF-8 content. Libxml2 automatically convert to the internal UTF-8 format independantly of the initial encoding, please read http://xmlsoft.org/encoding.html for more informations Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From oliverst@online.de Wed Oct 15 04:59:51 2003 Return-Path: Delivered-To: xml@gnome.org Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mail.gnome.org (Postfix) with ESMTP id 2090218515 for ; Wed, 15 Oct 2003 04:59:51 -0400 (EDT) Received: from [212.227.126.203] (helo=mrvnet.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1A9hVm-0002bQ-00 for xml@gnome.org; Wed, 15 Oct 2003 11:00:06 +0200 Received: from [172.23.4.129] (helo=config2.kundenserver.de) by mrvnet.kundenserver.de with esmtp (Exim 3.35 #1) id 1A9hVl-0004Ze-00 for xml@gnome.org; Wed, 15 Oct 2003 11:00:05 +0200 Received: from www-data by config2.kundenserver.de with local (Exim 3.35 #1 (Debian)) id 1A9hVl-0000H7-00 for ; Wed, 15 Oct 2003 11:00:05 +0200 To: Subject: Re: [xml] Access Violation when using TLS From: Message-Id: <5074873$10662080343f8d0b22251072.77124453@config2.schlund.de> X-Binford: 6100 (more power) X-Originating-From: 5074873 X-Mailer: Webmail X-Routing: DE X-Received: from config2 by 213.252.152.112 with HTTP id 5074873 for xml@gnome.org; Wed, 15 Oct 2003 10:58:01 +0200 Content-Type: text/plain; charset="iso-8859-1" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Priority: 3 Date: Wed, 15 Oct 2003 10:58:01 +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: OK, I just read about those older threading patches and about the "LIBXML_STATIC_FOR_DLL" define. So I added the define, compiled the 2.6.0beta6 again and it still crashes at line 397 in threads.c. From liyanage@access.ch Wed Oct 15 05:35:49 2003 Return-Path: Delivered-To: xml@gnome.org Received: from primus.futurelab.ch (host-179.futurelab.ch [62.2.169.179]) by mail.gnome.org (Postfix) with ESMTP id 6EA0618104 for ; Wed, 15 Oct 2003 05:35:48 -0400 (EDT) Received: from [192.168.169.5] (primavera.futurelab.ch [192.168.169.5]) by primus.futurelab.ch (8.12.10/8.12.10/fL-3.7) with ESMTP id h9F9a32h021384 for ; Wed, 15 Oct 2003 11:36:03 +0200 Mime-Version: 1.0 (Apple Message framework v604) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: xml@gnome.org From: Marc Liyanage Date: Wed, 15 Oct 2003 11:36:02 +0200 X-Mailer: Apple Mail (2.604) Subject: [xml] Possible improvement for xmlCleanupParser Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi there, Would it be possible to include calls to xmlCleanupInputCallbacks() and xmlCleanupOutputCallbacks() in xmlCleanupParser()? That way, a user of the library who needs to reset everything would only have to make one cleanup call, not three. Is there a reason for not making the two additional calls? A friend here at work just debugged a hard to find problem with Apache 2 and the corresponding mod_perl and the XML::LibXML Perl module. It was in the scheme match/open/close/read callback code / table. mod_perl loads the module code and the libxml library gets initialized, including some perl-specific match/open/close/read callback pointers to code in the scheme handler table. Then for some reason mod_perl unloads the perl module (XS) code again and reloads it at a different location. The old pointers in the libxml tables are not cleared out by a call to xmlCleanupParser(), and the new (valid) ones which are registered a second time get added to the top of the table. Now, when some code tries to access a resource with e.g. file://, the code works its way down the stack to the corresponding (default) entry in that table, but it crashes before getting there because of the (now invalid) code pointers into the already unloaded module in the middle of the stack. -Marc _________________________________________________________________ Marc Liyanage futureLAB AG phone: +41 52 260 22 10 mliyanage@futurelab.ch fax: +41 52 260 22 23 http://www.futurelab.ch mobile: +41 76 554 22 10 _________________________________________________________________ From mliyanage@futurelab.ch Wed Oct 15 05:21:27 2003 Return-Path: Delivered-To: xml@gnome.org Received: from primus.futurelab.ch (host-179.futurelab.ch [62.2.169.179]) by mail.gnome.org (Postfix) with ESMTP id C9E021814E for ; Wed, 15 Oct 2003 05:21:26 -0400 (EDT) Received: from [192.168.169.5] (primavera.futurelab.ch [192.168.169.5]) by primus.futurelab.ch (8.12.10/8.12.10/fL-3.7) with ESMTP id h9F9Lf2h021147 for ; Wed, 15 Oct 2003 11:21:41 +0200 Mime-Version: 1.0 (Apple Message framework v604) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: xml@gnome.org From: Marc Liyanage Date: Wed, 15 Oct 2003 11:21:39 +0200 X-Mailer: Apple Mail (2.604) Subject: [xml] Possible improvement for xmlCleanupParser Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi there, Would it be possible to include calls to xmlCleanupInputCallbacks() and xmlCleanupOutputCallbacks() in xmlCleanupParser()? That way, a user of the library who needs to reset everything would only have to make one cleanup call, not three. Is there a reason for not making the two additional calls? A friend here at work just debugged a hard to find problem with Apache 2 and the corresponding mod_perl and the XML::LibXML Perl module. It was in the scheme match/open/close/read callback code / table. mod_perl loads the module code and the libxml library gets initialized, including some perl-specific match/open/close/read callback pointers to code in the scheme handler table. Then for some reason mod_perl unloads the perl module (XS) code again and reloads it at a different location. The old pointers in the libxml tables are not cleared out by a call to xmlCleanupParser(), and the new (valid) ones which are registered a second time get added to the top of the table. Now, when some code tries to access a resource with e.g. file://, the code works its way down the stack to the corresponding (default) entry in that table, but it crashes before getting there because of the (now invalid) code pointers into the already unloaded module in the middle of the stack. -Marc _________________________________________________________________ Marc Liyanage futureLAB AG phone: +41 52 260 22 10 mliyanage@futurelab.ch fax: +41 52 260 22 23 http://www.futurelab.ch mobile: +41 76 554 22 10 _________________________________________________________________ From veillard@redhat.com Wed Oct 15 06:49:03 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id AA06418C8C for ; Wed, 15 Oct 2003 06:49:02 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9FAnGq31140; Wed, 15 Oct 2003 06:49:16 -0400 Date: Wed, 15 Oct 2003 06:49:16 -0400 From: Daniel Veillard To: Marc Liyanage Cc: xml@gnome.org Subject: Re: [xml] Possible improvement for xmlCleanupParser Message-ID: <20031015064916.C16905@redhat.com> Reply-To: veillard@redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from liyanage@access.ch on Wed, Oct 15, 2003 at 11:36:02AM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, Oct 15, 2003 at 11:36:02AM +0200, Marc Liyanage wrote: > > Hi there, > > Would it be possible to include calls to xmlCleanupInputCallbacks() and > xmlCleanupOutputCallbacks() in xmlCleanupParser()? > That way, a user of the library who needs to reset everything would > only have to make one cleanup call, not three. > Is there a reason for not making the two additional calls? it's just an oversight, no reason why those are missing. I added xmlCleanupInputCallbacks(); #ifdef LIBXML_OUTPUT_ENABLED xmlCleanupOutputCallbacks(); #endif and commited. thanks for the heads-up ! Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From spinmar@interfree.it Wed Oct 15 07:54:23 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail2a.webresidence.it (mail1.webmessenger.it [193.70.193.50]) by mail.gnome.org (Postfix) with ESMTP id 1DD3B184DF for ; Wed, 15 Oct 2003 07:54:23 -0400 (EDT) Received: from interfree.it (193.76.233.91) by mail2a.webresidence.it (7.0.019) (authenticated as m.spinetti@pisa.iol.it) id 3F58B6AC0000B610; Wed, 15 Oct 2003 13:54:37 +0200 Message-ID: <3F8D3636.3020104@interfree.it> Date: Wed, 15 Oct 2003 13:57:42 +0200 From: Marco Spinetti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: xml@gnome.org Cc: Marc Liyanage Subject: Re: [xml] Possible improvement for xmlCleanupParser References: <20031015064916.C16905@redhat.com> In-Reply-To: <20031015064916.C16905@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Does this problem regard to libxml2 version 2.4.30 and 2.5.11? --Marco Daniel Veillard wrote: >On Wed, Oct 15, 2003 at 11:36:02AM +0200, Marc Liyanage wrote: > > >>Hi there, >> >>Would it be possible to include calls to xmlCleanupInputCallbacks() and >>xmlCleanupOutputCallbacks() in xmlCleanupParser()? >>That way, a user of the library who needs to reset everything would >>only have to make one cleanup call, not three. >>Is there a reason for not making the two additional calls? >> >> > > it's just an oversight, no reason why those are missing. >I added > xmlCleanupInputCallbacks(); >#ifdef LIBXML_OUTPUT_ENABLED > xmlCleanupOutputCallbacks(); >#endif > > and commited. > > thanks for the heads-up ! > >Daniel > > > From jsp@PKC.com Wed Oct 15 09:15:49 2003 Return-Path: Delivered-To: xml@gnome.org Received: from pkc.com (unknown [216.75.143.162]) by mail.gnome.org (Postfix) with ESMTP id 348FD1820C for ; Wed, 15 Oct 2003 09:15:49 -0400 (EDT) Message-ID: <70d9c6eef6387544f06445a720fcc2d63f8d4894@pkc.com> From: Jesse Pelton To: "'oliverst@online.de'" , xml@gnome.org Subject: RE: [xml] Access Violation when using TLS Date: Wed, 15 Oct 2003 09:16:02 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: I'm not clear about your whole scenario, but here are a couple of thoughts and questions. First, are you sure you need to be using LIBXML_STATIC_FOR_DLL? It's intended for the case where libxml is statically linked into a DLL. It sounds like that may be what you're doing, but I'm not sure. Second, LIBXML_STATIC_FOR_DLL has no effect if you're using compiler TLS, as you must be doing if you're crashing in line 397. Try disabling compiler TLS. > -----Original Message----- > From: oliverst@online.de [mailto:oliverst@online.de] > Sent: Wednesday, October 15, 2003 4:58 AM > To: xml@gnome.org > Subject: Re: [xml] Access Violation when using TLS > > > > OK, I just read about those older threading patches and about the > "LIBXML_STATIC_FOR_DLL" define. So I added the define, compiled the > 2.6.0beta6 again and it still crashes at line 397 in threads.c. From Murray.Cumming@Comneon.com Wed Oct 15 10:40:53 2003 Return-Path: Delivered-To: xml@gnome.org Received: from smtp1.infineon.com (smtp1.infineon.com [194.175.117.76]) by mail.gnome.org (Postfix) with ESMTP id D18A018143 for ; Wed, 15 Oct 2003 10:40:52 -0400 (EDT) Received: from vihsx03a.vih.infineon.com (vih.ifx-mail3.com [172.31.163.97]) by smtp1.infineon.com (8.12.10/8.12.10) with ESMTP id h9FEcVSF021337 for ; Wed, 15 Oct 2003 16:38:31 +0200 (MEST) Received: by vihsx03a.vih.infineon.com with Internet Mail Service (5.5.2653.19) id <4PZDBL84>; Wed, 15 Oct 2003 16:41:16 +0200 Message-ID: <258B0164D480D5118D900800062B3858015E64BC@vihsx09a.vih.infineon.com> From: Murray.Cumming@Comneon.com To: xml@gnome.org Date: Wed, 15 Oct 2003 16:41:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [xml] DOM Parser + entities Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: I'm using the DOM Parser, with replaceEntities=0 in the parser context, so that the entity references appear in the tree instead of being resolved automatically to text. The entity reference node types are XML_ENTITY_REF_NODE, and, from looking at the source code, the nodes seem to be plain xmlNodes and don't need to be casted to any other struct type. So, 2 questions: 1. What useful things can I discover about this node other than the name? Maybe nothing. I'm clueless. 2. I notice that these Entity Reference nodes have children. The child node types are XML_ENTITY_DECL, but I can't see any logic to it. Are these child nodes useful/meaningful. Murray Cumming www.murrayc.com murrayc@usa.net From veillard@redhat.com Wed Oct 15 11:17:30 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id EF46718433 for ; Wed, 15 Oct 2003 11:17:29 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9FFHhP28805; Wed, 15 Oct 2003 11:17:43 -0400 Date: Wed, 15 Oct 2003 11:17:43 -0400 From: Daniel Veillard To: Murray.Cumming@Comneon.com Cc: xml@gnome.org Subject: Re: [xml] DOM Parser + entities Message-ID: <20031015111743.J16905@redhat.com> Reply-To: veillard@redhat.com References: <258B0164D480D5118D900800062B3858015E64BC@vihsx09a.vih.infineon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <258B0164D480D5118D900800062B3858015E64BC@vihsx09a.vih.infineon.com>; from Murray.Cumming@Comneon.com on Wed, Oct 15, 2003 at 04:41:06PM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, Oct 15, 2003 at 04:41:06PM +0200, Murray.Cumming@Comneon.com wrote: > I'm using the DOM Parser, with replaceEntities=0 in the parser context, so > that the entity references appear in the tree instead of being resolved > automatically to text. > > The entity reference node types are XML_ENTITY_REF_NODE, and, from looking > at the source code, the nodes seem to be plain xmlNodes and don't need to be > casted to any other struct type. > > So, 2 questions: > 1. What useful things can I discover about this node other than the name? > Maybe nothing. I'm clueless. Well an entity REF points though content to an entity DECL, see xmlEntityPtr / struct _xmlEntity , after the usual navigation fields you will find xmlChar *orig; /* content without ref substitution */ xmlChar *content; /* content or ndata if unparsed */ int length; /* the content length */ xmlEntityType etype; /* The entity type */ const xmlChar *ExternalID; /* External identifier for PUBLIC */ const xmlChar *SystemID; /* URI for a SYSTEM or PUBLIC Entity */ struct _xmlEntity *nexte; /* unused */ const xmlChar *URI; /* the full URI as computed */ int owner; /* does the entity own the childrens */ that's a lot of informations about the entity. > 2. I notice that these Entity Reference nodes have children. The child node > types are XML_ENTITY_DECL, but I can't see any logic to it. Are these child > nodes useful/meaningful. Multiple entity ref can point to the same declaration a declaration is the equivalent to Delivered-To: xml@gnome.org Received: from smtp1.infineon.com (smtp1.infineon.com [194.175.117.76]) by mail.gnome.org (Postfix) with ESMTP id 1A46B180F1 for ; Wed, 15 Oct 2003 12:17:54 -0400 (EDT) Received: from vihsx03a.vih.infineon.com (vih.ifx-mail3.com [172.31.163.97]) by smtp1.infineon.com (8.12.10/8.12.10) with ESMTP id h9FGFWSF020078; Wed, 15 Oct 2003 18:15:32 +0200 (MEST) Received: by vihsx03a.vih.infineon.com with Internet Mail Service (5.5.2653.19) id <4PZDBMMM>; Wed, 15 Oct 2003 18:18:17 +0200 Message-ID: <258B0164D480D5118D900800062B3858015E64D2@vihsx09a.vih.infineon.com> From: Murray.Cumming@Comneon.com To: veillard@redhat.com Cc: xml@gnome.org Subject: RE: [xml] DOM Parser + entities Date: Wed, 15 Oct 2003 18:18:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: > From: Daniel Veillard [mailto:veillard@redhat.com] > Sent: Mittwoch, 15. Oktober 2003 17:18 > To: Murray.Cumming@Comneon.com > > The entity reference node types are XML_ENTITY_REF_NODE, and, from > > looking at the source code, the nodes seem to be plain xmlNodes and > > don't need to be casted to any other struct type. > > > > So, 2 questions: > > 1. What useful things can I discover about this node other than the > > name? Maybe nothing. I'm clueless. > > Well an entity REF points though content to an entity DECL, > see xmlEntityPtr / struct _xmlEntity , after the usual > navigation fields you will find Thanks. Does that mean that I should cast the xmlNode* (of type XML_ENTITY_REF_NODE) to an xmlEntity* ? Murray Cumming www.murrayc.com murrayc@usa.net From Murray.Cumming@Comneon.com Wed Oct 15 12:21:28 2003 Return-Path: Delivered-To: xml@gnome.org Received: from smtp1.infineon.com (smtp1.infineon.com [194.175.117.76]) by mail.gnome.org (Postfix) with ESMTP id 9F9A318335 for ; Wed, 15 Oct 2003 12:21:27 -0400 (EDT) Received: from vihsx03a.vih.infineon.com (vih.ifx-mail3.com [172.31.163.97]) by smtp1.infineon.com (8.12.10/8.12.10) with ESMTP id h9FGJ5SF021089; Wed, 15 Oct 2003 18:19:06 +0200 (MEST) Received: by vihsx03a.vih.infineon.com with Internet Mail Service (5.5.2653.19) id <4PZDBMM5>; Wed, 15 Oct 2003 18:21:50 +0200 Message-ID: <258B0164D480D5118D900800062B3858015E64D4@vihsx09a.vih.infineon.com> From: Murray.Cumming@Comneon.com To: liam@holoweb.net, xml@gnome.org Subject: RE: [xml] WBXML -- "Binary XML" Date: Wed, 15 Oct 2003 18:21:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: > From: Liam R. E. Quin [mailto:liam@holoweb.net] > On Tue, 2003-10-14 at 17:55, Daniel Veillard wrote: > > Sorry, I very reluctant toward "Binary XML" in general > [...] > > We (W3C) just held a workshop on the subject of binary > interchange of XML Information Set Items... the results will > be public at the end of October. > > I think it is fair to say there is no consensus right now on > a single binary format, but, if there is a consensus, it's > that it's not WAP :-) Does WAP 2 even still use this? I thought WAP 2 was a bit more sane. Murray Cumming www.murrayc.com murrayc@usa.net From veillard@redhat.com Wed Oct 15 12:51:52 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 9ADEE180FD for ; Wed, 15 Oct 2003 12:51:52 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9FGq6F08974; Wed, 15 Oct 2003 12:52:06 -0400 Date: Wed, 15 Oct 2003 12:52:06 -0400 From: Daniel Veillard To: Murray.Cumming@Comneon.com Cc: xml@gnome.org Subject: Re: [xml] DOM Parser + entities Message-ID: <20031015125206.M16905@redhat.com> Reply-To: veillard@redhat.com References: <258B0164D480D5118D900800062B3858015E64D2@vihsx09a.vih.infineon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <258B0164D480D5118D900800062B3858015E64D2@vihsx09a.vih.infineon.com>; from Murray.Cumming@Comneon.com on Wed, Oct 15, 2003 at 06:18:06PM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, Oct 15, 2003 at 06:18:06PM +0200, Murray.Cumming@Comneon.com wrote: > > From: Daniel Veillard [mailto:veillard@redhat.com] > > Sent: Mittwoch, 15. Oktober 2003 17:18 > > To: Murray.Cumming@Comneon.com > > > The entity reference node types are XML_ENTITY_REF_NODE, and, from > > > looking at the source code, the nodes seem to be plain xmlNodes and > > > don't need to be casted to any other struct type. > > > > > > So, 2 questions: > > > 1. What useful things can I discover about this node other than the > > > name? Maybe nothing. I'm clueless. > > > > Well an entity REF points though content to an entity DECL, > > see xmlEntityPtr / struct _xmlEntity , after the usual > > navigation fields you will find > > Thanks. Does that mean that I should cast the xmlNode* (of type > XML_ENTITY_REF_NODE) to an xmlEntity* ? For a reference, no, the only field used are name, content and the navigation stuff, no cast should be needed. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From Murray.Cumming@Comneon.com Wed Oct 15 13:04:21 2003 Return-Path: Delivered-To: xml@gnome.org Received: from smtp1.infineon.com (smtp1.infineon.com [194.175.117.76]) by mail.gnome.org (Postfix) with ESMTP id 7844618226 for ; Wed, 15 Oct 2003 13:04:21 -0400 (EDT) Received: from vihsx03a.vih.infineon.com (vih.ifx-mail3.com [172.31.163.97]) by smtp1.infineon.com (8.12.10/8.12.10) with ESMTP id h9FH20SF024090; Wed, 15 Oct 2003 19:02:00 +0200 (MEST) Received: by vihsx03a.vih.infineon.com with Internet Mail Service (5.5.2653.19) id <4PZDBMTP>; Wed, 15 Oct 2003 19:04:44 +0200 Message-ID: <258B0164D480D5118D900800062B3858015E64D5@vihsx09a.vih.infineon.com> From: Murray.Cumming@Comneon.com To: veillard@redhat.com Cc: xml@gnome.org Subject: RE: [xml] DOM Parser + entities Date: Wed, 15 Oct 2003 19:04:35 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: > From: Daniel Veillard [mailto:veillard@redhat.com] > > > Well an entity REF points though content to an entity DECL, > > > see xmlEntityPtr / struct _xmlEntity , after the usual > > > navigation fields you will find > > > > Thanks. Does that mean that I should cast the xmlNode* (of type > > XML_ENTITY_REF_NODE) to an xmlEntity* ? > > For a reference, no, the only field used are name, content > and the navigation stuff, no cast should be needed. OK, now I think I understand "points through content". But xmlNode::content is an xmlChar*, not an xmlEntityPtr. Maybe I need another clue. Murray Cumming www.murrayc.com murrayc@usa.net From stephane.bidoul@softwareag.com Wed Oct 15 15:10:46 2003 Return-Path: Delivered-To: xml@gnome.org Received: from server8a.software-ag.de (server8a.software-ag.de [193.26.193.47]) by mail.gnome.org (Postfix) with ESMTP id DB27518480 for ; Wed, 15 Oct 2003 15:10:45 -0400 (EDT) Received: from softwareag.com by server8a.software-ag.de; (8.11.6/8.9.3) id h9FJAsF26094; Wed, 15 Oct 2003 21:10:54 +0200 Message-ID: <3F8D9BB5.4040106@softwareag.com> Date: Wed, 15 Oct 2003 21:10:45 +0200 From: =?ISO-8859-1?Q?St=E9phane_Bidoul?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jesse Pelton Cc: "'oliverst@online.de'" , xml@gnome.org Subject: Re: [xml] Access Violation when using TLS References: <70d9c6eef6387544f06445a720fcc2d63f8d4894@pkc.com> In-Reply-To: <70d9c6eef6387544f06445a720fcc2d63f8d4894@pkc.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Since you mention unloading the DLL, let me add that TLS will *not* work with LoadLibrary/FreeLibrary: it requires that the compiler knows about your DLL. So yes, please retry with 2.6.0beta6 without TLS and tell us how it works. If it still fails, try to be somewhat more explicit about your scneario. Thanks. -sbi >I'm not clear about your whole scenario, but here are a couple of thoughts >and questions. > >First, are you sure you need to be using LIBXML_STATIC_FOR_DLL? It's >intended for the case where libxml is statically linked into a DLL. It >sounds like that may be what you're doing, but I'm not sure. > >Second, LIBXML_STATIC_FOR_DLL has no effect if you're using compiler TLS, as >you must be doing if you're crashing in line 397. Try disabling compiler >TLS. > > > >>-----Original Message----- >>From: oliverst@online.de [mailto:oliverst@online.de] >>Sent: Wednesday, October 15, 2003 4:58 AM >>To: xml@gnome.org >>Subject: Re: [xml] Access Violation when using TLS >> >> >> >>OK, I just read about those older threading patches and about the >>"LIBXML_STATIC_FOR_DLL" define. So I added the define, compiled the >>2.6.0beta6 again and it still crashes at line 397 in threads.c. >> >> >_______________________________________________ >xml mailing list, project page http://xmlsoft.org/ >xml@gnome.org >http://mail.gnome.org/mailman/listinfo/xml > > From MANU_TA@terra.es Wed Oct 15 14:18:26 2003 Return-Path: Delivered-To: xml@gnome.org Received: from tfsmtp3.mail.isp (smtp.terra.es [213.4.129.129]) by mail.gnome.org (Postfix) with ESMTP id A2E62180DD for ; Wed, 15 Oct 2003 14:18:25 -0400 (EDT) Received: from teleline.es ([10.20.4.99]) by tfsmtp3.mail.isp (Netscape Messaging Server 4.15 tfsmtp3 Mar 14 2002 21:29:48) with ESMTP id HMT9J100.6MW for ; Wed, 15 Oct 2003 20:18:37 +0200 From: MANU_TA To: xml@gnome.org Message-ID: <317d8731584a.31584a317d87@teleline.es> Date: Wed, 15 Oct 2003 20:18:37 +0200 X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: es X-Accept-Language: es Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [xml] One question about XPath Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hello Daniel, I have a question about XPath. Let's supposed we have the following xml doc:
value1 response1 value2 response2 value3 response3
- My question is: Can I use XPath in order to obtain the value (responseX) from value (valueX)?. - Could you tell me what XPath "expresion" I have to use, please? This means, with the "valueX" I would like to obtain "responseX" using XPath (is it possible?) - For example: Whit the "value2" and the XPath "expresion" I want to obtain "response2". I am very gratefull if you could answer my questions. Thank you very much in advanded and regards, Manuel (Spain) From veillard@redhat.com Wed Oct 15 15:52:25 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 1FAE318229 for ; Wed, 15 Oct 2003 15:52:25 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9FJqba17092; Wed, 15 Oct 2003 15:52:37 -0400 Date: Wed, 15 Oct 2003 15:52:37 -0400 From: Daniel Veillard To: MANU_TA Cc: xml@gnome.org Subject: Re: [xml] One question about XPath Message-ID: <20031015155237.P16905@redhat.com> Reply-To: veillard@redhat.com References: <317d8731584a.31584a317d87@teleline.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <317d8731584a.31584a317d87@teleline.es>; from MANU_TA@terra.es on Wed, Oct 15, 2003 at 08:18:37PM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, Oct 15, 2003 at 08:18:37PM +0200, MANU_TA wrote: >
> > > value1 > response1 > > > > value2 > response2 > > > > value3 > response3 > > >
> > - My question is: Can I use XPath in order to obtain the > value (responseX) from value (valueX)?. > - Could you tell me what XPath "expresion" I have to use, please? > > This means, with the "valueX" I would like to obtain "responseX" using > XPath (is it possible?) picking the first one because teh node set may return multiple nodes: string((/main/label_1[sublabel_1 = 'valueX']/sublabel_2)[1]) What about reading a book or an on-line resource like http://www.zvon.org/ Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From seefeld@sympatico.ca Wed Oct 15 15:54:21 2003 Return-Path: Delivered-To: xml@gnome.org Received: from Orthosoft.ca (unknown [216.208.232.2]) by mail.gnome.org (Postfix) with SMTP id 352F21874B for ; Wed, 15 Oct 2003 15:54:21 -0400 (EDT) Message-ID: Date: Wed, 15 Oct 2003 16:00:51 -0400 From: Stefan Seefeld MIME-Version: 1.0 To: MANU_TA Cc: xml@gnome.org Subject: Re: [xml] One question about XPath References: <317d8731584a.31584a317d87@teleline.es> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: MANU_TA wrote: > Hello Daniel, > > I have a question about XPath. > > Let's supposed we have the following xml doc: > >
> > > value1 > response1 > > > > value2 > response2 > > > > value3 > response3 > > >
> > - My question is: Can I use XPath in order to obtain the > value (responseX) from value (valueX)?. > - Could you tell me what XPath "expresion" I have to use, please? /main/label_1[sublabel_1='value1']/sublabel_2 Regards, Stefan From david@davemalcolm.demon.co.uk Wed Oct 15 17:43:05 2003 Return-Path: Delivered-To: xml@gnome.org Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by mail.gnome.org (Postfix) with ESMTP id 46A8818141 for ; Wed, 15 Oct 2003 17:43:05 -0400 (EDT) Received: from davemalcolm.demon.co.uk ([80.177.172.172] helo=[192.168.0.3]) by anchor-post-31.mail.demon.net with esmtp (Exim 3.35 #1) id 1A9tQO-000HOm-0V; Wed, 15 Oct 2003 22:43:20 +0100 Subject: Re: [xml] DOM Parser + entities From: Dave Malcolm To: Murray.Cumming@Comneon.com Cc: xml@gnome.org In-Reply-To: <258B0164D480D5118D900800062B3858015E64BC@vihsx09a.vih.infineon.com> References: <258B0164D480D5118D900800062B3858015E64BC@vihsx09a.vih.infineon.com> Content-Type: text/plain Organization: Message-Id: <1066258036.2171.20.camel@shirehorse1> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 15 Oct 2003 22:47:16 +0000 Content-Transfer-Encoding: 7bit Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, 2003-10-15 at 14:41, Murray.Cumming@Comneon.com wrote: > I'm using the DOM Parser, with replaceEntities=0 in the parser context, so > that the entity references appear in the tree instead of being resolved > automatically to text. > > The entity reference node types are XML_ENTITY_REF_NODE, and, from looking > at the source code, the nodes seem to be plain xmlNodes and don't need to be > casted to any other struct type. > > So, 2 questions: > 1. What useful things can I discover about this node other than the name? > Maybe nothing. I'm clueless. > > 2. I notice that these Entity Reference nodes have children. The child node > types are XML_ENTITY_DECL, but I can't see any logic to it. Are these child > nodes useful/meaningful. The XML_ENTITY_REF_NODE should have children ptr == last ptr, pointing to a XML_ENTITY_DECL, which can be cast to an xmlEntityPtr, I believe. However, the parent of the XML_ENTITY_DECL will be the DTD, rather the reference node, and its siblings will likely be other XML_ENTITY_DECLs and comments etc from the DTD part of the document - this has caused me no end of trouble when naively doing tree walks in Conglomerate :-( -- David Malcolm www.conglomerate.org From xml@thewrittenword.com Wed Oct 15 17:48:55 2003 Return-Path: Delivered-To: xml@gnome.org Received: from spuckler.il.thewrittenword.com (mail2.thewrittenword.com [67.95.107.111]) by mail.gnome.org (Postfix) with ESMTP id B28A8180F2 for ; Wed, 15 Oct 2003 17:48:55 -0400 (EDT) Received: from spuckler.il.thewrittenword.com (localhost.il.thewrittenword.com [127.0.0.1]) by spuckler.il.thewrittenword.com (8.12.10/8.12.10) with ESMTP id h9FLnBne026857 for ; Wed, 15 Oct 2003 16:49:11 -0500 (CDT) Received: (from china@localhost) by spuckler.il.thewrittenword.com (8.12.10/8.12.10) id h9FLnAuD026856 for xml@gnome.org; Wed, 15 Oct 2003 16:49:10 -0500 (CDT) Date: Wed, 15 Oct 2003 16:49:10 -0500 From: Albert Chin To: xml@gnome.org Message-ID: <20031015214910.GA26536@spuckler.il.thewrittenword.com> Reply-To: xml@gnome.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Subject: [xml] libxslt-1.0.33 test failures on Solaris 9 (and AIX 5.1) Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Just build 1.0.33 on Solaris 9 with the Sun C compiler. I get the following test failure. Ditto for AIX 5.1. Anyone else seeing this? datetime.1.xml 23,38c23,38 < year : 1 < leap-year : false < month-in-year : 12 < month-name : December < month-abbreviation : Dec < week-in-year : 53 < day-in-year : 365 < day-in-month : 31 < day-of-week-in-month : 5 < day-in-week : 2 < day-name : Monday < day-abbreviation : Mon < time : 23:59:59.1234-05:00 < hour-in-day : 23 < minute-in-hour : 59 < second-in-minute : 59.1234 --- > year : NaN > leap-year : NaN > month-in-year : NaN > month-name : > month-abbreviation : > week-in-year : NaN > day-in-year : NaN > day-in-month : NaN > day-of-week-in-month : NaN > day-in-week : NaN > day-name : > day-abbreviation : > time : > hour-in-day : NaN > minute-in-hour : NaN > second-in-minute : NaN 41,56c41,56 < year : -1 < leap-year : false < month-in-year : 12 < month-name : December < month-abbreviation : Dec < week-in-year : 52 < day-in-year : 365 < day-in-month : 31 < day-of-week-in-month : 5 < day-in-week : 1 < day-name : Sunday < day-abbreviation : Sun < time : 23:59:59-05:00 < hour-in-day : 23 < minute-in-hour : 59 < second-in-minute : 59 --- > year : NaN > leap-year : NaN > month-in-year : NaN > month-name : > month-abbreviation : > week-in-year : NaN > day-in-year : NaN > day-in-month : NaN > day-of-week-in-month : NaN > day-in-week : NaN > day-name : > day-abbreviation : > time : > hour-in-day : NaN > minute-in-hour : NaN > second-in-minute : NaN -- albert chin (china@thewrittenword.com) From crutcher@unix.eng.ua.edu Wed Oct 15 16:34:16 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail.unix.eng.ua.edu (unknown [130.160.20.13]) by mail.gnome.org (Postfix) with ESMTP id 8469818BAD for ; Wed, 15 Oct 2003 16:34:16 -0400 (EDT) Received: from ox.unix.eng.ua.edu (ox.unix.eng.ua.edu [130.160.20.14]) by mail.unix.eng.ua.edu (Postfix) with ESMTP id BF44C4E4095; Wed, 15 Oct 2003 15:34:31 -0500 (CDT) Received: by ox.unix.eng.ua.edu (Postfix, from userid 500) id A70B024022B; Wed, 15 Oct 2003 15:34:30 -0500 (CDT) Date: Wed, 15 Oct 2003 15:34:30 -0500 From: Crutcher Dunnavant To: xml@gnome.org, crutcher@unix.eng.ua.edu Message-ID: <20031015203430.GA4690@ox.unix.eng.ua.edu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="9amGYk9869ThD9tj" Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: [xml] [PATCH] MAX_DEPTH --> xmlParserMaxDepth Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I ran into a problem using xsltproc which we traced back to the arbitrary, and non-settable libxml MAX_DEPTH macro in parser.c, so, I changed it. Sometimes you DO want rediculously huge files. Patches to libxml and xsltproc in libxslt are attached, please accept them. -- Crutcher Dunnavant ECSS Hacker / CS Master Student --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="libxml2-2.5.11-xmlParserMaxDepth.patch" --- libxml2-2.5.11/include/libxml/parserInternals.h 2003-10-07 10:45:15.000000000 -0500 +++ libxml2-2.5.11.xmlParserMaxDepth/include/libxml/parserInternals.h 2003-10-15 14:54:33.000000000 -0500 @@ -17,6 +17,15 @@ extern "C" { #endif +/** + * xmlParserMaxDepth: + * + * arbitrary depth limit for the XML documents that we allow to + * process. This is not a limitation of the parser but a safety + * boundary feature. + */ +extern unsigned int xmlParserMaxDepth; + /** * XML_MAX_NAMELEN: * --- libxml2-2.5.11/parser.c 2003-10-07 10:45:15.000000000 -0500 +++ libxml2-2.5.11.xmlParserMaxDepth/parser.c 2003-10-15 14:51:04.000000000 -0500 @@ -77,13 +77,13 @@ #endif /** - * MAX_DEPTH: + * xmlParserMaxDepth: * * arbitrary depth limit for the XML documents that we allow to * process. This is not a limitation of the parser but a safety * boundary feature. */ -#define MAX_DEPTH 1024 +unsigned int xmlParserMaxDepth = 1024; #define XML_PARSER_BIG_BUFFER_SIZE 300 #define XML_PARSER_BUFFER_SIZE 100 @@ -199,18 +199,16 @@ return (0); } } -#ifdef MAX_DEPTH - if (ctxt->nodeNr > MAX_DEPTH) { + if (ctxt->nodeNr > xmlParserMaxDepth) { if ((ctxt->sax != NULL) && (ctxt->sax->error != NULL)) ctxt->sax->error(ctxt->userData, - "Excessive depth in document: change MAX_DEPTH = %d\n", - MAX_DEPTH); + "Excessive depth in document: change xmlParserMaxDepth = %d\n", + xmlParserMaxDepth); ctxt->wellFormed = 0; ctxt->instate = XML_PARSER_EOF; if (ctxt->recovery == 0) ctxt->disableSAX = 1; return(0); } -#endif ctxt->nodeTab[ctxt->nodeNr] = value; ctxt->node = value; return (ctxt->nodeNr++); --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="libxslt-1.0.27-maxparserdepth.patch" --- libxslt-1.0.27/xsltproc/xsltproc.c 2003-10-15 15:08:07.000000000 -0500 +++ libxslt-1.0.27.maxparserdepth/xsltproc/xsltproc.c 2003-10-15 15:09:59.000000000 -0500 @@ -476,6 +476,7 @@ printf("\t--novalid skip the Dtd loading phase\n"); printf("\t--noout: do not dump the result\n"); printf("\t--maxdepth val : increase the maximum depth\n"); + printf("\t--maxparserdepth val : increase the maximum parser depth\n"); #ifdef LIBXML_HTML_ENABLED printf("\t--html: the input document is(are) an HTML file(s)\n"); #endif @@ -687,6 +688,15 @@ if (value > 0) xsltMaxDepth = value; } + } else if ((!strcmp(argv[i], "-maxparserdepth")) || + (!strcmp(argv[i], "--maxparserdepth"))) { + int value; + + i++; + if (sscanf(argv[i], "%d", &value) == 1) { + if (value > 0) + xmlParserMaxDepth = value; + } } else if ((!strcmp(argv[i],"-dumpextensions"))|| (!strcmp(argv[i],"--dumpextensions"))) { dumpextensions++; @@ -724,6 +734,10 @@ (!strcmp(argv[i], "--maxdepth"))) { i++; continue; + } else if ((!strcmp(argv[i], "-maxparserdepth")) || + (!strcmp(argv[i], "--maxparserdepth"))) { + i++; + continue; } else if ((!strcmp(argv[i], "-o")) || (!strcmp(argv[i], "-output")) || (!strcmp(argv[i], "--output"))) { --9amGYk9869ThD9tj-- From jpesenti@yahoo.com Wed Oct 15 19:35:38 2003 Return-Path: Delivered-To: xml@gnome.org Received: from web12301.mail.yahoo.com (web12301.mail.yahoo.com [216.136.173.99]) by mail.gnome.org (Postfix) with SMTP id 30ED2182D1 for ; Wed, 15 Oct 2003 19:35:37 -0400 (EDT) Message-ID: <20031015223527.74767.qmail@web12301.mail.yahoo.com> Received: from [151.201.142.149] by web12301.mail.yahoo.com via HTTP; Wed, 15 Oct 2003 15:35:27 PDT Date: Wed, 15 Oct 2003 15:35:27 -0700 (PDT) From: Jerome Pesenti To: xml@gnome.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [xml] htmlParseFile vs htmlParseDoc Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: There seems to be a big performance hit (x4 to x10) when using htmlParseDoc instead of htmlParseFile on big files. Interestingly, in 2.5.8 there was the same kind of problem when parsing XML, but it seems to be fixed in 2.5.11. Any idea what's going on? Thanks! Jerome __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com From oliverst@online.de Wed Oct 15 19:41:55 2003 Return-Path: Delivered-To: xml@gnome.org Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.184]) by mail.gnome.org (Postfix) with ESMTP id BAB9D18161 for ; Wed, 15 Oct 2003 19:41:54 -0400 (EDT) Received: from [212.227.126.155] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1A9vHN-0004qN-00; Thu, 16 Oct 2003 01:42:09 +0200 Received: from [80.136.148.39] (helo=kidman) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1A9vHN-0003g3-00; Thu, 16 Oct 2003 01:42:09 +0200 From: "=?ISO-8859-1?Q?Oliver_St=F6neberg?=" To: "=?ISO-8859-1?Q?St=E9phane_Bidoul?=" Date: Thu, 16 Oct 2003 01:35:27 +0200 MIME-Version: 1.0 Subject: Re: [xml] Access Violation when using TLS Reply-To: oliverst@online.de Cc: xml@gnome.org Message-ID: <3F8DF5DF.32686.5E65CFD@localhost> Priority: normal In-reply-to: <3F8D9BB5.4040106@softwareag.com> References: <70d9c6eef6387544f06445a720fcc2d63f8d4894@pkc.com> X-mailer: Pegasus Mail for Windows (v4.11) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: I tried it again without TLS and with the LIBXML_STATIC_FOR_DLL define and it worked. No more crash after FreeLibrary(). But it only worked in2.6.0beta6 and not in 2.5.11, guess that's because of those older patches, that have just been applied a few days ago. Looking forward to the final release to finally get my DLL working properly... It's quite depressing to find out, that hours and hours of trying and debugging have been wasted, because it would have never worked, even if I set that define I was missing, because that patches were missing. Thanks for your help and information, I guess I will now post less useless stuff to the list (hopefully) :) > Since you mention unloading the DLL, let me add that TLS will *not* > work with LoadLibrary/FreeLibrary: it requires that the compiler > knows about your DLL. > > So yes, please retry with 2.6.0beta6 without TLS and tell us > how it works. If it still fails, try to be somewhat more explicit > about your scneario. > > Thanks. > > -sbi > > >I'm not clear about your whole scenario, but here are a couple of thoughts > >and questions. > > > >First, are you sure you need to be using LIBXML_STATIC_FOR_DLL? It's > >intended for the case where libxml is statically linked into a DLL. It > >sounds like that may be what you're doing, but I'm not sure. > > > >Second, LIBXML_STATIC_FOR_DLL has no effect if you're using compiler TLS, as > >you must be doing if you're crashing in line 397. Try disabling compiler > >TLS. > > > > > > > >>-----Original Message----- > >>From: oliverst@online.de [mailto:oliverst@online.de] > >>Sent: Wednesday, October 15, 2003 4:58 AM > >>To: xml@gnome.org > >>Subject: Re: [xml] Access Violation when using TLS > >> > >> > >> > >>OK, I just read about those older threading patches and about the > >>"LIBXML_STATIC_FOR_DLL" define. So I added the define, compiled the > >>2.6.0beta6 again and it still crashes at line 397 in threads.c. > >> > >> > >_______________________________________________ > >xml mailing list, project page http://xmlsoft.org/ > >xml@gnome.org > >http://mail.gnome.org/mailman/listinfo/xml > > > > > > > From veillard@redhat.com Wed Oct 15 19:44:59 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 7565D18129 for ; Wed, 15 Oct 2003 19:44:59 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9FNjEW10315; Wed, 15 Oct 2003 19:45:14 -0400 Date: Wed, 15 Oct 2003 19:45:14 -0400 From: Daniel Veillard To: Crutcher Dunnavant Cc: xml@gnome.org Subject: Re: [xml] [PATCH] MAX_DEPTH --> xmlParserMaxDepth Message-ID: <20031015194514.S16905@redhat.com> Reply-To: veillard@redhat.com References: <20031015203430.GA4690@ox.unix.eng.ua.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031015203430.GA4690@ox.unix.eng.ua.edu>; from crutcher@unix.eng.ua.edu on Wed, Oct 15, 2003 at 03:34:30PM -0500 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, Oct 15, 2003 at 03:34:30PM -0500, Crutcher Dunnavant wrote: > I ran into a problem using xsltproc which we traced back to > the arbitrary, and non-settable libxml MAX_DEPTH macro in parser.c, > so, I changed it. howdy Crutcher, how are things ? Seem you still break software :-) > Sometimes you DO want rediculously huge files. Well, it's not about huge file, it's about huge depth. Since it can become an easy DoS attack, that guard is set in libxml2, nobody ever hit it before you (or didn't told). > Patches to libxml and xsltproc in libxslt are attached, please accept them. This makes some sense, after a bit of cleanup, I applied the patch to libxml2, that part is easy. On the other hand applying the patch to libxslt/xsltproc makes a hard dependancy to a not-yet-released version of the library, so I think it should go in but I may not be able to commit that right now. I also note that for symetry reasons it the same parsing option could be added to xmllint.c , cheers from #devel @ Red Hat, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard@redhat.com Wed Oct 15 19:47:33 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id BE4D218129 for ; Wed, 15 Oct 2003 19:47:33 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9FNljd11364; Wed, 15 Oct 2003 19:47:45 -0400 Date: Wed, 15 Oct 2003 19:47:45 -0400 From: Daniel Veillard To: Jerome Pesenti Cc: xml@gnome.org Subject: Re: [xml] htmlParseFile vs htmlParseDoc Message-ID: <20031015194745.T16905@redhat.com> Reply-To: veillard@redhat.com References: <20031015223527.74767.qmail@web12301.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031015223527.74767.qmail@web12301.mail.yahoo.com>; from jpesenti@yahoo.com on Wed, Oct 15, 2003 at 03:35:27PM -0700 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, Oct 15, 2003 at 03:35:27PM -0700, Jerome Pesenti wrote: > There seems to be a big performance hit (x4 to x10) > when using htmlParseDoc instead of htmlParseFile on > big files. > > Interestingly, in 2.5.8 there was the same kind of > problem when parsing XML, but it seems to be fixed in > 2.5.11. > > Any idea what's going on? Hum, I think it was about some buffer copies as the input was consumed when the buffer was initialized with a very large input. Can you still see this with the CVS version ? Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard@redhat.com Wed Oct 15 19:50:31 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 6CCD718230 for ; Wed, 15 Oct 2003 19:50:31 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9FNohM12548; Wed, 15 Oct 2003 19:50:43 -0400 Date: Wed, 15 Oct 2003 19:50:43 -0400 From: Daniel Veillard To: =?iso-8859-1?Q?Oliver_St=F6neberg?= Cc: =?iso-8859-1?Q?St=E9phane_Bidoul?= , xml@gnome.org Subject: Re: [xml] Access Violation when using TLS Message-ID: <20031015195043.U16905@redhat.com> Reply-To: veillard@redhat.com References: <70d9c6eef6387544f06445a720fcc2d63f8d4894@pkc.com> <3F8D9BB5.4040106@softwareag.com> <3F8DF5DF.32686.5E65CFD@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3F8DF5DF.32686.5E65CFD@localhost>; from oliverst@online.de on Thu, Oct 16, 2003 at 01:35:27AM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, Oct 16, 2003 at 01:35:27AM +0200, Oliver Stöneberg wrote: > I tried it again without TLS and with the LIBXML_STATIC_FOR_DLL > define and it worked. No more crash after FreeLibrary(). But it only > worked in2.6.0beta6 and not in 2.5.11, guess that's because of those > older patches, that have just been applied a few days ago. Looking > forward to the final release to finally get my DLL working > properly... Well I have been working on totally unrelated stuff during the beginning of the week, I will try to push a 2.6.0 release next week-end if there is no showstopper and I manage to clean up enough stuff. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From oliverst@online.de Thu Oct 16 05:05:47 2003 Return-Path: Delivered-To: xml@gnome.org Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mail.gnome.org (Postfix) with ESMTP id DB35D18386 for ; Thu, 16 Oct 2003 05:05:46 -0400 (EDT) Received: from [212.227.126.203] (helo=mrvnet.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1AA453-0006nE-00 for xml@gnome.org; Thu, 16 Oct 2003 11:06:01 +0200 Received: from [172.23.4.138] (helo=config11.kundenserver.de) by mrvnet.kundenserver.de with esmtp (Exim 3.35 #1) id 1AA453-0004ab-00 for xml@gnome.org; Thu, 16 Oct 2003 11:06:01 +0200 Received: from www-data by config11.kundenserver.de with local (Exim 3.35 #1 (Debian)) id 1AA453-0007Ii-00 for ; Thu, 16 Oct 2003 11:06:01 +0200 To: From: Message-Id: <5074873$10662941853f8e5ba9ddbbb8.00612466@config11.schlund.de> X-Binford: 6100 (more power) X-Originating-From: 5074873 X-Mailer: Webmail X-Routing: DE X-Received: from config11 by 213.252.152.112 with HTTP id 5074873 for xml@gnome.org; Thu, 16 Oct 2003 11:04:01 +0200 Content-Type: text/plain; charset="iso-8859-1" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Priority: 3 Date: Thu, 16 Oct 2003 11:04:01 +0200 Subject: [xml] Makefile, configure.js and DSP comments Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: - DocBook should removed from the configure.js - in the configure.js an additional kind of static build should be added ("dll" using LIBXML_STATIC_FOR_DLL) - it seems like the LIBXML_STATIC define is missing in the dsp coming with the libxml2 for the static compile - in the Makefile.am andMakefile.in in the start folder and the MSVC, BCB and VMS project files the "DOCBparser.c" is still present (mostly associated with WITH_TRIO_SOURCES) From veillard@redhat.com Thu Oct 16 05:14:50 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 3938C182D7 for ; Thu, 16 Oct 2003 05:14:50 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9G9F2X18401; Thu, 16 Oct 2003 05:15:02 -0400 Date: Thu, 16 Oct 2003 05:15:02 -0400 From: Daniel Veillard To: oliverst@online.de Cc: xml@gnome.org Subject: Re: [xml] Makefile, configure.js and DSP comments Message-ID: <20031016051502.A16905@redhat.com> Reply-To: veillard@redhat.com References: <5074873$10662941853f8e5ba9ddbbb8.00612466@config11.schlund.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <5074873$10662941853f8e5ba9ddbbb8.00612466@config11.schlund.de>; from oliverst@online.de on Thu, Oct 16, 2003 at 11:04:01AM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, Oct 16, 2003 at 11:04:01AM +0200, oliverst@online.de wrote: > > - DocBook should removed from the configure.js > - in the configure.js an additional kind of static build should be added > ("dll" using LIBXML_STATIC_FOR_DLL) > - it seems like the LIBXML_STATIC define is missing in the dsp coming > with the libxml2 for the static compile > - in the Makefile.am andMakefile.in in the start folder and the MSVC, > BCB and VMS project files the "DOCBparser.c" is still present (mostly > associated with WITH_TRIO_SOURCES) Someone provide patches ! I won't mess with the win32 subdir since I have absolutely no way to test any of the changes I would make. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From jpesenti@yahoo.com Thu Oct 16 08:17:23 2003 Return-Path: Delivered-To: xml@gnome.org Received: from web12302.mail.yahoo.com (web12302.mail.yahoo.com [216.136.173.100]) by mail.gnome.org (Postfix) with SMTP id 1E95418540 for ; Thu, 16 Oct 2003 08:17:23 -0400 (EDT) Message-ID: <20031016121738.64864.qmail@web12302.mail.yahoo.com> Received: from [151.201.142.149] by web12302.mail.yahoo.com via HTTP; Thu, 16 Oct 2003 05:17:38 PDT Date: Thu, 16 Oct 2003 05:17:38 -0700 (PDT) From: Jerome Pesenti Subject: Re: [xml] htmlParseFile vs htmlParseDoc To: xml@gnome.org In-Reply-To: <20031015194745.T16905@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Yes, here is a little program showing the problem. Test it with the data at: http://vivisimo.com/~pesenti/pubmed.xml Jerome ################################################### #include #include #include "libxml/parserInternals.h" #include "libxml/xmlmemory.h" #include "libxml/debugXML.h" #include "libxml/HTMLtree.h" #include "libxml/xmlIO.h" #include "libxml/DOCBparser.h" #include "libxml/xinclude.h" #include "libxml/xmlerror.h" #include "libxml/catalog.h" #include "libxml/tree.h" #include "libxml/HTMLparser.h" #define SIZE (10*1024*1024) char * read_all(const char *name) { FILE *f = fopen(name, "r"); char *s; int n; if (! f) { perror(name); exit(1); } s = malloc(sizeof(*s)*SIZE); if ((n = fread(s, 1, SIZE, f)) < 0 || n == SIZE) { /* error or file too large */ fprintf(stderr, "Could not load file, got %d bytes\n", n); exit(1); } s[n] = '\0'; return s; } int main(int argc, char **argv) { const char *str; htmlParserCtxtPtr ctxt; htmlDocPtr ret; str = read_all(argv[1]); printf("%ld - parsing with htmlParseDocument\n", time(NULL)); ctxt = htmlCreateMemoryParserCtxt(str, strlen(str)); htmlParseDocument(ctxt); printf("%ld - parsing with htmlParseDoc\n", time(NULL)); htmlParseDoc(str, NULL); printf("%ld - parsing with htmlParseFile\n", time(NULL)); htmlParseFile(argv[1], NULL); printf("%ld - done\n", time(NULL)); return 0; } --- Daniel Veillard wrote: > On Wed, Oct 15, 2003 at 03:35:27PM -0700, Jerome > Pesenti wrote: > > There seems to be a big performance hit (x4 to > x10) > > when using htmlParseDoc instead of htmlParseFile > on > > big files. > > > > Interestingly, in 2.5.8 there was the same kind of > > > problem when parsing XML, but it seems to be fixed > in > > 2.5.11. > > > > Any idea what's going on? > > Hum, I think it was about some buffer copies as > the > input was consumed when the buffer was initialized > with a very > large input. Can you still see this with the CVS > version ? > > Daniel > > -- > Daniel Veillard | Red Hat Network > https://rhn.redhat.com/ > veillard@redhat.com | libxml GNOME XML XSLT toolkit > http://xmlsoft.org/ > http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com From stamas@csillag.ilab.sztaki.hu Thu Oct 16 08:19:03 2003 Return-Path: Delivered-To: xml@gnome.org Received: from csillag.ilab.sztaki.hu (csillag.sztaki.hu [195.111.1.37]) by mail.gnome.org (Postfix) with ESMTP id E471818540 for ; Thu, 16 Oct 2003 08:19:02 -0400 (EDT) Received: from localhost (stamas@localhost) by csillag.ilab.sztaki.hu (8.11.6/8.11.6) with ESMTP id h9GCILJ14921 for ; Thu, 16 Oct 2003 14:18:21 +0200 Date: Thu, 16 Oct 2003 14:18:21 +0200 (CEST) From: Tamas Sarlos To: xml@gnome.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [xml] byte offset in original document Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi Daniel, A simple question: in the saxCharacters callback, is it possible to know the exact byte offset in the original HTML document of the xmlChar *buf argument? Thanks, Tamas Sarlos, Budapest, Hungary From jsp@PKC.com Thu Oct 16 08:29:03 2003 Return-Path: Delivered-To: xml@gnome.org Received: from pkc.com (unknown [216.75.143.162]) by mail.gnome.org (Postfix) with ESMTP id E439F18540 for ; Thu, 16 Oct 2003 08:29:02 -0400 (EDT) Message-ID: <8e4f8e74ab710422ff924a2b71bf50cc3f8e8f1d@pkc.com> From: Jesse Pelton To: "'veillard@redhat.com'" , oliverst@online.de Cc: xml@gnome.org Subject: RE: [xml] Makefile, configure.js and DSP comments Date: Thu, 16 Oct 2003 08:29:16 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Oliver, would you be willing to provide patches for some or all of this? I don't use the MSVC IDE, so I can't address the .dsp issues. I can deal with configure.js, but not for a few days, so any changes I make won't make it into 2.6.0 if it goes out this weekend. Daniel, do the makefile.am and makefile.in changes fall into your domain? > -----Original Message----- > From: Daniel Veillard [mailto:veillard@redhat.com] > Sent: Thursday, October 16, 2003 5:15 AM > To: oliverst@online.de > Cc: xml@gnome.org > Subject: Re: [xml] Makefile, configure.js and DSP comments > > > On Thu, Oct 16, 2003 at 11:04:01AM +0200, oliverst@online.de wrote: > > > > - DocBook should removed from the configure.js > > - in the configure.js an additional kind of static build > should be added > > ("dll" using LIBXML_STATIC_FOR_DLL) > > - it seems like the LIBXML_STATIC define is missing in the > dsp coming > > with the libxml2 for the static compile > > - in the Makefile.am andMakefile.in in the start folder and > the MSVC, > > BCB and VMS project files the "DOCBparser.c" is still > present (mostly > > associated with WITH_TRIO_SOURCES) > > Someone provide patches ! I won't mess with the win32 subdir since > I have absolutely no way to test any of the changes I would make. > > Daniel From veillard@redhat.com Thu Oct 16 08:30:00 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 9E20818540 for ; Thu, 16 Oct 2003 08:30:00 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9GCUD623242; Thu, 16 Oct 2003 08:30:13 -0400 Date: Thu, 16 Oct 2003 08:30:13 -0400 From: Daniel Veillard To: Tamas Sarlos Cc: xml@gnome.org Subject: Re: [xml] byte offset in original document Message-ID: <20031016083013.D16905@redhat.com> Reply-To: veillard@redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from stamas@csillag.ilab.sztaki.hu on Thu, Oct 16, 2003 at 02:18:21PM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, Oct 16, 2003 at 02:18:21PM +0200, Tamas Sarlos wrote: > Hi Daniel, > > A simple question: in the saxCharacters callback, is it possible to know > the exact byte offset in the original HTML document of the xmlChar *buf > argument? Hum you can try to add ctxt->input->consumed and ctxt->input->cur - ctxt->input->base , but there is no garantee that this is exact. I never checked so this may not work Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard@redhat.com Thu Oct 16 08:32:24 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 8C60318247 for ; Thu, 16 Oct 2003 08:32:24 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9GCWbW24305; Thu, 16 Oct 2003 08:32:37 -0400 Date: Thu, 16 Oct 2003 08:32:37 -0400 From: Daniel Veillard To: Jesse Pelton Cc: oliverst@online.de, xml@gnome.org Subject: Re: [xml] Makefile, configure.js and DSP comments Message-ID: <20031016083237.E16905@redhat.com> Reply-To: veillard@redhat.com References: <8e4f8e74ab710422ff924a2b71bf50cc3f8e8f22@pkc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <8e4f8e74ab710422ff924a2b71bf50cc3f8e8f22@pkc.com>; from jsp@PKC.com on Thu, Oct 16, 2003 at 08:29:16AM -0400 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, Oct 16, 2003 at 08:29:16AM -0400, Jesse Pelton wrote: > Daniel, do the makefile.am and makefile.in changes fall into your domain? Hum, which one, what's the problem ? And Makefile.in is generated from Makefile.am Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From stamas@csillag.ilab.sztaki.hu Thu Oct 16 08:54:36 2003 Return-Path: Delivered-To: xml@gnome.org Received: from csillag.ilab.sztaki.hu (csillag.sztaki.hu [195.111.1.37]) by mail.gnome.org (Postfix) with ESMTP id 4175C1812A for ; Thu, 16 Oct 2003 08:54:36 -0400 (EDT) Received: from localhost (stamas@localhost) by csillag.ilab.sztaki.hu (8.11.6/8.11.6) with ESMTP id h9GCrsG15225 for ; Thu, 16 Oct 2003 14:53:54 +0200 Date: Thu, 16 Oct 2003 14:53:54 +0200 (CEST) From: Tamas Sarlos To: xml@gnome.org Subject: Re: [xml] byte offset in original document In-Reply-To: <20031016083013.D16905@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, 16 Oct 2003, Daniel Veillard wrote: Thanks for the fast reply. We will give it a try and let you know if it works. Tamas > On Thu, Oct 16, 2003 at 02:18:21PM +0200, Tamas Sarlos wrote: > > Hi Daniel, > > > > A simple question: in the saxCharacters callback, is it possible to know > > the exact byte offset in the original HTML document of the xmlChar *buf > > argument? > > Hum you can try to add ctxt->input->consumed and > ctxt->input->cur - ctxt->input->base , but there is no garantee that > this is exact. I never checked so this may not work > > Daniel > > From eday@obj-sys.com Thu Oct 16 09:17:53 2003 Return-Path: Delivered-To: xml@gnome.org Received: from malone.intellispace.net (malone.intellispace.net [160.79.145.141]) by mail.gnome.org (Postfix) with ESMTP id 7A82C18D2F for ; Thu, 16 Oct 2003 09:17:53 -0400 (EDT) Received: from objsys1 (66.9.62.72) by malone.intellispace.net (5.1.053) id 3F87140F00108F55 for xml@gnome.org; Thu, 16 Oct 2003 09:17:38 -0400 Message-ID: <017201c393e8$cbc4bd70$483e0942@objsys1> From: "Ed Day" To: References: <5074873$10662941853f8e5ba9ddbbb8.00612466@config11.schlund.de> <20031016051502.A16905@redhat.com> Subject: Re: [xml] Makefile, configure.js and DSP comments Date: Thu, 16 Oct 2003 09:24:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: > - in the configure.js an additional kind of static build should be added > ("dll" using LIBXML_STATIC_FOR_DLL) I have fussed with Igor about this in the past. I think the LIBXML_STATIC option is already causing a static library for DLL to be created (i.e. it compiles with -MD option which causes the MSVCRT.dll to be included on link). A true static library on Windows should be compiled with -ML or -MT to cause the static C run-time library to be linked in. Is this what you are referring to in this option, or is there more to it? Regards, Ed Day ----- Original Message ----- From: "Daniel Veillard" To: Cc: Sent: Thursday, October 16, 2003 5:15 AM Subject: Re: [xml] Makefile, configure.js and DSP comments > On Thu, Oct 16, 2003 at 11:04:01AM +0200, oliverst@online.de wrote: > > > > - DocBook should removed from the configure.js > > - in the configure.js an additional kind of static build should be added > > ("dll" using LIBXML_STATIC_FOR_DLL) > > - it seems like the LIBXML_STATIC define is missing in the dsp coming > > with the libxml2 for the static compile > > - in the Makefile.am andMakefile.in in the start folder and the MSVC, > > BCB and VMS project files the "DOCBparser.c" is still present (mostly > > associated with WITH_TRIO_SOURCES) > > Someone provide patches ! I won't mess with the win32 subdir since > I have absolutely no way to test any of the changes I would make. > > Daniel > > -- > Daniel Veillard | Red Hat Network https://rhn.redhat.com/ > veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ > http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ > _______________________________________________ > xml mailing list, project page http://xmlsoft.org/ > xml@gnome.org > http://mail.gnome.org/mailman/listinfo/xml > From oliverst@online.de Thu Oct 16 09:31:54 2003 Return-Path: Delivered-To: xml@gnome.org Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mail.gnome.org (Postfix) with ESMTP id 9302C18D3A for ; Thu, 16 Oct 2003 09:31:53 -0400 (EDT) Received: from [212.227.126.203] (helo=mrvnet.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1AA8EW-00007i-00; Thu, 16 Oct 2003 15:32:04 +0200 Received: from [172.23.4.130] (helo=config3.kundenserver.de) by mrvnet.kundenserver.de with esmtp (Exim 3.35 #1) id 1AA8EV-0001Gw-00; Thu, 16 Oct 2003 15:32:03 +0200 Received: from www-data by config3.kundenserver.de with local (Exim 3.35 #1 (Debian)) id 1AA8EV-0008WL-00; Thu, 16 Oct 2003 15:32:03 +0200 To: =?iso-8859-1?Q?Jesse_Pelton?= Subject: Re: RE: [xml] Makefile, configure.js and DSP comments From: Cc: =?iso-8859-1?Q? "'veillard=40redhat=2Ecom'" ?= , , Message-Id: <5074873$10663108273f8e9cab45cf53.21270135@config3.schlund.de> X-Binford: 6100 (more power) X-Originating-From: 5074873 X-Mailer: Webmail X-Routing: DE X-Received: from config3 by 213.252.152.112 with HTTP id 5074873 for jsp@PKC.com; Thu, 16 Oct 2003 15:30:02 +0200 Content-Type: text/plain; charset="iso-8859-1" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Priority: 3 Date: Thu, 16 Oct 2003 15:30:02 +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: I could provide patches for the MSVC project files and maybe the BCB ones. I am not that expericened with makefiles, so I guess you better take care of it. It's not that bad for me, if the changes don't make it into 2.60., because I use a custom project file for my compile. But for other ppl out there relying on the configure.js or the project files, that come with it it would be quite nice to fix it. I will take a look at it later today or this week. Jesse Pelton schrieb am 16.10.2003, 14:29:16: > Oliver, would you be willing to provide patches for some or all of this? I > don't use the MSVC IDE, so I can't address the .dsp issues. I can deal with > configure.js, but not for a few days, so any changes I make won't make it > into 2.6.0 if it goes out this weekend. > > Daniel, do the makefile.am and makefile.in changes fall into your domain? > > > -----Original Message----- > > From: Daniel Veillard [mailto:veillard@redhat.com] > > Sent: Thursday, October 16, 2003 5:15 AM > > To: oliverst@online.de > > Cc: xml@gnome.org > > Subject: Re: [xml] Makefile, configure.js and DSP comments > > > > > > On Thu, Oct 16, 2003 at 11:04:01AM +0200, oliverst@online.de wrote: > > > > > > - DocBook should removed from the configure.js > > > - in the configure.js an additional kind of static build > > should be added > > > ("dll" using LIBXML_STATIC_FOR_DLL) > > > - it seems like the LIBXML_STATIC define is missing in the > > dsp coming > > > with the libxml2 for the static compile > > > - in the Makefile.am andMakefile.in in the start folder and > > the MSVC, > > > BCB and VMS project files the "DOCBparser.c" is still > > present (mostly > > > associated with WITH_TRIO_SOURCES) > > > > Someone provide patches ! I won't mess with the win32 subdir since > > I have absolutely no way to test any of the changes I would make. > > > > Daniel From oliverst@online.de Thu Oct 16 09:33:51 2003 Return-Path: Delivered-To: xml@gnome.org Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mail.gnome.org (Postfix) with ESMTP id E92B818D44 for ; Thu, 16 Oct 2003 09:33:50 -0400 (EDT) Received: from [212.227.126.202] (helo=mrvnet.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1AA8GP-00049e-00; Thu, 16 Oct 2003 15:34:01 +0200 Received: from [172.23.4.134] (helo=config7.kundenserver.de) by mrvnet.kundenserver.de with esmtp (Exim 3.35 #1) id 1AA8GP-0004vJ-00; Thu, 16 Oct 2003 15:34:01 +0200 Received: from www-data by config7.kundenserver.de with local (Exim 3.35 #1 (Debian)) id 1AA8GP-0004IA-00; Thu, 16 Oct 2003 15:34:01 +0200 To: Subject: Re: Re: [xml] Makefile, configure.js and DSP comments From: Cc: =?iso-8859-1?Q?Jesse_Pelton?= , Message-Id: <5074873$10663110183f8e9d6a4bd945.36054228@config7.schlund.de> X-Binford: 6100 (more power) X-Originating-From: 5074873 X-Mailer: Webmail X-Routing: DE X-Received: from config7 by 213.252.152.112 with HTTP id 5074873 for veillard@redhat.com; Thu, 16 Oct 2003 15:32:01 +0200 Content-Type: text/plain; charset="iso-8859-1" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Priority: 3 Date: Thu, 16 Oct 2003 15:32:01 +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: No real problem. It just still has the DOCBparser.c in libxml2_la_SOURCES. Daniel Veillard schrieb am 16.10.2003, 14:32:37: > On Thu, Oct 16, 2003 at 08:29:16AM -0400, Jesse Pelton wrote: > > Daniel, do the makefile.am and makefile.in changes fall into your domain? > > Hum, which one, what's the problem ? > And Makefile.in is generated from Makefile.am > > Daniel > > -- > Daniel Veillard | Red Hat Network https://rhn.redhat.com/ > veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ > http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From oliverst@online.de Thu Oct 16 09:43:52 2003 Return-Path: Delivered-To: xml@gnome.org Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mail.gnome.org (Postfix) with ESMTP id C7E48184EF for ; Thu, 16 Oct 2003 09:43:51 -0400 (EDT) Received: from [212.227.126.200] (helo=mrvnet.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1AA8Q6-0000oK-00; Thu, 16 Oct 2003 15:44:02 +0200 Received: from [172.23.4.143] (helo=config16.kundenserver.de) by mrvnet.kundenserver.de with esmtp (Exim 3.35 #1) id 1AA8Q6-0003tz-00; Thu, 16 Oct 2003 15:44:02 +0200 Received: from www-data by config16.kundenserver.de with local (Exim 3.35 #1 (Debian)) id 1AA8Q5-0004ez-00; Thu, 16 Oct 2003 15:44:01 +0200 To: Subject: Re: [xml] Makefile, configure.js and DSP comments From: Cc: Message-Id: <5074873$10663111343f8e9dde3d17f6.05071082@config16.schlund.de> X-Binford: 6100 (more power) X-Originating-From: 5074873 X-Mailer: Webmail X-Routing: DE X-Received: from config16 by 213.252.152.112 with HTTP id 5074873 for xml@gnome.org; Thu, 16 Oct 2003 15:42:01 +0200 Content-Type: text/plain; charset="iso-8859-1" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Priority: 3 Date: Thu, 16 Oct 2003 15:42:01 +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: > > - in the configure.js an additional kind of static build should be added > > ("dll" using LIBXML_STATIC_FOR_DLL) > I have fussed with Igor about this in the past. I think the LIBXML_STATIC > option is already causing a static library for DLL to be created (i.e. it > compiles with -MD option which causes the MSVCRT.dll to be included on link). A true static library on Windows should be compiled with -ML or -MT > to cause the static C run-time library to be linked in. > Is this what you are referring to in this option, or is there more to it? No, I meant a third state of static. So you can choose between "no", "normal static" and "static for DLL". Because the library is different when being compiled only with LIBXML_STATIC or with LIBXML_STATIC and LIBXML_STATIC_FOR_DLL. Not having the latter may cause problems, when linking the static lib into a DLL (see some earlier posts to the list). But as Stéphane pointed out, you can't have LIBXML_STATIC_FOR_DLL defined along with HAVE_COMPILER_TLS. to sum it up static no - no defines normal - LIBXML_STATIC dll - LIBXML_STATIC and LIBXML_STATIC_FOR_DLL (warning if HAVE_COMPILER_TLS is defined?) Not sure, if it should be part of the configure.js or not, but it would have helped a few weeks ago, if it jumped right into my face when I looked at the configuraion ;) From veillard@redhat.com Thu Oct 16 10:49:34 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 689BE1836B for ; Thu, 16 Oct 2003 10:49:34 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9GEnjL02259; Thu, 16 Oct 2003 10:49:45 -0400 Date: Thu, 16 Oct 2003 10:49:44 -0400 From: Daniel Veillard To: oliverst@online.de Cc: Jesse Pelton , xml@gnome.org Subject: Re: [xml] Makefile, configure.js and DSP comments Message-ID: <20031016104944.G16905@redhat.com> Reply-To: veillard@redhat.com References: <5074873$10663110183f8e9d6a4bd945.36054228@config7.schlund.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <5074873$10663110183f8e9d6a4bd945.36054228@config7.schlund.de>; from oliverst@online.de on Thu, Oct 16, 2003 at 03:32:01PM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, Oct 16, 2003 at 03:32:01PM +0200, oliverst@online.de wrote: > > No real problem. It just still has the DOCBparser.c in > libxml2_la_SOURCES. That's on purpose. ABI compatibility ! Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From scooman@coframi-colombes.com Thu Oct 16 10:43:35 2003 Return-Path: Delivered-To: xml@gnome.org Received: from gsxr1000.coframi-massy.com (mailhost.coframi-massy.com [217.167.143.110]) by mail.gnome.org (Postfix) with ESMTP id 7F91A186DD for ; Thu, 16 Oct 2003 10:43:33 -0400 (EDT) Received: from coframi-colombes.com (APuteaux-102-2-1-6.w193-251.abo.wanadoo.fr [193.251.91.6]) by gsxr1000.coframi-massy.com (8.12.8/8.12.8) with ESMTP id h9GEhiah002142 for ; Thu, 16 Oct 2003 16:43:46 +0200 Message-ID: <3F8EAEE3.7060008@coframi-colombes.com> Date: Thu, 16 Oct 2003 16:44:51 +0200 From: =?ISO-8859-1?Q?S=E9bastien_Cooman?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: fr-fr, en-us, en MIME-Version: 1.0 To: xml@gnome.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-104.9, requis 5, BAYES_00 -4.90, USER_IN_WHITELIST -100.00) Subject: [xml] XML parser under VxWorks Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hello, I wish to use an XML parser under VxWorks. Do LibXML2 or Expat working on this OS ? I am interested to know how I can make working these parsers under VxWorks (config.h, Makefile, ...). Can you help me ? Regards, scooman@coframi-colombes.com ________________ Sébastien COOMAN COFRAMI-Colombes From stephane.bidoul@softwareag.com Thu Oct 16 12:50:33 2003 Return-Path: Delivered-To: xml@gnome.org Received: from server8a.software-ag.de (server8a.software-ag.de [193.26.193.47]) by mail.gnome.org (Postfix) with ESMTP id 14CFF18D7D for ; Thu, 16 Oct 2003 12:50:32 -0400 (EDT) Received: from acsesbi by server8a.software-ag.de; (8.11.6/8.9.3) id h9GGoXF31347; Thu, 16 Oct 2003 18:50:34 +0200 From: "Stéphane Bidoul" To: , "'Jesse Pelton'" Cc: , Subject: RE: RE: [xml] Makefile, configure.js and DSP comments Date: Thu, 16 Oct 2003 18:41:20 +0200 Message-ID: <000001c39405$a47d0570$77261eac@acsesbi> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <5074873$10663108273f8e9cab45cf53.21270135@config3.schlund.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: A few month ago, Igor was always repeating that those dsp projects where not maintained anymore. What's their status today? Should'nt we simply remove them from CVS? DOCBparser.c does not hurt. It can remain there for ABI compatibility on windows as well. Adding the LIBXML_STATIC_FOR_DLL option in configure.js is useful, if only to document the option somehow. I may look into it, but not right now. -sbi > -----Original Message----- > From: xml-admin@gnome.org [mailto:xml-admin@gnome.org]On Behalf Of > oliverst@online.de > Sent: 16 October, 2003 15:30 > To: Jesse Pelton > Cc: 'veillard@redhat.com'; oliverst@online.de; xml@gnome.org > Subject: Re: RE: [xml] Makefile, configure.js and DSP comments > > > > I could provide patches for the MSVC project files and maybe the BCB > ones. I am not that expericened with makefiles, so I guess you better > take care of it. It's not that bad for me, if the changes > don't make it > into 2.60., because I use a custom project file for my > compile. But for > other ppl out there relying on the configure.js or the project files, > that come with it it would be quite nice to fix it. I will take a look > at it later today or this week. > > Jesse Pelton schrieb am 16.10.2003, 14:29:16: > > Oliver, would you be willing to provide patches for some or > all of this? I > > don't use the MSVC IDE, so I can't address the .dsp issues. > I can deal with > > configure.js, but not for a few days, so any changes I make > won't make it > > into 2.6.0 if it goes out this weekend. > > > > Daniel, do the makefile.am and makefile.in changes fall > into your domain? > > > > > -----Original Message----- > > > From: Daniel Veillard [mailto:veillard@redhat.com] > > > Sent: Thursday, October 16, 2003 5:15 AM > > > To: oliverst@online.de > > > Cc: xml@gnome.org > > > Subject: Re: [xml] Makefile, configure.js and DSP comments > > > > > > > > > On Thu, Oct 16, 2003 at 11:04:01AM +0200, > oliverst@online.de wrote: > > > > > > > > - DocBook should removed from the configure.js > > > > - in the configure.js an additional kind of static build > > > should be added > > > > ("dll" using LIBXML_STATIC_FOR_DLL) > > > > - it seems like the LIBXML_STATIC define is missing in the > > > dsp coming > > > > with the libxml2 for the static compile > > > > - in the Makefile.am andMakefile.in in the start folder and > > > the MSVC, > > > > BCB and VMS project files the "DOCBparser.c" is still > > > present (mostly > > > > associated with WITH_TRIO_SOURCES) > > > > > > Someone provide patches ! I won't mess with the win32 > subdir since > > > I have absolutely no way to test any of the changes I would make. > > > > > > Daniel > _______________________________________________ > xml mailing list, project page http://xmlsoft.org/ > xml@gnome.org > http://mail.gnome.org/mailman/listinfo/xml From veillard@redhat.com Thu Oct 16 13:00:05 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 39049180FD for ; Thu, 16 Oct 2003 13:00:05 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9GH0Cn14463; Thu, 16 Oct 2003 13:00:12 -0400 Date: Thu, 16 Oct 2003 13:00:11 -0400 From: Daniel Veillard To: =?iso-8859-1?Q?St=E9phane_Bidoul?= Cc: oliverst@online.de, "'Jesse Pelton'" , xml@gnome.org Subject: Re: [xml] Makefile, configure.js and DSP comments Message-ID: <20031016130011.J16905@redhat.com> Reply-To: veillard@redhat.com References: <5074873$10663108273f8e9cab45cf53.21270135@config3.schlund.de> <000001c39405$a47d0570$77261eac@acsesbi> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <000001c39405$a47d0570$77261eac@acsesbi>; from stephane.bidoul@softwareag.com on Thu, Oct 16, 2003 at 06:41:20PM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, Oct 16, 2003 at 06:41:20PM +0200, Stéphane Bidoul wrote: > A few month ago, Igor was always repeating > that those dsp projects where not maintained > anymore. What's their status today? > Should'nt we simply remove them from CVS? that's probably the right thing to do. What is obsolete precisely ? > DOCBparser.c does not hurt. It can > remain there for ABI compatibility > on windows as well. > > Adding the LIBXML_STATIC_FOR_DLL option > in configure.js is useful, if only > to document the option somehow. > I may look into it, but not right now. okay, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From mgrushinskiy@comcast.net Thu Oct 16 14:14:16 2003 Return-Path: Delivered-To: xml@gnome.org Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mail.gnome.org (Postfix) with ESMTP id 8054D1845D for ; Thu, 16 Oct 2003 14:14:16 -0400 (EDT) Received: from 204.127.197.117 ([204.127.197.117]) by comcast.net (rwcrmhc11) with SMTP id <2003101618143101300t4u8de>; Thu, 16 Oct 2003 18:14:31 +0000 Received: from [192.128.133.68] by 204.127.197.117; Thu, 16 Oct 2003 18:14:30 +0000 From: mgrushinskiy@comcast.net To: Sébastien Cooman Cc: xml@gnome.org, Subject: Re: [xml] XML parser under VxWorks Date: Thu, 16 Oct 2003 18:14:30 +0000 Message-Id: <101620031814.19897.20f5@comcast.net> X-Mailer: AT&T Message Center Version 1 (Oct 14 2003) X-Authenticated-Sender: bWdydXNoaW5za2l5QGNvbWNhc3QubmV0 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Here is one guide which can help a little http://chard.tuc.noao.edu/mpg/ntp/vxworks.html Written by the person who ported NTP to vxWorks > Hello, > > I wish to use an XML parser under VxWorks. > Do LibXML2 or Expat working on this OS ? > > I am interested to know how I can make working these parsers under > VxWorks (config.h, Makefile, ...). > > Can you help me ? > > Regards, > > scooman@coframi-colombes.com > > ________________ > Sébastien COOMAN > COFRAMI-Colombes > > _______________________________________________ > xml mailing list, project page http://xmlsoft.org/ > xml@gnome.org > http://mail.gnome.org/mailman/listinfo/xml From stephane.bidoul@softwareag.com Fri Oct 17 03:26:32 2003 Return-Path: Delivered-To: xml@gnome.org Received: from server8a.software-ag.de (server8a.software-ag.de [193.26.193.47]) by mail.gnome.org (Postfix) with ESMTP id 0042318260 for ; Fri, 17 Oct 2003 03:26:31 -0400 (EDT) Received: from acsesbi by server8a.software-ag.de; (8.11.6/8.9.3) id h9H7QYF23479; Fri, 17 Oct 2003 09:26:34 +0200 From: "Stéphane Bidoul" To: Cc: , "'Jesse Pelton'" , Subject: RE: [xml] Makefile, configure.js and DSP comments Date: Fri, 17 Oct 2003 09:26:49 +0200 Message-ID: <001801c39480$09b49460$1b67140a@acsesbi> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <20031016130011.J16905@redhat.com> Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: > On Thu, Oct 16, 2003 at 06:41:20PM +0200, Stéphane Bidoul wrote: > > A few month ago, Igor was always repeating > > that those dsp projects where not maintained > > anymore. What's their status today? > > Should'nt we simply remove them from CVS? > > that's probably the right thing to do. What is obsolete > precisely ? Everything in win32/dsp, and probably in win32/bsb5 too, since configure.js now supports the Borland and mingw compilers. -sbi From veillard@redhat.com Fri Oct 17 05:25:33 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id E047A18118 for ; Fri, 17 Oct 2003 05:25:32 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9H9Pfr18846; Fri, 17 Oct 2003 05:25:41 -0400 Date: Fri, 17 Oct 2003 05:25:40 -0400 From: Daniel Veillard To: =?iso-8859-1?Q?St=E9phane_Bidoul?= Cc: oliverst@online.de, "'Jesse Pelton'" , xml@gnome.org Subject: Re: [xml] Makefile, configure.js and DSP comments Message-ID: <20031017052540.R16905@redhat.com> Reply-To: veillard@redhat.com References: <20031016130011.J16905@redhat.com> <001801c39480$09b49460$1b67140a@acsesbi> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <001801c39480$09b49460$1b67140a@acsesbi>; from stephane.bidoul@softwareag.com on Fri, Oct 17, 2003 at 09:26:49AM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Fri, Oct 17, 2003 at 09:26:49AM +0200, Stéphane Bidoul wrote: > > On Thu, Oct 16, 2003 at 06:41:20PM +0200, Stéphane Bidoul wrote: > > > A few month ago, Igor was always repeating > > > that those dsp projects where not maintained > > > anymore. What's their status today? > > > Should'nt we simply remove them from CVS? > > > > that's probably the right thing to do. What is obsolete > > precisely ? > > Everything in win32/dsp, > and probably in win32/bsb5 too, since > configure.js now supports the Borland and > mingw compilers. Okay, done. I also removed dsp for libxslt ! Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From gnome-xml@m.gmane.org Fri Oct 17 08:43:42 2003 Return-Path: Delivered-To: xml@gnome.org Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by mail.gnome.org (Postfix) with ESMTP id 52E65182D3 for ; Fri, 17 Oct 2003 08:43:42 -0400 (EDT) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AATxU-0007TA-00 for ; Fri, 17 Oct 2003 14:43:56 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: xml@gnome.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AATxT-0007T2-00 for ; Fri, 17 Oct 2003 14:43:55 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AATxT-0007Ck-00 for ; Fri, 17 Oct 2003 14:43:55 +0200 From: Enno Rehling Date: Fri, 17 Oct 2003 14:44:08 +0200 Lines: 28 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC79471BF1971A6FC06F86503" X-Complaints-To: usenet@sea.gmane.org User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: de-at, de, en X-Enigmail-Version: 0.81.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime Subject: [xml] Something better than _private? Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC79471BF1971A6FC06F86503 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I want to store user-data on document nodes, but since everone else (libxslt, I hear) is also using _private, I'm not sure that that's such a good place to put it. Is there an alternative way? Any best practice for this? Enno. -- "You can get further with a kind word and a gun than with a kind word alone." - Al Capone --------------enigC79471BF1971A6FC06F86503 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-nr2 (Windows XP) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/j+Qc2FTH6fnzT0IRAmYxAJ91FpEwHR8JKza1IuxgPpmRDevBKQCdFvn6 Nh4Ive2UYK2SUd7QAdwpzV4= =ExHR -----END PGP SIGNATURE----- --------------enigC79471BF1971A6FC06F86503-- From veillard@redhat.com Fri Oct 17 08:48:43 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 8A8A71845C for ; Fri, 17 Oct 2003 08:48:42 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9HCmrc09715; Fri, 17 Oct 2003 08:48:53 -0400 Date: Fri, 17 Oct 2003 08:48:53 -0400 From: Daniel Veillard To: Enno Rehling Cc: xml@gnome.org Subject: Re: [xml] Something better than _private? Message-ID: <20031017084853.S16905@redhat.com> Reply-To: veillard@redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from enno@despammed.com on Fri, Oct 17, 2003 at 02:44:08PM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Fri, Oct 17, 2003 at 02:44:08PM +0200, Enno Rehling wrote: > I want to store user-data on document nodes, but since everone else > (libxslt, I hear) is also using _private, I'm not sure that that's such a > good place to put it. Is there an alternative way? Any best practice for this? No, _private is the dedicated place for this. The fact that libxslt modifies the node has a simple rule: libxslt modifies the document it's being passed to be transformed if you want to transform a document you're using for other processing you must make a copy of it first and handle that copy to libxslt. I'm not gonna add a new field for this reason. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From kbuchcik@4commerce.de Fri Oct 17 10:32:26 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mx01.qsc.de (mx01.qsc.de [213.148.129.14]) by mail.gnome.org (Postfix) with ESMTP id 5E75B18BC0 for ; Fri, 17 Oct 2003 10:32:26 -0400 (EDT) Received: from port-212-202-229-162.reverse.qsc.de ([212.202.229.162] helo=kisone) by mx01.qsc.de with smtp (Exim 3.35 #1) id 1AAVei-00086H-00 for xml@gnome.org; Fri, 17 Oct 2003 16:32:41 +0200 From: Kasimier Buchcik To: X-Priority: 3 Received: from emission [10.254.2.2] by kisone [10.254.2.2] with SMTP eMission ESMTPServer; Fri, 17 Oct 2003 16:25:11 +0200 Received: from 4commerce.de (10.1.72.2 [10.1.72.2]) by kisone.kisnet.de with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 47243F61; Fri, 17 Oct 2003 16:25:10 +0200 Message-ID: <3F8FFC6D.5080204@4commerce.de> Date: Fri, 17 Oct 2003 16:27:57 +0200 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en References: <20031017084853.S16905@redhat.com> In-Reply-To: <20031017084853.S16905@redhat.com> X-eMessageService: eMission.SMTPServer Subject: "Re: [xml] Something better than _private?" Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi, Daniel Veillard wrote: > On Fri, Oct 17, 2003 at 02:44:08PM +0200, Enno Rehling wrote: >=20 >>I want to store user-data on document nodes, but since everone else=20 >>(libxslt, I hear) is also using _private, I'm not sure that that's such a=20 >>good place to put it. Is there an alternative way? Any best practice for t= his? >=20 >=20 > No, _private is the dedicated place for this. > The fact that libxslt modifies the node has a simple rule: > libxslt modifies the document it's being passed to be transformed > if you want to transform a document you're using for other processing > you must make a copy of it first and handle that copy to libxslt. > I'm not gonna add a new field for this reason. >=20 > Daniel I have an additional question concerning this issue: We use the xmlDoc's _private field in some cases; since it works fine I=20 assume that the xmlDoc's _private field is not touched by=20 transformations. Daniel, is this correct? Will it be save to use this=20 field on the xmlDoc if transforming? Thanks, Kasimier Buchcik From veillard@redhat.com Fri Oct 17 10:38:15 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 3239018848 for ; Fri, 17 Oct 2003 10:38:14 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9HEcQC23806; Fri, 17 Oct 2003 10:38:26 -0400 Date: Fri, 17 Oct 2003 10:38:26 -0400 From: Daniel Veillard To: Kasimier Buchcik Cc: xml@gnome.org Subject: Re: "Re: [xml] Something better than _private?" Message-ID: <20031017103826.U16905@redhat.com> Reply-To: veillard@redhat.com References: <20031017084853.S16905@redhat.com> <3F8FFC6D.5080204@4commerce.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3F8FFC6D.5080204@4commerce.de>; from kbuchcik@4commerce.de on Fri, Oct 17, 2003 at 04:27:57PM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Fri, Oct 17, 2003 at 04:27:57PM +0200, Kasimier Buchcik wrote: > I have an additional question concerning this issue: > We use the xmlDoc's _private field in some cases; since it works fine I > assume that the xmlDoc's _private field is not touched by > transformations. Daniel, is this correct? Will it be save to use this > field on the xmlDoc if transforming? That's right libxslt won't touch it. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From crutcher@unix.eng.ua.edu Sat Oct 18 00:52:28 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail.unix.eng.ua.edu (unknown [130.160.20.13]) by mail.gnome.org (Postfix) with ESMTP id 5C1B618264 for ; Sat, 18 Oct 2003 00:52:28 -0400 (EDT) Received: from ox.unix.eng.ua.edu (ox.unix.eng.ua.edu [130.160.20.14]) by mail.unix.eng.ua.edu (Postfix) with ESMTP id 44EEC4E4095 for ; Fri, 17 Oct 2003 23:52:44 -0500 (CDT) Received: by ox.unix.eng.ua.edu (Postfix, from userid 500) id BDEED24022B; Fri, 17 Oct 2003 23:52:43 -0500 (CDT) Date: Fri, 17 Oct 2003 23:52:43 -0500 From: Crutcher Dunnavant To: xml@gnome.org Message-ID: <20031018045243.GA9783@ox.unix.eng.ua.edu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: [xml] [Patch] xsltproc --load-trace Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I needed something like this to calculate rebuild deps for some generated files, couldn't find it. Here is a patch that adds a flag to xsltproc to dump a trace to stderr for every external entity which loads successfully. Might be worth keeping. -- Crutcher Dunnavant ECSS Hacker / CS Master Student --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="libxslt-1.0.27-load-trace.patch" --- libxslt-1.0.27.orig/xsltproc/xsltproc.c 2003-10-15 15:08:07.000000000 -0500 +++ libxslt-1.0.27/xsltproc/xsltproc.c 2003-10-17 23:46:55.000000000 -0500 @@ -100,6 +100,7 @@ #ifdef LIBXML_HTML_ENABLED static int html = 0; #endif +static int load_trace = 0; #ifdef LIBXML_XINCLUDE_ENABLED static int xinclude = 0; #endif @@ -167,6 +168,13 @@ if (ret != NULL) { if (warning != NULL) ctxt->sax->warning = warning; + if (load_trace) { + fprintf \ + (stderr, + "Loaded URL=\"%s\" ID=\"%s\"\n", + URL ? URL : "(null)", + ID ? ID : "(null)"); + } return(ret); } } @@ -182,6 +190,13 @@ if (ret != NULL) { if (warning != NULL) ctxt->sax->warning = warning; + if (load_trace) { + fprintf \ + (stderr, + "Loaded URL=\"%s\" ID=\"%s\"\n", + URL ? URL : "(null)", + ID ? ID : "(null)"); + } return(ret); } } @@ -500,6 +515,7 @@ #ifdef LIBXML_XINCLUDE_ENABLED printf("\t--xinclude : do XInclude processing on document intput\n"); #endif + printf("\t--load-trace : print trace of all external entites loaded\n"); printf("\t--profile or --norman : dump profiling informations \n"); printf("\nProject libxslt home page: http://xmlsoft.org/XSLT/\n"); printf("To report bugs and get help: http://xmlsoft.org/XSLT/bugs.html\n"); @@ -638,6 +654,9 @@ xinclude++; xsltSetXIncludeDefault(1); #endif + } else if ((!strcmp(argv[i], "-load-trace")) || + (!strcmp(argv[i], "--load-trace"))) { + load_trace++; } else if ((!strcmp(argv[i], "-param")) || (!strcmp(argv[i], "--param"))) { i++; --r5Pyd7+fXNt84Ff3-- From gigerstyle@gmx.ch Sun Oct 19 06:45:30 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by mail.gnome.org (Postfix) with SMTP id 4C1E918668 for ; Sun, 19 Oct 2003 06:45:30 -0400 (EDT) Received: (qmail 20184 invoked by uid 65534); 19 Oct 2003 10:45:44 -0000 Received: from dclient217-162-212-193.hispeed.ch (EHLO vaio.gigerstyle.ch) (217.162.212.193) by mail.gmx.net (mp015) with SMTP; 19 Oct 2003 12:45:44 +0200 X-Authenticated: #1226656 Date: Sun, 19 Oct 2003 12:45:44 +0200 From: Marc Giger To: xml@gnome.org Message-Id: <20031019124544.6acb7795.gigerstyle@gmx.ch> X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [xml] extend xml Document with new rootNode Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi list, I'm new to libxml and need some help. What I try to do is to extend an existing xml-document with a new root node. I've already tried some things... To illustrate the "problem", the actual xml file is something like the following: And the goal should be: What is the best way to achieve this? Perhaps it is relevant that the xml-tree will never be written out to a file. It's processed "in memory". Thank you for your help! greets Marc From crutcher@unix.eng.ua.edu Sun Oct 19 09:09:55 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail.unix.eng.ua.edu (mule.unix.eng.ua.edu [130.160.20.13]) by mail.gnome.org (Postfix) with ESMTP id B97AC1812F for ; Sun, 19 Oct 2003 09:09:55 -0400 (EDT) Received: from ox.unix.eng.ua.edu (ox.unix.eng.ua.edu [130.160.20.14]) by mail.unix.eng.ua.edu (Postfix) with ESMTP id A3AFF4E4095 for ; Sun, 19 Oct 2003 08:10:11 -0500 (CDT) Received: by ox.unix.eng.ua.edu (Postfix, from userid 500) id 1853024022B; Sun, 19 Oct 2003 08:10:11 -0500 (CDT) Date: Sun, 19 Oct 2003 08:10:11 -0500 From: Crutcher Dunnavant To: xml@gnome.org Message-ID: <20031019131011.GA32585@ox.unix.eng.ua.edu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ZPt4rx8FFjLCG7dd" Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: [xml] [PATCH] --load-trace patch 2 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Noticed that if path resolution are being augmented by the --path flag, you get the wrong URL, so fixed the previous patch in this one. -- Crutcher Dunnavant ECSS Hacker / CS Master Student --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="libxslt-1.0.27-load-trace.2.patch" --- libxslt-1.0.27.orig/xsltproc/xsltproc.c 2003-10-15 15:08:07.000000000 -0500 +++ libxslt-1.0.27/xsltproc/xsltproc.c 2003-10-19 08:08:01.000000000 -0500 @@ -100,6 +100,7 @@ #ifdef LIBXML_HTML_ENABLED static int html = 0; #endif +static int load_trace = 0; #ifdef LIBXML_XINCLUDE_ENABLED static int xinclude = 0; #endif @@ -167,6 +168,13 @@ if (ret != NULL) { if (warning != NULL) ctxt->sax->warning = warning; + if (load_trace) { + fprintf \ + (stderr, + "Loaded URL=\"%s\" ID=\"%s\"\n", + URL ? URL : "(null)", + ID ? ID : "(null)"); + } return(ret); } } @@ -178,12 +186,20 @@ newURL = xmlStrcat(newURL, (const xmlChar *) URL); if (newURL != NULL) { ret = defaultEntityLoader((const char *)newURL, ID, ctxt); - xmlFree(newURL); if (ret != NULL) { if (warning != NULL) ctxt->sax->warning = warning; + if (load_trace) { + fprintf \ + (stderr, + "Loaded URL=\"%s\" ID=\"%s\"\n", + newURL, + ID ? ID : "(null)"); + } + xmlFree(newURL); return(ret); } + xmlFree(newURL); } } if (warning != NULL) { @@ -500,6 +516,7 @@ #ifdef LIBXML_XINCLUDE_ENABLED printf("\t--xinclude : do XInclude processing on document intput\n"); #endif + printf("\t--load-trace : print trace of all external entites loaded\n"); printf("\t--profile or --norman : dump profiling informations \n"); printf("\nProject libxslt home page: http://xmlsoft.org/XSLT/\n"); printf("To report bugs and get help: http://xmlsoft.org/XSLT/bugs.html\n"); @@ -638,6 +655,9 @@ xinclude++; xsltSetXIncludeDefault(1); #endif + } else if ((!strcmp(argv[i], "-load-trace")) || + (!strcmp(argv[i], "--load-trace"))) { + load_trace++; } else if ((!strcmp(argv[i], "-param")) || (!strcmp(argv[i], "--param"))) { i++; --ZPt4rx8FFjLCG7dd-- From veillard@redhat.com Sun Oct 19 10:46:35 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 43EB618198 for ; Sun, 19 Oct 2003 10:46:35 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9JEkna06094; Sun, 19 Oct 2003 10:46:49 -0400 Date: Sun, 19 Oct 2003 10:46:49 -0400 From: Daniel Veillard To: Chris Anderson Cc: xml@gnome.org Subject: Re: [xml] RAW && NXT with strncmp() Message-ID: <20031019104649.E16905@redhat.com> Reply-To: veillard@redhat.com References: <001901c38822$1a668da0$2964a8c0@kvp> <20031001095055.G21529@redhat.com> <1065026851.2063.31.camel@stellifer> <20031006050925.B21001@redhat.com> <1065729540.27221.87.camel@kayak.charm.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1065729540.27221.87.camel@kayak.charm.net>; from christop@charm.net on Thu, Oct 09, 2003 at 03:59:00PM -0400 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, Oct 09, 2003 at 03:59:00PM -0400, Chris Anderson wrote: > I messed with how memcmp works, trying a couple of different things like > comparing shorts and integers instead of chars (x86 allows unaligned > access w/penalty). All work slightly slower than just comparing chars. > I believe the memcmp is slower because it moves the chars from immediate > operands to another memory reference. How's this for a compromise, not > quite as pretty, but still somewhat readable: > > ! if (memcmp(CUR_PTR, " > --- > > ! if (CMP9(CUR_PTR, '<', '!', 'D', 'O', 'C', 'T', 'Y', 'P', 'E')) Okay, this is better than the original solution, applied and commited, thanks ! Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From mdev@idg.nl Sun Oct 19 15:07:19 2003 Return-Path: Delivered-To: xml@gnome.org Received: from yoshimo.webtechs.idg.nl (yoshimo.webtechs.idg.nl [62.250.20.10]) by mail.gnome.org (Postfix) with ESMTP id 5B49618735 for ; Sun, 19 Oct 2003 15:07:19 -0400 (EDT) Received: from ghost.lan.webteckies.org (node123e0.a2000.nl [24.132.35.224]) by yoshimo.webtechs.idg.nl (Postfix) with ESMTP id 7279B3C01 for ; Sun, 19 Oct 2003 21:08:01 +0200 (CEST) From: Melvyn Sopacua Organization: IDG.nl To: xml@gnome.org Date: Sun, 19 Oct 2003 21:07:31 +0200 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_zDuk/ynIZWDhqAO"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200310192107.31484.mdev@idg.nl> Subject: [xml] xmlHashScan and *data argument Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: --Boundary-02=_zDuk/ynIZWDhqAO Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: signed data Content-Disposition: inline Hi, I'm trying to build a tree-like output from a given DTD. For that I need to= =20 know the 'indent level' I'm printing at, so I thought I'd pass an int point= er=20 as data. That gives all kinds of weird results and it looks like the passed= =20 element is never initialized. If I set the level within the callback and se= t=20 data to NULL, everything works correctly. The code in valid.c uses an xmlBuffer to pass to the callback and looking i= nto=20 hash.c there are a number or argument mangles, that don't make sense to me. What is assumed about this 'data' argument and can it be only an xmlBuffer? =2D-=20 Melvyn --Boundary-02=_zDuk/ynIZWDhqAO Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQA/kuDz3yAApqL73WMRAjuUAJ4xCbL96ONFsZouBhIy95RtIS0r8ACdHDs9 HrQGGzNjIjkoVyuWtCj+uqs= =TSlt -----END PGP SIGNATURE----- --Boundary-02=_zDuk/ynIZWDhqAO-- From veillard@redhat.com Sun Oct 19 15:48:48 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 4AA7318677 for ; Sun, 19 Oct 2003 15:48:48 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9JJn0G11425; Sun, 19 Oct 2003 15:49:00 -0400 Date: Sun, 19 Oct 2003 15:49:00 -0400 From: Daniel Veillard To: Melvyn Sopacua Cc: xml@gnome.org Subject: Re: [xml] xmlHashScan and *data argument Message-ID: <20031019154900.G16905@redhat.com> Reply-To: veillard@redhat.com References: <200310192107.31484.mdev@idg.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200310192107.31484.mdev@idg.nl>; from mdev@idg.nl on Sun, Oct 19, 2003 at 09:07:31PM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Sun, Oct 19, 2003 at 09:07:31PM +0200, Melvyn Sopacua wrote: Content-Description: signed data > Hi, > > I'm trying to build a tree-like output from a given DTD. For that I need to > know the 'indent level' I'm printing at, so I thought I'd pass an int pointer > as data. That gives all kinds of weird results and it looks like the passed > element is never initialized. If I set the level within the callback and set > data to NULL, everything works correctly. > > The code in valid.c uses an xmlBuffer to pass to the callback and looking into > hash.c there are a number or argument mangles, that don't make sense to me. > > What is assumed about this 'data' argument and can it be only an xmlBuffer? I have no idea what you're trying to do, nor what you problem is. xmlHashScan is used to traverse a hash table. The xmlHashScanner argment is called for each element in the table with the content in the hash, the data you passed and the name of the data in the hash as the third argument. There is nothing assumed about data. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From aospan@netup.ru Sun Oct 19 16:41:59 2003 Return-Path: Delivered-To: xml@gnome.org Received: from netup.ru (unknown [195.161.112.6]) by mail.gnome.org (Postfix) with ESMTP id D99BB18677 for ; Sun, 19 Oct 2003 16:41:58 -0400 (EDT) Received: from [62.118.151.113] (helo=note) by netup.ru with asmtp (Exim 4.22) id 1ABKNV-0004b4-KX; Mon, 20 Oct 2003 00:42:18 +0400 Message-ID: <004801c39681$726c65c0$0100a8c0@note> From: "Abylai Ospan" To: "Peter Jacobi" Cc: References: <3F8336BC.10710.5A3227@localhost> Subject: Re: [xml] Charset trouble Date: Mon, 20 Oct 2003 00:41:58 +0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hello! I have problem with charsets again ;-( I'm add in c++ sub_subtree = xmlNewChild(subtree, NULL,(xmlChar*) "param_value",(xmlChar*)mstring.c_str()); but following error ocure when mstring in KOI8-R charset: output conversion failed due to conv error Bytes: 0xC0 0xE1 0xFB 0xEB xmlOutputBufferWrite: encoder error output conversion failed due to conv error Bytes: 0xE1 0xFB 0xEB 0xE0 xmlOutputBufferWrite: encoder error output conversion failed due to conv error Bytes: 0xFB 0xEB 0xE0 0xE9 xmlOutputBufferWrite: encoder error output conversion failed due to conv error Bytes: 0xEB 0xE0 0xE9 0x20 xmlOutputBufferWrite: encoder error output conversion failed due to conv error Bytes: 0xE0 0xE9 0x20 0xCE How define source charset (like in xml file) on xmlNewChild ? Thanks! wbr, Abylai ----- Original Message ----- From: "Peter Jacobi" To: "Abylai Ospan" Sent: Tuesday, October 07, 2003 11:57 PM Subject: Re: [xml] Charset trouble > Hi Abylai, > > I fear you are somewhat on the wrong list for your questions? > > But I hope some of your fellow Russians on the list help you nevertheless. > > Until their responses arrive: > > 1. Have looked at http://koi8.pp.ru/framed-koi8.html and generally > speaking googled around to find your answers? > > > I have some trouble with html-forms contains russian letters. For example, I > > see (using tcpdump) that all available browsers (Opera 5x, Mozilla, IE 6x) > > send %D1%85 for russian letter "x" and for all russian letter they send hex > > digits. How to convert this to native KOI8-R Charset ? > > 2. "%D1%85" is HTML-escaped for "\xD1\x85" which > is UTF-8 encoded U+0445 which is CYRILLIC SMALL LETTER HA, > which seems to be OK. > So you must HTML-decode and then transcode into your preferred > charset, using iconv on Linux or MultiByteToWideChar+ > WideCharToMultiByte on Win32. > > > Or how to tell > > browser send form data in KOI8-R ? > > 3. This seems to be widely broken, according to the > browser comparison table at > http://koi8.pp.ru/framed-koi8.html > > > Or how to generate html-page using > > libxml/libxslt in KOI8-R charset (I've read that only utf-8/16 output > > available) ? > > 4. If compiling with iconv, you can specify every charset you think > of as an output character set. > > Regards, > Peter Jacobi > Hamburg, Germany > > From mdev@idg.nl Sun Oct 19 16:43:23 2003 Return-Path: Delivered-To: xml@gnome.org Received: from yoshimo.webtechs.idg.nl (yoshimo.webtechs.idg.nl [62.250.20.10]) by mail.gnome.org (Postfix) with ESMTP id 5E0C11879C for ; Sun, 19 Oct 2003 16:43:23 -0400 (EDT) Received: from ghost.lan.webteckies.org (node123e0.a2000.nl [24.132.35.224]) by yoshimo.webtechs.idg.nl (Postfix) with ESMTP id BB09D3C01; Sun, 19 Oct 2003 22:44:07 +0200 (CEST) From: Melvyn Sopacua Organization: IDG.nl To: xml@gnome.org Subject: Re: [xml] xmlHashScan and *data argument Date: Sun, 19 Oct 2003 22:43:33 +0200 User-Agent: KMail/1.5.4 References: <200310192107.31484.mdev@idg.nl> <20031019154900.G16905@redhat.com> In-Reply-To: <20031019154900.G16905@redhat.com> Cc: veillard@redhat.com MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_5dvk/KOROD73Y/p"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200310192243.37793.mdev@idg.nl> Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: --Boundary-02=_5dvk/KOROD73Y/p Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: signed data Content-Disposition: inline On Sunday 19 October 2003 21:49, Daniel Veillard wrote: > On Sun, Oct 19, 2003 at 09:07:31PM +0200, Melvyn Sopacua wrote: > Content-Description: signed data > > > Hi, > > > > I'm trying to build a tree-like output from a given DTD. For that I need > > to know the 'indent level' I'm printing at, so I thought I'd pass an int > > pointer as data. That gives all kinds of weird results and it looks like > > the passed element is never initialized. If I set the level within the > > callback and set data to NULL, everything works correctly. > > > > The code in valid.c uses an xmlBuffer to pass to the callback and looki= ng > > into hash.c there are a number or argument mangles, that don't make sen= se > > to me. > > > > What is assumed about this 'data' argument and can it be only an > > xmlBuffer? > > I have no idea what you're trying to do, nor what you problem is. > xmlHashScan is used to traverse a hash table. The xmlHashScanner > argment is called for each element in the table with the content > in the hash, the data you passed and the name of the data in the hash > as the third argument. There is nothing assumed about data. This works: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D void printElementStructured(xmlElementPtr el) { int level =3D 0; switch( el->etype ) /* pass level along to content printer, but if called from * content, the indent level is 0 again */ } /* in main() */ table =3D dtd->elements; /* dtd is an xmlDtdPtr */ if( table !=3D NULL ) { xmlHashScan(table, (xmlHashScanner) printElementStructured, NULL); } =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This doesn't: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D void printElementStructured(int *level, xmlElementPtr el) { int i; for(i=3D0; i < *level ; i++ ) print("\t"); switch( el->etype ) =2E.. } /* in main() */ int level =3D 0; table =3D dtd->elements; if( table !=3D NULL ) { xmlHashScan(table, (xmlHashScanner) printElementStructured, &level); } =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I basically took this from xmlDumpElementDesc in valid.c and *thought* that= =20 the data argument, would be passed in as first arg to the xmlHashScanner - = in=20 fact - that part works, but the xmlElementPtr is invalid: (gdb) print *el $1 =3D {_private =3D 0x0, type =3D 134541632, name =3D 0x804e140 "", childr= en =3D=20 0xbfbff584, last =3D 0x8048611, parent =3D 0x2, next =3D 0xbfbff58c, prev =3D 0xbfbff= 598, doc =3D 0xbfbff584, etype =3D 134514153, content =3D 0x804a13c, attributes =3D 0xbfbff584, prefix =3D 0x80484ba "=C3", contModel =3D 0x80= 485f1} =2D-=20 Melvyn --Boundary-02=_5dvk/KOROD73Y/p Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQA/kvd53yAApqL73WMRAjmaAJ9MBs+/KHZS1fHUg6U6ONboOgqXtQCghIV2 jm34WDNd0WdHT2/GbzA8rxk= =uFH3 -----END PGP SIGNATURE----- --Boundary-02=_5dvk/KOROD73Y/p-- From veillard@redhat.com Sun Oct 19 16:53:57 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id E600618761 for ; Sun, 19 Oct 2003 16:53:56 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9JKs9g31494; Sun, 19 Oct 2003 16:54:09 -0400 Date: Sun, 19 Oct 2003 16:54:09 -0400 From: Daniel Veillard To: Abylai Ospan Cc: Peter Jacobi , xml@gnome.org Subject: Re: [xml] Charset trouble Message-ID: <20031019165409.H16905@redhat.com> Reply-To: veillard@redhat.com References: <3F8336BC.10710.5A3227@localhost> <004801c39681$726c65c0$0100a8c0@note> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <004801c39681$726c65c0$0100a8c0@note>; from aospan@netup.ru on Mon, Oct 20, 2003 at 12:41:58AM +0400 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Mon, Oct 20, 2003 at 12:41:58AM +0400, Abylai Ospan wrote: > Hello! > > I have problem with charsets again ;-( > I'm add in c++ > sub_subtree = xmlNewChild(subtree, NULL,(xmlChar*) > "param_value",(xmlChar*)mstring.c_str()); > > but following error ocure when mstring in KOI8-R charset: you MUST convert the string to UTF-8 before casting it to (xmlChar*) and using it with the libxml2 API ! Have you read the documentation ? http://xmlsoft.org/encoding.html Yes you MUST do it, there is NO workaround !!! Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard@redhat.com Sun Oct 19 17:01:14 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id E76D5187D0 for ; Sun, 19 Oct 2003 17:01:13 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9JL1Sj01283; Sun, 19 Oct 2003 17:01:28 -0400 Date: Sun, 19 Oct 2003 17:01:28 -0400 From: Daniel Veillard To: Melvyn Sopacua Cc: xml@gnome.org Subject: Re: [xml] xmlHashScan and *data argument Message-ID: <20031019170128.I16905@redhat.com> Reply-To: veillard@redhat.com References: <200310192107.31484.mdev@idg.nl> <20031019154900.G16905@redhat.com> <200310192243.37793.mdev@idg.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200310192243.37793.mdev@idg.nl>; from mdev@idg.nl on Sun, Oct 19, 2003 at 10:43:33PM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Sun, Oct 19, 2003 at 10:43:33PM +0200, Melvyn Sopacua wrote: Content-Description: signed data > This works: > ======================================================================== > void printElementStructured(xmlElementPtr el) [...] > This doesn't: > ======================================================================== > void printElementStructured(int *level, xmlElementPtr el) > { [...] > xmlHashScan(table, (xmlHashScanner) printElementStructured, &level); And you're surprised ? Your problem is the use of the C language apparently. You cannot expect to shuffle arguments and have the compiler guess magically that your interface changed and reorder arguments. xmlElementPtr is the first argument, changing it to the second one is unlikely to work with any C compiler. Parameters are accessed by index on the stack relative to the current function frame pointer, not by magic name association. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From mdev@idg.nl Sun Oct 19 17:31:42 2003 Return-Path: Delivered-To: xml@gnome.org Received: from yoshimo.webtechs.idg.nl (yoshimo.webtechs.idg.nl [62.250.20.10]) by mail.gnome.org (Postfix) with ESMTP id 7FD661840D for ; Sun, 19 Oct 2003 17:31:42 -0400 (EDT) Received: from ghost.lan.webteckies.org (node123e0.a2000.nl [24.132.35.224]) by yoshimo.webtechs.idg.nl (Postfix) with ESMTP id 5DAEC3C01; Sun, 19 Oct 2003 23:32:28 +0200 (CEST) From: Melvyn Sopacua Organization: IDG.nl To: xml@gnome.org Subject: Re: [xml] xmlHashScan and *data argument Date: Sun, 19 Oct 2003 23:31:54 +0200 User-Agent: KMail/1.5.4 References: <200310192107.31484.mdev@idg.nl> <200310192243.37793.mdev@idg.nl> <20031019170128.I16905@redhat.com> In-Reply-To: <20031019170128.I16905@redhat.com> Cc: veillard@redhat.com MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_OLwk/6e+0jrZIsF"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200310192331.58342.mdev@idg.nl> Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: --Boundary-02=_OLwk/6e+0jrZIsF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: signed data Content-Disposition: inline On Sunday 19 October 2003 23:01, Daniel Veillard wrote: > On Sun, Oct 19, 2003 at 10:43:33PM +0200, Melvyn Sopacua wrote: > Content-Description: signed data > > > This works: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > void printElementStructured(xmlElementPtr el) > > [...] > > > This doesn't: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > void printElementStructured(int *level, xmlElementPtr el) > > { > > [...] > > > xmlHashScan(table, (xmlHashScanner) printElementStructured, &level); > > And you're surprised ? > Your problem is the use of the C language apparently. You cannot expect > to shuffle arguments and have the compiler guess magically that your > interface changed and reorder arguments. Ehm - then I don't know why your own code in valid.c works. > xmlElementPtr is the first argument, changing it to the second one is > unlikely to work with any C compiler. Parameters are accessed by index > on the stack relative to the current function frame pointer, not by magic > name association. How is the second version different from: /** * xmlDumpElementDecl: * @buf: the XML buffer output * @elem: An element table * * This will dump the content of the element declaration as an XML * DTD definition */ void xmlDumpElementDecl(xmlBufferPtr buf, xmlElementPtr elem) { /* Notice buf as first argument */ } /** * xmlDumpElementTable: * @buf: the XML buffer output * @table: An element table * * This will dump the content of the element table as an XML DTD definition */ void xmlDumpElementTable(xmlBufferPtr buf, xmlElementTablePtr table) { xmlHashScan(table, (xmlHashScanner) xmlDumpElementDecl, buf); } =46urther investigation shows that xmlSchemaTypeDump in xmlschema.c indeed = has=20 the argument order you list and swapping the arguments in my function works. =2D-=20 Melvyn --Boundary-02=_OLwk/6e+0jrZIsF Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQA/kwLO3yAApqL73WMRAhI4AJsFj1A8e+SFZwutsIeqc2qiQIlO0wCeLuVo 60IOSfpl3QXzK5IHEuFJu4E= =1R5F -----END PGP SIGNATURE----- --Boundary-02=_OLwk/6e+0jrZIsF-- From veillard@redhat.com Sun Oct 19 17:35:59 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 64A0E1840D for ; Sun, 19 Oct 2003 17:35:59 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9JLa8a12290; Sun, 19 Oct 2003 17:36:08 -0400 Date: Sun, 19 Oct 2003 17:36:08 -0400 From: Daniel Veillard To: Crutcher Dunnavant Cc: xml@gnome.org Subject: Re: [xml] [PATCH] --load-trace patch 2 Message-ID: <20031019173608.J16905@redhat.com> Reply-To: veillard@redhat.com References: <20031019131011.GA32585@ox.unix.eng.ua.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031019131011.GA32585@ox.unix.eng.ua.edu>; from crutcher@unix.eng.ua.edu on Sun, Oct 19, 2003 at 08:10:11AM -0500 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Sun, Oct 19, 2003 at 08:10:11AM -0500, Crutcher Dunnavant wrote: > Noticed that if path resolution are being augmented by the --path > flag, you get the wrong URL, so fixed the previous patch in this one. okay, applied and commited, thanks, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard@redhat.com Sun Oct 19 17:43:11 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id D25731840D for ; Sun, 19 Oct 2003 17:43:10 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9JLhPG14700; Sun, 19 Oct 2003 17:43:25 -0400 Date: Sun, 19 Oct 2003 17:43:25 -0400 From: Daniel Veillard To: Melvyn Sopacua Cc: xml@gnome.org Subject: Re: [xml] xmlHashScan and *data argument Message-ID: <20031019174325.K16905@redhat.com> Reply-To: veillard@redhat.com References: <200310192107.31484.mdev@idg.nl> <200310192243.37793.mdev@idg.nl> <20031019170128.I16905@redhat.com> <200310192331.58342.mdev@idg.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200310192331.58342.mdev@idg.nl>; from mdev@idg.nl on Sun, Oct 19, 2003 at 11:31:54PM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Sun, Oct 19, 2003 at 11:31:54PM +0200, Melvyn Sopacua wrote: Content-Description: signed data > On Sunday 19 October 2003 23:01, Daniel Veillard wrote: > > On Sun, Oct 19, 2003 at 10:43:33PM +0200, Melvyn Sopacua wrote: > > Content-Description: signed data > > > > > This works: > > > ======================================================================== > > > void printElementStructured(xmlElementPtr el) > > > > [...] > > > > > This doesn't: > > > ======================================================================== > > > void printElementStructured(int *level, xmlElementPtr el) > > > { > > > > [...] > > > > > xmlHashScan(table, (xmlHashScanner) printElementStructured, &level); > > > > And you're surprised ? > > Your problem is the use of the C language apparently. You cannot expect > > to shuffle arguments and have the compiler guess magically that your > > interface changed and reorder arguments. > > Ehm - then I don't know why your own code in valid.c works. I don't see the point. I just looked at your mail, and if the first version works, then obviously the second version cannot work. > How is the second version different from: I dunno. So then your first version should not work, but you reported it as "working", but you can't obviously have both "working". > Further investigation shows that xmlSchemaTypeDump in xmlschema.c indeed has > the argument order you list and swapping the arguments in my function works. Okay, normal. There is actually 3rd argument passed if you look at the declaration of xmlHashScanner() in libxml/hash.h Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From mdev@idg.nl Sun Oct 19 18:31:46 2003 Return-Path: Delivered-To: xml@gnome.org Received: from yoshimo.webtechs.idg.nl (unknown [62.250.20.10]) by mail.gnome.org (Postfix) with ESMTP id 7332618373 for ; Sun, 19 Oct 2003 18:31:46 -0400 (EDT) Received: from ghost.lan.webteckies.org (node123e0.a2000.nl [24.132.35.224]) by yoshimo.webtechs.idg.nl (Postfix) with ESMTP id B05303C01; Mon, 20 Oct 2003 00:32:20 +0200 (CEST) From: Melvyn Sopacua Organization: IDG.nl To: veillard@redhat.com Subject: Re: [xml] xmlHashScan and *data argument Date: Mon, 20 Oct 2003 00:31:46 +0200 User-Agent: KMail/1.5.4 Cc: xml@gnome.org References: <200310192107.31484.mdev@idg.nl> <200310192331.58342.mdev@idg.nl> <20031019174325.K16905@redhat.com> In-Reply-To: <20031019174325.K16905@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_WDxk/KIaAI7pTzF"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200310200031.50790.mdev@idg.nl> Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: --Boundary-02=_WDxk/KIaAI7pTzF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: signed data Content-Disposition: inline On Sunday 19 October 2003 23:43, Daniel Veillard wrote: > On Sun, Oct 19, 2003 at 11:31:54PM +0200, Melvyn Sopacua wrote: > Content-Description: signed data > > > On Sunday 19 October 2003 23:01, Daniel Veillard wrote: > > > On Sun, Oct 19, 2003 at 10:43:33PM +0200, Melvyn Sopacua wrote: > > > Content-Description: signed data > > > > > > > This works: > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > >=3D=3D=3D void printElementStructured(xmlElementPtr el) > > > > > > [...] > > > > > > > This doesn't: > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > >=3D=3D=3D void printElementStructured(int *level, xmlElementPtr el) > > > > { > > > > > > [...] > > > > > > > xmlHashScan(table, (xmlHashScanner) printElementStructured, &level= ); =46or the first version, the call to xmlHashScan is: xmlHashScan(table, (xmlHashScanner) printElementStructured, NULL); so there is no data argument passed. Just to be clear: these are two tries for the same program. > > > And you're surprised ? > > > Your problem is the use of the C language apparently. You cannot > > > expect to shuffle arguments and have the compiler guess magically that > > > your interface changed and reorder arguments. > > > > Ehm - then I don't know why your own code in valid.c works. > > I don't see the point. I just looked at your mail, and if the first > version works, then obviously the second version cannot work. > > > How is the second version different from: > > I dunno. So then your first version should not work, but you reported it > as "working", but you can't obviously have both "working". I still don't get why xmlDumpElementDecl accepts buf as first argument whil= e=20 it is an xmlHashScanner on an xmlElementTable - the same as I'm doing. I won't dwell on it, but if you can explain it, I can sleep better ;) > > Further investigation shows that xmlSchemaTypeDump in xmlschema.c indeed > > has the argument order you list and swapping the arguments in my functi= on > > works. > > Okay, normal. There is actually 3rd argument passed if you look at the > declaration of xmlHashScanner() in libxml/hash.h Yes - the name associated. I suppose that's the name in the _xmlHashEntry=20 struct, and judging from xmlAddElementDecl that would be identical to=20 xmlDtdElement->name. =2D-=20 Melvyn --Boundary-02=_WDxk/KIaAI7pTzF Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQA/kxDW3yAApqL73WMRAkPDAKCZHoUOdSXAc0jV1wGydwiTX3XzDgCfYvzT NLNfZ+WaQS8JtYznDoZK1Ns= =Z8Gv -----END PGP SIGNATURE----- --Boundary-02=_WDxk/KIaAI7pTzF-- From wbrack@mmm.com.hk Sun Oct 19 20:50:11 2003 Return-Path: Delivered-To: xml@gnome.org Received: from delightful.com.hk (adsl-63-204-84-206.dsl.sktn01.pacbell.net [63.204.84.206]) by mail.gnome.org (Postfix) with ESMTP id 0594D180E5 for ; Sun, 19 Oct 2003 20:50:11 -0400 (EDT) Received: from delightful.com.hk (localhost [127.0.0.1]) by delightful.com.hk (8.12.9/8.12.9) with SMTP id h9K0oMVq031456; Sun, 19 Oct 2003 17:50:23 -0700 Received: from 219.78.248.100 (SquirrelMail authenticated user wbrack) by www.delightful.com.hk with HTTP; Mon, 20 Oct 2003 08:50:23 +0800 (HKT) Message-ID: <1122.219.78.248.100.1066611023.squirrel@www.delightful.com.hk> In-Reply-To: <200310200031.50790.mdev@idg.nl> References: <200310192107.31484.mdev@idg.nl> <200310192331.58342.mdev@idg.nl> <20031019174325.K16905@redhat.com> <200310200031.50790.mdev@idg.nl> Date: Mon, 20 Oct 2003 08:50:23 +0800 (HKT) Subject: Re: [xml] xmlHashScan and *data argument From: "William M. Brack" To: xml@gnome.org Cc: "Melvyn Sopacua" User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Melvyn Sopacua said: > On Sunday 19 October 2003 23:43, Daniel Veillard wrote: >> On Sun, Oct 19, 2003 at 11:31:54PM +0200, Melvyn Sopacua wrote: > I still don't get why xmlDumpElementDecl accepts buf as first > argument while > it is an xmlHashScanner on an xmlElementTable - the same as I'm > doing. > > I won't dwell on it, but if you can explain it, I can sleep better > ;) > >> > Further investigation shows that xmlSchemaTypeDump in >> xmlschema.c indeed >> > has the argument order you list and swapping the arguments in my >> function >> > works. >> >> Okay, normal. There is actually 3rd argument passed if you look >> at the >> declaration of xmlHashScanner() in libxml/hash.h hmmmm..... This thread has gotten my poor mind all twisted. It certainly seems to me that Melvyn has a "valid" point concerning the scan callbacks for dumping data in valid.c. Let's see... the function def for the scanner callback is: /** * xmlHashScanner: * @payload: the data in the hash * @data: extra scannner data * @name: the name associated * * Callback when scanning data in a hash with the simple scanner. */ typedef void (*xmlHashScanner)(void *payload, void *data, xmlChar *name); while the callback function in valid.c has: /** * xmlDumpElementDecl: * @buf: the XML buffer output * @elem: An element table * * This will dump the content of the element declaration as an XML * DTD definition */ void xmlDumpElementDecl(xmlBufferPtr buf, xmlElementPtr elem) { and the corresponding callback function in xmlschemas.c has: /** * xmlSchemaTypeDump: * @output: the file output * @type: a type structure * * Dump a SchemaType structure */ static void xmlSchemaTypeDump(xmlSchemaTypePtr type, FILE * output) It certainly looks as though it's worth reviewing the valid.c code.... Bill From h.shibuya@vertexsystems.co.jp Mon Oct 20 02:59:07 2003 Return-Path: Delivered-To: xml@gnome.org Received: from ssemail007.crayfish.net (ssemail007.crayfish.net [210.172.136.3]) by mail.gnome.org (Postfix) with ESMTP id 69C9018145 for ; Mon, 20 Oct 2003 02:59:06 -0400 (EDT) Received: from Dimension4500C (h084.p464.iij4u.or.jp [210.149.208.84]) by ssemail007.crayfish.net (8.9.3p2/3.7W Crayfish POPbeforeSMTP'd) with ESMTP id PAA08384 for ; Mon, 20 Oct 2003 15:59:21 +0900 (JST) From: "Shibuya" To: Date: Mon, 20 Oct 2003 15:59:17 +0900 Message-ID: <000401c396d7$b1167580$1a01a8c0@Dimension4500C> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: [xml] cannot open include file . xmlwin32version.h Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Although I compiled the sauce of libxml, the error message "can't open include file. ../../include/libxml/xmlwin32version.h" comes out of me. Surely the file xmlwin32version.h is not found in source. From veillard@redhat.com Mon Oct 20 03:00:50 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 5892118145 for ; Mon, 20 Oct 2003 03:00:50 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9K70od17757; Mon, 20 Oct 2003 03:00:50 -0400 Date: Mon, 20 Oct 2003 03:00:50 -0400 From: Daniel Veillard To: "William M. Brack" Cc: xml@gnome.org, Melvyn Sopacua Subject: Re: [xml] xmlHashScan and *data argument Message-ID: <20031020030050.N16905@redhat.com> Reply-To: veillard@redhat.com References: <200310192107.31484.mdev@idg.nl> <200310192331.58342.mdev@idg.nl> <20031019174325.K16905@redhat.com> <200310200031.50790.mdev@idg.nl> <1122.219.78.248.100.1066611023.squirrel@www.delightful.com.hk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1122.219.78.248.100.1066611023.squirrel@www.delightful.com.hk>; from wbrack@mmm.com.hk on Mon, Oct 20, 2003 at 08:50:23AM +0800 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Mon, Oct 20, 2003 at 08:50:23AM +0800, William M. Brack wrote: > Melvyn Sopacua said: > > On Sunday 19 October 2003 23:43, Daniel Veillard wrote: > >> On Sun, Oct 19, 2003 at 11:31:54PM +0200, Melvyn Sopacua wrote: > > > > I still don't get why xmlDumpElementDecl accepts buf as first > > argument while > > it is an xmlHashScanner on an xmlElementTable - the same as I'm > > doing. > > > > I won't dwell on it, but if you can explain it, I can sleep better > > ;) > > > >> > Further investigation shows that xmlSchemaTypeDump in > >> xmlschema.c indeed > >> > has the argument order you list and swapping the arguments in my > >> function > >> > works. > >> > >> Okay, normal. There is actually 3rd argument passed if you look > >> at the > >> declaration of xmlHashScanner() in libxml/hash.h > > hmmmm..... This thread has gotten my poor mind all twisted. It > certainly seems to me that Melvyn has a "valid" point concerning the > scan callbacks for dumping data in valid.c. Let's see... the > function def for the scanner callback is: Hum, maybe I didn't put enough attention in checking the actual code. I looked at the code posted in the mail, and assumed the one in valid.c worked (maybe it's simply not used anymore) because that kind of error should lead to an immediate crash if called. Maybe bugzilla it so this issue gets checked for good (might be as simple as xmllint'in a document with an internal subset and putting a breakpoint in the given function). Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard@redhat.com Mon Oct 20 03:15:51 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id D75511883C for ; Mon, 20 Oct 2003 03:15:50 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9K7G4r22636; Mon, 20 Oct 2003 03:16:04 -0400 Date: Mon, 20 Oct 2003 03:16:04 -0400 From: Daniel Veillard To: Shibuya Cc: xml@gnome.org Subject: Re: [xml] cannot open include file . xmlwin32version.h Message-ID: <20031020031604.O16905@redhat.com> Reply-To: veillard@redhat.com References: <000401c396d7$b1167580$1a01a8c0@Dimension4500C> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <000401c396d7$b1167580$1a01a8c0@Dimension4500C>; from h.shibuya@vertexsystems.co.jp on Mon, Oct 20, 2003 at 03:59:17PM +0900 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Mon, Oct 20, 2003 at 03:59:17PM +0900, Shibuya wrote: > Although I compiled the sauce of libxml, the error message "can't open > include file. ../../include/libxml/xmlwin32version.h" comes out of me. > Surely the file xmlwin32version.h is not found in source. What version, what platform, what compiler, what module raises this error ? I don't see how any code in libxml2 can address the header with "../../include/libxml/xmlwin32version.h" I never use local include addressing in the source code ! Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From pj@walter-graphtek.com Mon Oct 20 03:30:38 2003 Return-Path: Delivered-To: xml@gnome.org Received: from jessenlenz.com (mail.jessenlenz.com [212.79.192.34]) by mail.gnome.org (Postfix) with ESMTP id 821FD181D2 for ; Mon, 20 Oct 2003 03:30:38 -0400 (EDT) Received: from SOFTDEV8 (217.80.11.155) by jessenlenz.com with ESMTP (Eudora Internet Mail Server 3.1.4); Mon, 20 Oct 2003 09:27:55 +0200 From: "Peter Jacobi" To: "Abylai Ospan" Date: Mon, 20 Oct 2003 09:32:06 +0200 MIME-Version: 1.0 Subject: Re: [xml] Charset trouble Cc: Message-ID: <3F93AB96.21857.40CC08@localhost> Priority: normal In-reply-to: <004801c39681$726c65c0$0100a8c0@note> X-mailer: Pegasus Mail for Windows (v4.02) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi Abylai, "Abylai Ospan" wrote: > I have problem with charsets again ;-( > I'm add in c++ > sub_subtree = xmlNewChild(subtree, NULL,(xmlChar*) > "param_value",(xmlChar*)mstring.c_str()); > > but following error ocure when mstring in KOI8-R charset: > > output conversion failed due to conv error > Bytes: 0xC0 0xE1 0xFB 0xEB As Daniel already pointed out, you have to convert to UTF-8 yourself. This is totally independent on the output encoding you specify. As you are on C++, there is a painless, stylistically pleasant way to never forget the conversion: Put it in the stdcpp string to char const* conversions. I don't know if one of the publicly available libxml C++ does this already, but I use it myself and I suspect others as well. Something along the lines of: typedef xmlChar const *pxmlChar; class XmlChar: public string { static char const runtimecharset []; public: XmlChar (string const &s): { convert (s, runtimecharset, *this, "UTF-8"); } operator pxmlChar () const {return (pxmlChar) c_string ();} }; Usage: sub_subtree = xmlNewChild (subtree, NULL, XmlChar ("param_value"), XmlChar (mstring) ); Regards, Peter Jacobi From igor@zlatkovic.com Mon Oct 20 06:24:58 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail.zlatkovic.com (spell.zlatkovic.com [62.75.159.112]) by mail.gnome.org (Postfix) with ESMTP id C34EE1878C for ; Mon, 20 Oct 2003 06:24:57 -0400 (EDT) Received: from zlatkovic.com (pD951B046.dip.t-dialin.net [217.81.176.70]) (authenticated bits=0) by mail.zlatkovic.com (8.12.8/8.12.8) with ESMTP id h9KAPB9V009088 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Mon, 20 Oct 2003 12:25:13 +0200 Message-ID: <3F93B806.50102@zlatkovic.com> Date: Mon, 20 Oct 2003 12:25:10 +0200 From: Igor Zlatkovic Organization: zlatkovic.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031008 X-Accept-Language: en, de MIME-Version: 1.0 To: xml@gnome.org Subject: Re: [xml] Makefile, configure.js and DSP comments References: <20031016130011.J16905@redhat.com> <001801c39480$09b49460$1b67140a@acsesbi> <20031017052540.R16905@redhat.com> In-Reply-To: <20031017052540.R16905@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Huh... I was disconnected for one week and as the devil wants it, that was the week with more posts than the whole month before :-) Daniel Veillard wrote: > On Fri, Oct 17, 2003 at 09:26:49AM +0200, Stéphane Bidoul wrote: > >>>On Thu, Oct 16, 2003 at 06:41:20PM +0200, Stéphane Bidoul wrote: >>> >>>>A few month ago, Igor was always repeating >>>>that those dsp projects where not maintained >>>>anymore. What's their status today? >>>>Should'nt we simply remove them from CVS? >>> >>> that's probably the right thing to do. What is obsolete >>>precisely ? >> >>Everything in win32/dsp, >>and probably in win32/bsb5 too, since >>configure.js now supports the Borland and >>mingw compilers. > > > Okay, done. I also removed dsp for libxslt ! Thanks. Sorry for my not doing it before. Ciao, Igor From veillard@redhat.com Mon Oct 20 07:31:01 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 4F18E18301 for ; Mon, 20 Oct 2003 07:31:01 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9KBV6j14303; Mon, 20 Oct 2003 07:31:06 -0400 Date: Mon, 20 Oct 2003 07:31:06 -0400 From: Daniel Veillard To: Igor Zlatkovic Cc: xml@gnome.org Subject: Re: [xml] Makefile, configure.js and DSP comments Message-ID: <20031020073106.P16905@redhat.com> Reply-To: veillard@redhat.com References: <20031016130011.J16905@redhat.com> <001801c39480$09b49460$1b67140a@acsesbi> <20031017052540.R16905@redhat.com> <3F93B806.50102@zlatkovic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3F93B806.50102@zlatkovic.com>; from igor@zlatkovic.com on Mon, Oct 20, 2003 at 12:25:10PM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Mon, Oct 20, 2003 at 12:25:10PM +0200, Igor Zlatkovic wrote: > Huh... I was disconnected for one week and as the devil wants it, that was > the week with more posts than the whole month before :-) Any chance you can check the CVS version before tonite ? I plan to finally release 2.6.0 this night if there is no last moment problem. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From igor@zlatkovic.com Mon Oct 20 09:13:26 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail.zlatkovic.com (spell.zlatkovic.com [62.75.159.112]) by mail.gnome.org (Postfix) with ESMTP id 22F4A181DE for ; Mon, 20 Oct 2003 09:13:26 -0400 (EDT) Received: from zlatkovic.com (pD951B046.dip.t-dialin.net [217.81.176.70]) (authenticated bits=0) by mail.zlatkovic.com (8.12.8/8.12.8) with ESMTP id h9KDDd9V004380 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 20 Oct 2003 15:13:41 +0200 Message-ID: <3F93DF83.4060705@zlatkovic.com> Date: Mon, 20 Oct 2003 15:13:39 +0200 From: Igor Zlatkovic Reply-To: xml@gnome.org Organization: zlatkovic.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031008 X-Accept-Language: en, de MIME-Version: 1.0 To: veillard@redhat.com Cc: xml@gnome.org Subject: Re: [xml] Makefile, configure.js and DSP comments References: <20031016130011.J16905@redhat.com> <001801c39480$09b49460$1b67140a@acsesbi> <20031017052540.R16905@redhat.com> <3F93B806.50102@zlatkovic.com> <20031020073106.P16905@redhat.com> In-Reply-To: <20031020073106.P16905@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Daniel Veillard wrote: > On Mon, Oct 20, 2003 at 12:25:10PM +0200, Igor Zlatkovic wrote: > >>Huh... I was disconnected for one week and as the devil wants it, that was >>the week with more posts than the whole month before :-) > > > Any chance you can check the CVS version before tonite ? I plan to > finally release 2.6.0 this night if there is no last moment problem. The disc on my Windows machine denies all cooperation. Only one machine is left to my disposal and even if it has all operating systems installed, I must complete some other tasks on Linux now. I won't be able to boot Windows before 20:00, if that isn't too late... Ciao, Igor From veillard@redhat.com Mon Oct 20 10:16:25 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 76390180E2 for ; Mon, 20 Oct 2003 10:16:25 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9KEGfE28577 for xml@gnome.org; Mon, 20 Oct 2003 10:16:41 -0400 Date: Mon, 20 Oct 2003 10:16:41 -0400 From: Daniel Veillard To: xml@gnome.org Subject: Re: [xml] Makefile, configure.js and DSP comments Message-ID: <20031020101641.Q16905@redhat.com> Reply-To: veillard@redhat.com References: <20031016130011.J16905@redhat.com> <001801c39480$09b49460$1b67140a@acsesbi> <20031017052540.R16905@redhat.com> <3F93B806.50102@zlatkovic.com> <20031020073106.P16905@redhat.com> <3F93DF83.4060705@zlatkovic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3F93DF83.4060705@zlatkovic.com>; from igor@zlatkovic.com on Mon, Oct 20, 2003 at 03:13:39PM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Mon, Oct 20, 2003 at 03:13:39PM +0200, Igor Zlatkovic wrote: > Daniel Veillard wrote: > > Any chance you can check the CVS version before tonite ? I plan to > > finally release 2.6.0 this night if there is no last moment problem. > > The disc on my Windows machine denies all cooperation. Only one machine is > left to my disposal and even if it has all operating systems installed, I > must complete some other tasks on Linux now. heh :-) > I won't be able to boot Windows before 20:00, if that isn't too late... Nahh, I will probably do the release late at night. And if you can't check well that just mean we may get a few patches soon after 2.6.0 :-) Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From alfred.mickautsch@schuler-ag.com Mon Oct 20 14:29:30 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail-relay1 (mail-relay1.schuler-ag.com [62.156.183.20]) by mail.gnome.org (Postfix) with ESMTP id 2050C18155 for ; Mon, 20 Oct 2003 14:29:27 -0400 (EDT) Received: from sbs-proxy-test.schuler-ag.com ([192.168.16.254]) by mail-relay1 with Microsoft SMTPSVC(6.0.3790.0); Mon, 20 Oct 2003 20:34:13 +0200 Received: from mail pickup service by sbs-proxy-test.schuler-ag.com with Microsoft SMTPSVC; Mon, 20 Oct 2003 20:29:42 +0200 Content-Type: multipart/mixed; boundary="----=_NextPart_000_48EAD_01C39748.E420F330" Received: from pandora.schuler-ag.com ([192.168.16.20]) by sbs-proxy-test.schuler-ag.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 20 Oct 2003 20:29:40 +0200 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 20 Oct 2003 20:29:40 +0200 Message-ID: <4F38C8B9DAB1014DBDCB29538BBFD6A128508E@pandora.schuler-ag.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: xmlwriter - the next step thread-index: AcOXOSS7UaXLD2mcQcyzXDwT098Tug== From: "Mickautsch, Alfred" To: X-OriginalArrivalTime: 20 Oct 2003 18:29:40.0459 (UTC) FILETIME=[1FD60BB0:01C39738] Subject: [xml] xmlwriter - the next step Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_48EAD_01C39748.E420F330 x-gfisavedcharset: iso-8859-1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I did a little work on the xmlWriter last weekend. It still lacks a lot of functionality and it does not make any validation checks, but I was able to write a usable xml file :-). However, it is only partially tested :-(. Servus -- Alfred -- Alfred Mickautsch schuler business solutions AG Karl-Berner-Str. 4 D-72285 Pfalzgrafenweiler tel: +49 (0)74 45 830-184 fax: +49 (0)74 45 830-349 e-mail: alfred.mickautsch@schuler-ag.com ------=_NextPart_000_48EAD_01C39748.E420F330 Content-Disposition: attachment; filename="xmlwriter.h" Content-Description: xmlwriter.h Content-Type: application/octet-stream; name="xmlwriter.h"; name="xmlwriter.h" Content-Transfer-Encoding: base64 Ci8qCiAqIHhtbHdyaXRlci5oIDogSW50ZXJmYWNlcywgY29uc3RhbnRzIGFuZCB0eXBlcyBvZiB0 aGUKICogdGV4dCB3cml0aW5nIEFQSS5mb3IgWE1MCiAqCiAqIEZvciBsaWNlbnNlIGFuZCBkaXNj bGFpbWVyIHNlZSB0aGUgbGljZW5zZSBhbmQgZGlzY2xhaW1lciBvZgogKiBsaWJ4bWwyLgogKgog KiBhbGZyZWRAbWlja2F1dHNjaC5kZQogKi8KCiNpZm5kZWYgX19YTUxfWE1MV1JJVEVSX0hfXwoj ZGVmaW5lIF9fWE1MX1hNTFdSSVRFUl9IX18KCiNpZmRlZiBfX2NwbHVzcGx1cwpleHRlcm4gIkMi IHsKI2VuZGlmCgojaW5jbHVkZSA8bGlieG1sL3htbElPLmg+CiNpbmNsdWRlIDxsaWJ4bWwvbGlz dC5oPgoKICAgIHR5cGVkZWYgZW51bSB7CiAgICAgICAgWE1MX1RFWFRXUklURVJfTk9ORSwKICAg ICAgICBYTUxfVEVYVFdSSVRFUl9OQU1FLAogICAgICAgIFhNTF9URVhUV1JJVEVSX0FUVFJJQlVU RSwKICAgICAgICBYTUxfVEVYVFdSSVRFUl9URVhULAogICAgICAgIFhNTF9URVhUV1JJVEVSX1BJ LAogICAgICAgIFhNTF9URVhUV1JJVEVSX1BJX1RFWFQsCiAgICAgICAgWE1MX1RFWFRXUklURVJf Q0RBVEEsCiAgICAgICAgWE1MX1RFWFRXUklURVJfRFRELAogICAgICAgIFhNTF9URVhUV1JJVEVS X0RURF9URVhULAogICAgICAgIFhNTF9URVhUV1JJVEVSX0RURF9FTEVNLAogICAgICAgIFhNTF9U RVhUV1JJVEVSX0RURF9BVFRMLAogICAgICAgIFhNTF9URVhUV1JJVEVSX0RURF9FTlRZLAogICAg fSB4bWxUZXh0V3JpdGVyU3RhdGU7CgogICAgdHlwZWRlZiBzdHJ1Y3QgX3htbFRleHRXcml0ZXJT dGFja0VudHJ5IHsKICAgICAgICB4bWxDaGFyICpuYW1lOwogICAgICAgIHhtbFRleHRXcml0ZXJT dGF0ZSBzdGF0ZTsKICAgIH0geG1sVGV4dFdyaXRlclN0YWNrRW50cnk7CgogICAgdHlwZWRlZiBz dHJ1Y3QgX3htbFRleHRXcml0ZXJOc1N0YWNrRW50cnkgewogICAgICAgIHhtbENoYXIgKnByZWZp eDsKICAgICAgICB4bWxDaGFyICp1cmk7CiAgICAgICAgeG1sTGlua1B0ciBlbGVtOwogICAgfSB4 bWxUZXh0V3JpdGVyTnNTdGFja0VudHJ5OwoKICAgIHR5cGVkZWYgc3RydWN0IF94bWxUZXh0V3Jp dGVyIHsKICAgICAgICB4bWxPdXRwdXRCdWZmZXJQdHIgb3V0OyAvKiBvdXRwdXQgYnVmZmVyICov CiAgICAgICAgeG1sTGlzdFB0ciBub2RlczsgICAgICAgLyogZWxlbWVudCBuYW1lIHN0YWNrICov CiAgICAgICAgeG1sTGlzdFB0ciBuc3N0YWNrOyAgICAgLyogbmFtZSBzcGFjZXMgc3RhY2sgKi8K ICAgICAgICBpbnQgbGV2ZWw7CiAgICAgICAgY2hhciBpbmRlbnQ7ICAgICAgICAgICAgLyogaW5k ZW50IGFtb3VudCAqLwogICAgICAgIGNoYXIgaWNoYXI7ICAgICAgICAgICAgIC8qIGluZGVudCBj aGFyYWN0ZXIgKi8KICAgICAgICBjaGFyIHFjaGFyOyAgICAgICAgICAgICAvKiBjaGFyYWN0ZXIg dXNlZCBmb3IgcXVvdGluZyBhdHRyaWJ1dGUgdmFsdWVzICovCiAgICB9IHhtbFRleHRXcml0ZXI7 CgogICAgdHlwZWRlZiB4bWxUZXh0V3JpdGVyICp4bWxUZXh0V3JpdGVyUHRyOwoKLyoKICogQ29u c3RydWN0b3JzICYgRGVzdHJ1Y3RvcgogKi8KICAgIHhtbFRleHRXcml0ZXJQdHIgeG1sTmV3VGV4 dFdyaXRlcih4bWxPdXRwdXRCdWZmZXJQdHIgb3V0KTsKICAgIHhtbFRleHRXcml0ZXJQdHIgeG1s TmV3VGV4dFdyaXRlckZpbGVuYW1lKGNvbnN0IGNoYXIgKnVyaSwKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGludCBjb21wcmVzc2lvbik7CiAgICB4bWxUZXh0 V3JpdGVyUHRyIHhtbE5ld1RleHRXcml0ZXJNZW1vcnkoeG1sQnVmZmVyUHRyIGJ1ZiwKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnQgY29tcHJlc3Npb24pOwog ICAgdm9pZCB4bWxGcmVlVGV4dFdyaXRlcih4bWxUZXh0V3JpdGVyUHRyIHdyaXRlcik7CgovKgog KiBGdW5jdGlvbnMKICovCgoKLyoKICogRG9jdW1lbnQKICovCiAgICBpbnQgeG1sVGV4dFdyaXRl clN0YXJ0RG9jdW1lbnQoeG1sVGV4dFdyaXRlclB0ciB3cml0ZXIsCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgY29uc3QgY2hhciAqdmVyc2lvbiwKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBjb25zdCBjaGFyICplbmNvZGluZywKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBjb25zdCBjaGFyICpzdGFuZGFsb25lKTsKICAgIGludCB4bWxUZXh0 V3JpdGVyRW5kRG9jdW1lbnQoeG1sVGV4dFdyaXRlclB0ciB3cml0ZXIpOwoKLyoKICogQ29tbWVu dHMKICovCiAgICBpbnQgeG1sVGV4dFdyaXRlcldyaXRlRm9ybWF0Q29tbWVudCh4bWxUZXh0V3Jp dGVyUHRyIHdyaXRlciwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNv bnN0IGNoYXIgKmZvcm1hdCwgLi4uKTsKICAgIGludCB4bWxUZXh0V3JpdGVyV3JpdGVWRm9ybWF0 Q29tbWVudCh4bWxUZXh0V3JpdGVyUHRyIHdyaXRlciwKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBjb25zdCBjaGFyICpmb3JtYXQsCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgdmFfbGlzdCBhcmdwdHIpOwogICAgaW50IHhtbFRleHRXcml0 ZXJXcml0ZUNvbW1lbnQoeG1sVGV4dFdyaXRlclB0ciB3cml0ZXIsCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICogY29udGVudCk7CgovKgogKiBFbGVtZW50 cwogKi8KICAgIGludCB4bWxUZXh0V3JpdGVyU3RhcnRFbGVtZW50KHhtbFRleHRXcml0ZXJQdHIg d3JpdGVyLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgeG1sQ2hhciAq IG5hbWUpOwogICAgaW50IHhtbFRleHRXcml0ZXJTdGFydEVsZW1lbnROUyh4bWxUZXh0V3JpdGVy UHRyIHdyaXRlciwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgeG1s Q2hhciAqIHByZWZpeCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3Qg eG1sQ2hhciAqIG5hbWUsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0 IHhtbENoYXIgKiBuYW1lc3BhY2VVUkkpOwogICAgaW50IHhtbFRleHRXcml0ZXJFbmRFbGVtZW50 KHhtbFRleHRXcml0ZXJQdHIgd3JpdGVyKTsKICAgIGludCB4bWxUZXh0V3JpdGVyRnVsbEVuZEVs ZW1lbnQoeG1sVGV4dFdyaXRlclB0ciB3cml0ZXIpOwoKLyoKICogRWxlbWVudHMgY29udmVuaWVu Y3kgZnVuY3Rpb25zCiAqLwogICAgaW50IHhtbFRleHRXcml0ZXJXcml0ZUZvcm1hdEVsZW1lbnQo eG1sVGV4dFdyaXRlclB0ciB3cml0ZXIsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBjb25zdCB4bWxDaGFyICogbmFtZSwKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGNvbnN0IGNoYXIgKmZvcm1hdCwgLi4uKTsKICAgIGludCB4bWxUZXh0V3Jp dGVyV3JpdGVWRm9ybWF0RWxlbWVudCh4bWxUZXh0V3JpdGVyUHRyIHdyaXRlciwKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICogbmFtZSwKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCBjaGFyICpmb3JtYXQs CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdmFfbGlzdCBhcmdwdHIp OwogICAgaW50IHhtbFRleHRXcml0ZXJXcml0ZUVsZW1lbnQoeG1sVGV4dFdyaXRlclB0ciB3cml0 ZXIsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICogbmFt ZSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHhtbENoYXIgKiBjb250 ZW50KTsKICAgIGludCB4bWxUZXh0V3JpdGVyV3JpdGVGb3JtYXRFbGVtZW50TlMoeG1sVGV4dFdy aXRlclB0ciB3cml0ZXIsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGNvbnN0IHhtbENoYXIgKiBwcmVmaXgsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGNvbnN0IHhtbENoYXIgKiBuYW1lLAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICogbmFtZXNwYWNlVVJJLAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCBjaGFyICpmb3JtYXQsIC4uLik7 CiAgICBpbnQgeG1sVGV4dFdyaXRlcldyaXRlVkZvcm1hdEVsZW1lbnROUyh4bWxUZXh0V3JpdGVy UHRyIHdyaXRlciwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNv bnN0IHhtbENoYXIgKiBwcmVmaXgsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBjb25zdCB4bWxDaGFyICogbmFtZSwKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGNvbnN0IHhtbENoYXIgKiBuYW1lc3BhY2VVUkksCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCBjaGFyICpmb3JtYXQsCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB2YV9saXN0IGFyZ3B0cik7CiAg ICBpbnQgeG1sVGV4dFdyaXRlcldyaXRlRWxlbWVudE5TKHhtbFRleHRXcml0ZXJQdHIgd3JpdGVy LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICogcHJl Zml4LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICog bmFtZSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgeG1sQ2hhciAq IG5hbWVzcGFjZVVSSSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3Qg eG1sQ2hhciAqIGNvbnRlbnQpOwoKLyoKICogVGV4dAogKi8KICAgIGludCB4bWxUZXh0V3JpdGVy V3JpdGVGb3JtYXRSYXcoeG1sVGV4dFdyaXRlclB0ciB3cml0ZXIsCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGNvbnN0IGNoYXIgKmZvcm1hdCwgLi4uKTsKICAgIGludCB4bWxU ZXh0V3JpdGVyV3JpdGVWRm9ybWF0UmF3KHhtbFRleHRXcml0ZXJQdHIgd3JpdGVyLAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgY2hhciAqZm9ybWF0LCB2YV9saXN0 IGFyZ3B0cik7CiAgICBpbnQgeG1sVGV4dFdyaXRlcldyaXRlUmF3TGVuKHhtbFRleHRXcml0ZXJQ dHIgd3JpdGVyLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFy ICogY29udGVudCwgaW50IGxlbik7CiAgICBpbnQgeG1sVGV4dFdyaXRlcldyaXRlUmF3KHhtbFRl eHRXcml0ZXJQdHIgd3JpdGVyLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4 bWxDaGFyICogY29udGVudCk7CiAgICBpbnQgeG1sVGV4dFdyaXRlcldyaXRlRm9ybWF0U3RyaW5n KHhtbFRleHRXcml0ZXJQdHIgd3JpdGVyLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBjb25zdCBjaGFyICpmb3JtYXQsIC4uLik7CiAgICBpbnQgeG1sVGV4dFdyaXRlcldy aXRlVkZvcm1hdFN0cmluZyh4bWxUZXh0V3JpdGVyUHRyIHdyaXRlciwKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IGNoYXIgKmZvcm1hdCwKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHZhX2xpc3QgYXJncHRyKTsKICAgIGludCB4bWxU ZXh0V3JpdGVyV3JpdGVTdHJpbmcoeG1sVGV4dFdyaXRlclB0ciB3cml0ZXIsCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHhtbENoYXIgKiBjb250ZW50KTsKICAgIGludCB4 bWxUZXh0V3JpdGVyV3JpdGVCYXNlNjQoeG1sVGV4dFdyaXRlclB0ciB3cml0ZXIsIGNvbnN0IHZv aWQgKmRhdGEsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGludCBzdGFydCwgaW50 IGxlbik7CiAgICBpbnQgeG1sVGV4dFdyaXRlcldyaXRlQmluSGV4KHhtbFRleHRXcml0ZXJQdHIg d3JpdGVyLCBjb25zdCB2b2lkICpkYXRhLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBpbnQgc3RhcnQsIGludCBsZW4pOwoKLyoKICogQXR0cmlidXRlcwogKi8KICAgIGludCB4bWxU ZXh0V3JpdGVyU3RhcnRBdHRyaWJ1dGUoeG1sVGV4dFdyaXRlclB0ciB3cml0ZXIsCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHhtbENoYXIgKiBuYW1lKTsKICAgIGlu dCB4bWxUZXh0V3JpdGVyU3RhcnRBdHRyaWJ1dGVOUyh4bWxUZXh0V3JpdGVyUHRyIHdyaXRlciwK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICogcHJl Zml4LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHhtbENoYXIg KiBuYW1lLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHhtbENo YXIgKiBuYW1lc3BhY2VVUkkpOwogICAgaW50IHhtbFRleHRXcml0ZXJFbmRBdHRyaWJ1dGUoeG1s VGV4dFdyaXRlclB0ciB3cml0ZXIpOwoKLyoKICogQXR0cmlidXRlcyBjb252ZW5pZW5jeSBmdW5j dGlvbnMKICovCiAgICBpbnQgeG1sVGV4dFdyaXRlcldyaXRlRm9ybWF0QXR0cmlidXRlKHhtbFRl eHRXcml0ZXJQdHIgd3JpdGVyLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBjb25zdCB4bWxDaGFyICogbmFtZSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgY29uc3QgY2hhciAqZm9ybWF0LCAuLi4pOwogICAgaW50IHhtbFRleHRXcml0 ZXJXcml0ZVZGb3JtYXRBdHRyaWJ1dGUoeG1sVGV4dFdyaXRlclB0ciB3cml0ZXIsCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICogbmFtZSwK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IGNoYXIgKmZv cm1hdCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHZhX2xpc3Qg YXJncHRyKTsKICAgIGludCB4bWxUZXh0V3JpdGVyV3JpdGVBdHRyaWJ1dGUoeG1sVGV4dFdyaXRl clB0ciB3cml0ZXIsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHht bENoYXIgKiBuYW1lLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4 bWxDaGFyICogY29udGVudCk7CiAgICBpbnQgeG1sVGV4dFdyaXRlcldyaXRlRm9ybWF0QXR0cmli dXRlTlMoeG1sVGV4dFdyaXRlclB0ciB3cml0ZXIsCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgY29uc3QgeG1sQ2hhciAqIHByZWZpeCwKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICogbmFtZSwKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICogbmFt ZXNwYWNlVVJJLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNv bnN0IGNoYXIgKmZvcm1hdCwgLi4uKTsKICAgIGludCB4bWxUZXh0V3JpdGVyV3JpdGVWRm9ybWF0 QXR0cmlidXRlTlMoeG1sVGV4dFdyaXRlclB0ciB3cml0ZXIsCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHhtbENoYXIgKiBwcmVmaXgsCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHhtbENoYXIgKiBuYW1l LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxD aGFyICogbmFtZXNwYWNlVVJJLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBjb25zdCBjaGFyICpmb3JtYXQsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHZhX2xpc3QgYXJncHRyKTsKICAgIGludCB4bWxUZXh0V3JpdGVyV3Jp dGVBdHRyaWJ1dGVOUyh4bWxUZXh0V3JpdGVyUHRyIHdyaXRlciwKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICogcHJlZml4LAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHhtbENoYXIgKiBuYW1lLAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHhtbENoYXIgKiBuYW1lc3BhY2VVUkks CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgeG1sQ2hhciAqIGNv bnRlbnQpOwoKLyoKICogUEkncwogKi8KICAgIGludCB4bWxUZXh0V3JpdGVyU3RhcnRQSSh4bWxU ZXh0V3JpdGVyUHRyIHdyaXRlciwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4 bWxDaGFyICogdGFyZ2V0KTsKICAgIGludCB4bWxUZXh0V3JpdGVyRW5kUEkoeG1sVGV4dFdyaXRl clB0ciB3cml0ZXIpOwoKLyoKICogUEkgY29udmVuaWVuY3kgZnVuY3Rpb25zCiAqLwogICAgaW50 IHhtbFRleHRXcml0ZXJXcml0ZUZvcm1hdFBJKHhtbFRleHRXcml0ZXJQdHIgd3JpdGVyLAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHhtbENoYXIgKiB0YXJnZXQsCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgY2hhciAqZm9ybWF0LCAuLi4p OwogICAgaW50IHhtbFRleHRXcml0ZXJXcml0ZVZGb3JtYXRQSSh4bWxUZXh0V3JpdGVyUHRyIHdy aXRlciwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgeG1sQ2hhciAq IHRhcmdldCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgY2hhciAq Zm9ybWF0LCB2YV9saXN0IGFyZ3B0cik7CiAgICBpbnQgeG1sVGV4dFdyaXRlcldyaXRlUEkoeG1s VGV4dFdyaXRlclB0ciB3cml0ZXIsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3Qg eG1sQ2hhciAqIHRhcmdldCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxD aGFyICogY29udGVudCk7CiNkZWZpbmUgeG1sVGV4dFdyaXRlcldyaXRlUHJvY2Vzc2luZ0luc3Ry dWN0aW9uIHhtbFRleHRXcml0ZXJXcml0ZVBJCgovKgogKiBDREFUQQogKi8KICAgIGludCB4bWxU ZXh0V3JpdGVyU3RhcnRDREFUQSh4bWxUZXh0V3JpdGVyUHRyIHdyaXRlcik7CiAgICBpbnQgeG1s VGV4dFdyaXRlckVuZENEQVRBKHhtbFRleHRXcml0ZXJQdHIgd3JpdGVyKTsKCi8qCiAqIENEQVRB IGNvbnZlbmllbmN5IGZ1bmN0aW9ucwogKi8KICAgIGludCB4bWxUZXh0V3JpdGVyV3JpdGVGb3Jt YXRDREFUQSh4bWxUZXh0V3JpdGVyUHRyIHdyaXRlciwKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBjb25zdCBjaGFyICpmb3JtYXQsIC4uLik7CiAgICBpbnQgeG1sVGV4dFdy aXRlcldyaXRlVkZvcm1hdENEQVRBKHhtbFRleHRXcml0ZXJQdHIgd3JpdGVyLAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCBjaGFyICpmb3JtYXQsIHZhX2xpc3Qg YXJncHRyKTsKICAgIGludCB4bWxUZXh0V3JpdGVyV3JpdGVDREFUQSh4bWxUZXh0V3JpdGVyUHRy IHdyaXRlciwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICog Y29udGVudCk7CgovKgogKiBEVEQKICovCiAgICBpbnQgeG1sVGV4dFdyaXRlclN0YXJ0RFREKHht bFRleHRXcml0ZXJQdHIgd3JpdGVyLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25z dCB4bWxDaGFyICogbmFtZSwgY29uc3QgeG1sQ2hhciAqIHB1YmlkLAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICogc3lzaWQpOwogICAgaW50IHhtbFRleHRXcml0 ZXJFbmREVEQoeG1sVGV4dFdyaXRlclB0ciB3cml0ZXIpOwoKLyoKICogRFREIGNvbnZlbmllbmN5 IGZ1bmN0aW9ucwogKi8KICAgIGludCB4bWxUZXh0V3JpdGVyV3JpdGVGb3JtYXREVEQoeG1sVGV4 dFdyaXRlclB0ciB3cml0ZXIsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNv bnN0IHhtbENoYXIgKiBuYW1lLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBj b25zdCB4bWxDaGFyICogcHViaWQsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGNvbnN0IHhtbENoYXIgKiBzeXNpZCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgY29uc3QgY2hhciAqZm9ybWF0LCAuLi4pOwogICAgaW50IHhtbFRleHRXcml0ZXJXcml0ZVZG b3JtYXREVEQoeG1sVGV4dFdyaXRlclB0ciB3cml0ZXIsCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICogbmFtZSwKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGNvbnN0IHhtbENoYXIgKiBwdWJpZCwKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGNvbnN0IHhtbENoYXIgKiBzeXNpZCwKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IGNoYXIgKmZvcm1hdCwgdmFfbGlzdCBhcmdwdHIp OwogICAgaW50IHhtbFRleHRXcml0ZXJXcml0ZURURCh4bWxUZXh0V3JpdGVyUHRyIHdyaXRlciwK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgeG1sQ2hhciAqIG5hbWUsIGNvbnN0 IHhtbENoYXIgKiBwdWJpZCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgeG1s Q2hhciAqIHN5c2lkLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFy ICogc3Vic2V0KTsKI2RlZmluZSB4bWxUZXh0V3JpdGVyV3JpdGVEb2NUeXBlIHhtbFRleHRXcml0 ZXJXcml0ZURURAoKLyoKICogRFREIGVsZW1lbnQgZGVmaW5pdGlvbgogKi8KICAgIGludCB4bWxU ZXh0V3JpdGVyU3RhcnREVERFbGVtZW50KHhtbFRleHRXcml0ZXJQdHIgd3JpdGVyLAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgeG1sQ2hhciAqIG5hbWUpOwojZGVm aW5lIHhtbFRleHRXcml0ZXJFbmREVERFbGVtZW50IHhtbFRleHRXcml0ZXJFbmREVEQKCi8qCiAq IERURCBlbGVtZW50IGRlZmluaXRpb24gY29udmVuaWVuY3kgZnVuY3Rpb25zCiAqLwogICAgaW50 IHhtbFRleHRXcml0ZXJXcml0ZUZvcm1hdERUREVsZW1lbnQoeG1sVGV4dFdyaXRlclB0ciB3cml0 ZXIsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxD aGFyICogbmFtZSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNv bnN0IGNoYXIgKmZvcm1hdCwgLi4uKTsKICAgIGludCB4bWxUZXh0V3JpdGVyV3JpdGVWRm9ybWF0 RFRERWxlbWVudCh4bWxUZXh0V3JpdGVyUHRyIHdyaXRlciwKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICogbmFtZSwKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCBjaGFyICpmb3JtYXQsCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdmFfbGlzdCBhcmdwdHIpOwog ICAgaW50IHhtbFRleHRXcml0ZXJXcml0ZURUREVsZW1lbnQoeG1sVGV4dFdyaXRlclB0ciB3cml0 ZXIsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICog bmFtZSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHhtbENoYXIg KiBjb250ZW50KTsKCi8qCiAqIERURCBhdHRyaWJ1dGUgbGlzdCBkZWZpbml0aW9uCiAqLwogICAg aW50IHhtbFRleHRXcml0ZXJTdGFydERUREF0dGxpc3QoeG1sVGV4dFdyaXRlclB0ciB3cml0ZXIs CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICogbmFt ZSk7CiNkZWZpbmUgeG1sVGV4dFdyaXRlckVuZERUREF0dGxpc3QgeG1sVGV4dFdyaXRlckVuZERU RAoKLyoKICogRFREIGF0dHJpYnV0ZSBsaXN0IGRlZmluaXRpb24gY29udmVuaWVuY3kgZnVuY3Rp b25zCiAqLwogICAgaW50IHhtbFRleHRXcml0ZXJXcml0ZUZvcm1hdERUREF0dGxpc3QoeG1sVGV4 dFdyaXRlclB0ciB3cml0ZXIsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBjb25zdCB4bWxDaGFyICogbmFtZSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGNvbnN0IGNoYXIgKmZvcm1hdCwgLi4uKTsKICAgIGludCB4bWxUZXh0V3Jp dGVyV3JpdGVWRm9ybWF0RFREQXR0bGlzdCh4bWxUZXh0V3JpdGVyUHRyIHdyaXRlciwKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICogbmFt ZSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCBjaGFy ICpmb3JtYXQsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdmFf bGlzdCBhcmdwdHIpOwogICAgaW50IHhtbFRleHRXcml0ZXJXcml0ZURUREF0dGxpc3QoeG1sVGV4 dFdyaXRlclB0ciB3cml0ZXIsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBj b25zdCB4bWxDaGFyICogbmFtZSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGNvbnN0IHhtbENoYXIgKiBjb250ZW50KTsKCi8qCiAqIERURCBlbnRpdHkgZGVmaW5pdGlvbgog Ki8KICAgIGludCB4bWxUZXh0V3JpdGVyU3RhcnREVERFbnRpdHkoeG1sVGV4dFdyaXRlclB0ciB3 cml0ZXIsIGludCBwZSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3Qg eG1sQ2hhciAqIG5hbWUpOwojZGVmaW5lIHhtbFRleHRXcml0ZXJFbmREVERFbnRpdHkgeG1sVGV4 dFdyaXRlckVuZERURAoKLyoKICogRFREIGVudGl0eSBkZWZpbml0aW9uIGNvbnZlbmllbmN5IGZ1 bmN0aW9ucwogKi8KICAgIGludCB4bWxUZXh0V3JpdGVyV3JpdGVGb3JtYXREVERJbnRlcm5hbEVu dGl0eSh4bWxUZXh0V3JpdGVyUHRyIHdyaXRlciwKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBpbnQgcGUsCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgeG1sQ2hhciAqIG5hbWUsCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgY2hhciAqZm9ybWF0 LCAuLi4pOwogICAgaW50IHhtbFRleHRXcml0ZXJXcml0ZVZGb3JtYXREVERJbnRlcm5hbEVudGl0 eSh4bWxUZXh0V3JpdGVyUHRyIHdyaXRlciwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgaW50IHBlLAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICogbmFtZSwKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgY2hhciAqZm9ybWF0 LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB2YV9s aXN0IGFyZ3B0cik7CiAgICBpbnQgeG1sVGV4dFdyaXRlcldyaXRlRFRESW50ZXJuYWxFbnRpdHko eG1sVGV4dFdyaXRlclB0ciB3cml0ZXIsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgaW50IHBlLCBjb25zdCB4bWxDaGFyICogbmFtZSwKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICogY29udGVudCk7CiAg ICBpbnQgeG1sVGV4dFdyaXRlcldyaXRlRFRERXh0ZXJuYWxFbnRpdHkoeG1sVGV4dFdyaXRlclB0 ciB3cml0ZXIsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW50 IHBlLCBjb25zdCB4bWxDaGFyICogbmFtZSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICogcHViaWQsCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgeG1sQ2hhciAqIHN5c2lkLAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHhtbENoYXIgKiBuZGF0YWlk KTsKICAgIGludCB4bWxUZXh0V3JpdGVyV3JpdGVEVERFbnRpdHkoeG1sVGV4dFdyaXRlclB0ciB3 cml0ZXIsIGludCBwZSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3Qg eG1sQ2hhciAqIG5hbWUsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0 IHhtbENoYXIgKiBwdWJpZCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29u c3QgeG1sQ2hhciAqIHN5c2lkLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBj b25zdCB4bWxDaGFyICogbmRhdGFpZCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgY29uc3QgeG1sQ2hhciAqIGNvbnRlbnQpOwoKLyoKICogRFREIG5vdGF0aW9uIGRlZmluaXRp b24KICovCiAgICBpbnQgeG1sVGV4dFdyaXRlcldyaXRlRFRETm90YXRpb24oeG1sVGV4dFdyaXRl clB0ciB3cml0ZXIsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3Qg eG1sQ2hhciAqIG5hbWUsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29u c3QgeG1sQ2hhciAqIHB1YmlkLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGNvbnN0IHhtbENoYXIgKiBzeXNpZCk7CgovKgogKiBtaXNjCiAqLwogICAgaW50IHhtbFRleHRX cml0ZXJGbHVzaCh4bWxUZXh0V3JpdGVyUHRyIHdyaXRlcik7CgojaWZkZWYgX19jcGx1c3BsdXMK fSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAvL2V4dGVybiAiQyIKI2VuZGlmCiNlbmRp ZiAgICAgICAgICAgICAgICAgICAgICAgICAgLyogX19YTUxfWE1MV1JJVEVSX0hfXyAqLwo= ------=_NextPart_000_48EAD_01C39748.E420F330 Content-Disposition: attachment; filename="xmlwriter.c" Content-Description: xmlwriter.c Content-Type: application/octet-stream; name="xmlwriter.c"; name="xmlwriter.c" Content-Transfer-Encoding: base64 Ci8qCiAqIHhtbHdyaXRlci5jOiBYTUwgdGV4dCB3cml0ZXIgaW1wbGVtZW50YXRpb24KICoKICog Rm9yIGxpY2Vuc2UgYW5kIGRpc2NsYWltZXIgc2VlIHRoZSBsaWNlbnNlIGFuZCBkaXNjbGFpbWVy IG9mCiAqIGxpYnhtbDIuCiAqCiAqIGFsZnJlZEBtaWNrYXV0c2NoLmRlCiAqLwoKI2luY2x1ZGUg PHN0cmluZy5oPgojaW5jbHVkZSA8c3RkYXJnLmg+CgojaW5jbHVkZSA8Li4vbGlieG1sLmg+CiNp bmNsdWRlIDxsaWJ4bWwveG1sbWVtb3J5Lmg+CiNpbmNsdWRlIDxsaWJ4bWwvcGFyc2VyLmg+Cgoj aW5jbHVkZSAieG1sd3JpdGVyLmgiCgojZGVmaW5lIEI2NExJTkVMRU4gNzIKI2RlZmluZSBCNjRD UkxGICJcclxuIgoKc3RhdGljIHZvaWQgeG1sRnJlZVRleHRXcml0ZXJTdGFja0VudHJ5KHhtbExp bmtQdHIgbGspOwpzdGF0aWMgaW50IHhtbENtcFRleHRXcml0ZXJTdGFja0VudHJ5KGNvbnN0IHZv aWQgKmRhdGEwLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHZv aWQgKmRhdGExKTsKc3RhdGljIHZvaWQgeG1sRnJlZVRleHRXcml0ZXJOc1N0YWNrRW50cnkoeG1s TGlua1B0ciBsayk7CnN0YXRpYyBpbnQgeG1sQ21wVGV4dFdyaXRlck5zU3RhY2tFbnRyeShjb25z dCB2b2lkICpkYXRhMCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNv bnN0IHZvaWQgKmRhdGExKTsKc3RhdGljIGludCB4bWxUZXh0V3JpdGVyV3JpdGVNZW1DYWxsYmFj ayh2b2lkICpjb250ZXh0LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGNvbnN0IHhtbENoYXIgKiBzdHIsIGludCBsZW4pOwpzdGF0aWMgaW50IHhtbFRleHRXcml0ZXJD bG9zZU1lbUNhbGxiYWNrKHZvaWQgKmNvbnRleHQpOwpzdGF0aWMgeG1sQ2hhciAqeG1sVGV4dFdy aXRlclZTcHJpbnRmKGNvbnN0IGNoYXIgKmZvcm1hdCwgdmFfbGlzdCBhcmdwdHIpOwpzdGF0aWMg aW50IHhtbE91dHB1dEJ1ZmZlcldyaXRlQmFzZTY0KHhtbE91dHB1dEJ1ZmZlclB0ciBvdXQsIGlu dCBsZW4sCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgdW5zaWdu ZWQgY2hhciAqZGF0YSk7CgovKioKICogeG1sTmV3VGV4dFdyaXRlcjoKICogQG91dDogIGFuIHht bE91dHB1dEJ1ZmZlclB0cgogKgogKiBDcmVhdGUgYSBuZXcgeG1sTmV3VGV4dFdyaXRlciBzdHJ1 Y3R1cmUgdXNpbmcgYW4geG1sT3V0cHV0QnVmZmVyUHRyCiAqCiAqIFJldHVybnMgdGhlIG5ldyB4 bWxUZXh0V3JpdGVyUHRyIG9yIE5VTEwgaW4gY2FzZSBvZiBlcnJvcgogKi8KeG1sVGV4dFdyaXRl clB0cgp4bWxOZXdUZXh0V3JpdGVyKHhtbE91dHB1dEJ1ZmZlclB0ciBvdXQpCnsKICAgIHhtbFRl eHRXcml0ZXJQdHIgcmV0OwoKICAgIHJldCA9ICh4bWxUZXh0V3JpdGVyUHRyKSB4bWxNYWxsb2Mo c2l6ZW9mKHhtbFRleHRXcml0ZXIpKTsKICAgIGlmIChyZXQgPT0gTlVMTCkgewogICAgICAgIHht bEdlbmVyaWNFcnJvcih4bWxHZW5lcmljRXJyb3JDb250ZXh0LAogICAgICAgICAgICAgICAgICAg ICAgICAieG1sTmV3VGV4dFdyaXRlciA6IG91dCBvZiBtZW1vcnkhXG4iKTsKICAgICAgICByZXR1 cm4gTlVMTDsKICAgIH0KICAgIG1lbXNldChyZXQsIDAsIChzaXplX3QpIHNpemVvZih4bWxUZXh0 V3JpdGVyKSk7CgogICAgcmV0LT5ub2RlcyA9IHhtbExpc3RDcmVhdGUoKHhtbExpc3REZWFsbG9j YXRvcikKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHhtbEZyZWVUZXh0V3JpdGVyU3Rh Y2tFbnRyeSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICh4bWxMaXN0RGF0YUNvbXBh cmUpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB4bWxDbXBUZXh0V3JpdGVyU3RhY2tF bnRyeSk7CiAgICBpZiAocmV0LT5ub2RlcyA9PSBOVUxMKSB7CiAgICAgICAgeG1sR2VuZXJpY0Vy cm9yKHhtbEdlbmVyaWNFcnJvckNvbnRleHQsCiAgICAgICAgICAgICAgICAgICAgICAgICJ4bWxO ZXdUZXh0V3JpdGVyIDogb3V0IG9mIG1lbW9yeSFcbiIpOwogICAgICAgIHhtbEZyZWUocmV0KTsK ICAgICAgICByZXR1cm4gTlVMTDsKICAgIH0KCiAgICByZXQtPm5zc3RhY2sgPSB4bWxMaXN0Q3Jl YXRlKCh4bWxMaXN0RGVhbGxvY2F0b3IpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHhtbEZyZWVUZXh0V3JpdGVyTnNTdGFja0VudHJ5LAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAoeG1sTGlzdERhdGFDb21wYXJlKQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB4bWxDbXBUZXh0V3JpdGVyTnNTdGFja0VudHJ5KTsKICAgIGlmIChyZXQtPm5zc3RhY2sg PT0gTlVMTCkgewogICAgICAgIHhtbEdlbmVyaWNFcnJvcih4bWxHZW5lcmljRXJyb3JDb250ZXh0 LAogICAgICAgICAgICAgICAgICAgICAgICAieG1sTmV3VGV4dFdyaXRlciA6IG91dCBvZiBtZW1v cnkhXG4iKTsKICAgICAgICB4bWxGcmVlKHJldC0+bm9kZXMpOwogICAgICAgIHhtbEZyZWUocmV0 KTsKICAgICAgICByZXR1cm4gTlVMTDsKICAgIH0KCiAgICByZXQtPm91dCA9IG91dDsKICAgIHJl dC0+aWNoYXIgPSAnICc7CiAgICByZXQtPnFjaGFyID0gJyInOwoKICAgIHJldHVybiByZXQ7Cn0K Ci8qKgogKiB4bWxOZXdUZXh0V3JpdGVyRmlsZW5hbWU6CiAqIEB1cmk6ICB0aGUgVVJJIG9mIHRo ZSByZXNvdXJjZSBmb3IgdGhlIG91dHB1dAogKiBAY29tcHJlc3Npb246ICBjb21wcmVzcyB0aGUg b3V0cHV0PwogKgogKiBDcmVhdGUgYSBuZXcgeG1sTmV3VGV4dFdyaXRlciBzdHJ1Y3R1cmUgd2l0 aCBAdXJpIGFzIG91dHB1dAogKgogKiBSZXR1cm5zIHRoZSBuZXcgeG1sVGV4dFdyaXRlclB0ciBv ciBOVUxMIGluIGNhc2Ugb2YgZXJyb3IKICovCnhtbFRleHRXcml0ZXJQdHIKeG1sTmV3VGV4dFdy aXRlckZpbGVuYW1lKGNvbnN0IGNoYXIgKnVyaSwgaW50IGNvbXByZXNzaW9uKQp7CiAgICB4bWxU ZXh0V3JpdGVyUHRyIHJldDsKICAgIHhtbE91dHB1dEJ1ZmZlclB0ciBvdXQ7CgogICAgb3V0ID0g eG1sT3V0cHV0QnVmZmVyQ3JlYXRlRmlsZW5hbWUodXJpLCBOVUxMLCBjb21wcmVzc2lvbik7CiAg ICBpZiAob3V0ID09IE5VTEwpIHsKICAgICAgICB4bWxHZW5lcmljRXJyb3IoeG1sR2VuZXJpY0Vy cm9yQ29udGV4dCwKICAgICAgICAgICAgICAgICAgICAgICAgInhtbE5ld1RleHRXcml0ZXJGaWxl bmFtZSA6IG91dCBvZiBtZW1vcnkhXG4iKTsKICAgICAgICByZXR1cm4gTlVMTDsKICAgIH0KCiAg ICByZXQgPSB4bWxOZXdUZXh0V3JpdGVyKG91dCk7CiAgICBpZiAocmV0ID09IE5VTEwpIHsKICAg ICAgICB4bWxHZW5lcmljRXJyb3IoeG1sR2VuZXJpY0Vycm9yQ29udGV4dCwKICAgICAgICAgICAg ICAgICAgICAgICAgInhtbE5ld1RleHRXcml0ZXJGaWxlbmFtZSA6IG91dCBvZiBtZW1vcnkhXG4i KTsKICAgICAgICB4bWxPdXRwdXRCdWZmZXJDbG9zZShvdXQpOwogICAgICAgIHJldHVybiBOVUxM OwogICAgfQoKICAgIHJldHVybiByZXQ7Cn0KCi8qKgogKiB4bWxOZXdUZXh0V3JpdGVyTWVtb3J5 OgogKiBAYnVmOiAgeG1sQnVmZmVyUHRyCiAqIEBjb21wcmVzc2lvbjogIGNvbXByZXNzIHRoZSBv dXRwdXQ/CiAqCiAqIENyZWF0ZSBhIG5ldyB4bWxOZXdUZXh0V3JpdGVyIHN0cnVjdHVyZSB3aXRo IEBidWYgYXMgb3V0cHV0CiAqIFRPRE86IGhhbmRsZSBjb21wcmVzc2lvbgogKgogKiBSZXR1cm5z IHRoZSBuZXcgeG1sVGV4dFdyaXRlclB0ciBvciBOVUxMIGluIGNhc2Ugb2YgZXJyb3IKICovCnht bFRleHRXcml0ZXJQdHIKeG1sTmV3VGV4dFdyaXRlck1lbW9yeSh4bWxCdWZmZXJQdHIgYnVmLCBp bnQgY29tcHJlc3Npb24pCnsKICAgIHhtbFRleHRXcml0ZXJQdHIgcmV0OwogICAgeG1sT3V0cHV0 QnVmZmVyUHRyIG91dDsKCi8qOjp0b2RvIGhhbmRsZSBjb21wcmVzc2lvbiAqLwogICAgb3V0ID0g eG1sT3V0cHV0QnVmZmVyQ3JlYXRlSU8oKHhtbE91dHB1dFdyaXRlQ2FsbGJhY2spCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB4bWxUZXh0V3JpdGVyV3JpdGVNZW1DYWxsYmFjaywK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICh4bWxPdXRwdXRDbG9zZUNhbGxiYWNr KQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgeG1sVGV4dFdyaXRlckNsb3NlTWVt Q2FsbGJhY2ssCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAodm9pZCAqKSBidWYs IE5VTEwpOwogICAgaWYgKG91dCA9PSBOVUxMKSB7CiAgICAgICAgeG1sR2VuZXJpY0Vycm9yKHht bEdlbmVyaWNFcnJvckNvbnRleHQsCiAgICAgICAgICAgICAgICAgICAgICAgICJ4bWxOZXdUZXh0 V3JpdGVyTWVtb3J5IDogb3V0IG9mIG1lbW9yeSFcbiIpOwogICAgICAgIHJldHVybiBOVUxMOwog ICAgfQoKICAgIHJldCA9IHhtbE5ld1RleHRXcml0ZXIob3V0KTsKICAgIGlmIChyZXQgPT0gTlVM TCkgewogICAgICAgIHhtbEdlbmVyaWNFcnJvcih4bWxHZW5lcmljRXJyb3JDb250ZXh0LAogICAg ICAgICAgICAgICAgICAgICAgICAieG1sTmV3VGV4dFdyaXRlck1lbW9yeSA6IG91dCBvZiBtZW1v cnkhXG4iKTsKICAgICAgICB4bWxPdXRwdXRCdWZmZXJDbG9zZShvdXQpOwogICAgICAgIHJldHVy biBOVUxMOwogICAgfQoKICAgIHJldHVybiByZXQ7Cn0KCi8qKgogKiB4bWxGcmVlVGV4dFdyaXRl cjoKICogQHdyaXRlcjogIHRoZSB4bWxUZXh0V3JpdGVyUHRyCiAqCiAqIERlYWxsb2NhdGUgYWxs IHRoZSByZXNvdXJjZXMgYXNzb2NpYXRlZCB0byB0aGUgd3JpdGVyCiAqLwp2b2lkCnhtbEZyZWVU ZXh0V3JpdGVyKHhtbFRleHRXcml0ZXJQdHIgd3JpdGVyKQp7CiAgICBpZiAod3JpdGVyID09IE5V TEwpCiAgICAgICAgcmV0dXJuOwoKICAgIGlmICh3cml0ZXItPm91dCAhPSBOVUxMKQogICAgICAg IHhtbE91dHB1dEJ1ZmZlckNsb3NlKHdyaXRlci0+b3V0KTsKCiAgICBpZiAod3JpdGVyLT5ub2Rl cyAhPSBOVUxMKQogICAgICAgIHhtbExpc3REZWxldGUod3JpdGVyLT5ub2Rlcyk7CgogICAgaWYg KHdyaXRlci0+bnNzdGFjayAhPSBOVUxMKQogICAgICAgIHhtbExpc3REZWxldGUod3JpdGVyLT5u c3N0YWNrKTsKCiAgICB4bWxGcmVlKHdyaXRlcik7Cn0KCi8qKgogKiB4bWxUZXh0V3JpdGVyU3Rh cnREb2N1bWVudDoKICogQHdyaXRlcjogIHRoZSB4bWxUZXh0V3JpdGVyUHRyCiAqIEB2ZXJzaW9u OiAgdGhlIHhtbCB2ZXJzaW9uICgiMS4wIikgb3IgTlVMTCBmb3IgZGVmYXVsdCAoIjEuMCIpCiAq IEBlbmNvZGluZzogIHRoZSBlbmNvZGluZyBvciBOVUxMIGZvciBkZWZhdWx0CiAqIEBzdGFuZGFs b25lOiAieWVzIiBvciAibm8iIG9yIE5VTEwgZm9yIGRlZmF1bHQKICoKICogU3RhcnQgYSBuZXcg eG1sIGRvY3VtZW50CiAqCiAqIFJldHVybnMgdGhlIGJ5dGVzIHdyaXR0ZW4gKG1heSBiZSAwIGJl Y2F1c2Ugb2YgYnVmZmVyaW5nKSBvciAtMSBpbiBjYXNlIG9mIGVycm9yCiAqLwppbnQKeG1sVGV4 dFdyaXRlclN0YXJ0RG9jdW1lbnQoeG1sVGV4dFdyaXRlclB0ciB3cml0ZXIsIGNvbnN0IGNoYXIg KnZlcnNpb24sCiAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IGNoYXIgKmVuY29kaW5n LCBjb25zdCBjaGFyICpzdGFuZGFsb25lKQp7CiAgICBpbnQgY291bnQ7CiAgICBpbnQgc3VtOwog ICAgeG1sTGlua1B0ciBsazsKICAgIHhtbENoYXJFbmNvZGluZ0hhbmRsZXJQdHIgZW5jb2RlcjsK CiAgICBpZiAoKHdyaXRlciA9PSBOVUxMKSB8fCAod3JpdGVyLT5vdXQgPT0gTlVMTCkpCiAgICAg ICAgcmV0dXJuIC0xOwoKICAgIGxrID0geG1sTGlzdEZyb250KHdyaXRlci0+bm9kZXMpOwogICAg aWYgKChsayAhPSBOVUxMKSAmJiAoeG1sTGlua0dldERhdGEobGspICE9IE5VTEwpKSB7CiAgICAg ICAgeG1sR2VuZXJpY0Vycm9yKHhtbEdlbmVyaWNFcnJvckNvbnRleHQsCiAgICAgICAgICAgICAg ICAgICAgICAgICJ4bWxUZXh0V3JpdGVyU3RhcnREb2N1bWVudCA6IG9ubHkgb25lIHByb2xvZyBh bGxvd2VkIGluIGFuIFhNTCBkb2N1bWVudCFcbiIpOwogICAgICAgIHJldHVybiAtMTsKICAgIH0K CiAgICBlbmNvZGVyID0gTlVMTDsKICAgIGlmIChlbmNvZGluZyAhPSBOVUxMKSB7CiAgICAgICAg ZW5jb2RlciA9IHhtbEZpbmRDaGFyRW5jb2RpbmdIYW5kbGVyKGVuY29kaW5nKTsKICAgICAgICBp ZiAoZW5jb2RlciA9PSBOVUxMKSB7CiAgICAgICAgICAgIHhtbEdlbmVyaWNFcnJvcih4bWxHZW5l cmljRXJyb3JDb250ZXh0LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgInhtbFRleHRXcml0 ZXJTdGFydERvY3VtZW50IDogb3V0IG9mIG1lbW9yeSFcbiIpOwogICAgICAgICAgICByZXR1cm4g LTE7CiAgICAgICAgfQogICAgfQoKICAgIHdyaXRlci0+b3V0LT5lbmNvZGVyID0gZW5jb2RlcjsK ICAgIGlmIChlbmNvZGVyICE9IE5VTEwpIHsKICAgICAgICB3cml0ZXItPm91dC0+Y29udiA9IHht bEJ1ZmZlckNyZWF0ZVNpemUoNDAwMCk7CiAgICAgICAgeG1sQ2hhckVuY091dEZ1bmMoZW5jb2Rl ciwgd3JpdGVyLT5vdXQtPmNvbnYsIE5VTEwpOwogICAgfSBlbHNlCiAgICAgICAgd3JpdGVyLT5v dXQtPmNvbnYgPSBOVUxMOwoKICAgIHN1bSA9IDA7CiAgICBjb3VudCA9IHhtbE91dHB1dEJ1ZmZl cldyaXRlU3RyaW5nKHdyaXRlci0+b3V0LCAiPD94bWwgdmVyc2lvbj0iKTsKICAgIGlmIChjb3Vu dCA8IDApCiAgICAgICAgcmV0dXJuIC0xOwogICAgc3VtICs9IGNvdW50OwogICAgY291bnQgPSB4 bWxPdXRwdXRCdWZmZXJXcml0ZSh3cml0ZXItPm91dCwgMSwgJndyaXRlci0+cWNoYXIpOwogICAg aWYgKGNvdW50IDwgMCkKICAgICAgICByZXR1cm4gLTE7CiAgICBzdW0gKz0gY291bnQ7CiAgICBp ZiAodmVyc2lvbiAhPSAwKQogICAgICAgIGNvdW50ID0geG1sT3V0cHV0QnVmZmVyV3JpdGVTdHJp bmcod3JpdGVyLT5vdXQsIHZlcnNpb24pOwogICAgZWxzZQogICAgICAgIGNvdW50ID0geG1sT3V0 cHV0QnVmZmVyV3JpdGVTdHJpbmcod3JpdGVyLT5vdXQsICIxLjAiKTsKICAgIGlmIChjb3VudCA8 IDApCiAgICAgICAgcmV0dXJuIC0xOwogICAgc3VtICs9IGNvdW50OwogICAgY291bnQgPSB4bWxP dXRwdXRCdWZmZXJXcml0ZSh3cml0ZXItPm91dCwgMSwgJndyaXRlci0+cWNoYXIpOwogICAgaWYg KGNvdW50IDwgMCkKICAgICAgICByZXR1cm4gLTE7CiAgICBzdW0gKz0gY291bnQ7CiAgICBpZiAo d3JpdGVyLT5vdXQtPmVuY29kZXIgIT0gMCkgewogICAgICAgIGNvdW50ID0geG1sT3V0cHV0QnVm ZmVyV3JpdGVTdHJpbmcod3JpdGVyLT5vdXQsICIgZW5jb2Rpbmc9Iik7CiAgICAgICAgaWYgKGNv dW50IDwgMCkKICAgICAgICAgICAgcmV0dXJuIC0xOwogICAgICAgIHN1bSArPSBjb3VudDsKICAg ICAgICBjb3VudCA9IHhtbE91dHB1dEJ1ZmZlcldyaXRlKHdyaXRlci0+b3V0LCAxLCAmd3JpdGVy LT5xY2hhcik7CiAgICAgICAgaWYgKGNvdW50IDwgMCkKICAgICAgICAgICAgcmV0dXJuIC0xOwog ICAgICAgIHN1bSArPSBjb3VudDsKICAgICAgICBjb3VudCA9CiAgICAgICAgICAgIHhtbE91dHB1 dEJ1ZmZlcldyaXRlU3RyaW5nKHdyaXRlci0+b3V0LAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB3cml0ZXItPm91dC0+ZW5jb2Rlci0+bmFtZSk7CiAgICAgICAgaWYgKGNv dW50IDwgMCkKICAgICAgICAgICAgcmV0dXJuIC0xOwogICAgICAgIHN1bSArPSBjb3VudDsKICAg ICAgICBjb3VudCA9IHhtbE91dHB1dEJ1ZmZlcldyaXRlKHdyaXRlci0+b3V0LCAxLCAmd3JpdGVy LT5xY2hhcik7CiAgICAgICAgaWYgKGNvdW50IDwgMCkKICAgICAgICAgICAgcmV0dXJuIC0xOwog ICAgICAgIHN1bSArPSBjb3VudDsKICAgIH0KCiAgICBpZiAoc3RhbmRhbG9uZSAhPSAwKSB7CiAg ICAgICAgY291bnQgPSB4bWxPdXRwdXRCdWZmZXJXcml0ZVN0cmluZyh3cml0ZXItPm91dCwgIiBz dGFuZGFsb25lPSIpOwogICAgICAgIGlmIChjb3VudCA8IDApCiAgICAgICAgICAgIHJldHVybiAt MTsKICAgICAgICBzdW0gKz0gY291bnQ7CiAgICAgICAgY291bnQgPSB4bWxPdXRwdXRCdWZmZXJX cml0ZSh3cml0ZXItPm91dCwgMSwgJndyaXRlci0+cWNoYXIpOwogICAgICAgIGlmIChjb3VudCA8 IDApCiAgICAgICAgICAgIHJldHVybiAtMTsKICAgICAgICBzdW0gKz0gY291bnQ7CiAgICAgICAg Y291bnQgPSB4bWxPdXRwdXRCdWZmZXJXcml0ZVN0cmluZyh3cml0ZXItPm91dCwgc3RhbmRhbG9u ZSk7CiAgICAgICAgaWYgKGNvdW50IDwgMCkKICAgICAgICAgICAgcmV0dXJuIC0xOwogICAgICAg IHN1bSArPSBjb3VudDsKICAgICAgICBjb3VudCA9IHhtbE91dHB1dEJ1ZmZlcldyaXRlKHdyaXRl ci0+b3V0LCAxLCAmd3JpdGVyLT5xY2hhcik7CiAgICAgICAgaWYgKGNvdW50IDwgMCkKICAgICAg ICAgICAgcmV0dXJuIC0xOwogICAgICAgIHN1bSArPSBjb3VudDsKICAgIH0KCiAgICBjb3VudCA9 IHhtbE91dHB1dEJ1ZmZlcldyaXRlU3RyaW5nKHdyaXRlci0+b3V0LCAiPz5cbiIpOwogICAgaWYg KGNvdW50IDwgMCkKICAgICAgICByZXR1cm4gLTE7CiAgICBzdW0gKz0gY291bnQ7CgogICAgcmV0 dXJuIHN1bTsKfQoKLyoqCiAqIHhtbFRleHRXcml0ZXJFbmREb2N1bWVudDoKICogQHdyaXRlcjog IHRoZSB4bWxUZXh0V3JpdGVyUHRyCiAqCiAqIEVuZCBhbiB4bWwgZG9jdW1lbnQuIEFsbCBvcGVu IGVsZW1lbnRzIGFyZSBjbG9zZWQKICoKICogUmV0dXJucyB0aGUgYnl0ZXMgd3JpdHRlbiAobWF5 IGJlIDAgYmVjYXVzZSBvZiBidWZmZXJpbmcpIG9yIC0xIGluIGNhc2Ugb2YgZXJyb3IKICovCmlu dAp4bWxUZXh0V3JpdGVyRW5kRG9jdW1lbnQoeG1sVGV4dFdyaXRlclB0ciB3cml0ZXIpCnsKICAg IGludCBjb3VudDsKICAgIGludCBzdW07CiAgICB4bWxMaW5rUHRyIGxrOwogICAgeG1sVGV4dFdy aXRlclN0YWNrRW50cnkgKnA7CgogICAgaWYgKHdyaXRlciA9PSBOVUxMKQogICAgICAgIHJldHVy biAtMTsKCiAgICBzdW0gPSAwOwogICAgd2hpbGUgKGxrID0geG1sTGlzdEZyb250KHdyaXRlci0+ bm9kZXMpKSB7CiAgICAgICAgcCA9ICh4bWxUZXh0V3JpdGVyU3RhY2tFbnRyeSAqKSB4bWxMaW5r R2V0RGF0YShsayk7CiAgICAgICAgaWYgKHAgPT0gMCkKICAgICAgICAgICAgYnJlYWs7CiAgICAg ICAgc3dpdGNoIChwLT5zdGF0ZSkgewogICAgICAgICAgICBjYXNlIFhNTF9URVhUV1JJVEVSX05B TUU6CiAgICAgICAgICAgIGNhc2UgWE1MX1RFWFRXUklURVJfQVRUUklCVVRFOgogICAgICAgICAg ICBjYXNlIFhNTF9URVhUV1JJVEVSX1RFWFQ6CiAgICAgICAgICAgICAgICBjb3VudCA9IHhtbFRl eHRXcml0ZXJFbmRFbGVtZW50KHdyaXRlcik7CiAgICAgICAgICAgICAgICBpZiAoY291bnQgPCAw KQogICAgICAgICAgICAgICAgICAgIHJldHVybiAtMTsKICAgICAgICAgICAgICAgIHN1bSArPSBj b3VudDsKICAgICAgICAgICAgICAgIGJyZWFrOwogICAgICAgICAgICBjYXNlIFhNTF9URVhUV1JJ VEVSX1BJOgogICAgICAgICAgICBjYXNlIFhNTF9URVhUV1JJVEVSX1BJX1RFWFQ6CiAgICAgICAg ICAgICAgICBjb3VudCA9IHhtbFRleHRXcml0ZXJFbmRQSSh3cml0ZXIpOwogICAgICAgICAgICAg ICAgaWYgKGNvdW50IDwgMCkKICAgICAgICAgICAgICAgICAgICByZXR1cm4gLTE7CiAgICAgICAg ICAgICAgICBzdW0gKz0gY291bnQ7CiAgICAgICAgICAgICAgICBicmVhazsKICAgICAgICAgICAg Y2FzZSBYTUxfVEVYVFdSSVRFUl9DREFUQToKICAgICAgICAgICAgICAgIGNvdW50ID0geG1sVGV4 dFdyaXRlckVuZENEQVRBKHdyaXRlcik7CiAgICAgICAgICAgICAgICBpZiAoY291bnQgPCAwKQog ICAgICAgICAgICAgICAgICAgIHJldHVybiAtMTsKICAgICAgICAgICAgICAgIHN1bSArPSBjb3Vu dDsKICAgICAgICAgICAgICAgIGJyZWFrOwogICAgICAgICAgICBjYXNlIFhNTF9URVhUV1JJVEVS X0RURDoKICAgICAgICAgICAgICAgIGNvdW50ID0geG1sVGV4dFdyaXRlckVuZERURCh3cml0ZXIp OwogICAgICAgICAgICAgICAgaWYgKGNvdW50IDwgMCkKICAgICAgICAgICAgICAgICAgICByZXR1 cm4gLTE7CiAgICAgICAgICAgICAgICBzdW0gKz0gY291bnQ7CiAgICAgICAgICAgICAgICBicmVh azsKICAgICAgICB9CiAgICB9CgogICAgcmV0dXJuIHN1bTsKfQoKLyoqCiAqIHhtbFRleHRXcml0 ZXJXcml0ZUZvcm1hdENvbW1lbnQ6CiAqIEB3cml0ZXI6ICB0aGUgeG1sVGV4dFdyaXRlclB0cgog KiBAZm9ybWF0OiAgZm9ybWF0IHN0cmluZyAoc2VlIHByaW50ZikKICoKICogV3JpdGUgYW4geG1s IGNvbW1lbnQuCiAqCiAqIFJldHVybnMgdGhlIGJ5dGVzIHdyaXR0ZW4gKG1heSBiZSAwIGJlY2F1 c2Ugb2YgYnVmZmVyaW5nKSBvciAtMSBpbiBjYXNlIG9mIGVycm9yCiAqLwppbnQKeG1sVGV4dFdy aXRlcldyaXRlRm9ybWF0Q29tbWVudCh4bWxUZXh0V3JpdGVyUHRyIHdyaXRlciwKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBjb25zdCBjaGFyICpmb3JtYXQsIC4uLikKewogICAgaW50 IHJjOwogICAgdmFfbGlzdCBhcDsKCiAgICB2YV9zdGFydChhcCwgZm9ybWF0KTsKCiAgICByYyA9 IHhtbFRleHRXcml0ZXJXcml0ZVZGb3JtYXRDb21tZW50KHdyaXRlciwgZm9ybWF0LCBhcCk7Cgog ICAgdmFfZW5kKGFwKTsKICAgIHJldHVybiByYzsKfQoKLyoqCiAqIHhtbFRleHRXcml0ZXJXcml0 ZVZGb3JtYXRDb21tZW50OgogKiBAd3JpdGVyOiAgdGhlIHhtbFRleHRXcml0ZXJQdHIKICogQGZv cm1hdDogIGZvcm1hdCBzdHJpbmcgKHNlZSBwcmludGYpCiAqIEBhcmdwdHI6ICBwb2ludGVyIHRv IHRoZSBmaXJzdCBtZW1iZXIgb2YgdGhlIHZhcmlhYmxlIGFyZ3VtZW50IGxpc3QuCiAqCiAqIFdy aXRlIGFuIHhtbCBjb21tZW50LgogKgogKiBSZXR1cm5zIHRoZSBieXRlcyB3cml0dGVuIChtYXkg YmUgMCBiZWNhdXNlIG9mIGJ1ZmZlcmluZykgb3IgLTEgaW4gY2FzZSBvZiBlcnJvcgogKi8KaW50 CnhtbFRleHRXcml0ZXJXcml0ZVZGb3JtYXRDb21tZW50KHhtbFRleHRXcml0ZXJQdHIgd3JpdGVy LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCBjaGFyICpmb3JtYXQsIHZh X2xpc3QgYXJncHRyKQp7CiAgICBpbnQgcmM7CiAgICB4bWxDaGFyICpidWY7CgogICAgaWYgKHdy aXRlciA9PSBOVUxMKQogICAgICAgIHJldHVybiAtMTsKCiAgICBidWYgPSB4bWxUZXh0V3JpdGVy VlNwcmludGYoZm9ybWF0LCBhcmdwdHIpOwogICAgaWYgKGJ1ZiA9PSAwKQogICAgICAgIHJldHVy biAwOwoKICAgIHJjID0geG1sVGV4dFdyaXRlcldyaXRlQ29tbWVudCh3cml0ZXIsIGJ1Zik7Cgog ICAgeG1sRnJlZShidWYpOwogICAgcmV0dXJuIHJjOwp9CgovKioKICogeG1sVGV4dFdyaXRlcldy aXRlQ29tbWVudDoKICogQHdyaXRlcjogIHRoZSB4bWxUZXh0V3JpdGVyUHRyCiAqIEBjb250ZW50 OiAgY29tbWVudCBzdHJpbmcKICoKICogV3JpdGUgYW4geG1sIGNvbW1lbnQuCiAqCiAqIFJldHVy bnMgdGhlIGJ5dGVzIHdyaXR0ZW4gKG1heSBiZSAwIGJlY2F1c2Ugb2YgYnVmZmVyaW5nKSBvciAt MSBpbiBjYXNlIG9mIGVycm9yCiAqLwppbnQKeG1sVGV4dFdyaXRlcldyaXRlQ29tbWVudCh4bWxU ZXh0V3JpdGVyUHRyIHdyaXRlciwgY29uc3QgeG1sQ2hhciAqIGNvbnRlbnQpCnsKICAgIGludCBj b3VudDsKICAgIGludCBzdW07CiAgICB4bWxMaW5rUHRyIGxrOwogICAgeG1sVGV4dFdyaXRlclN0 YWNrRW50cnkgKnA7CiAgICB4bWxDaGFyICpidWY7CgogICAgaWYgKCh3cml0ZXIgPT0gTlVMTCkg fHwgKHdyaXRlci0+b3V0ID09IE5VTEwpKQogICAgICAgIHJldHVybiAtMTsKCiAgICBpZiAoY29u dGVudCA9PSBOVUxMKQogICAgICAgIHJldHVybiAwOwoKICAgIHN1bSA9IDA7CiAgICBsayA9IHht bExpc3RGcm9udCh3cml0ZXItPm5vZGVzKTsKICAgIGlmIChsayAhPSAwKSB7CiAgICAgICAgcCA9 ICh4bWxUZXh0V3JpdGVyU3RhY2tFbnRyeSAqKSB4bWxMaW5rR2V0RGF0YShsayk7CiAgICAgICAg aWYgKHAgIT0gMCkgewogICAgICAgICAgICBzd2l0Y2ggKHAtPnN0YXRlKSB7CiAgICAgICAgICAg ICAgICBjYXNlIFhNTF9URVhUV1JJVEVSX1BJOgogICAgICAgICAgICAgICAgY2FzZSBYTUxfVEVY VFdSSVRFUl9QSV9URVhUOgogICAgICAgICAgICAgICAgICAgIHJldHVybiAtMTsKICAgICAgICAg ICAgICAgIGNhc2UgWE1MX1RFWFRXUklURVJfTk9ORToKICAgICAgICAgICAgICAgIGNhc2UgWE1M X1RFWFRXUklURVJfVEVYVDoKICAgICAgICAgICAgICAgICAgICBicmVhazsKICAgICAgICAgICAg ICAgIGNhc2UgWE1MX1RFWFRXUklURVJfTkFNRToKICAgICAgICAgICAgICAgICAgICBjb3VudCA9 IHhtbE91dHB1dEJ1ZmZlcldyaXRlU3RyaW5nKHdyaXRlci0+b3V0LCAiPiIpOwogICAgICAgICAg ICAgICAgICAgIGlmIChjb3VudCA8IDApCiAgICAgICAgICAgICAgICAgICAgICAgIHJldHVybiAt MTsKICAgICAgICAgICAgICAgICAgICBzdW0gKz0gY291bnQ7CiAgICAgICAgICAgICAgICAgICAg cC0+c3RhdGUgPSBYTUxfVEVYVFdSSVRFUl9URVhUOwogICAgICAgICAgICAgICAgICAgIGJyZWFr OwogICAgICAgICAgICB9CiAgICAgICAgfQogICAgfQoKICAgIGNvdW50ID0geG1sT3V0cHV0QnVm ZmVyV3JpdGVTdHJpbmcod3JpdGVyLT5vdXQsICI8IS0tIik7CiAgICBpZiAoY291bnQgPCAwKQog ICAgICAgIHJldHVybiAtMTsKICAgIHN1bSArPSBjb3VudDsKICAgIGJ1ZiA9IHhtbEVuY29kZUVu dGl0aWVzUmVlbnRyYW50KE5VTEwsIGNvbnRlbnQpOwogICAgaWYgKGJ1ZiAhPSAwKSB7CiAgICAg ICAgY291bnQgPSB4bWxPdXRwdXRCdWZmZXJXcml0ZVN0cmluZyh3cml0ZXItPm91dCwgYnVmKTsK ICAgICAgICB4bWxGcmVlKGJ1Zik7CiAgICB9IGVsc2UKICAgICAgICBjb3VudCA9IHhtbE91dHB1 dEJ1ZmZlcldyaXRlU3RyaW5nKHdyaXRlci0+b3V0LCBjb250ZW50KTsKICAgIGlmIChjb3VudCA8 IDApCiAgICAgICAgcmV0dXJuIC0xOwogICAgc3VtICs9IGNvdW50OwogICAgY291bnQgPSB4bWxP dXRwdXRCdWZmZXJXcml0ZVN0cmluZyh3cml0ZXItPm91dCwgIi0tPiIpOwogICAgaWYgKGNvdW50 IDwgMCkKICAgICAgICByZXR1cm4gLTE7CiAgICBzdW0gKz0gY291bnQ7CgogICAgcmV0dXJuIHN1 bTsKfQoKLyoqCiAqIHhtbFRleHRXcml0ZXJTdGFydEVsZW1lbnQ6CiAqIEB3cml0ZXI6ICB0aGUg eG1sVGV4dFdyaXRlclB0cgogKiBAbmFtZTogIGVsZW1lbnQgbmFtZQogKgogKiBTdGFydCBhbiB4 bWwgZWxlbWVudC4KICoKICogUmV0dXJucyB0aGUgYnl0ZXMgd3JpdHRlbiAobWF5IGJlIDAgYmVj YXVzZSBvZiBidWZmZXJpbmcpIG9yIC0xIGluIGNhc2Ugb2YgZXJyb3IKICovCmludAp4bWxUZXh0 V3JpdGVyU3RhcnRFbGVtZW50KHhtbFRleHRXcml0ZXJQdHIgd3JpdGVyLCBjb25zdCB4bWxDaGFy ICogbmFtZSkKewogICAgaW50IGNvdW50OwogICAgaW50IHN1bTsKICAgIHhtbExpbmtQdHIgbGs7 CiAgICB4bWxUZXh0V3JpdGVyU3RhY2tFbnRyeSAqcDsKCiAgICBpZiAoKHdyaXRlciA9PSBOVUxM KSB8fCAobmFtZSA9PSBOVUxMKSB8fCAoKm5hbWUgPT0gJ1wwJykpCiAgICAgICAgcmV0dXJuIC0x OwoKICAgIHN1bSA9IDA7CiAgICBsayA9IHhtbExpc3RGcm9udCh3cml0ZXItPm5vZGVzKTsKICAg IGlmIChsayAhPSAwKSB7CiAgICAgICAgcCA9ICh4bWxUZXh0V3JpdGVyU3RhY2tFbnRyeSAqKSB4 bWxMaW5rR2V0RGF0YShsayk7CiAgICAgICAgaWYgKHAgIT0gMCkgewogICAgICAgICAgICBzd2l0 Y2ggKHAtPnN0YXRlKSB7CiAgICAgICAgICAgICAgICBjYXNlIFhNTF9URVhUV1JJVEVSX1BJOgog ICAgICAgICAgICAgICAgY2FzZSBYTUxfVEVYVFdSSVRFUl9QSV9URVhUOgogICAgICAgICAgICAg ICAgICAgIHJldHVybiAtMTsKICAgICAgICAgICAgICAgIGNhc2UgWE1MX1RFWFRXUklURVJfTk9O RToKICAgICAgICAgICAgICAgICAgICBicmVhazsKICAgICAgICAgICAgICAgIGNhc2UgWE1MX1RF WFRXUklURVJfTkFNRToKICAgICAgICAgICAgICAgICAgICBjb3VudCA9IHhtbE91dHB1dEJ1ZmZl cldyaXRlU3RyaW5nKHdyaXRlci0+b3V0LCAiPiIpOwogICAgICAgICAgICAgICAgICAgIGlmIChj b3VudCA8IDApCiAgICAgICAgICAgICAgICAgICAgICAgIHJldHVybiAtMTsKICAgICAgICAgICAg ICAgICAgICBzdW0gKz0gY291bnQ7CiAgICAgICAgICAgICAgICAgICAgcC0+c3RhdGUgPSBYTUxf VEVYVFdSSVRFUl9URVhUOwogICAgICAgICAgICAgICAgICAgIGJyZWFrOwogICAgICAgICAgICB9 CiAgICAgICAgfQogICAgfQoKICAgIHAgPSAoeG1sVGV4dFdyaXRlclN0YWNrRW50cnkgKikKICAg ICAgICB4bWxNYWxsb2Moc2l6ZW9mKHhtbFRleHRXcml0ZXJTdGFja0VudHJ5KSk7CiAgICBpZiAo cCA9PSAwKSB7CiAgICAgICAgeG1sR2VuZXJpY0Vycm9yKHhtbEdlbmVyaWNFcnJvckNvbnRleHQs CiAgICAgICAgICAgICAgICAgICAgICAgICJ4bWxUZXh0V3JpdGVyU3RhcnRFbGVtZW50IDogb3V0 IG9mIG1lbW9yeSFcbiIpOwogICAgICAgIHJldHVybiAtMTsKICAgIH0KCiAgICBwLT5uYW1lID0g eG1sU3RyZHVwKG5hbWUpOwogICAgaWYgKHAtPm5hbWUgPT0gMCkgewogICAgICAgIHhtbEdlbmVy aWNFcnJvcih4bWxHZW5lcmljRXJyb3JDb250ZXh0LAogICAgICAgICAgICAgICAgICAgICAgICAi eG1sVGV4dFdyaXRlclN0YXJ0RWxlbWVudCA6IG91dCBvZiBtZW1vcnkhXG4iKTsKICAgICAgICB4 bWxGcmVlKHApOwogICAgICAgIHJldHVybiAtMTsKICAgIH0KICAgIHAtPnN0YXRlID0gWE1MX1RF WFRXUklURVJfTkFNRTsKCiAgICB4bWxMaXN0UHVzaEZyb250KHdyaXRlci0+bm9kZXMsIHApOwoK ICAgIGNvdW50ID0geG1sT3V0cHV0QnVmZmVyV3JpdGVTdHJpbmcod3JpdGVyLT5vdXQsICI8Iik7 CiAgICBpZiAoY291bnQgPCAwKQogICAgICAgIHJldHVybiAtMTsKICAgIHN1bSArPSBjb3VudDsK ICAgIGNvdW50ID0geG1sT3V0cHV0QnVmZmVyV3JpdGVTdHJpbmcod3JpdGVyLT5vdXQsIHAtPm5h bWUpOwogICAgaWYgKGNvdW50IDwgMCkKICAgICAgICByZXR1cm4gLTE7CiAgICBzdW0gKz0gY291 bnQ7CgogICAgcmV0dXJuIHN1bTsKfQoKLyoqCiAqIHhtbFRleHRXcml0ZXJTdGFydEVsZW1lbnRO UzoKICogQHdyaXRlcjogIHRoZSB4bWxUZXh0V3JpdGVyUHRyCiAqIEBwcmVmaXg6ICBuYW1lc3Bh Y2UgcHJlZml4IG9yIE5VTEwKICogQG5hbWU6ICBlbGVtZW50IGxvY2FsIG5hbWUKICogQG5hbWVz cGFjZVVSSTogIG5hbWVzcGFjZSBVUkkgb3IgTlVMTAogKgogKiBTdGFydCBhbiB4bWwgZWxlbWVu dCB3aXRoIG5hbWVzcGFjZSBzdXBwb3J0LgogKgogKiBSZXR1cm5zIHRoZSBieXRlcyB3cml0dGVu IChtYXkgYmUgMCBiZWNhdXNlIG9mIGJ1ZmZlcmluZykgb3IgLTEgaW4gY2FzZSBvZiBlcnJvcgog Ki8KaW50CnhtbFRleHRXcml0ZXJTdGFydEVsZW1lbnROUyh4bWxUZXh0V3JpdGVyUHRyIHdyaXRl ciwKICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHhtbENoYXIgKiBwcmVmaXgsIGNv bnN0IHhtbENoYXIgKiBuYW1lLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgeG1s Q2hhciAqIG5hbWVzcGFjZVVSSSkKewogICAgaW50IGNvdW50OwogICAgaW50IHN1bTsKICAgIHht bENoYXIgKmJ1ZjsKCiAgICBpZiAoKHdyaXRlciA9PSBOVUxMKSB8fCAobmFtZSA9PSBOVUxMKSB8 fCAoKm5hbWUgPT0gJ1wwJykpCiAgICAgICAgcmV0dXJuIC0xOwoKICAgIGJ1ZiA9IDA7CiAgICBp ZiAocHJlZml4ICE9IDApIHsKICAgICAgICBidWYgPSB4bWxTdHJkdXAocHJlZml4KTsKICAgICAg ICBidWYgPSB4bWxTdHJjYXQoYnVmLCAiOiIpOwogICAgfQogICAgYnVmID0geG1sU3RyY2F0KGJ1 ZiwgbmFtZSk7CgogICAgc3VtID0gMDsKICAgIGNvdW50ID0geG1sVGV4dFdyaXRlclN0YXJ0RWxl bWVudCh3cml0ZXIsIGJ1Zik7CiAgICB4bWxGcmVlKGJ1Zik7CiAgICBpZiAoY291bnQgPCAwKQog ICAgICAgIHJldHVybiAtMTsKICAgIHN1bSArPSBjb3VudDsKCiAgICBpZiAobmFtZXNwYWNlVVJJ ICE9IDApIHsKICAgICAgICBidWYgPSB4bWxTdHJkdXAoInhtbG5zIik7CiAgICAgICAgaWYgKHBy ZWZpeCAhPSAwKSB7CiAgICAgICAgICAgIGJ1ZiA9IHhtbFN0cmNhdChidWYsICI6Iik7CiAgICAg ICAgICAgIGJ1ZiA9IHhtbFN0cmNhdChidWYsIHByZWZpeCk7CiAgICAgICAgfQoKICAgICAgICBj b3VudCA9IHhtbFRleHRXcml0ZXJXcml0ZUF0dHJpYnV0ZSh3cml0ZXIsIGJ1ZiwgbmFtZXNwYWNl VVJJKTsKICAgICAgICB4bWxGcmVlKGJ1Zik7CiAgICAgICAgaWYgKGNvdW50IDwgMCkKICAgICAg ICAgICAgcmV0dXJuIC0xOwogICAgICAgIHN1bSArPSBjb3VudDsKICAgIH0KCiAgICByZXR1cm4g c3VtOwp9CgovKioKICogeG1sVGV4dFdyaXRlckVuZEVsZW1lbnQ6CiAqIEB3cml0ZXI6ICB0aGUg eG1sVGV4dFdyaXRlclB0cgogKgogKiBFbmQgdGhlIGN1cnJlbnQgeG1sIGVsZW1lbnQuCiAqCiAq IFJldHVybnMgdGhlIGJ5dGVzIHdyaXR0ZW4gKG1heSBiZSAwIGJlY2F1c2Ugb2YgYnVmZmVyaW5n KSBvciAtMSBpbiBjYXNlIG9mIGVycm9yCiAqLwppbnQKeG1sVGV4dFdyaXRlckVuZEVsZW1lbnQo eG1sVGV4dFdyaXRlclB0ciB3cml0ZXIpCnsKICAgIGludCBjb3VudDsKICAgIGludCBzdW07CiAg ICB4bWxMaW5rUHRyIGxrOwogICAgeG1sVGV4dFdyaXRlclN0YWNrRW50cnkgKnA7CgogICAgaWYg KHdyaXRlciA9PSBOVUxMKQogICAgICAgIHJldHVybiAtMTsKCiAgICBsayA9IHhtbExpc3RGcm9u dCh3cml0ZXItPm5vZGVzKTsKICAgIGlmIChsayA9PSAwKQogICAgICAgIHJldHVybiAtMTsKCiAg ICBwID0gKHhtbFRleHRXcml0ZXJTdGFja0VudHJ5ICopIHhtbExpbmtHZXREYXRhKGxrKTsKICAg IGlmIChwID09IDApCiAgICAgICAgcmV0dXJuIC0xOwoKICAgIHN1bSA9IDA7CiAgICBzd2l0Y2gg KHAtPnN0YXRlKSB7CiAgICAgICAgY2FzZSBYTUxfVEVYVFdSSVRFUl9BVFRSSUJVVEU6CiAgICAg ICAgICAgIGNvdW50ID0geG1sVGV4dFdyaXRlckVuZEF0dHJpYnV0ZSh3cml0ZXIpOwogICAgICAg ICAgICBpZiAoY291bnQgPCAwKQogICAgICAgICAgICAgICAgcmV0dXJuIC0xOwogICAgICAgICAg ICBzdW0gKz0gY291bnQ7CiAgICAgICAgICAgIC8qIGZhbGx0aHJvdWdoICovCiAgICAgICAgY2Fz ZSBYTUxfVEVYVFdSSVRFUl9OQU1FOgogICAgICAgICAgICBjb3VudCA9IHhtbE91dHB1dEJ1ZmZl cldyaXRlU3RyaW5nKHdyaXRlci0+b3V0LCAiLz4iKTsKICAgICAgICAgICAgaWYgKGNvdW50IDwg MCkKICAgICAgICAgICAgICAgIHJldHVybiAtMTsKICAgICAgICAgICAgc3VtICs9IGNvdW50Owog ICAgICAgICAgICBicmVhazsKICAgICAgICBjYXNlIFhNTF9URVhUV1JJVEVSX1RFWFQ6CiAgICAg ICAgICAgIGNvdW50ID0geG1sT3V0cHV0QnVmZmVyV3JpdGVTdHJpbmcod3JpdGVyLT5vdXQsICI8 LyIpOwogICAgICAgICAgICBpZiAoY291bnQgPCAwKQogICAgICAgICAgICAgICAgcmV0dXJuIC0x OwogICAgICAgICAgICBzdW0gKz0gY291bnQ7CiAgICAgICAgICAgIGNvdW50ID0geG1sT3V0cHV0 QnVmZmVyV3JpdGVTdHJpbmcod3JpdGVyLT5vdXQsIHAtPm5hbWUpOwogICAgICAgICAgICBpZiAo Y291bnQgPCAwKQogICAgICAgICAgICAgICAgcmV0dXJuIC0xOwogICAgICAgICAgICBzdW0gKz0g Y291bnQ7CiAgICAgICAgICAgIGNvdW50ID0geG1sT3V0cHV0QnVmZmVyV3JpdGVTdHJpbmcod3Jp dGVyLT5vdXQsICI+Iik7CiAgICAgICAgICAgIGlmIChjb3VudCA8IDApCiAgICAgICAgICAgICAg ICByZXR1cm4gLTE7CiAgICAgICAgICAgIHN1bSArPSBjb3VudDsKICAgICAgICAgICAgYnJlYWs7 CiAgICAgICAgZGVmYXVsdDoKICAgICAgICAgICAgcmV0dXJuIC0xOwogICAgfQoKICAgIHhtbExp c3RQb3BGcm9udCh3cml0ZXItPm5vZGVzKTsKICAgIHJldHVybiBzdW07Cn0KCi8qKgogKiB4bWxU ZXh0V3JpdGVyRnVsbEVuZEVsZW1lbnQ6CiAqIEB3cml0ZXI6ICB0aGUgeG1sVGV4dFdyaXRlclB0 cgogKgogKiBFbmQgdGhlIGN1cnJlbnQgeG1sIGVsZW1lbnQuIFdyaXRlcyBhbiBlbmQgdGFnIGV2 ZW4gaWYgdGhlIGVsZW1lbnQgaXMgZW1wdHkKICoKICogUmV0dXJucyB0aGUgYnl0ZXMgd3JpdHRl biAobWF5IGJlIDAgYmVjYXVzZSBvZiBidWZmZXJpbmcpIG9yIC0xIGluIGNhc2Ugb2YgZXJyb3IK ICovCmludAp4bWxUZXh0V3JpdGVyRnVsbEVuZEVsZW1lbnQoeG1sVGV4dFdyaXRlclB0ciB3cml0 ZXIpCnsKICAgIGludCBjb3VudDsKICAgIGludCBzdW07CiAgICB4bWxMaW5rUHRyIGxrOwogICAg eG1sVGV4dFdyaXRlclN0YWNrRW50cnkgKnA7CgogICAgaWYgKHdyaXRlciA9PSBOVUxMKQogICAg ICAgIHJldHVybiAtMTsKCiAgICBsayA9IHhtbExpc3RGcm9udCh3cml0ZXItPm5vZGVzKTsKICAg IGlmIChsayA9PSAwKQogICAgICAgIHJldHVybiAtMTsKCiAgICBwID0gKHhtbFRleHRXcml0ZXJT dGFja0VudHJ5ICopIHhtbExpbmtHZXREYXRhKGxrKTsKICAgIGlmIChwID09IDApCiAgICAgICAg cmV0dXJuIC0xOwoKICAgIHN1bSA9IDA7CiAgICBzd2l0Y2ggKHAtPnN0YXRlKSB7CiAgICAgICAg Y2FzZSBYTUxfVEVYVFdSSVRFUl9BVFRSSUJVVEU6CiAgICAgICAgICAgIGNvdW50ID0geG1sVGV4 dFdyaXRlckVuZEF0dHJpYnV0ZSh3cml0ZXIpOwogICAgICAgICAgICBpZiAoY291bnQgPCAwKQog ICAgICAgICAgICAgICAgcmV0dXJuIC0xOwogICAgICAgICAgICBzdW0gKz0gY291bnQ7CiAgICAg ICAgICAgIC8qIGZhbGx0aHJvdWdoICovCiAgICAgICAgY2FzZSBYTUxfVEVYVFdSSVRFUl9OQU1F OgogICAgICAgICAgICBjb3VudCA9IHhtbE91dHB1dEJ1ZmZlcldyaXRlU3RyaW5nKHdyaXRlci0+ b3V0LCAiPiIpOwogICAgICAgICAgICBpZiAoY291bnQgPCAwKQogICAgICAgICAgICAgICAgcmV0 dXJuIC0xOwogICAgICAgICAgICBzdW0gKz0gY291bnQ7CiAgICAgICAgICAgIC8qIGZhbGx0aHJv dWdoICovCiAgICAgICAgY2FzZSBYTUxfVEVYVFdSSVRFUl9URVhUOgogICAgICAgICAgICBjb3Vu dCA9IHhtbE91dHB1dEJ1ZmZlcldyaXRlU3RyaW5nKHdyaXRlci0+b3V0LCAiPC8iKTsKICAgICAg ICAgICAgaWYgKGNvdW50IDwgMCkKICAgICAgICAgICAgICAgIHJldHVybiAtMTsKICAgICAgICAg ICAgc3VtICs9IGNvdW50OwogICAgICAgICAgICBjb3VudCA9IHhtbE91dHB1dEJ1ZmZlcldyaXRl U3RyaW5nKHdyaXRlci0+b3V0LCBwLT5uYW1lKTsKICAgICAgICAgICAgaWYgKGNvdW50IDwgMCkK ICAgICAgICAgICAgICAgIHJldHVybiAtMTsKICAgICAgICAgICAgc3VtICs9IGNvdW50OwogICAg ICAgICAgICBjb3VudCA9IHhtbE91dHB1dEJ1ZmZlcldyaXRlU3RyaW5nKHdyaXRlci0+b3V0LCAi PiIpOwogICAgICAgICAgICBpZiAoY291bnQgPCAwKQogICAgICAgICAgICAgICAgcmV0dXJuIC0x OwogICAgICAgICAgICBzdW0gKz0gY291bnQ7CiAgICAgICAgICAgIGJyZWFrOwogICAgICAgIGRl ZmF1bHQ6CiAgICAgICAgICAgIHJldHVybiAtMTsKICAgIH0KCiAgICB4bWxMaXN0UG9wRnJvbnQo d3JpdGVyLT5ub2Rlcyk7CiAgICByZXR1cm4gc3VtOwp9CgovKioKICogeG1sVGV4dFdyaXRlcldy aXRlRm9ybWF0UmF3OgogKiBAd3JpdGVyOiAgdGhlIHhtbFRleHRXcml0ZXJQdHIKICogQGZvcm1h dDogIGZvcm1hdCBzdHJpbmcgKHNlZSBwcmludGYpCiAqCiAqIFdyaXRlIGEgZm9ybWF0dGVkIHJh dyB4bWwgdGV4dC4KICoKICogUmV0dXJucyB0aGUgYnl0ZXMgd3JpdHRlbiAobWF5IGJlIDAgYmVj YXVzZSBvZiBidWZmZXJpbmcpIG9yIC0xIGluIGNhc2Ugb2YgZXJyb3IKICovCmludAp4bWxUZXh0 V3JpdGVyV3JpdGVGb3JtYXRSYXcoeG1sVGV4dFdyaXRlclB0ciB3cml0ZXIsIGNvbnN0IGNoYXIg KmZvcm1hdCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4uLikKewogICAgaW50IHJjOwog ICAgdmFfbGlzdCBhcDsKCiAgICB2YV9zdGFydChhcCwgZm9ybWF0KTsKCiAgICByYyA9IHhtbFRl eHRXcml0ZXJXcml0ZVZGb3JtYXRSYXcod3JpdGVyLCBmb3JtYXQsIGFwKTsKCiAgICB2YV9lbmQo YXApOwogICAgcmV0dXJuIHJjOwp9CgovKioKICogeG1sVGV4dFdyaXRlcldyaXRlVkZvcm1hdFJh dzoKICogQHdyaXRlcjogIHRoZSB4bWxUZXh0V3JpdGVyUHRyCiAqIEBmb3JtYXQ6ICBmb3JtYXQg c3RyaW5nIChzZWUgcHJpbnRmKQogKiBAYXJncHRyOiAgcG9pbnRlciB0byB0aGUgZmlyc3QgbWVt YmVyIG9mIHRoZSB2YXJpYWJsZSBhcmd1bWVudCBsaXN0LgogKgogKiBXcml0ZSBhIGZvcm1hdHRl ZCByYXcgeG1sIHRleHQuCiAqCiAqIFJldHVybnMgdGhlIGJ5dGVzIHdyaXR0ZW4gKG1heSBiZSAw IGJlY2F1c2Ugb2YgYnVmZmVyaW5nKSBvciAtMSBpbiBjYXNlIG9mIGVycm9yCiAqLwppbnQKeG1s VGV4dFdyaXRlcldyaXRlVkZvcm1hdFJhdyh4bWxUZXh0V3JpdGVyUHRyIHdyaXRlciwgY29uc3Qg Y2hhciAqZm9ybWF0LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgIHZhX2xpc3QgYXJncHRy KQp7CiAgICBpbnQgcmM7CiAgICB4bWxDaGFyICpidWY7CgogICAgaWYgKHdyaXRlciA9PSBOVUxM KQogICAgICAgIHJldHVybiAtMTsKCiAgICBidWYgPSB4bWxUZXh0V3JpdGVyVlNwcmludGYoZm9y bWF0LCBhcmdwdHIpOwogICAgaWYgKGJ1ZiA9PSAwKQogICAgICAgIHJldHVybiAwOwoKICAgIHJj ID0geG1sVGV4dFdyaXRlcldyaXRlUmF3KHdyaXRlciwgYnVmKTsKCiAgICB4bWxGcmVlKGJ1Zik7 CiAgICByZXR1cm4gcmM7Cn0KCi8qKgogKiB4bWxUZXh0V3JpdGVyV3JpdGVTdHJpbmdMZW46CiAq IEB3cml0ZXI6ICB0aGUgeG1sVGV4dFdyaXRlclB0cgogKiBAY29udGVudDogIHRleHQgc3RyaW5n CiAqIEBsZW46ICBsZW5ndGggb2YgdGhlIHRleHQgc3RyaW5nCiAqCiAqIFdyaXRlIGFuIHhtbCB0 ZXh0LgogKiBUT0RPOiB3aGF0IGFib3V0IGVudGl0aWVzIGFuZCBzcGVjaWFsIGNoYXJzPz8KICoK ICogUmV0dXJucyB0aGUgYnl0ZXMgd3JpdHRlbiAobWF5IGJlIDAgYmVjYXVzZSBvZiBidWZmZXJp bmcpIG9yIC0xIGluIGNhc2Ugb2YgZXJyb3IKICovCmludAp4bWxUZXh0V3JpdGVyV3JpdGVSYXdM ZW4oeG1sVGV4dFdyaXRlclB0ciB3cml0ZXIsIGNvbnN0IHhtbENoYXIgKiBjb250ZW50LAogICAg ICAgICAgICAgICAgICAgICAgICAgaW50IGxlbikKewogICAgaW50IGNvdW50OwogICAgaW50IHN1 bTsKICAgIHhtbExpbmtQdHIgbGs7CiAgICB4bWxUZXh0V3JpdGVyU3RhY2tFbnRyeSAqcDsKCiAg ICBpZiAod3JpdGVyID09IE5VTEwpCiAgICAgICAgcmV0dXJuIC0xOwoKICAgIGxrID0geG1sTGlz dEZyb250KHdyaXRlci0+bm9kZXMpOwogICAgaWYgKGxrID09IDApCiAgICAgICAgcmV0dXJuIDA7 CgogICAgcCA9ICh4bWxUZXh0V3JpdGVyU3RhY2tFbnRyeSAqKSB4bWxMaW5rR2V0RGF0YShsayk7 CiAgICBpZiAocCA9PSAwKQogICAgICAgIHJldHVybiAwOwoKICAgIHN1bSA9IDA7CiAgICBzd2l0 Y2ggKHAtPnN0YXRlKSB7CiAgICAgICAgY2FzZSBYTUxfVEVYVFdSSVRFUl9OT05FOgogICAgICAg ICAgICByZXR1cm4gLTE7CiAgICAgICAgY2FzZSBYTUxfVEVYVFdSSVRFUl9OQU1FOgogICAgICAg ICAgICBjb3VudCA9IHhtbE91dHB1dEJ1ZmZlcldyaXRlU3RyaW5nKHdyaXRlci0+b3V0LCAiPiIp OwogICAgICAgICAgICBpZiAoY291bnQgPCAwKQogICAgICAgICAgICAgICAgcmV0dXJuIC0xOwog ICAgICAgICAgICBzdW0gKz0gY291bnQ7CiAgICAgICAgICAgIHAtPnN0YXRlID0gWE1MX1RFWFRX UklURVJfVEVYVDsKICAgICAgICAgICAgYnJlYWs7CiAgICAgICAgY2FzZSBYTUxfVEVYVFdSSVRF Ul9QSToKICAgICAgICAgICAgY291bnQgPSB4bWxPdXRwdXRCdWZmZXJXcml0ZVN0cmluZyh3cml0 ZXItPm91dCwgIiAiKTsKICAgICAgICAgICAgaWYgKGNvdW50IDwgMCkKICAgICAgICAgICAgICAg IHJldHVybiAtMTsKICAgICAgICAgICAgc3VtICs9IGNvdW50OwogICAgICAgICAgICBwLT5zdGF0 ZSA9IFhNTF9URVhUV1JJVEVSX1BJX1RFWFQ7CiAgICAgICAgICAgIGJyZWFrOwogICAgICAgIGNh c2UgWE1MX1RFWFRXUklURVJfRFREOgogICAgICAgICAgICBjb3VudCA9IHhtbE91dHB1dEJ1ZmZl cldyaXRlU3RyaW5nKHdyaXRlci0+b3V0LCAiIFsiKTsKICAgICAgICAgICAgaWYgKGNvdW50IDwg MCkKICAgICAgICAgICAgICAgIHJldHVybiAtMTsKICAgICAgICAgICAgc3VtICs9IGNvdW50Owog ICAgICAgICAgICBwLT5zdGF0ZSA9IFhNTF9URVhUV1JJVEVSX0RURF9URVhUOwogICAgICAgICAg ICBicmVhazsKICAgICAgICBkZWZhdWx0OgogICAgICAgICAgICBicmVhazsKICAgIH0KCiAgICBj b3VudCA9IHhtbE91dHB1dEJ1ZmZlcldyaXRlKHdyaXRlci0+b3V0LCBsZW4sIGNvbnRlbnQpOwog ICAgaWYgKGNvdW50IDwgMCkKICAgICAgICByZXR1cm4gLTE7CiAgICBzdW0gKz0gY291bnQ7Cgog ICAgcmV0dXJuIHN1bTsKfQoKLyoqCiAqIHhtbFRleHRXcml0ZXJXcml0ZVJhdzoKICogQHdyaXRl cjogIHRoZSB4bWxUZXh0V3JpdGVyUHRyCiAqIEBjb250ZW50OiAgdGV4dCBzdHJpbmcKICoKICog V3JpdGUgYSByYXcgeG1sIHRleHQuCiAqCiAqIFJldHVybnMgdGhlIGJ5dGVzIHdyaXR0ZW4gKG1h eSBiZSAwIGJlY2F1c2Ugb2YgYnVmZmVyaW5nKSBvciAtMSBpbiBjYXNlIG9mIGVycm9yCiAqLwpp bnQKeG1sVGV4dFdyaXRlcldyaXRlUmF3KHhtbFRleHRXcml0ZXJQdHIgd3JpdGVyLCBjb25zdCB4 bWxDaGFyICogY29udGVudCkKewogICAgcmV0dXJuIHhtbFRleHRXcml0ZXJXcml0ZVJhd0xlbih3 cml0ZXIsIGNvbnRlbnQsIHhtbFN0cmxlbihjb250ZW50KSk7Cn0KCi8qKgogKiB4bWxUZXh0V3Jp dGVyV3JpdGVGb3JtYXRTdHJpbmc6CiAqIEB3cml0ZXI6ICB0aGUgeG1sVGV4dFdyaXRlclB0cgog KiBAZm9ybWF0OiAgZm9ybWF0IHN0cmluZyAoc2VlIHByaW50ZikKICoKICogV3JpdGUgYSBmb3Jt YXR0ZWQgeG1sIHRleHQuCiAqCiAqIFJldHVybnMgdGhlIGJ5dGVzIHdyaXR0ZW4gKG1heSBiZSAw IGJlY2F1c2Ugb2YgYnVmZmVyaW5nKSBvciAtMSBpbiBjYXNlIG9mIGVycm9yCiAqLwppbnQKeG1s VGV4dFdyaXRlcldyaXRlRm9ybWF0U3RyaW5nKHhtbFRleHRXcml0ZXJQdHIgd3JpdGVyLCBjb25z dCBjaGFyICpmb3JtYXQsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuLi4pCnsKICAg IGludCByYzsKICAgIHZhX2xpc3QgYXA7CgogICAgdmFfc3RhcnQoYXAsIGZvcm1hdCk7CgogICAg cmMgPSB4bWxUZXh0V3JpdGVyV3JpdGVWRm9ybWF0U3RyaW5nKHdyaXRlciwgZm9ybWF0LCBhcCk7 CgogICAgdmFfZW5kKGFwKTsKICAgIHJldHVybiByYzsKfQoKLyoqCiAqIHhtbFRleHRXcml0ZXJX cml0ZVZGb3JtYXRTdHJpbmc6CiAqIEB3cml0ZXI6ICB0aGUgeG1sVGV4dFdyaXRlclB0cgogKiBA Zm9ybWF0OiAgZm9ybWF0IHN0cmluZyAoc2VlIHByaW50ZikKICogQGFyZ3B0cjogIHBvaW50ZXIg dG8gdGhlIGZpcnN0IG1lbWJlciBvZiB0aGUgdmFyaWFibGUgYXJndW1lbnQgbGlzdC4KICoKICog V3JpdGUgYSBmb3JtYXR0ZWQgeG1sIHRleHQuCiAqCiAqIFJldHVybnMgdGhlIGJ5dGVzIHdyaXR0 ZW4gKG1heSBiZSAwIGJlY2F1c2Ugb2YgYnVmZmVyaW5nKSBvciAtMSBpbiBjYXNlIG9mIGVycm9y CiAqLwppbnQKeG1sVGV4dFdyaXRlcldyaXRlVkZvcm1hdFN0cmluZyh4bWxUZXh0V3JpdGVyUHRy IHdyaXRlciwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCBjaGFyICpmb3Jt YXQsIHZhX2xpc3QgYXJncHRyKQp7CiAgICBpbnQgcmM7CiAgICB4bWxDaGFyICpidWY7CgogICAg aWYgKHdyaXRlciA9PSBOVUxMKQogICAgICAgIHJldHVybiAtMTsKCiAgICBidWYgPSB4bWxUZXh0 V3JpdGVyVlNwcmludGYoZm9ybWF0LCBhcmdwdHIpOwogICAgaWYgKGJ1ZiA9PSAwKQogICAgICAg IHJldHVybiAwOwoKICAgIHJjID0geG1sVGV4dFdyaXRlcldyaXRlU3RyaW5nKHdyaXRlciwgYnVm KTsKCiAgICB4bWxGcmVlKGJ1Zik7CiAgICByZXR1cm4gcmM7Cn0KCi8qKgogKiB4bWxUZXh0V3Jp dGVyV3JpdGVTdHJpbmc6CiAqIEB3cml0ZXI6ICB0aGUgeG1sVGV4dFdyaXRlclB0cgogKiBAY29u dGVudDogIHRleHQgc3RyaW5nCiAqCiAqIFdyaXRlIGFuIHhtbCB0ZXh0LgogKgogKiBSZXR1cm5z IHRoZSBieXRlcyB3cml0dGVuIChtYXkgYmUgMCBiZWNhdXNlIG9mIGJ1ZmZlcmluZykgb3IgLTEg aW4gY2FzZSBvZiBlcnJvcgogKi8KaW50CnhtbFRleHRXcml0ZXJXcml0ZVN0cmluZyh4bWxUZXh0 V3JpdGVyUHRyIHdyaXRlciwgY29uc3QgeG1sQ2hhciAqIGNvbnRlbnQpCnsKICAgIGludCBjb3Vu dDsKICAgIGludCBzdW07CiAgICB4bWxMaW5rUHRyIGxrOwogICAgeG1sVGV4dFdyaXRlclN0YWNr RW50cnkgKnA7CiAgICB4bWxDaGFyICpidWY7CgogICAgaWYgKHdyaXRlciA9PSBOVUxMKQogICAg ICAgIHJldHVybiAtMTsKCiAgICBsayA9IHhtbExpc3RGcm9udCh3cml0ZXItPm5vZGVzKTsKICAg IGlmIChsayA9PSAwKQogICAgICAgIHJldHVybiAtMTsKCiAgICBwID0gKHhtbFRleHRXcml0ZXJT dGFja0VudHJ5ICopIHhtbExpbmtHZXREYXRhKGxrKTsKICAgIGlmIChwID09IDApCiAgICAgICAg cmV0dXJuIC0xOwoKICAgIHN1bSA9IDA7CiAgICBzd2l0Y2ggKHAtPnN0YXRlKSB7CiAgICAgICAg Y2FzZSBYTUxfVEVYVFdSSVRFUl9OT05FOgogICAgICAgICAgICByZXR1cm4gLTE7CiAgICAgICAg Y2FzZSBYTUxfVEVYVFdSSVRFUl9OQU1FOgogICAgICAgICAgICBjb3VudCA9IHhtbE91dHB1dEJ1 ZmZlcldyaXRlU3RyaW5nKHdyaXRlci0+b3V0LCAiPiIpOwogICAgICAgICAgICBpZiAoY291bnQg PCAwKQogICAgICAgICAgICAgICAgcmV0dXJuIC0xOwogICAgICAgICAgICBzdW0gKz0gY291bnQ7 CiAgICAgICAgICAgIHAtPnN0YXRlID0gWE1MX1RFWFRXUklURVJfVEVYVDsKICAgICAgICAgICAg Z290byBlbmNvZGU7CiAgICAgICAgY2FzZSBYTUxfVEVYVFdSSVRFUl9QSToKICAgICAgICAgICAg Y291bnQgPSB4bWxPdXRwdXRCdWZmZXJXcml0ZVN0cmluZyh3cml0ZXItPm91dCwgIiAiKTsKICAg ICAgICAgICAgaWYgKGNvdW50IDwgMCkKICAgICAgICAgICAgICAgIHJldHVybiAtMTsKICAgICAg ICAgICAgc3VtICs9IGNvdW50OwogICAgICAgICAgICBwLT5zdGF0ZSA9IFhNTF9URVhUV1JJVEVS X1BJX1RFWFQ7CiAgICAgICAgICAgIC8qIGZhbGx0aHJvdWdoICovCiAgICAgICAgY2FzZSBYTUxf VEVYVFdSSVRFUl9QSV9URVhUOgogICAgICAgIGNhc2UgWE1MX1RFWFRXUklURVJfVEVYVDoKICAg ICAgICBjYXNlIFhNTF9URVhUV1JJVEVSX0FUVFJJQlVURToKICAgICAgICAgIGVuY29kZToKICAg ICAgICAgICAgYnVmID0geG1sRW5jb2RlRW50aXRpZXNSZWVudHJhbnQoTlVMTCwgY29udGVudCk7 CiAgICAgICAgICAgIGJyZWFrOwogICAgICAgIGNhc2UgWE1MX1RFWFRXUklURVJfRFREOgogICAg ICAgICAgICBjb3VudCA9IHhtbE91dHB1dEJ1ZmZlcldyaXRlU3RyaW5nKHdyaXRlci0+b3V0LCAi IFsiKTsKICAgICAgICAgICAgaWYgKGNvdW50IDwgMCkKICAgICAgICAgICAgICAgIHJldHVybiAt MTsKICAgICAgICAgICAgc3VtICs9IGNvdW50OwogICAgICAgICAgICBwLT5zdGF0ZSA9IFhNTF9U RVhUV1JJVEVSX0RURF9URVhUOwogICAgICAgICAgICAvKiBmYWxsdGhyb3VnaCAqLwogICAgICAg IGNhc2UgWE1MX1RFWFRXUklURVJfRFREX1RFWFQ6CiAgICAgICAgY2FzZSBYTUxfVEVYVFdSSVRF Ul9EVERfRUxFTToKICAgICAgICBjYXNlIFhNTF9URVhUV1JJVEVSX0NEQVRBOgogICAgICAgICAg ICBidWYgPSB4bWxTdHJkdXAoY29udGVudCk7CiAgICAgICAgICAgIGJyZWFrOwogICAgfQoKICAg IGlmIChidWYgIT0gMCkgewogICAgICAgIGNvdW50ID0geG1sT3V0cHV0QnVmZmVyV3JpdGVTdHJp bmcod3JpdGVyLT5vdXQsIGJ1Zik7CiAgICAgICAgeG1sRnJlZShidWYpOwogICAgfSBlbHNlCiAg ICAgICAgY291bnQgPSAtMTsKICAgIGlmIChjb3VudCA8IDApCiAgICAgICAgcmV0dXJuIC0xOwog ICAgc3VtICs9IGNvdW50OwoKICAgIHJldHVybiBzdW07Cn0KCi8qKgogKiB4bWxPdXRwdXRCdWZm ZXJXcml0ZUJhc2U2NDoKICogQG91dDogdGhlIHhtbE91dHB1dEJ1ZmZlclB0cgogKiBAZGF0YTog ICBiaW5hcnkgZGF0YQogKiBAbGVuOiAgdGhlIG51bWJlciBvZiBieXRlcyB0byBlbmNvZGUKICoK ICogV3JpdGUgYmFzZTY0IGVuY29kZWQgZGF0YSB0byBhbiB4bWxPdXRwdXRCdWZmZXIuCiAqIEFk YXB0ZWQgZnJvbSBKb2huIFdhbGtlcidzIGJhc2U2NC5jIChodHRwOi8vd3d3LmZvdXJtaWxhYi5j aC8pLgogKgogKiBSZXR1cm5zIHRoZSBieXRlcyB3cml0dGVuIChtYXkgYmUgMCBiZWNhdXNlIG9m IGJ1ZmZlcmluZykgb3IgLTEgaW4gY2FzZSBvZiBlcnJvcgogKi8Kc3RhdGljIGludAp4bWxPdXRw dXRCdWZmZXJXcml0ZUJhc2U2NCh4bWxPdXRwdXRCdWZmZXJQdHIgb3V0LCBpbnQgbGVuLAogICAg ICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB1bnNpZ25lZCBjaGFyICpkYXRhKQp7CiAgICBz dGF0aWMgdW5zaWduZWQgY2hhciBkdGFibGVbNjRdID0KICAgICAgICAiQUJDREVGR0hJSktMTU5P UFFSU1RVVldYWVphYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5ejAxMjM0NTY3ODkrLyI7CiAgICBp bnQgaTsKICAgIGludCBsaW5lbGVuOwogICAgaW50IGNvdW50OwogICAgaW50IHN1bTsKCiAgICBs aW5lbGVuID0gMDsKICAgIHN1bSA9IDA7CgogICAgaSA9IDA7CiAgICB3aGlsZSAoVFJVRSkgewog ICAgICAgIHVuc2lnbmVkIGNoYXIgaWdyb3VwWzNdOwogICAgICAgIHVuc2lnbmVkIGNoYXIgb2dy b3VwWzRdOwogICAgICAgIGludCBjOwogICAgICAgIGludCBuOwoKICAgICAgICBpZ3JvdXBbMF0g PSBpZ3JvdXBbMV0gPSBpZ3JvdXBbMl0gPSAwOwogICAgICAgIGZvciAobiA9IDA7IG4gPCAzICYm IGkgPCBsZW47IG4rKywgaSsrKSB7CiAgICAgICAgICAgIGMgPSBkYXRhW2ldOwogICAgICAgICAg ICBpZ3JvdXBbbl0gPSAodW5zaWduZWQgY2hhcikgYzsKICAgICAgICB9CgogICAgICAgIGlmIChu ID4gMCkgewogICAgICAgICAgICBvZ3JvdXBbMF0gPSBkdGFibGVbaWdyb3VwWzBdID4+IDJdOwog ICAgICAgICAgICBvZ3JvdXBbMV0gPSBkdGFibGVbKChpZ3JvdXBbMF0gJiAzKSA8PCA0KSB8IChp Z3JvdXBbMV0gPj4gNCldOwogICAgICAgICAgICBvZ3JvdXBbMl0gPQogICAgICAgICAgICAgICAg ZHRhYmxlWygoaWdyb3VwWzFdICYgMHhGKSA8PCAyKSB8IChpZ3JvdXBbMl0gPj4gNildOwogICAg ICAgICAgICBvZ3JvdXBbM10gPSBkdGFibGVbaWdyb3VwWzJdICYgMHgzRl07CgogICAgICAgICAg ICBpZiAobiA8IDMpIHsKICAgICAgICAgICAgICAgIG9ncm91cFszXSA9ICc9JzsKICAgICAgICAg ICAgICAgIGlmIChuIDwgMikgewogICAgICAgICAgICAgICAgICAgIG9ncm91cFsyXSA9ICc9JzsK ICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgfQoKICAgICAgICAgICAgaWYgKGxpbmVsZW4g Pj0gQjY0TElORUxFTikgewogICAgICAgICAgICAgICAgY291bnQgPSB4bWxPdXRwdXRCdWZmZXJX cml0ZShvdXQsIDIsIEI2NENSTEYpOwogICAgICAgICAgICAgICAgaWYgKGNvdW50ID09IC0xKQog ICAgICAgICAgICAgICAgICAgIHJldHVybiAtMTsKICAgICAgICAgICAgICAgIHN1bSArPSBjb3Vu dDsKICAgICAgICAgICAgICAgIGxpbmVsZW4gPSAwOwogICAgICAgICAgICB9CiAgICAgICAgICAg IGNvdW50ID0geG1sT3V0cHV0QnVmZmVyV3JpdGUob3V0LCA0LCBvZ3JvdXApOwogICAgICAgICAg ICBpZiAoY291bnQgPT0gLTEpCiAgICAgICAgICAgICAgICByZXR1cm4gLTE7CiAgICAgICAgICAg IHN1bSArPSBjb3VudDsKCiAgICAgICAgICAgIGxpbmVsZW4gKz0gNDsKICAgICAgICB9CiAgICB9 CgogICAgY291bnQgPSB4bWxPdXRwdXRCdWZmZXJXcml0ZShvdXQsIDIsIEI2NENSTEYpOwogICAg aWYgKGNvdW50ID09IC0xKQogICAgICAgIHJldHVybiAtMTsKICAgIHN1bSArPSBjb3VudDsKCiAg ICByZXR1cm4gc3VtOwp9CgovKioKICogeG1sVGV4dFdyaXRlcldyaXRlQmFzZTY0OgogKiBAd3Jp dGVyOiB0aGUgeG1sVGV4dFdyaXRlclB0cgogKiBAZGF0YTogICBiaW5hcnkgZGF0YQogKiBAc3Rh cnQ6ICB0aGUgcG9zaXRpb24gd2l0aGluIHRoZSBkYXRhIG9mIHRoZSBmaXJzdCBieXRlIHRvIGVu Y29kZQogKiBAbGVuOiAgdGhlIG51bWJlciBvZiBieXRlcyB0byBlbmNvZGUKICoKICogV3JpdGUg YW4gYmFzZTY0IGVuY29kZWQgeG1sIHRleHQuCiAqCiAqIFJldHVybnMgdGhlIGJ5dGVzIHdyaXR0 ZW4gKG1heSBiZSAwIGJlY2F1c2Ugb2YgYnVmZmVyaW5nKSBvciAtMSBpbiBjYXNlIG9mIGVycm9y CiAqLwppbnQKeG1sVGV4dFdyaXRlcldyaXRlQmFzZTY0KHhtbFRleHRXcml0ZXJQdHIgd3JpdGVy LCBjb25zdCB4bWxDaGFyICogZGF0YSwKICAgICAgICAgICAgICAgICAgICAgICAgIGludCBzdGFy dCwgaW50IGxlbikKewogICAgaW50IGNvdW50OwogICAgaW50IHN1bTsKICAgIHhtbExpbmtQdHIg bGs7CiAgICB4bWxUZXh0V3JpdGVyU3RhY2tFbnRyeSAqcDsKCiAgICBpZiAod3JpdGVyID09IE5V TEwpCiAgICAgICAgcmV0dXJuIC0xOwoKICAgIGxrID0geG1sTGlzdEZyb250KHdyaXRlci0+bm9k ZXMpOwogICAgaWYgKGxrID09IDApCiAgICAgICAgcmV0dXJuIDA7CgogICAgcCA9ICh4bWxUZXh0 V3JpdGVyU3RhY2tFbnRyeSAqKSB4bWxMaW5rR2V0RGF0YShsayk7CiAgICBpZiAocCA9PSAwKQog ICAgICAgIHJldHVybiAwOwoKICAgIHN1bSA9IDA7CiAgICBzd2l0Y2ggKHAtPnN0YXRlKSB7CiAg ICAgICAgY2FzZSBYTUxfVEVYVFdSSVRFUl9OT05FOgogICAgICAgICAgICByZXR1cm4gLTE7CiAg ICAgICAgY2FzZSBYTUxfVEVYVFdSSVRFUl9OQU1FOgogICAgICAgICAgICBjb3VudCA9IHhtbE91 dHB1dEJ1ZmZlcldyaXRlU3RyaW5nKHdyaXRlci0+b3V0LCAiPiIpOwogICAgICAgICAgICBpZiAo Y291bnQgPCAwKQogICAgICAgICAgICAgICAgcmV0dXJuIC0xOwogICAgICAgICAgICBzdW0gKz0g Y291bnQ7CiAgICAgICAgICAgIHAtPnN0YXRlID0gWE1MX1RFWFRXUklURVJfVEVYVDsKICAgICAg ICAgICAgYnJlYWs7CiAgICAgICAgY2FzZSBYTUxfVEVYVFdSSVRFUl9QSToKICAgICAgICAgICAg Y291bnQgPSB4bWxPdXRwdXRCdWZmZXJXcml0ZVN0cmluZyh3cml0ZXItPm91dCwgIiAiKTsKICAg ICAgICAgICAgaWYgKGNvdW50IDwgMCkKICAgICAgICAgICAgICAgIHJldHVybiAtMTsKICAgICAg ICAgICAgc3VtICs9IGNvdW50OwogICAgICAgICAgICBwLT5zdGF0ZSA9IFhNTF9URVhUV1JJVEVS X1BJX1RFWFQ7CiAgICAgICAgICAgIGJyZWFrOwogICAgICAgIGNhc2UgWE1MX1RFWFRXUklURVJf RFREOgogICAgICAgICAgICBjb3VudCA9IHhtbE91dHB1dEJ1ZmZlcldyaXRlU3RyaW5nKHdyaXRl ci0+b3V0LCAiIFsiKTsKICAgICAgICAgICAgaWYgKGNvdW50IDwgMCkKICAgICAgICAgICAgICAg IHJldHVybiAtMTsKICAgICAgICAgICAgc3VtICs9IGNvdW50OwogICAgICAgICAgICBwLT5zdGF0 ZSA9IFhNTF9URVhUV1JJVEVSX0RURF9URVhUOwogICAgICAgICAgICBicmVhazsKICAgICAgICBk ZWZhdWx0OgogICAgICAgICAgICBicmVhazsKICAgIH0KCiAgICBjb3VudCA9CiAgICAgICAgeG1s T3V0cHV0QnVmZmVyV3JpdGVCYXNlNjQod3JpdGVyLT5vdXQsIGxlbiwKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAodW5zaWduZWQgY2hhciAqKSBkYXRhICsgc3RhcnQpOwogICAg aWYgKGNvdW50IDwgMCkKICAgICAgICByZXR1cm4gLTE7CiAgICBzdW0gKz0gY291bnQ7CgogICAg cmV0dXJuIHN1bTsKfQoKLyoqCiAqIHhtbE91dHB1dEJ1ZmZlcldyaXRlQmluSGV4OgogKiBAb3V0 OiB0aGUgeG1sT3V0cHV0QnVmZmVyUHRyCiAqIEBkYXRhOiAgIGJpbmFyeSBkYXRhCiAqIEBsZW46 ICB0aGUgbnVtYmVyIG9mIGJ5dGVzIHRvIGVuY29kZQogKgogKiBXcml0ZSBocXggZW5jb2RlZCBk YXRhIHRvIGFuIHhtbE91dHB1dEJ1ZmZlci4KICogOjp0b2RvCiAqCiAqIFJldHVybnMgdGhlIGJ5 dGVzIHdyaXR0ZW4gKG1heSBiZSAwIGJlY2F1c2Ugb2YgYnVmZmVyaW5nKSBvciAtMSBpbiBjYXNl IG9mIGVycm9yCiAqLwpzdGF0aWMgaW50CnhtbE91dHB1dEJ1ZmZlcldyaXRlQmluSGV4KHhtbE91 dHB1dEJ1ZmZlclB0ciBvdXQsIGludCBsZW4sCiAgICAgICAgICAgICAgICAgICAgICAgICAgIGNv bnN0IHVuc2lnbmVkIGNoYXIgKmRhdGEpCnsKICAgIHJldHVybiAtMTsKfQoKLyoqCiAqIHhtbFRl eHRXcml0ZXJXcml0ZUJpbkhleDoKICogQHdyaXRlcjogdGhlIHhtbFRleHRXcml0ZXJQdHIKICog QGRhdGE6ICAgYmluYXJ5IGRhdGEKICogQHN0YXJ0OiAgdGhlIHBvc2l0aW9uIHdpdGhpbiB0aGUg ZGF0YSBvZiB0aGUgZmlyc3QgYnl0ZSB0byBlbmNvZGUKICogQGxlbjogIHRoZSBudW1iZXIgb2Yg Ynl0ZXMgdG8gZW5jb2RlCiAqCiAqIFdyaXRlIGEgQmluSGV4IGVuY29kZWQgeG1sIHRleHQuCiAq CiAqIFJldHVybnMgdGhlIGJ5dGVzIHdyaXR0ZW4gKG1heSBiZSAwIGJlY2F1c2Ugb2YgYnVmZmVy aW5nKSBvciAtMSBpbiBjYXNlIG9mIGVycm9yCiAqLwppbnQKeG1sVGV4dFdyaXRlcldyaXRlQmlu SGV4KHhtbFRleHRXcml0ZXJQdHIgd3JpdGVyLCBjb25zdCB4bWxDaGFyICogZGF0YSwKICAgICAg ICAgICAgICAgICAgICAgICAgIGludCBzdGFydCwgaW50IGxlbikKewogICAgaW50IGNvdW50Owog ICAgaW50IHN1bTsKICAgIHhtbExpbmtQdHIgbGs7CiAgICB4bWxUZXh0V3JpdGVyU3RhY2tFbnRy eSAqcDsKCiAgICBpZiAod3JpdGVyID09IE5VTEwpCiAgICAgICAgcmV0dXJuIC0xOwoKICAgIGxr ID0geG1sTGlzdEZyb250KHdyaXRlci0+bm9kZXMpOwogICAgaWYgKGxrID09IDApCiAgICAgICAg cmV0dXJuIDA7CgogICAgcCA9ICh4bWxUZXh0V3JpdGVyU3RhY2tFbnRyeSAqKSB4bWxMaW5rR2V0 RGF0YShsayk7CiAgICBpZiAocCA9PSAwKQogICAgICAgIHJldHVybiAwOwoKICAgIHN1bSA9IDA7 CiAgICBzd2l0Y2ggKHAtPnN0YXRlKSB7CiAgICAgICAgY2FzZSBYTUxfVEVYVFdSSVRFUl9OT05F OgogICAgICAgICAgICByZXR1cm4gLTE7CiAgICAgICAgY2FzZSBYTUxfVEVYVFdSSVRFUl9OQU1F OgogICAgICAgICAgICBjb3VudCA9IHhtbE91dHB1dEJ1ZmZlcldyaXRlU3RyaW5nKHdyaXRlci0+ b3V0LCAiPiIpOwogICAgICAgICAgICBpZiAoY291bnQgPCAwKQogICAgICAgICAgICAgICAgcmV0 dXJuIC0xOwogICAgICAgICAgICBzdW0gKz0gY291bnQ7CiAgICAgICAgICAgIHAtPnN0YXRlID0g WE1MX1RFWFRXUklURVJfVEVYVDsKICAgICAgICAgICAgYnJlYWs7CiAgICAgICAgY2FzZSBYTUxf VEVYVFdSSVRFUl9QSToKICAgICAgICAgICAgY291bnQgPSB4bWxPdXRwdXRCdWZmZXJXcml0ZVN0 cmluZyh3cml0ZXItPm91dCwgIiAiKTsKICAgICAgICAgICAgaWYgKGNvdW50IDwgMCkKICAgICAg ICAgICAgICAgIHJldHVybiAtMTsKICAgICAgICAgICAgc3VtICs9IGNvdW50OwogICAgICAgICAg ICBwLT5zdGF0ZSA9IFhNTF9URVhUV1JJVEVSX1BJX1RFWFQ7CiAgICAgICAgICAgIGJyZWFrOwog ICAgICAgIGNhc2UgWE1MX1RFWFRXUklURVJfRFREOgogICAgICAgICAgICBjb3VudCA9IHhtbE91 dHB1dEJ1ZmZlcldyaXRlU3RyaW5nKHdyaXRlci0+b3V0LCAiIFsiKTsKICAgICAgICAgICAgaWYg KGNvdW50IDwgMCkKICAgICAgICAgICAgICAgIHJldHVybiAtMTsKICAgICAgICAgICAgc3VtICs9 IGNvdW50OwogICAgICAgICAgICBwLT5zdGF0ZSA9IFhNTF9URVhUV1JJVEVSX0RURF9URVhUOwog ICAgICAgICAgICBicmVhazsKICAgICAgICBkZWZhdWx0OgogICAgICAgICAgICBicmVhazsKICAg IH0KCiAgICBjb3VudCA9CiAgICAgICAgeG1sT3V0cHV0QnVmZmVyV3JpdGVCaW5IZXgod3JpdGVy LT5vdXQsIGxlbiwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAodW5zaWduZWQg Y2hhciAqKSBkYXRhICsgc3RhcnQpOwogICAgaWYgKGNvdW50IDwgMCkKICAgICAgICByZXR1cm4g LTE7CiAgICBzdW0gKz0gY291bnQ7CgogICAgcmV0dXJuIHN1bTsKfQoKLyoqCiAqIHhtbFRleHRX cml0ZXJTdGFydEF0dHJpYnV0ZToKICogQHdyaXRlcjogIHRoZSB4bWxUZXh0V3JpdGVyUHRyCiAq IEBuYW1lOiAgZWxlbWVudCBuYW1lCiAqCiAqIFN0YXJ0IGFuIHhtbCBhdHRyaWJ1dGUuCiAqCiAq IFJldHVybnMgdGhlIGJ5dGVzIHdyaXR0ZW4gKG1heSBiZSAwIGJlY2F1c2Ugb2YgYnVmZmVyaW5n KSBvciAtMSBpbiBjYXNlIG9mIGVycm9yCiAqLwppbnQKeG1sVGV4dFdyaXRlclN0YXJ0QXR0cmli dXRlKHhtbFRleHRXcml0ZXJQdHIgd3JpdGVyLCBjb25zdCB4bWxDaGFyICogbmFtZSkKewogICAg aW50IGNvdW50OwogICAgaW50IHN1bTsKICAgIHhtbExpbmtQdHIgbGs7CiAgICB4bWxUZXh0V3Jp dGVyU3RhY2tFbnRyeSAqcDsKCiAgICBpZiAoKHdyaXRlciA9PSBOVUxMKSB8fCAobmFtZSA9PSBO VUxMKSB8fCAoKm5hbWUgPT0gJ1wwJykpCiAgICAgICAgcmV0dXJuIC0xOwoKICAgIHN1bSA9IDA7 CiAgICBsayA9IHhtbExpc3RGcm9udCh3cml0ZXItPm5vZGVzKTsKICAgIGlmIChsayA9PSAwKQog ICAgICAgIHJldHVybiAtMTsKCiAgICBwID0gKHhtbFRleHRXcml0ZXJTdGFja0VudHJ5ICopIHht bExpbmtHZXREYXRhKGxrKTsKICAgIGlmIChwID09IDApCiAgICAgICAgcmV0dXJuIC0xOwoKICAg IHN3aXRjaCAocC0+c3RhdGUpIHsKICAgICAgICBjYXNlIFhNTF9URVhUV1JJVEVSX0FUVFJJQlVU RToKICAgICAgICAgICAgY291bnQgPSB4bWxUZXh0V3JpdGVyRW5kQXR0cmlidXRlKHdyaXRlcik7 CiAgICAgICAgICAgIGlmIChjb3VudCA8IDApCiAgICAgICAgICAgICAgICByZXR1cm4gLTE7CiAg ICAgICAgICAgIHN1bSArPSBjb3VudDsKICAgICAgICAgICAgLyogZmFsbHRocm91Z2ggKi8KICAg ICAgICBjYXNlIFhNTF9URVhUV1JJVEVSX05BTUU6CiAgICAgICAgICAgIGNvdW50ID0geG1sT3V0 cHV0QnVmZmVyV3JpdGVTdHJpbmcod3JpdGVyLT5vdXQsICIgIik7CiAgICAgICAgICAgIGlmIChj b3VudCA8IDApCiAgICAgICAgICAgICAgICByZXR1cm4gLTE7CiAgICAgICAgICAgIHN1bSArPSBj b3VudDsKICAgICAgICAgICAgY291bnQgPSB4bWxPdXRwdXRCdWZmZXJXcml0ZVN0cmluZyh3cml0 ZXItPm91dCwgbmFtZSk7CiAgICAgICAgICAgIGlmIChjb3VudCA8IDApCiAgICAgICAgICAgICAg ICByZXR1cm4gLTE7CiAgICAgICAgICAgIHN1bSArPSBjb3VudDsKICAgICAgICAgICAgY291bnQg PSB4bWxPdXRwdXRCdWZmZXJXcml0ZVN0cmluZyh3cml0ZXItPm91dCwgIj0iKTsKICAgICAgICAg ICAgaWYgKGNvdW50IDwgMCkKICAgICAgICAgICAgICAgIHJldHVybiAtMTsKICAgICAgICAgICAg c3VtICs9IGNvdW50OwogICAgICAgICAgICBjb3VudCA9IHhtbE91dHB1dEJ1ZmZlcldyaXRlKHdy aXRlci0+b3V0LCAxLCAmd3JpdGVyLT5xY2hhcik7CiAgICAgICAgICAgIGlmIChjb3VudCA8IDAp CiAgICAgICAgICAgICAgICByZXR1cm4gLTE7CiAgICAgICAgICAgIHN1bSArPSBjb3VudDsKICAg ICAgICAgICAgcC0+c3RhdGUgPSBYTUxfVEVYVFdSSVRFUl9BVFRSSUJVVEU7CiAgICAgICAgICAg IGJyZWFrOwogICAgICAgIGRlZmF1bHQ6CiAgICAgICAgICAgIHJldHVybiAtMTsKICAgIH0KCiAg ICByZXR1cm4gc3VtOwp9CgovKioKICogeG1sVGV4dFdyaXRlclN0YXJ0QXR0cmlidXRlTlM6CiAq IEB3cml0ZXI6ICB0aGUgeG1sVGV4dFdyaXRlclB0cgogKiBAcHJlZml4OiAgbmFtZXNwYWNlIHBy ZWZpeCBvciBOVUxMCiAqIEBuYW1lOiAgZWxlbWVudCBsb2NhbCBuYW1lCiAqIEBuYW1lc3BhY2VV Ukk6ICBuYW1lc3BhY2UgVVJJIG9yIE5VTEwKICoKICogU3RhcnQgYW4geG1sIGF0dHJpYnV0ZSB3 aXRoIG5hbWVzcGFjZSBzdXBwb3J0LgogKgogKiBSZXR1cm5zIHRoZSBieXRlcyB3cml0dGVuICht YXkgYmUgMCBiZWNhdXNlIG9mIGJ1ZmZlcmluZykgb3IgLTEgaW4gY2FzZSBvZiBlcnJvcgogKi8K aW50CnhtbFRleHRXcml0ZXJTdGFydEF0dHJpYnV0ZU5TKHhtbFRleHRXcml0ZXJQdHIgd3JpdGVy LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICogcHJlZml4LCBj b25zdCB4bWxDaGFyICogbmFtZSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3Qg eG1sQ2hhciAqIG5hbWVzcGFjZVVSSSkKewogICAgaW50IGNvdW50OwogICAgaW50IHN1bTsKICAg IHhtbENoYXIgKmJ1ZjsKICAgIHhtbFRleHRXcml0ZXJOc1N0YWNrRW50cnkgKnA7CgogICAgaWYg KCh3cml0ZXIgPT0gTlVMTCkgfHwgKG5hbWUgPT0gTlVMTCkgfHwgKCpuYW1lID09ICdcMCcpKQog ICAgICAgIHJldHVybiAtMTsKCiAgICBidWYgPSAwOwogICAgaWYgKHByZWZpeCAhPSAwKSB7CiAg ICAgICAgYnVmID0geG1sU3RyZHVwKHByZWZpeCk7CiAgICAgICAgYnVmID0geG1sU3RyY2F0KGJ1 ZiwgIjoiKTsKICAgIH0KICAgIGJ1ZiA9IHhtbFN0cmNhdChidWYsIG5hbWUpOwoKICAgIHN1bSA9 IDA7CiAgICBjb3VudCA9IHhtbFRleHRXcml0ZXJTdGFydEF0dHJpYnV0ZSh3cml0ZXIsIGJ1Zik7 CiAgICB4bWxGcmVlKGJ1Zik7CiAgICBpZiAoY291bnQgPCAwKQogICAgICAgIHJldHVybiAtMTsK ICAgIHN1bSArPSBjb3VudDsKCiAgICBpZiAobmFtZXNwYWNlVVJJICE9IDApIHsKICAgICAgICBi dWYgPSB4bWxTdHJkdXAoInhtbG5zIik7CiAgICAgICAgaWYgKHByZWZpeCAhPSAwKSB7CiAgICAg ICAgICAgIGJ1ZiA9IHhtbFN0cmNhdChidWYsICI6Iik7CiAgICAgICAgICAgIGJ1ZiA9IHhtbFN0 cmNhdChidWYsIHByZWZpeCk7CiAgICAgICAgfQoKICAgICAgICBwID0gKHhtbFRleHRXcml0ZXJO c1N0YWNrRW50cnkgKikKICAgICAgICAgICAgeG1sTWFsbG9jKHNpemVvZih4bWxUZXh0V3JpdGVy TnNTdGFja0VudHJ5KSk7CiAgICAgICAgaWYgKHAgPT0gMCkgewogICAgICAgICAgICB4bWxHZW5l cmljRXJyb3IoeG1sR2VuZXJpY0Vycm9yQ29udGV4dCwKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICJ4bWxUZXh0V3JpdGVyU3RhcnRBdHRyaWJ1dGVOUyA6IG91dCBvZiBtZW1vcnkhXG4iKTsK ICAgICAgICAgICAgcmV0dXJuIC0xOwogICAgICAgIH0KCiAgICAgICAgcC0+cHJlZml4ID0gYnVm OwogICAgICAgIHAtPnVyaSA9IHhtbFN0cmR1cChuYW1lc3BhY2VVUkkpOwogICAgICAgIGlmIChw LT51cmkgPT0gMCkgewogICAgICAgICAgICB4bWxHZW5lcmljRXJyb3IoeG1sR2VuZXJpY0Vycm9y Q29udGV4dCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICJ4bWxUZXh0V3JpdGVyU3RhcnRB dHRyaWJ1dGVOUyA6IG91dCBvZiBtZW1vcnkhXG4iKTsKICAgICAgICAgICAgeG1sRnJlZShwKTsK ICAgICAgICAgICAgcmV0dXJuIC0xOwogICAgICAgIH0KICAgICAgICBwLT5lbGVtID0geG1sTGlz dEZyb250KHdyaXRlci0+bm9kZXMpOwoKICAgICAgICB4bWxMaXN0UHVzaEZyb250KHdyaXRlci0+ bnNzdGFjaywgcCk7CiAgICB9CgogICAgcmV0dXJuIHN1bTsKfQoKLyoqCiAqIHhtbFRleHRXcml0 ZXJFbmRBdHRyaWJ1dGU6CiAqIEB3cml0ZXI6ICB0aGUgeG1sVGV4dFdyaXRlclB0cgogKgogKiBF bmQgdGhlIGN1cnJlbnQgeG1sIGVsZW1lbnQuCiAqCiAqIFJldHVybnMgdGhlIGJ5dGVzIHdyaXR0 ZW4gKG1heSBiZSAwIGJlY2F1c2Ugb2YgYnVmZmVyaW5nKSBvciAtMSBpbiBjYXNlIG9mIGVycm9y CiAqLwppbnQKeG1sVGV4dFdyaXRlckVuZEF0dHJpYnV0ZSh4bWxUZXh0V3JpdGVyUHRyIHdyaXRl cikKewogICAgaW50IGNvdW50OwogICAgaW50IHN1bTsKICAgIHhtbExpbmtQdHIgbGs7CiAgICB4 bWxUZXh0V3JpdGVyU3RhY2tFbnRyeSAqcDsKICAgIHhtbFRleHRXcml0ZXJOc1N0YWNrRW50cnkg Km5wOwoKICAgIGlmICh3cml0ZXIgPT0gTlVMTCkKICAgICAgICByZXR1cm4gLTE7CgogICAgbGsg PSB4bWxMaXN0RnJvbnQod3JpdGVyLT5ub2Rlcyk7CiAgICBpZiAobGsgPT0gMCkgewogICAgICAg IHhtbExpc3REZWxldGUod3JpdGVyLT5uc3N0YWNrKTsKICAgICAgICByZXR1cm4gLTE7CiAgICB9 CgogICAgcCA9ICh4bWxUZXh0V3JpdGVyU3RhY2tFbnRyeSAqKSB4bWxMaW5rR2V0RGF0YShsayk7 CiAgICBpZiAocCA9PSAwKSB7CiAgICAgICAgeG1sTGlzdERlbGV0ZSh3cml0ZXItPm5zc3RhY2sp OwogICAgICAgIHJldHVybiAtMTsKICAgIH0KCiAgICBzdW0gPSAwOwogICAgc3dpdGNoIChwLT5z dGF0ZSkgewogICAgICAgIGNhc2UgWE1MX1RFWFRXUklURVJfQVRUUklCVVRFOgogICAgICAgICAg ICBwLT5zdGF0ZSA9IFhNTF9URVhUV1JJVEVSX05BTUU7CgogICAgICAgICAgICBjb3VudCA9IHht bE91dHB1dEJ1ZmZlcldyaXRlKHdyaXRlci0+b3V0LCAxLCAmd3JpdGVyLT5xY2hhcik7CiAgICAg ICAgICAgIGlmIChjb3VudCA8IDApIHsKICAgICAgICAgICAgICAgIHhtbExpc3REZWxldGUod3Jp dGVyLT5uc3N0YWNrKTsKICAgICAgICAgICAgICAgIHJldHVybiAtMTsKICAgICAgICAgICAgfQog ICAgICAgICAgICBzdW0gKz0gY291bnQ7CgogICAgICAgICAgICB3aGlsZSAoIXhtbExpc3RFbXB0 eSh3cml0ZXItPm5zc3RhY2spKSB7CiAgICAgICAgICAgICAgICBsayA9IHhtbExpc3RGcm9udCh3 cml0ZXItPm5zc3RhY2spOwogICAgICAgICAgICAgICAgbnAgPSAoeG1sVGV4dFdyaXRlck5zU3Rh Y2tFbnRyeSAqKSB4bWxMaW5rR2V0RGF0YShsayk7CiAgICAgICAgICAgICAgICBpZiAobnAgIT0g MCkgewogICAgICAgICAgICAgICAgICAgIGNvdW50ID0KICAgICAgICAgICAgICAgICAgICAgICAg eG1sVGV4dFdyaXRlcldyaXRlQXR0cmlidXRlKHdyaXRlciwgbnAtPnByZWZpeCwKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5wLT51cmkpOwogICAg ICAgICAgICAgICAgICAgIGlmIChjb3VudCA8IDApIHsKICAgICAgICAgICAgICAgICAgICAgICAg eG1sTGlzdERlbGV0ZSh3cml0ZXItPm5zc3RhY2spOwogICAgICAgICAgICAgICAgICAgICAgICBy ZXR1cm4gLTE7CiAgICAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgICAgIHN1bSAr PSBjb3VudDsKICAgICAgICAgICAgICAgIH0KCiAgICAgICAgICAgICAgICB4bWxMaXN0UG9wRnJv bnQod3JpdGVyLT5uc3N0YWNrKTsKICAgICAgICAgICAgfQogICAgICAgICAgICBicmVhazsKCiAg ICAgICAgZGVmYXVsdDoKICAgICAgICAgICAgeG1sTGlzdENsZWFyKHdyaXRlci0+bnNzdGFjayk7 CiAgICAgICAgICAgIHJldHVybiAtMTsKICAgIH0KCiAgICByZXR1cm4gc3VtOwp9CgovKioKICog eG1sVGV4dFdyaXRlcldyaXRlRm9ybWF0QXR0cmlidXRlOgogKiBAd3JpdGVyOiAgdGhlIHhtbFRl eHRXcml0ZXJQdHIKICogQG5hbWU6ICBhdHRyaWJ1dGUgbmFtZQogKiBAZm9ybWF0OiAgZm9ybWF0 IHN0cmluZyAoc2VlIHByaW50ZikKICoKICogV3JpdGUgYSBmb3JtYXR0ZWQgeG1sIGF0dHJpYnV0 ZS4KICoKICogUmV0dXJucyB0aGUgYnl0ZXMgd3JpdHRlbiAobWF5IGJlIDAgYmVjYXVzZSBvZiBi dWZmZXJpbmcpIG9yIC0xIGluIGNhc2Ugb2YgZXJyb3IKICovCmludAp4bWxUZXh0V3JpdGVyV3Jp dGVGb3JtYXRBdHRyaWJ1dGUoeG1sVGV4dFdyaXRlclB0ciB3cml0ZXIsCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICogbmFtZSwgY29uc3QgY2hhciAqZm9y bWF0LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLi4uKQp7CiAgICBpbnQgcmM7 CiAgICB2YV9saXN0IGFwOwoKICAgIHZhX3N0YXJ0KGFwLCBmb3JtYXQpOwoKICAgIHJjID0geG1s VGV4dFdyaXRlcldyaXRlVkZvcm1hdEF0dHJpYnV0ZSh3cml0ZXIsIG5hbWUsIGZvcm1hdCwgYXAp OwoKICAgIHZhX2VuZChhcCk7CiAgICByZXR1cm4gcmM7Cn0KCi8qKgogKiB4bWxUZXh0V3JpdGVy V3JpdGVWRm9ybWF0QXR0cmlidXRlOgogKiBAd3JpdGVyOiAgdGhlIHhtbFRleHRXcml0ZXJQdHIK ICogQG5hbWU6ICBhdHRyaWJ1dGUgbmFtZQogKiBAZm9ybWF0OiAgZm9ybWF0IHN0cmluZyAoc2Vl IHByaW50ZikKICogQGFyZ3B0cjogIHBvaW50ZXIgdG8gdGhlIGZpcnN0IG1lbWJlciBvZiB0aGUg dmFyaWFibGUgYXJndW1lbnQgbGlzdC4KICoKICogV3JpdGUgYSBmb3JtYXR0ZWQgeG1sIGF0dHJp YnV0ZS4KICoKICogUmV0dXJucyB0aGUgYnl0ZXMgd3JpdHRlbiAobWF5IGJlIDAgYmVjYXVzZSBv ZiBidWZmZXJpbmcpIG9yIC0xIGluIGNhc2Ugb2YgZXJyb3IKICovCmludAp4bWxUZXh0V3JpdGVy V3JpdGVWRm9ybWF0QXR0cmlidXRlKHhtbFRleHRXcml0ZXJQdHIgd3JpdGVyLAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHhtbENoYXIgKiBuYW1lLAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IGNoYXIgKmZvcm1hdCwgdmFfbGlzdCBhcmdw dHIpCnsKICAgIGludCByYzsKICAgIHhtbENoYXIgKmJ1ZjsKCiAgICBpZiAod3JpdGVyID09IE5V TEwpCiAgICAgICAgcmV0dXJuIC0xOwoKICAgIGJ1ZiA9IHhtbFRleHRXcml0ZXJWU3ByaW50Zihm b3JtYXQsIGFyZ3B0cik7CiAgICBpZiAoYnVmID09IDApCiAgICAgICAgcmV0dXJuIDA7CgogICAg cmMgPSB4bWxUZXh0V3JpdGVyV3JpdGVBdHRyaWJ1dGUod3JpdGVyLCBuYW1lLCBidWYpOwoKICAg IHhtbEZyZWUoYnVmKTsKICAgIHJldHVybiByYzsKfQoKLyoqCiAqIHhtbFRleHRXcml0ZXJXcml0 ZUF0dHJpYnV0ZToKICogQHdyaXRlcjogIHRoZSB4bWxUZXh0V3JpdGVyUHRyCiAqIEBuYW1lOiAg YXR0cmlidXRlIG5hbWUKICogQGNvbnRlbnQ6ICBhdHRyaWJ1dGUgY29udGVudAogKgogKiBXcml0 ZSBhbiB4bWwgYXR0cmlidXRlLgogKgogKiBSZXR1cm5zIHRoZSBieXRlcyB3cml0dGVuIChtYXkg YmUgMCBiZWNhdXNlIG9mIGJ1ZmZlcmluZykgb3IgLTEgaW4gY2FzZSBvZiBlcnJvcgogKi8KaW50 CnhtbFRleHRXcml0ZXJXcml0ZUF0dHJpYnV0ZSh4bWxUZXh0V3JpdGVyUHRyIHdyaXRlciwgY29u c3QgeG1sQ2hhciAqIG5hbWUsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxD aGFyICogY29udGVudCkKewogICAgaW50IGNvdW50OwogICAgaW50IHN1bTsKCiAgICBzdW0gPSAw OwogICAgY291bnQgPSB4bWxUZXh0V3JpdGVyU3RhcnRBdHRyaWJ1dGUod3JpdGVyLCBuYW1lKTsK ICAgIGlmIChjb3VudCA8IDApCiAgICAgICAgcmV0dXJuIC0xOwogICAgc3VtICs9IGNvdW50Owog ICAgY291bnQgPSB4bWxUZXh0V3JpdGVyV3JpdGVTdHJpbmcod3JpdGVyLCBjb250ZW50KTsKICAg IGlmIChjb3VudCA8IDApCiAgICAgICAgcmV0dXJuIC0xOwogICAgc3VtICs9IGNvdW50OwogICAg Y291bnQgPSB4bWxUZXh0V3JpdGVyRW5kQXR0cmlidXRlKHdyaXRlcik7CiAgICBpZiAoY291bnQg PCAwKQogICAgICAgIHJldHVybiAtMTsKICAgIHN1bSArPSBjb3VudDsKCiAgICByZXR1cm4gc3Vt Owp9CgovKioKICogeG1sVGV4dFdyaXRlcldyaXRlRm9ybWF0QXR0cmlidXRlTlM6CiAqIEB3cml0 ZXI6ICB0aGUgeG1sVGV4dFdyaXRlclB0cgogKiBAcHJlZml4OiAgbmFtZXNwYWNlIHByZWZpeAog KiBAbmFtZTogIGF0dHJpYnV0ZSBsb2NhbCBuYW1lCiAqIEBuYW1lc3BhY2VVUkk6ICBuYW1lc3Bh Y2UgVVJJCiAqIEBmb3JtYXQ6ICBmb3JtYXQgc3RyaW5nIChzZWUgcHJpbnRmKQogKgogKiBXcml0 ZSBhIGZvcm1hdHRlZCB4bWwgYXR0cmlidXRlLndpdGggbmFtZXNwYWNlIHN1cHBvcnQKICoKICog UmV0dXJucyB0aGUgYnl0ZXMgd3JpdHRlbiAobWF5IGJlIDAgYmVjYXVzZSBvZiBidWZmZXJpbmcp IG9yIC0xIGluIGNhc2Ugb2YgZXJyb3IKICovCmludAp4bWxUZXh0V3JpdGVyV3JpdGVGb3JtYXRB dHRyaWJ1dGVOUyh4bWxUZXh0V3JpdGVyUHRyIHdyaXRlciwKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgY29uc3QgeG1sQ2hhciAqIHByZWZpeCwKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgY29uc3QgeG1sQ2hhciAqIG5hbWUsCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGNvbnN0IHhtbENoYXIgKiBuYW1lc3BhY2VVUkksCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IGNoYXIgKmZvcm1hdCwgLi4uKQp7CiAg ICBpbnQgcmM7CiAgICB2YV9saXN0IGFwOwoKICAgIHZhX3N0YXJ0KGFwLCBmb3JtYXQpOwoKICAg IHJjID0geG1sVGV4dFdyaXRlcldyaXRlVkZvcm1hdEF0dHJpYnV0ZU5TKHdyaXRlciwgcHJlZml4 LCBuYW1lLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbmFt ZXNwYWNlVVJJLCBmb3JtYXQsIGFwKTsKCiAgICB2YV9lbmQoYXApOwogICAgcmV0dXJuIHJjOwp9 CgovKioKICogeG1sVGV4dFdyaXRlcldyaXRlVkZvcm1hdEF0dHJpYnV0ZU5TOgogKiBAd3JpdGVy OiAgdGhlIHhtbFRleHRXcml0ZXJQdHIKICogQHByZWZpeDogIG5hbWVzcGFjZSBwcmVmaXgKICog QG5hbWU6ICBhdHRyaWJ1dGUgbG9jYWwgbmFtZQogKiBAbmFtZXNwYWNlVVJJOiAgbmFtZXNwYWNl IFVSSQogKiBAZm9ybWF0OiAgZm9ybWF0IHN0cmluZyAoc2VlIHByaW50ZikKICogQGFyZ3B0cjog IHBvaW50ZXIgdG8gdGhlIGZpcnN0IG1lbWJlciBvZiB0aGUgdmFyaWFibGUgYXJndW1lbnQgbGlz dC4KICoKICogV3JpdGUgYSBmb3JtYXR0ZWQgeG1sIGF0dHJpYnV0ZS53aXRoIG5hbWVzcGFjZSBz dXBwb3J0CiAqCiAqIFJldHVybnMgdGhlIGJ5dGVzIHdyaXR0ZW4gKG1heSBiZSAwIGJlY2F1c2Ug b2YgYnVmZmVyaW5nKSBvciAtMSBpbiBjYXNlIG9mIGVycm9yCiAqLwppbnQKeG1sVGV4dFdyaXRl cldyaXRlVkZvcm1hdEF0dHJpYnV0ZU5TKHhtbFRleHRXcml0ZXJQdHIgd3JpdGVyLAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgeG1sQ2hhciAqIHByZWZpeCwKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHhtbENoYXIgKiBuYW1lLAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgeG1sQ2hhciAqIG5hbWVz cGFjZVVSSSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IGNoYXIg KmZvcm1hdCwgdmFfbGlzdCBhcmdwdHIpCnsKICAgIGludCByYzsKICAgIHhtbENoYXIgKmJ1ZjsK CiAgICBpZiAod3JpdGVyID09IE5VTEwpCiAgICAgICAgcmV0dXJuIC0xOwoKICAgIGJ1ZiA9IHht bFRleHRXcml0ZXJWU3ByaW50Zihmb3JtYXQsIGFyZ3B0cik7CiAgICBpZiAoYnVmID09IDApCiAg ICAgICAgcmV0dXJuIDA7CgogICAgcmMgPSB4bWxUZXh0V3JpdGVyV3JpdGVBdHRyaWJ1dGVOUyh3 cml0ZXIsIHByZWZpeCwgbmFtZSwgbmFtZXNwYWNlVVJJLAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBidWYpOwoKICAgIHhtbEZyZWUoYnVmKTsKICAgIHJldHVybiByYzsK fQoKLyoqCiAqIHhtbFRleHRXcml0ZXJXcml0ZUF0dHJpYnV0ZU5TOgogKiBAd3JpdGVyOiAgdGhl IHhtbFRleHRXcml0ZXJQdHIKICogQHByZWZpeDogIG5hbWVzcGFjZSBwcmVmaXgKICogQG5hbWU6 ICBhdHRyaWJ1dGUgbG9jYWwgbmFtZQogKiBAbmFtZXNwYWNlVVJJOiAgbmFtZXNwYWNlIFVSSQog KiBAY29udGVudDogIGF0dHJpYnV0ZSBjb250ZW50CiAqCiAqIFdyaXRlIGFuIHhtbCBhdHRyaWJ1 dGUuCiAqCiAqIFJldHVybnMgdGhlIGJ5dGVzIHdyaXR0ZW4gKG1heSBiZSAwIGJlY2F1c2Ugb2Yg YnVmZmVyaW5nKSBvciAtMSBpbiBjYXNlIG9mIGVycm9yCiAqLwppbnQKeG1sVGV4dFdyaXRlcldy aXRlQXR0cmlidXRlTlMoeG1sVGV4dFdyaXRlclB0ciB3cml0ZXIsCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGNvbnN0IHhtbENoYXIgKiBwcmVmaXgsIGNvbnN0IHhtbENoYXIgKiBuYW1l LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICogbmFtZXNwYWNl VVJJLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICogY29udGVu dCkKewogICAgaW50IGNvdW50OwogICAgaW50IHN1bTsKICAgIHhtbENoYXIgKmJ1ZjsKCiAgICBp ZiAoKHdyaXRlciA9PSBOVUxMKSB8fCAobmFtZSA9PSBOVUxMKSB8fCAoKm5hbWUgPT0gJ1wwJykp CiAgICAgICAgcmV0dXJuIC0xOwoKICAgIGJ1ZiA9IDA7CiAgICBpZiAocHJlZml4ICE9IE5VTEwp IHsKICAgICAgICBidWYgPSB4bWxTdHJkdXAocHJlZml4KTsKICAgICAgICBidWYgPSB4bWxTdHJj YXQoYnVmLCAiOiIpOwogICAgfQogICAgYnVmID0geG1sU3RyY2F0KGJ1ZiwgbmFtZSk7CgogICAg c3VtID0gMDsKICAgIGNvdW50ID0geG1sVGV4dFdyaXRlcldyaXRlQXR0cmlidXRlKHdyaXRlciwg YnVmLCBjb250ZW50KTsKICAgIHhtbEZyZWUoYnVmKTsKICAgIGlmIChjb3VudCA8IDApCiAgICAg ICAgcmV0dXJuIC0xOwogICAgc3VtICs9IGNvdW50OwoKICAgIGlmIChuYW1lc3BhY2VVUkkgIT0g TlVMTCkgewogICAgICAgIGJ1ZiA9IDA7CiAgICAgICAgYnVmID0geG1sU3RyZHVwKCJ4bWxucyIp OwogICAgICAgIGlmIChwcmVmaXggIT0gTlVMTCkgewogICAgICAgICAgICBidWYgPSB4bWxTdHJj YXQoYnVmLCAiOiIpOwogICAgICAgICAgICBidWYgPSB4bWxTdHJjYXQoYnVmLCBwcmVmaXgpOwog ICAgICAgIH0KICAgICAgICBjb3VudCA9IHhtbFRleHRXcml0ZXJXcml0ZUF0dHJpYnV0ZSh3cml0 ZXIsIGJ1ZiwgbmFtZXNwYWNlVVJJKTsKICAgICAgICB4bWxGcmVlKGJ1Zik7CiAgICAgICAgaWYg KGNvdW50IDwgMCkKICAgICAgICAgICAgcmV0dXJuIC0xOwogICAgICAgIHN1bSArPSBjb3VudDsK ICAgIH0KICAgIHJldHVybiBzdW07Cn0KCi8qKgogKiB4bWxUZXh0V3JpdGVyV3JpdGVGb3JtYXRF bGVtZW50OgogKiBAd3JpdGVyOiAgdGhlIHhtbFRleHRXcml0ZXJQdHIKICogQG5hbWU6ICBlbGVt ZW50IG5hbWUKICogQGZvcm1hdDogIGZvcm1hdCBzdHJpbmcgKHNlZSBwcmludGYpCiAqCiAqIFdy aXRlIGEgZm9ybWF0dGVkIHhtbCBlbGVtZW50LgogKgogKiBSZXR1cm5zIHRoZSBieXRlcyB3cml0 dGVuIChtYXkgYmUgMCBiZWNhdXNlIG9mIGJ1ZmZlcmluZykgb3IgLTEgaW4gY2FzZSBvZiBlcnJv cgogKi8KaW50CnhtbFRleHRXcml0ZXJXcml0ZUZvcm1hdEVsZW1lbnQoeG1sVGV4dFdyaXRlclB0 ciB3cml0ZXIsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgeG1sQ2hhciAq IG5hbWUsIGNvbnN0IGNoYXIgKmZvcm1hdCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAuLi4pCnsKICAgIGludCByYzsKICAgIHZhX2xpc3QgYXA7CgogICAgdmFfc3RhcnQoYXAsIGZv cm1hdCk7CgogICAgcmMgPSB4bWxUZXh0V3JpdGVyV3JpdGVWRm9ybWF0RWxlbWVudCh3cml0ZXIs IG5hbWUsIGZvcm1hdCwgYXApOwoKICAgIHZhX2VuZChhcCk7CiAgICByZXR1cm4gcmM7Cn0KCi8q KgogKiB4bWxUZXh0V3JpdGVyV3JpdGVWRm9ybWF0RWxlbWVudDoKICogQHdyaXRlcjogIHRoZSB4 bWxUZXh0V3JpdGVyUHRyCiAqIEBuYW1lOiAgZWxlbWVudCBuYW1lCiAqIEBmb3JtYXQ6ICBmb3Jt YXQgc3RyaW5nIChzZWUgcHJpbnRmKQogKiBAYXJncHRyOiAgcG9pbnRlciB0byB0aGUgZmlyc3Qg bWVtYmVyIG9mIHRoZSB2YXJpYWJsZSBhcmd1bWVudCBsaXN0LgogKgogKiBXcml0ZSBhIGZvcm1h dHRlZCB4bWwgZWxlbWVudC4KICoKICogUmV0dXJucyB0aGUgYnl0ZXMgd3JpdHRlbiAobWF5IGJl IDAgYmVjYXVzZSBvZiBidWZmZXJpbmcpIG9yIC0xIGluIGNhc2Ugb2YgZXJyb3IKICovCmludAp4 bWxUZXh0V3JpdGVyV3JpdGVWRm9ybWF0RWxlbWVudCh4bWxUZXh0V3JpdGVyUHRyIHdyaXRlciwK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgeG1sQ2hhciAqIG5hbWUsIGNv bnN0IGNoYXIgKmZvcm1hdCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdmFfbGlz dCBhcmdwdHIpCnsKICAgIGludCByYzsKICAgIHhtbENoYXIgKmJ1ZjsKCiAgICBpZiAod3JpdGVy ID09IE5VTEwpCiAgICAgICAgcmV0dXJuIC0xOwoKICAgIGJ1ZiA9IHhtbFRleHRXcml0ZXJWU3By aW50Zihmb3JtYXQsIGFyZ3B0cik7CiAgICBpZiAoYnVmID09IDApCiAgICAgICAgcmV0dXJuIDA7 CgogICAgcmMgPSB4bWxUZXh0V3JpdGVyV3JpdGVFbGVtZW50KHdyaXRlciwgbmFtZSwgYnVmKTsK CiAgICB4bWxGcmVlKGJ1Zik7CiAgICByZXR1cm4gcmM7Cn0KCi8qKgogKiB4bWxUZXh0V3JpdGVy V3JpdGVFbGVtZW50OgogKiBAd3JpdGVyOiAgdGhlIHhtbFRleHRXcml0ZXJQdHIKICogQG5hbWU6 ICBlbGVtZW50IG5hbWUKICogQGNvbnRlbnQ6ICBlbGVtZW50IGNvbnRlbnQKICoKICogV3JpdGUg YW4geG1sIGVsZW1lbnQuCiAqCiAqIFJldHVybnMgdGhlIGJ5dGVzIHdyaXR0ZW4gKG1heSBiZSAw IGJlY2F1c2Ugb2YgYnVmZmVyaW5nKSBvciAtMSBpbiBjYXNlIG9mIGVycm9yCiAqLwppbnQKeG1s VGV4dFdyaXRlcldyaXRlRWxlbWVudCh4bWxUZXh0V3JpdGVyUHRyIHdyaXRlciwgY29uc3QgeG1s Q2hhciAqIG5hbWUsCiAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgeG1sQ2hhciAqIGNv bnRlbnQpCnsKICAgIGludCBjb3VudDsKICAgIGludCBzdW07CgogICAgc3VtID0gMDsKICAgIGNv dW50ID0geG1sVGV4dFdyaXRlclN0YXJ0RWxlbWVudCh3cml0ZXIsIG5hbWUpOwogICAgaWYgKGNv dW50ID09IC0xKQogICAgICAgIHJldHVybiAtMTsKICAgIHN1bSArPSBjb3VudDsKICAgIGNvdW50 ID0geG1sVGV4dFdyaXRlcldyaXRlU3RyaW5nKHdyaXRlciwgY29udGVudCk7CiAgICBpZiAoY291 bnQgPT0gLTEpCiAgICAgICAgcmV0dXJuIC0xOwogICAgc3VtICs9IGNvdW50OwogICAgY291bnQg PSB4bWxUZXh0V3JpdGVyRW5kRWxlbWVudCh3cml0ZXIpOwogICAgaWYgKGNvdW50ID09IC0xKQog ICAgICAgIHJldHVybiAtMTsKICAgIHN1bSArPSBjb3VudDsKCiAgICByZXR1cm4gc3VtOwp9Cgov KioKICogeG1sVGV4dFdyaXRlcldyaXRlRm9ybWF0RWxlbWVudE5TOgogKiBAd3JpdGVyOiAgdGhl IHhtbFRleHRXcml0ZXJQdHIKICogQHByZWZpeDogIG5hbWVzcGFjZSBwcmVmaXgKICogQG5hbWU6 ICBlbGVtZW50IGxvY2FsIG5hbWUKICogQG5hbWVzcGFjZVVSSTogIG5hbWVzcGFjZSBVUkkKICog QGZvcm1hdDogIGZvcm1hdCBzdHJpbmcgKHNlZSBwcmludGYpCiAqCiAqIFdyaXRlIGEgZm9ybWF0 dGVkIHhtbCBlbGVtZW50IHdpdGggbmFtZXNwYWNlIHN1cHBvcnQuCiAqCiAqIFJldHVybnMgdGhl IGJ5dGVzIHdyaXR0ZW4gKG1heSBiZSAwIGJlY2F1c2Ugb2YgYnVmZmVyaW5nKSBvciAtMSBpbiBj YXNlIG9mIGVycm9yCiAqLwppbnQKeG1sVGV4dFdyaXRlcldyaXRlRm9ybWF0RWxlbWVudE5TKHht bFRleHRXcml0ZXJQdHIgd3JpdGVyLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Y29uc3QgeG1sQ2hhciAqIHByZWZpeCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGNvbnN0IHhtbENoYXIgKiBuYW1lLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Y29uc3QgeG1sQ2hhciAqIG5hbWVzcGFjZVVSSSwKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGNvbnN0IGNoYXIgKmZvcm1hdCwgLi4uKQp7CiAgICBpbnQgcmM7CiAgICB2YV9saXN0 IGFwOwoKICAgIHZhX3N0YXJ0KGFwLCBmb3JtYXQpOwoKICAgIHJjID0geG1sVGV4dFdyaXRlcldy aXRlVkZvcm1hdEVsZW1lbnROUyh3cml0ZXIsIHByZWZpeCwgbmFtZSwKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBuYW1lc3BhY2VVUkksIGZvcm1hdCwgYXApOwoK ICAgIHZhX2VuZChhcCk7CiAgICByZXR1cm4gcmM7Cn0KCi8qKgogKiB4bWxUZXh0V3JpdGVyV3Jp dGVWRm9ybWF0RWxlbWVudE5TOgogKiBAd3JpdGVyOiAgdGhlIHhtbFRleHRXcml0ZXJQdHIKICog QHByZWZpeDogIG5hbWVzcGFjZSBwcmVmaXgKICogQG5hbWU6ICBlbGVtZW50IGxvY2FsIG5hbWUK ICogQG5hbWVzcGFjZVVSSTogIG5hbWVzcGFjZSBVUkkKICogQGZvcm1hdDogIGZvcm1hdCBzdHJp bmcgKHNlZSBwcmludGYpCiAqIEBhcmdwdHI6ICBwb2ludGVyIHRvIHRoZSBmaXJzdCBtZW1iZXIg b2YgdGhlIHZhcmlhYmxlIGFyZ3VtZW50IGxpc3QuCiAqCiAqIFdyaXRlIGEgZm9ybWF0dGVkIHht bCBlbGVtZW50IHdpdGggbmFtZXNwYWNlIHN1cHBvcnQuCiAqCiAqIFJldHVybnMgdGhlIGJ5dGVz IHdyaXR0ZW4gKG1heSBiZSAwIGJlY2F1c2Ugb2YgYnVmZmVyaW5nKSBvciAtMSBpbiBjYXNlIG9m IGVycm9yCiAqLwppbnQKeG1sVGV4dFdyaXRlcldyaXRlVkZvcm1hdEVsZW1lbnROUyh4bWxUZXh0 V3JpdGVyUHRyIHdyaXRlciwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25z dCB4bWxDaGFyICogcHJlZml4LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNv bnN0IHhtbENoYXIgKiBuYW1lLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNv bnN0IHhtbENoYXIgKiBuYW1lc3BhY2VVUkksCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgY29uc3QgY2hhciAqZm9ybWF0LCB2YV9saXN0IGFyZ3B0cikKewogICAgaW50IHJjOwog ICAgeG1sQ2hhciAqYnVmOwoKICAgIGlmICh3cml0ZXIgPT0gTlVMTCkKICAgICAgICByZXR1cm4g LTE7CgogICAgYnVmID0geG1sVGV4dFdyaXRlclZTcHJpbnRmKGZvcm1hdCwgYXJncHRyKTsKICAg IGlmIChidWYgPT0gMCkKICAgICAgICByZXR1cm4gMDsKCiAgICByYyA9IHhtbFRleHRXcml0ZXJX cml0ZUVsZW1lbnROUyh3cml0ZXIsIHByZWZpeCwgbmFtZSwgbmFtZXNwYWNlVVJJLAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYnVmKTsKCiAgICB4bWxGcmVlKGJ1Zik7CiAg ICByZXR1cm4gcmM7Cn0KCi8qKgogKiB4bWxUZXh0V3JpdGVyV3JpdGVFbGVtZW50TlM6CiAqIEB3 cml0ZXI6ICB0aGUgeG1sVGV4dFdyaXRlclB0cgogKiBAcHJlZml4OiAgbmFtZXNwYWNlIHByZWZp eAogKiBAbmFtZTogIGVsZW1lbnQgbG9jYWwgbmFtZQogKiBAbmFtZXNwYWNlVVJJOiAgbmFtZXNw YWNlIFVSSQogKiBAY29udGVudDogIGVsZW1lbnQgY29udGVudAogKgogKiBXcml0ZSBhbiB4bWwg ZWxlbWVudCB3aXRoIG5hbWVzcGFjZSBzdXBwb3J0LgogKgogKiBSZXR1cm5zIHRoZSBieXRlcyB3 cml0dGVuIChtYXkgYmUgMCBiZWNhdXNlIG9mIGJ1ZmZlcmluZykgb3IgLTEgaW4gY2FzZSBvZiBl cnJvcgogKi8KaW50CnhtbFRleHRXcml0ZXJXcml0ZUVsZW1lbnROUyh4bWxUZXh0V3JpdGVyUHRy IHdyaXRlciwKICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHhtbENoYXIgKiBwcmVm aXgsIGNvbnN0IHhtbENoYXIgKiBuYW1lLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgY29u c3QgeG1sQ2hhciAqIG5hbWVzcGFjZVVSSSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNv bnN0IHhtbENoYXIgKiBjb250ZW50KQp7CiAgICBpbnQgY291bnQ7CiAgICBpbnQgc3VtOwoKICAg IGlmICgod3JpdGVyID09IE5VTEwpIHx8IChuYW1lID09IE5VTEwpIHx8ICgqbmFtZSA9PSAnXDAn KSkKICAgICAgICByZXR1cm4gLTE7CgogICAgc3VtID0gMDsKICAgIGNvdW50ID0KICAgICAgICB4 bWxUZXh0V3JpdGVyU3RhcnRFbGVtZW50TlMod3JpdGVyLCBwcmVmaXgsIG5hbWUsIG5hbWVzcGFj ZVVSSSk7CiAgICBpZiAoY291bnQgPCAwKQogICAgICAgIHJldHVybiAtMTsKICAgIHN1bSArPSBj b3VudDsKICAgIGNvdW50ID0geG1sVGV4dFdyaXRlcldyaXRlU3RyaW5nKHdyaXRlciwgY29udGVu dCk7CiAgICBpZiAoY291bnQgPT0gLTEpCiAgICAgICAgcmV0dXJuIC0xOwogICAgc3VtICs9IGNv dW50OwogICAgY291bnQgPSB4bWxUZXh0V3JpdGVyRW5kRWxlbWVudCh3cml0ZXIpOwogICAgaWYg KGNvdW50ID09IC0xKQogICAgICAgIHJldHVybiAtMTsKICAgIHN1bSArPSBjb3VudDsKCiAgICBy ZXR1cm4gc3VtOwp9CgovKioKICogeG1sVGV4dFdyaXRlclN0YXJ0UEk6CiAqIEB3cml0ZXI6ICB0 aGUgeG1sVGV4dFdyaXRlclB0cgogKiBAdGFyZ2V0OiAgUEkgdGFyZ2V0CiAqCiAqIFN0YXJ0IGFu IHhtbCBQSS4KICoKICogUmV0dXJucyB0aGUgYnl0ZXMgd3JpdHRlbiAobWF5IGJlIDAgYmVjYXVz ZSBvZiBidWZmZXJpbmcpIG9yIC0xIGluIGNhc2Ugb2YgZXJyb3IKICovCmludAp4bWxUZXh0V3Jp dGVyU3RhcnRQSSh4bWxUZXh0V3JpdGVyUHRyIHdyaXRlciwgY29uc3QgeG1sQ2hhciAqIHRhcmdl dCkKewogICAgaW50IGNvdW50OwogICAgaW50IHN1bTsKICAgIHhtbExpbmtQdHIgbGs7CiAgICB4 bWxUZXh0V3JpdGVyU3RhY2tFbnRyeSAqcDsKCiAgICBpZiAoKHdyaXRlciA9PSBOVUxMKSB8fCAo dGFyZ2V0ID09IE5VTEwpIHx8ICgqdGFyZ2V0ID09ICdcMCcpKQogICAgICAgIHJldHVybiAtMTsK CiAgICBpZiAoeG1sU3RyY2FzZWNtcCh0YXJnZXQsIChjb25zdCB4bWxDaGFyICopICJ4bWwiKSA9 PSAwKSB7CiAgICAgICAgeG1sR2VuZXJpY0Vycm9yKHhtbEdlbmVyaWNFcnJvckNvbnRleHQsCiAg ICAgICAgICAgICAgICAgICAgICAgICJ4bWxUZXh0V3JpdGVyU3RhcnRQSSA6IHRhcmdldCBuYW1l IFtYeF1bTW1dW0xsXSBpcyByZXNlcnZlZCBmb3IgeG1sIHN0YW5kYXJkaXphdGlvbiFcbiIpOwog ICAgICAgIHJldHVybiAtMTsKICAgIH0KCiAgICBzdW0gPSAwOwogICAgbGsgPSB4bWxMaXN0RnJv bnQod3JpdGVyLT5ub2Rlcyk7CiAgICBpZiAobGsgIT0gMCkgewogICAgICAgIHAgPSAoeG1sVGV4 dFdyaXRlclN0YWNrRW50cnkgKikgeG1sTGlua0dldERhdGEobGspOwogICAgICAgIGlmIChwICE9 IDApIHsKICAgICAgICAgICAgc3dpdGNoIChwLT5zdGF0ZSkgewogICAgICAgICAgICAgICAgY2Fz ZSBYTUxfVEVYVFdSSVRFUl9BVFRSSUJVVEU6CiAgICAgICAgICAgICAgICAgICAgY291bnQgPSB4 bWxUZXh0V3JpdGVyRW5kQXR0cmlidXRlKHdyaXRlcik7CiAgICAgICAgICAgICAgICAgICAgaWYg KGNvdW50IDwgMCkKICAgICAgICAgICAgICAgICAgICAgICAgcmV0dXJuIC0xOwogICAgICAgICAg ICAgICAgICAgIHN1bSArPSBjb3VudDsKICAgICAgICAgICAgICAgICAgICAvKiBmYWxsdGhyb3Vn aCAqLwogICAgICAgICAgICAgICAgY2FzZSBYTUxfVEVYVFdSSVRFUl9OQU1FOgogICAgICAgICAg ICAgICAgICAgIGNvdW50ID0geG1sT3V0cHV0QnVmZmVyV3JpdGVTdHJpbmcod3JpdGVyLT5vdXQs ICI+Iik7CiAgICAgICAgICAgICAgICAgICAgaWYgKGNvdW50IDwgMCkKICAgICAgICAgICAgICAg ICAgICAgICAgcmV0dXJuIC0xOwogICAgICAgICAgICAgICAgICAgIHN1bSArPSBjb3VudDsKICAg ICAgICAgICAgICAgICAgICBwLT5zdGF0ZSA9IFhNTF9URVhUV1JJVEVSX1RFWFQ7CiAgICAgICAg ICAgICAgICAgICAgYnJlYWs7CiAgICAgICAgICAgICAgICBjYXNlIFhNTF9URVhUV1JJVEVSX1BJ OgogICAgICAgICAgICAgICAgY2FzZSBYTUxfVEVYVFdSSVRFUl9QSV9URVhUOgogICAgICAgICAg ICAgICAgICAgIHhtbEdlbmVyaWNFcnJvcih4bWxHZW5lcmljRXJyb3JDb250ZXh0LAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAieG1sVGV4dFdyaXRlclN0YXJ0UEkgOiBuZXN0 ZWQgUEkhXG4iKTsKICAgICAgICAgICAgICAgICAgICByZXR1cm4gLTE7CiAgICAgICAgICAgICAg ICBkZWZhdWx0OgogICAgICAgICAgICAgICAgICAgIHJldHVybiAtMTsKICAgICAgICAgICAgfQog ICAgICAgIH0KICAgIH0KCiAgICBwID0gKHhtbFRleHRXcml0ZXJTdGFja0VudHJ5ICopCiAgICAg ICAgeG1sTWFsbG9jKHNpemVvZih4bWxUZXh0V3JpdGVyU3RhY2tFbnRyeSkpOwogICAgaWYgKHAg PT0gMCkgewogICAgICAgIHhtbEdlbmVyaWNFcnJvcih4bWxHZW5lcmljRXJyb3JDb250ZXh0LAog ICAgICAgICAgICAgICAgICAgICAgICAieG1sVGV4dFdyaXRlclN0YXJ0UEkgOiBvdXQgb2YgbWVt b3J5IVxuIik7CiAgICAgICAgcmV0dXJuIC0xOwogICAgfQoKICAgIHAtPm5hbWUgPSB4bWxTdHJk dXAodGFyZ2V0KTsKICAgIGlmIChwLT5uYW1lID09IDApIHsKICAgICAgICB4bWxHZW5lcmljRXJy b3IoeG1sR2VuZXJpY0Vycm9yQ29udGV4dCwKICAgICAgICAgICAgICAgICAgICAgICAgInhtbFRl eHRXcml0ZXJTdGFydFBJIDogb3V0IG9mIG1lbW9yeSFcbiIpOwogICAgICAgIHhtbEZyZWUocCk7 CiAgICAgICAgcmV0dXJuIC0xOwogICAgfQogICAgcC0+c3RhdGUgPSBYTUxfVEVYVFdSSVRFUl9Q STsKCiAgICB4bWxMaXN0UHVzaEZyb250KHdyaXRlci0+bm9kZXMsIHApOwoKICAgIGNvdW50ID0g eG1sT3V0cHV0QnVmZmVyV3JpdGVTdHJpbmcod3JpdGVyLT5vdXQsICI8PyIpOwogICAgaWYgKGNv dW50IDwgMCkKICAgICAgICByZXR1cm4gLTE7CiAgICBzdW0gKz0gY291bnQ7CiAgICBjb3VudCA9 IHhtbE91dHB1dEJ1ZmZlcldyaXRlU3RyaW5nKHdyaXRlci0+b3V0LCBwLT5uYW1lKTsKICAgIGlm IChjb3VudCA8IDApCiAgICAgICAgcmV0dXJuIC0xOwogICAgc3VtICs9IGNvdW50OwoKICAgIHJl dHVybiBzdW07Cn0KCi8qKgogKiB4bWxUZXh0V3JpdGVyRW5kUEk6CiAqIEB3cml0ZXI6ICB0aGUg eG1sVGV4dFdyaXRlclB0cgogKgogKiBFbmQgdGhlIGN1cnJlbnQgeG1sIFBJLgogKgogKiBSZXR1 cm5zIHRoZSBieXRlcyB3cml0dGVuIChtYXkgYmUgMCBiZWNhdXNlIG9mIGJ1ZmZlcmluZykgb3Ig LTEgaW4gY2FzZSBvZiBlcnJvcgogKi8KaW50CnhtbFRleHRXcml0ZXJFbmRQSSh4bWxUZXh0V3Jp dGVyUHRyIHdyaXRlcikKewogICAgaW50IGNvdW50OwogICAgaW50IHN1bTsKICAgIHhtbExpbmtQ dHIgbGs7CiAgICB4bWxUZXh0V3JpdGVyU3RhY2tFbnRyeSAqcDsKCiAgICBpZiAod3JpdGVyID09 IE5VTEwpCiAgICAgICAgcmV0dXJuIC0xOwoKICAgIGxrID0geG1sTGlzdEZyb250KHdyaXRlci0+ bm9kZXMpOwogICAgaWYgKGxrID09IDApCiAgICAgICAgcmV0dXJuIDA7CgogICAgcCA9ICh4bWxU ZXh0V3JpdGVyU3RhY2tFbnRyeSAqKSB4bWxMaW5rR2V0RGF0YShsayk7CiAgICBpZiAocCA9PSAw KQogICAgICAgIHJldHVybiAwOwoKICAgIHN1bSA9IDA7CiAgICBzd2l0Y2ggKHAtPnN0YXRlKSB7 CiAgICAgICAgY2FzZSBYTUxfVEVYVFdSSVRFUl9QSToKICAgICAgICBjYXNlIFhNTF9URVhUV1JJ VEVSX1BJX1RFWFQ6CiAgICAgICAgICAgIGNvdW50ID0geG1sT3V0cHV0QnVmZmVyV3JpdGVTdHJp bmcod3JpdGVyLT5vdXQsICI/PiIpOwogICAgICAgICAgICBpZiAoY291bnQgPCAwKQogICAgICAg ICAgICAgICAgcmV0dXJuIC0xOwogICAgICAgICAgICBzdW0gKz0gY291bnQ7CiAgICAgICAgICAg IGJyZWFrOwogICAgICAgIGRlZmF1bHQ6CiAgICAgICAgICAgIHJldHVybiAtMTsKICAgIH0KCiAg ICB4bWxMaXN0UG9wRnJvbnQod3JpdGVyLT5ub2Rlcyk7CiAgICByZXR1cm4gc3VtOwp9CgovKioK ICogeG1sVGV4dFdyaXRlcldyaXRlRm9ybWF0UEk6CiAqIEB3cml0ZXI6ICB0aGUgeG1sVGV4dFdy aXRlclB0cgogKiBAdGFyZ2V0OiAgUEkgdGFyZ2V0CiAqIEBmb3JtYXQ6ICBmb3JtYXQgc3RyaW5n IChzZWUgcHJpbnRmKQogKgogKiBXcml0ZSBhIGZvcm1hdHRlZCBQSS4KICoKICogUmV0dXJucyB0 aGUgYnl0ZXMgd3JpdHRlbiAobWF5IGJlIDAgYmVjYXVzZSBvZiBidWZmZXJpbmcpIG9yIC0xIGlu IGNhc2Ugb2YgZXJyb3IKICovCmludAp4bWxUZXh0V3JpdGVyV3JpdGVGb3JtYXRQSSh4bWxUZXh0 V3JpdGVyUHRyIHdyaXRlciwgY29uc3QgeG1sQ2hhciAqIHRhcmdldCwKICAgICAgICAgICAgICAg ICAgICAgICAgICAgY29uc3QgY2hhciAqZm9ybWF0LCAuLi4pCnsKICAgIGludCByYzsKICAgIHZh X2xpc3QgYXA7CgogICAgdmFfc3RhcnQoYXAsIGZvcm1hdCk7CgogICAgcmMgPSB4bWxUZXh0V3Jp dGVyV3JpdGVWRm9ybWF0UEkod3JpdGVyLCB0YXJnZXQsIGZvcm1hdCwgYXApOwoKICAgIHZhX2Vu ZChhcCk7CiAgICByZXR1cm4gcmM7Cn0KCi8qKgogKiB4bWxUZXh0V3JpdGVyV3JpdGVWRm9ybWF0 UEk6CiAqIEB3cml0ZXI6ICB0aGUgeG1sVGV4dFdyaXRlclB0cgogKiBAdGFyZ2V0OiAgUEkgdGFy Z2V0CiAqIEBmb3JtYXQ6ICBmb3JtYXQgc3RyaW5nIChzZWUgcHJpbnRmKQogKgogKiBXcml0ZSBh IGZvcm1hdHRlZCB4bWwgUEkuCiAqCiAqIFJldHVybnMgdGhlIGJ5dGVzIHdyaXR0ZW4gKG1heSBi ZSAwIGJlY2F1c2Ugb2YgYnVmZmVyaW5nKSBvciAtMSBpbiBjYXNlIG9mIGVycm9yCiAqLwppbnQK eG1sVGV4dFdyaXRlcldyaXRlVkZvcm1hdFBJKHhtbFRleHRXcml0ZXJQdHIgd3JpdGVyLAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgeG1sQ2hhciAqIHRhcmdldCwgY29uc3QgY2hh ciAqZm9ybWF0LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgdmFfbGlzdCBhcmdwdHIpCnsK ICAgIGludCByYzsKICAgIHhtbENoYXIgKmJ1ZjsKCiAgICBpZiAod3JpdGVyID09IE5VTEwpCiAg ICAgICAgcmV0dXJuIC0xOwoKICAgIGJ1ZiA9IHhtbFRleHRXcml0ZXJWU3ByaW50Zihmb3JtYXQs IGFyZ3B0cik7CiAgICBpZiAoYnVmID09IDApCiAgICAgICAgcmV0dXJuIDA7CgogICAgcmMgPSB4 bWxUZXh0V3JpdGVyV3JpdGVQSSh3cml0ZXIsIHRhcmdldCwgYnVmKTsKCiAgICB4bWxGcmVlKGJ1 Zik7CiAgICByZXR1cm4gcmM7Cn0KCi8qKgogKiB4bWxUZXh0V3JpdGVyV3JpdGVQSToKICogQHdy aXRlcjogIHRoZSB4bWxUZXh0V3JpdGVyUHRyCiAqIEB0YXJnZXQ6ICBQSSB0YXJnZXQKICogQGNv bnRlbnQ6ICBQSSBjb250ZW50CiAqCiAqIFdyaXRlIGFuIHhtbCBQSS4KICoKICogUmV0dXJucyB0 aGUgYnl0ZXMgd3JpdHRlbiAobWF5IGJlIDAgYmVjYXVzZSBvZiBidWZmZXJpbmcpIG9yIC0xIGlu IGNhc2Ugb2YgZXJyb3IKICovCmludAp4bWxUZXh0V3JpdGVyV3JpdGVQSSh4bWxUZXh0V3JpdGVy UHRyIHdyaXRlciwgY29uc3QgeG1sQ2hhciAqIHRhcmdldCwKICAgICAgICAgICAgICAgICAgICAg Y29uc3QgeG1sQ2hhciAqIGNvbnRlbnQpCnsKICAgIGludCBjb3VudDsKICAgIGludCBzdW07Cgog ICAgc3VtID0gMDsKICAgIGNvdW50ID0geG1sVGV4dFdyaXRlclN0YXJ0UEkod3JpdGVyLCB0YXJn ZXQpOwogICAgaWYgKGNvdW50ID09IC0xKQogICAgICAgIHJldHVybiAtMTsKICAgIHN1bSArPSBj b3VudDsKICAgIGlmIChjb250ZW50ICE9IDApIHsKICAgICAgICBjb3VudCA9IHhtbFRleHRXcml0 ZXJXcml0ZVN0cmluZyh3cml0ZXIsIGNvbnRlbnQpOwogICAgICAgIGlmIChjb3VudCA9PSAtMSkK ICAgICAgICAgICAgcmV0dXJuIC0xOwogICAgICAgIHN1bSArPSBjb3VudDsKICAgIH0KICAgIGNv dW50ID0geG1sVGV4dFdyaXRlckVuZFBJKHdyaXRlcik7CiAgICBpZiAoY291bnQgPT0gLTEpCiAg ICAgICAgcmV0dXJuIC0xOwogICAgc3VtICs9IGNvdW50OwoKICAgIHJldHVybiBzdW07Cn0KCi8q KgogKiB4bWxUZXh0V3JpdGVyU3RhcnRDREFUQToKICogQHdyaXRlcjogIHRoZSB4bWxUZXh0V3Jp dGVyUHRyCiAqCiAqIFN0YXJ0IGFuIHhtbCBDREFUQSBzZWN0aW9uLgogKgogKiBSZXR1cm5zIHRo ZSBieXRlcyB3cml0dGVuIChtYXkgYmUgMCBiZWNhdXNlIG9mIGJ1ZmZlcmluZykgb3IgLTEgaW4g Y2FzZSBvZiBlcnJvcgogKi8KaW50CnhtbFRleHRXcml0ZXJTdGFydENEQVRBKHhtbFRleHRXcml0 ZXJQdHIgd3JpdGVyKQp7CiAgICBpbnQgY291bnQ7CiAgICBpbnQgc3VtOwogICAgeG1sTGlua1B0 ciBsazsKICAgIHhtbFRleHRXcml0ZXJTdGFja0VudHJ5ICpwOwoKICAgIGlmICh3cml0ZXIgPT0g TlVMTCkKICAgICAgICByZXR1cm4gLTE7CgogICAgc3VtID0gMDsKICAgIGxrID0geG1sTGlzdEZy b250KHdyaXRlci0+bm9kZXMpOwogICAgaWYgKGxrICE9IDApIHsKICAgICAgICBwID0gKHhtbFRl eHRXcml0ZXJTdGFja0VudHJ5ICopIHhtbExpbmtHZXREYXRhKGxrKTsKICAgICAgICBpZiAocCAh PSAwKSB7CiAgICAgICAgICAgIHN3aXRjaCAocC0+c3RhdGUpIHsKICAgICAgICAgICAgICAgIGNh c2UgWE1MX1RFWFRXUklURVJfTk9ORToKICAgICAgICAgICAgICAgIGNhc2UgWE1MX1RFWFRXUklU RVJfUEk6CiAgICAgICAgICAgICAgICBjYXNlIFhNTF9URVhUV1JJVEVSX1BJX1RFWFQ6CiAgICAg ICAgICAgICAgICAgICAgYnJlYWs7CiAgICAgICAgICAgICAgICBjYXNlIFhNTF9URVhUV1JJVEVS X0FUVFJJQlVURToKICAgICAgICAgICAgICAgICAgICBjb3VudCA9IHhtbFRleHRXcml0ZXJFbmRB dHRyaWJ1dGUod3JpdGVyKTsKICAgICAgICAgICAgICAgICAgICBpZiAoY291bnQgPCAwKQogICAg ICAgICAgICAgICAgICAgICAgICByZXR1cm4gLTE7CiAgICAgICAgICAgICAgICAgICAgc3VtICs9 IGNvdW50OwogICAgICAgICAgICAgICAgICAgIC8qIGZhbGx0aHJvdWdoICovCiAgICAgICAgICAg ICAgICBjYXNlIFhNTF9URVhUV1JJVEVSX05BTUU6CiAgICAgICAgICAgICAgICAgICAgY291bnQg PSB4bWxPdXRwdXRCdWZmZXJXcml0ZVN0cmluZyh3cml0ZXItPm91dCwgIj4iKTsKICAgICAgICAg ICAgICAgICAgICBpZiAoY291bnQgPCAwKQogICAgICAgICAgICAgICAgICAgICAgICByZXR1cm4g LTE7CiAgICAgICAgICAgICAgICAgICAgc3VtICs9IGNvdW50OwogICAgICAgICAgICAgICAgICAg IHAtPnN0YXRlID0gWE1MX1RFWFRXUklURVJfVEVYVDsKICAgICAgICAgICAgICAgICAgICBicmVh azsKICAgICAgICAgICAgICAgIGNhc2UgWE1MX1RFWFRXUklURVJfQ0RBVEE6CiAgICAgICAgICAg ICAgICAgICAgeG1sR2VuZXJpY0Vycm9yKHhtbEdlbmVyaWNFcnJvckNvbnRleHQsCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICJ4bWxUZXh0V3JpdGVyU3RhcnRDREFUQSA6IENE QVRBIG5vdCBhbGxvd2VkIGluIHRoaXMgY29udGV4dCFcbiIpOwogICAgICAgICAgICAgICAgICAg IHJldHVybiAtMTsKICAgICAgICAgICAgICAgIGRlZmF1bHQ6CiAgICAgICAgICAgICAgICAgICAg cmV0dXJuIC0xOwogICAgICAgICAgICB9CiAgICAgICAgfQogICAgfQoKICAgIHAgPSAoeG1sVGV4 dFdyaXRlclN0YWNrRW50cnkgKikKICAgICAgICB4bWxNYWxsb2Moc2l6ZW9mKHhtbFRleHRXcml0 ZXJTdGFja0VudHJ5KSk7CiAgICBpZiAocCA9PSAwKSB7CiAgICAgICAgeG1sR2VuZXJpY0Vycm9y KHhtbEdlbmVyaWNFcnJvckNvbnRleHQsCiAgICAgICAgICAgICAgICAgICAgICAgICJ4bWxUZXh0 V3JpdGVyU3RhcnRDREFUQSA6IG91dCBvZiBtZW1vcnkhXG4iKTsKICAgICAgICByZXR1cm4gLTE7 CiAgICB9CgogICAgcC0+bmFtZSA9IDA7CiAgICBwLT5zdGF0ZSA9IFhNTF9URVhUV1JJVEVSX0NE QVRBOwoKICAgIHhtbExpc3RQdXNoRnJvbnQod3JpdGVyLT5ub2RlcywgcCk7CgogICAgY291bnQg PSB4bWxPdXRwdXRCdWZmZXJXcml0ZVN0cmluZyh3cml0ZXItPm91dCwgIjwhW0NEQVRBWyIpOwog ICAgaWYgKGNvdW50IDwgMCkKICAgICAgICByZXR1cm4gLTE7CiAgICBzdW0gKz0gY291bnQ7Cgog ICAgcmV0dXJuIHN1bTsKfQoKLyoqCiAqIHhtbFRleHRXcml0ZXJFbmRDREFUQToKICogQHdyaXRl cjogIHRoZSB4bWxUZXh0V3JpdGVyUHRyCiAqCiAqIEVuZCBhbiB4bWwgQ0RBVEEgc2VjdGlvbi4K ICoKICogUmV0dXJucyB0aGUgYnl0ZXMgd3JpdHRlbiAobWF5IGJlIDAgYmVjYXVzZSBvZiBidWZm ZXJpbmcpIG9yIC0xIGluIGNhc2Ugb2YgZXJyb3IKICovCmludAp4bWxUZXh0V3JpdGVyRW5kQ0RB VEEoeG1sVGV4dFdyaXRlclB0ciB3cml0ZXIpCnsKICAgIGludCBjb3VudDsKICAgIGludCBzdW07 CiAgICB4bWxMaW5rUHRyIGxrOwogICAgeG1sVGV4dFdyaXRlclN0YWNrRW50cnkgKnA7CgogICAg aWYgKHdyaXRlciA9PSBOVUxMKQogICAgICAgIHJldHVybiAtMTsKCiAgICBsayA9IHhtbExpc3RG cm9udCh3cml0ZXItPm5vZGVzKTsKICAgIGlmIChsayA9PSAwKQogICAgICAgIHJldHVybiAtMTsK CiAgICBwID0gKHhtbFRleHRXcml0ZXJTdGFja0VudHJ5ICopIHhtbExpbmtHZXREYXRhKGxrKTsK ICAgIGlmIChwID09IDApCiAgICAgICAgcmV0dXJuIC0xOwoKICAgIHN1bSA9IDA7CiAgICBzd2l0 Y2ggKHAtPnN0YXRlKSB7CiAgICAgICAgY2FzZSBYTUxfVEVYVFdSSVRFUl9DREFUQToKICAgICAg ICAgICAgY291bnQgPSB4bWxPdXRwdXRCdWZmZXJXcml0ZVN0cmluZyh3cml0ZXItPm91dCwgIl1d PiIpOwogICAgICAgICAgICBpZiAoY291bnQgPCAwKQogICAgICAgICAgICAgICAgcmV0dXJuIC0x OwogICAgICAgICAgICBzdW0gKz0gY291bnQ7CiAgICAgICAgICAgIGJyZWFrOwogICAgICAgIGRl ZmF1bHQ6CiAgICAgICAgICAgIHJldHVybiAtMTsKICAgIH0KCiAgICB4bWxMaXN0UG9wRnJvbnQo d3JpdGVyLT5ub2Rlcyk7CiAgICByZXR1cm4gc3VtOwp9CgovKioKICogeG1sVGV4dFdyaXRlcldy aXRlRm9ybWF0Q0RBVEE6CiAqIEB3cml0ZXI6ICB0aGUgeG1sVGV4dFdyaXRlclB0cgogKiBAZm9y bWF0OiAgZm9ybWF0IHN0cmluZyAoc2VlIHByaW50ZikKICoKICogV3JpdGUgYSBmb3JtYXR0ZWQg eG1sIENEQVRBLgogKgogKiBSZXR1cm5zIHRoZSBieXRlcyB3cml0dGVuIChtYXkgYmUgMCBiZWNh dXNlIG9mIGJ1ZmZlcmluZykgb3IgLTEgaW4gY2FzZSBvZiBlcnJvcgogKi8KaW50CnhtbFRleHRX cml0ZXJXcml0ZUZvcm1hdENEQVRBKHhtbFRleHRXcml0ZXJQdHIgd3JpdGVyLCBjb25zdCBjaGFy ICpmb3JtYXQsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4uLikKewogICAgaW50IHJj OwogICAgdmFfbGlzdCBhcDsKCiAgICB2YV9zdGFydChhcCwgZm9ybWF0KTsKCiAgICByYyA9IHht bFRleHRXcml0ZXJXcml0ZVZGb3JtYXRDREFUQSh3cml0ZXIsIGZvcm1hdCwgYXApOwoKICAgIHZh X2VuZChhcCk7CiAgICByZXR1cm4gcmM7Cn0KCi8qKgogKiB4bWxUZXh0V3JpdGVyV3JpdGVWRm9y bWF0Q0RBVEE6CiAqIEB3cml0ZXI6ICB0aGUgeG1sVGV4dFdyaXRlclB0cgogKiBAZm9ybWF0OiAg Zm9ybWF0IHN0cmluZyAoc2VlIHByaW50ZikKICoKICogV3JpdGUgYSBmb3JtYXR0ZWQgeG1sIENE QVRBLgogKgogKiBSZXR1cm5zIHRoZSBieXRlcyB3cml0dGVuIChtYXkgYmUgMCBiZWNhdXNlIG9m IGJ1ZmZlcmluZykgb3IgLTEgaW4gY2FzZSBvZiBlcnJvcgogKi8KaW50CnhtbFRleHRXcml0ZXJX cml0ZVZGb3JtYXRDREFUQSh4bWxUZXh0V3JpdGVyUHRyIHdyaXRlciwgY29uc3QgY2hhciAqZm9y bWF0LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdmFfbGlzdCBhcmdwdHIpCnsKICAg IGludCByYzsKICAgIHhtbENoYXIgKmJ1ZjsKCiAgICBpZiAod3JpdGVyID09IE5VTEwpCiAgICAg ICAgcmV0dXJuIC0xOwoKICAgIGJ1ZiA9IHhtbFRleHRXcml0ZXJWU3ByaW50Zihmb3JtYXQsIGFy Z3B0cik7CiAgICBpZiAoYnVmID09IDApCiAgICAgICAgcmV0dXJuIDA7CgogICAgcmMgPSB4bWxU ZXh0V3JpdGVyV3JpdGVDREFUQSh3cml0ZXIsIGJ1Zik7CgogICAgeG1sRnJlZShidWYpOwogICAg cmV0dXJuIHJjOwp9CgovKioKICogeG1sVGV4dFdyaXRlcldyaXRlQ0RBVEE6CiAqIEB3cml0ZXI6 ICB0aGUgeG1sVGV4dFdyaXRlclB0cgogKiBAY29udGVudDogIENEQVRBIGNvbnRlbnQKICoKICog V3JpdGUgYW4geG1sIENEQVRBLgogKgogKiBSZXR1cm5zIHRoZSBieXRlcyB3cml0dGVuIChtYXkg YmUgMCBiZWNhdXNlIG9mIGJ1ZmZlcmluZykgb3IgLTEgaW4gY2FzZSBvZiBlcnJvcgogKi8KaW50 CnhtbFRleHRXcml0ZXJXcml0ZUNEQVRBKHhtbFRleHRXcml0ZXJQdHIgd3JpdGVyLCBjb25zdCB4 bWxDaGFyICogY29udGVudCkKewogICAgaW50IGNvdW50OwogICAgaW50IHN1bTsKCiAgICBzdW0g PSAwOwogICAgY291bnQgPSB4bWxUZXh0V3JpdGVyU3RhcnRDREFUQSh3cml0ZXIpOwogICAgaWYg KGNvdW50ID09IC0xKQogICAgICAgIHJldHVybiAtMTsKICAgIHN1bSArPSBjb3VudDsKICAgIGlm IChjb250ZW50ICE9IDApIHsKICAgICAgICBjb3VudCA9IHhtbFRleHRXcml0ZXJXcml0ZVN0cmlu Zyh3cml0ZXIsIGNvbnRlbnQpOwogICAgICAgIGlmIChjb3VudCA9PSAtMSkKICAgICAgICAgICAg cmV0dXJuIC0xOwogICAgICAgIHN1bSArPSBjb3VudDsKICAgIH0KICAgIGNvdW50ID0geG1sVGV4 dFdyaXRlckVuZENEQVRBKHdyaXRlcik7CiAgICBpZiAoY291bnQgPT0gLTEpCiAgICAgICAgcmV0 dXJuIC0xOwogICAgc3VtICs9IGNvdW50OwoKICAgIHJldHVybiBzdW07Cn0KCi8qKgogKiB4bWxU ZXh0V3JpdGVyU3RhcnREVEQ6CiAqIEB3cml0ZXI6ICB0aGUgeG1sVGV4dFdyaXRlclB0cgogKiBA bmFtZTogIHRoZSBuYW1lIG9mIHRoZSBEVEQKICogQHB1YmlkOiAgdGhlIHB1YmxpYyBpZGVudGlm aWVyLCB3aGljaCBpcyBhbiBhbHRlcm5hdGl2ZSB0byB0aGUgc3lzdGVtIGlkZW50aWZpZXIKICog QHN5c2lkOiAgdGhlIHN5c3RlbSBpZGVudGlmaWVyLCB3aGljaCBpcyB0aGUgVVJJIG9mIHRoZSBE VEQKICoKICogU3RhcnQgYW4geG1sIERURC4KICoKICogUmV0dXJucyB0aGUgYnl0ZXMgd3JpdHRl biAobWF5IGJlIDAgYmVjYXVzZSBvZiBidWZmZXJpbmcpIG9yIC0xIGluIGNhc2Ugb2YgZXJyb3IK ICovCmludAp4bWxUZXh0V3JpdGVyU3RhcnREVEQoeG1sVGV4dFdyaXRlclB0ciB3cml0ZXIsCiAg ICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICogbmFtZSwKICAgICAgICAgICAgICAg ICAgICAgIGNvbnN0IHhtbENoYXIgKiBwdWJpZCwgY29uc3QgeG1sQ2hhciAqIHN5c2lkKQp7CiAg ICBpbnQgY291bnQ7CiAgICBpbnQgc3VtOwogICAgeG1sTGlua1B0ciBsazsKICAgIHhtbFRleHRX cml0ZXJTdGFja0VudHJ5ICpwOwoKICAgIGlmICh3cml0ZXIgPT0gTlVMTCB8fCBuYW1lID09IE5V TEwgfHwgKm5hbWUgPT0gJ1wwJykKICAgICAgICByZXR1cm4gLTE7CgogICAgc3VtID0gMDsKICAg IGxrID0geG1sTGlzdEZyb250KHdyaXRlci0+bm9kZXMpOwogICAgaWYgKGxrICE9IDApIHsKICAg ICAgICB4bWxHZW5lcmljRXJyb3IoeG1sR2VuZXJpY0Vycm9yQ29udGV4dCwKICAgICAgICAgICAg ICAgICAgICAgICAgInhtbFRleHRXcml0ZXJTdGFydERURCA6IERURCBhbGxvd2VkIG9ubHkgaW4g cHJvbG9nIVxuIik7CiAgICAgICAgcmV0dXJuIC0xOwogICAgfQoKICAgIHAgPSAoeG1sVGV4dFdy aXRlclN0YWNrRW50cnkgKikKICAgICAgICB4bWxNYWxsb2Moc2l6ZW9mKHhtbFRleHRXcml0ZXJT dGFja0VudHJ5KSk7CiAgICBpZiAocCA9PSAwKSB7CiAgICAgICAgeG1sR2VuZXJpY0Vycm9yKHht bEdlbmVyaWNFcnJvckNvbnRleHQsCiAgICAgICAgICAgICAgICAgICAgICAgICJ4bWxUZXh0V3Jp dGVyU3RhcnREVEQgOiBvdXQgb2YgbWVtb3J5IVxuIik7CiAgICAgICAgcmV0dXJuIC0xOwogICAg fQoKICAgIHAtPm5hbWUgPSB4bWxTdHJkdXAobmFtZSk7CiAgICBpZiAocC0+bmFtZSA9PSAwKSB7 CiAgICAgICAgeG1sR2VuZXJpY0Vycm9yKHhtbEdlbmVyaWNFcnJvckNvbnRleHQsCiAgICAgICAg ICAgICAgICAgICAgICAgICJ4bWxUZXh0V3JpdGVyU3RhcnREVEQgOiBvdXQgb2YgbWVtb3J5IVxu Iik7CiAgICAgICAgeG1sRnJlZShwKTsKICAgICAgICByZXR1cm4gLTE7CiAgICB9CiAgICBwLT5z dGF0ZSA9IFhNTF9URVhUV1JJVEVSX0RURDsKCiAgICB4bWxMaXN0UHVzaEZyb250KHdyaXRlci0+ bm9kZXMsIHApOwoKICAgIGNvdW50ID0geG1sT3V0cHV0QnVmZmVyV3JpdGVTdHJpbmcod3JpdGVy LT5vdXQsICI8IURPQ1RZUEUgIik7CiAgICBpZiAoY291bnQgPCAwKQogICAgICAgIHJldHVybiAt MTsKICAgIHN1bSArPSBjb3VudDsKICAgIGNvdW50ID0geG1sT3V0cHV0QnVmZmVyV3JpdGVTdHJp bmcod3JpdGVyLT5vdXQsIG5hbWUpOwogICAgaWYgKGNvdW50IDwgMCkKICAgICAgICByZXR1cm4g LTE7CiAgICBzdW0gKz0gY291bnQ7CgogICAgaWYgKHB1YmlkICE9IDApIHsKICAgICAgICBpZiAo c3lzaWQgPT0gMCkgewogICAgICAgICAgICB4bWxHZW5lcmljRXJyb3IoeG1sR2VuZXJpY0Vycm9y Q29udGV4dCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICJ4bWxUZXh0V3JpdGVyU3RhcnRE VEQgOiBzeXN0ZW0gaWRlbnRpZmllciBuZWVkZWQhXG4iKTsKICAgICAgICAgICAgcmV0dXJuIC0x OwogICAgICAgIH0KCiAgICAgICAgY291bnQgPSB4bWxPdXRwdXRCdWZmZXJXcml0ZVN0cmluZyh3 cml0ZXItPm91dCwgIiBQVUJMSUMgXCIiKTsKICAgICAgICBpZiAoY291bnQgPCAwKQogICAgICAg ICAgICByZXR1cm4gLTE7CiAgICAgICAgc3VtICs9IGNvdW50OwoKICAgICAgICBjb3VudCA9IHht bE91dHB1dEJ1ZmZlcldyaXRlU3RyaW5nKHdyaXRlci0+b3V0LCBwdWJpZCk7CiAgICAgICAgaWYg KGNvdW50IDwgMCkKICAgICAgICAgICAgcmV0dXJuIC0xOwogICAgICAgIHN1bSArPSBjb3VudDsK CiAgICAgICAgY291bnQgPSB4bWxPdXRwdXRCdWZmZXJXcml0ZVN0cmluZyh3cml0ZXItPm91dCwg IlwiIik7CiAgICAgICAgaWYgKGNvdW50IDwgMCkKICAgICAgICAgICAgcmV0dXJuIC0xOwogICAg ICAgIHN1bSArPSBjb3VudDsKICAgIH0KCiAgICBpZiAoc3lzaWQgIT0gMCkgewogICAgICAgIGlm IChwdWJpZCA9PSAwKSB7CiAgICAgICAgICAgIGNvdW50ID0geG1sT3V0cHV0QnVmZmVyV3JpdGVT dHJpbmcod3JpdGVyLT5vdXQsICIgU1lTVEVNIik7CiAgICAgICAgICAgIGlmIChjb3VudCA8IDAp CiAgICAgICAgICAgICAgICByZXR1cm4gLTE7CiAgICAgICAgICAgIHN1bSArPSBjb3VudDsKICAg ICAgICB9CgogICAgICAgIGNvdW50ID0geG1sT3V0cHV0QnVmZmVyV3JpdGVTdHJpbmcod3JpdGVy LT5vdXQsICIgXCIiKTsKICAgICAgICBpZiAoY291bnQgPCAwKQogICAgICAgICAgICByZXR1cm4g LTE7CiAgICAgICAgc3VtICs9IGNvdW50OwoKICAgICAgICBjb3VudCA9IHhtbE91dHB1dEJ1ZmZl cldyaXRlU3RyaW5nKHdyaXRlci0+b3V0LCBzeXNpZCk7CiAgICAgICAgaWYgKGNvdW50IDwgMCkK ICAgICAgICAgICAgcmV0dXJuIC0xOwogICAgICAgIHN1bSArPSBjb3VudDsKCiAgICAgICAgY291 bnQgPSB4bWxPdXRwdXRCdWZmZXJXcml0ZVN0cmluZyh3cml0ZXItPm91dCwgIlwiIik7CiAgICAg ICAgaWYgKGNvdW50IDwgMCkKICAgICAgICAgICAgcmV0dXJuIC0xOwogICAgICAgIHN1bSArPSBj b3VudDsKICAgIH0KCiAgICByZXR1cm4gc3VtOwp9CgovKioKICogeG1sVGV4dFdyaXRlckVuZERU RDoKICogQHdyaXRlcjogIHRoZSB4bWxUZXh0V3JpdGVyUHRyCiAqCiAqIEVuZCBhbiB4bWwgRFRE LgogKgogKiBSZXR1cm5zIHRoZSBieXRlcyB3cml0dGVuIChtYXkgYmUgMCBiZWNhdXNlIG9mIGJ1 ZmZlcmluZykgb3IgLTEgaW4gY2FzZSBvZiBlcnJvcgogKi8KaW50CnhtbFRleHRXcml0ZXJFbmRE VEQoeG1sVGV4dFdyaXRlclB0ciB3cml0ZXIpCnsKICAgIGludCBjb3VudDsKICAgIGludCBzdW07 CiAgICB4bWxMaW5rUHRyIGxrOwogICAgeG1sVGV4dFdyaXRlclN0YWNrRW50cnkgKnA7CgogICAg aWYgKHdyaXRlciA9PSBOVUxMKQogICAgICAgIHJldHVybiAtMTsKCiAgICBzdW0gPSAwOwogICAg bGsgPSB4bWxMaXN0RnJvbnQod3JpdGVyLT5ub2Rlcyk7CiAgICBpZiAobGsgPT0gMCkKICAgICAg ICByZXR1cm4gLTE7CgogICAgcCA9ICh4bWxUZXh0V3JpdGVyU3RhY2tFbnRyeSAqKSB4bWxMaW5r R2V0RGF0YShsayk7CiAgICBpZiAocCA9PSAwKQogICAgICAgIHJldHVybiAtMTsKCiAgICBzd2l0 Y2ggKHAtPnN0YXRlKSB7CiAgICAgICAgY2FzZSBYTUxfVEVYVFdSSVRFUl9EVERfVEVYVDoKICAg ICAgICAgICAgY291bnQgPSB4bWxPdXRwdXRCdWZmZXJXcml0ZVN0cmluZyh3cml0ZXItPm91dCwg Il0iKTsKICAgICAgICAgICAgaWYgKGNvdW50IDwgMCkKICAgICAgICAgICAgICAgIHJldHVybiAt MTsKICAgICAgICAgICAgc3VtICs9IGNvdW50OwogICAgICAgICAgICAvKiBmYWxsdGhyb3VnaCAq LwogICAgICAgIGNhc2UgWE1MX1RFWFRXUklURVJfRFREOgogICAgICAgIGNhc2UgWE1MX1RFWFRX UklURVJfRFREX0VMRU06CiAgICAgICAgY2FzZSBYTUxfVEVYVFdSSVRFUl9EVERfQVRUTDoKICAg ICAgICAgICAgY291bnQgPSB4bWxPdXRwdXRCdWZmZXJXcml0ZVN0cmluZyh3cml0ZXItPm91dCwg Ij4iKTsKICAgICAgICAgICAgaWYgKGNvdW50IDwgMCkKICAgICAgICAgICAgICAgIHJldHVybiAt MTsKICAgICAgICAgICAgc3VtICs9IGNvdW50OwogICAgICAgICAgICBicmVhazsKICAgICAgICBk ZWZhdWx0OgogICAgICAgICAgICByZXR1cm4gLTE7CiAgICB9CgogICAgeG1sTGlzdFBvcEZyb250 KHdyaXRlci0+bm9kZXMpOwogICAgcmV0dXJuIHN1bTsKfQoKLyoqCiAqIHhtbFRleHRXcml0ZXJX cml0ZUZvcm1hdERURDoKICogQHdyaXRlcjogIHRoZSB4bWxUZXh0V3JpdGVyUHRyCiAqIEBuYW1l OiAgdGhlIG5hbWUgb2YgdGhlIERURAogKiBAcHViaWQ6ICB0aGUgcHVibGljIGlkZW50aWZpZXIs IHdoaWNoIGlzIGFuIGFsdGVybmF0aXZlIHRvIHRoZSBzeXN0ZW0gaWRlbnRpZmllcgogKiBAc3lz aWQ6ICB0aGUgc3lzdGVtIGlkZW50aWZpZXIsIHdoaWNoIGlzIHRoZSBVUkkgb2YgdGhlIERURAog KiBAZm9ybWF0OiAgZm9ybWF0IHN0cmluZyAoc2VlIHByaW50ZikKICoKICogV3JpdGUgYSBEVEQg d2l0aCBhIGZvcm1hdHRlZCBtYXJrdXAgZGVjbGFyYXRpb25zIHBhcnQuCiAqCiAqIFJldHVybnMg dGhlIGJ5dGVzIHdyaXR0ZW4gKG1heSBiZSAwIGJlY2F1c2Ugb2YgYnVmZmVyaW5nKSBvciAtMSBp biBjYXNlIG9mIGVycm9yCiAqLwppbnQKeG1sVGV4dFdyaXRlcldyaXRlRm9ybWF0RFREKHhtbFRl eHRXcml0ZXJQdHIgd3JpdGVyLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgeG1s Q2hhciAqIG5hbWUsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICog cHViaWQsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICogc3lzaWQs IGNvbnN0IGNoYXIgKmZvcm1hdCwgLi4uKQp7CiAgICBpbnQgcmM7CiAgICB2YV9saXN0IGFwOwoK ICAgIHZhX3N0YXJ0KGFwLCBmb3JtYXQpOwoKICAgIHJjID0geG1sVGV4dFdyaXRlcldyaXRlVkZv cm1hdERURCh3cml0ZXIsIG5hbWUsIHB1YmlkLCBzeXNpZCwgZm9ybWF0LAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGFwKTsKCiAgICB2YV9lbmQoYXApOwogICAgcmV0dXJu IHJjOwp9CgovKioKICogeG1sVGV4dFdyaXRlcldyaXRlVkZvcm1hdERURDoKICogQHdyaXRlcjog IHRoZSB4bWxUZXh0V3JpdGVyUHRyCiAqIEBuYW1lOiAgdGhlIG5hbWUgb2YgdGhlIERURAogKiBA cHViaWQ6ICB0aGUgcHVibGljIGlkZW50aWZpZXIsIHdoaWNoIGlzIGFuIGFsdGVybmF0aXZlIHRv IHRoZSBzeXN0ZW0gaWRlbnRpZmllcgogKiBAc3lzaWQ6ICB0aGUgc3lzdGVtIGlkZW50aWZpZXIs IHdoaWNoIGlzIHRoZSBVUkkgb2YgdGhlIERURAogKiBAZm9ybWF0OiAgZm9ybWF0IHN0cmluZyAo c2VlIHByaW50ZikKICoKICogV3JpdGUgYSBEVEQgd2l0aCBhIGZvcm1hdHRlZCBtYXJrdXAgZGVj bGFyYXRpb25zIHBhcnQuCiAqCiAqIFJldHVybnMgdGhlIGJ5dGVzIHdyaXR0ZW4gKG1heSBiZSAw IGJlY2F1c2Ugb2YgYnVmZmVyaW5nKSBvciAtMSBpbiBjYXNlIG9mIGVycm9yCiAqLwppbnQKeG1s VGV4dFdyaXRlcldyaXRlVkZvcm1hdERURCh4bWxUZXh0V3JpdGVyUHRyIHdyaXRlciwKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICogbmFtZSwKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICogcHViaWQsCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgY29uc3QgeG1sQ2hhciAqIHN5c2lkLAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGNvbnN0IGNoYXIgKmZvcm1hdCwgdmFfbGlzdCBhcmdwdHIpCnsKICAgIGludCByYzsK ICAgIHhtbENoYXIgKmJ1ZjsKCiAgICBpZiAod3JpdGVyID09IE5VTEwpCiAgICAgICAgcmV0dXJu IC0xOwoKICAgIGJ1ZiA9IHhtbFRleHRXcml0ZXJWU3ByaW50Zihmb3JtYXQsIGFyZ3B0cik7CiAg ICBpZiAoYnVmID09IDApCiAgICAgICAgcmV0dXJuIDA7CgogICAgcmMgPSB4bWxUZXh0V3JpdGVy V3JpdGVEVEQod3JpdGVyLCBuYW1lLCBwdWJpZCwgc3lzaWQsIGJ1Zik7CgogICAgeG1sRnJlZShi dWYpOwogICAgcmV0dXJuIHJjOwp9CgovKioKICogeG1sVGV4dFdyaXRlcldyaXRlRFREOgogKiBA d3JpdGVyOiAgdGhlIHhtbFRleHRXcml0ZXJQdHIKICogQG5hbWU6ICB0aGUgbmFtZSBvZiB0aGUg RFRECiAqIEBwdWJpZDogIHRoZSBwdWJsaWMgaWRlbnRpZmllciwgd2hpY2ggaXMgYW4gYWx0ZXJu YXRpdmUgdG8gdGhlIHN5c3RlbSBpZGVudGlmaWVyCiAqIEBzeXNpZDogIHRoZSBzeXN0ZW0gaWRl bnRpZmllciwgd2hpY2ggaXMgdGhlIFVSSSBvZiB0aGUgRFRECiAqIEBmb3JtYXQ6ICBmb3JtYXQg c3RyaW5nIChzZWUgcHJpbnRmKQogKgogKiBXcml0ZSBhIERURC4KICoKICogUmV0dXJucyB0aGUg Ynl0ZXMgd3JpdHRlbiAobWF5IGJlIDAgYmVjYXVzZSBvZiBidWZmZXJpbmcpIG9yIC0xIGluIGNh c2Ugb2YgZXJyb3IKICovCmludAp4bWxUZXh0V3JpdGVyV3JpdGVEVEQoeG1sVGV4dFdyaXRlclB0 ciB3cml0ZXIsCiAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICogbmFtZSwKICAg ICAgICAgICAgICAgICAgICAgIGNvbnN0IHhtbENoYXIgKiBwdWJpZCwKICAgICAgICAgICAgICAg ICAgICAgIGNvbnN0IHhtbENoYXIgKiBzeXNpZCwgY29uc3QgeG1sQ2hhciAqIHN1YnNldCkKewog ICAgaW50IGNvdW50OwogICAgaW50IHN1bTsKCiAgICBzdW0gPSAwOwogICAgY291bnQgPSB4bWxU ZXh0V3JpdGVyU3RhcnREVEQod3JpdGVyLCBuYW1lLCBwdWJpZCwgc3lzaWQpOwogICAgaWYgKGNv dW50ID09IC0xKQogICAgICAgIHJldHVybiAtMTsKICAgIHN1bSArPSBjb3VudDsKICAgIGlmIChz dWJzZXQgIT0gMCkgewogICAgICAgIGNvdW50ID0geG1sVGV4dFdyaXRlcldyaXRlU3RyaW5nKHdy aXRlciwgc3Vic2V0KTsKICAgICAgICBpZiAoY291bnQgPT0gLTEpCiAgICAgICAgICAgIHJldHVy biAtMTsKICAgICAgICBzdW0gKz0gY291bnQ7CiAgICB9CiAgICBjb3VudCA9IHhtbFRleHRXcml0 ZXJFbmREVEQod3JpdGVyKTsKICAgIGlmIChjb3VudCA9PSAtMSkKICAgICAgICByZXR1cm4gLTE7 CiAgICBzdW0gKz0gY291bnQ7CgogICAgcmV0dXJuIHN1bTsKfQoKaW50CnhtbFRleHRXcml0ZXJT dGFydERUREVsZW1lbnQoeG1sVGV4dFdyaXRlclB0ciB3cml0ZXIsIGNvbnN0IHhtbENoYXIgKiBu YW1lKQp7CiAgICBpbnQgY291bnQ7CiAgICBpbnQgc3VtOwogICAgeG1sTGlua1B0ciBsazsKICAg IHhtbFRleHRXcml0ZXJTdGFja0VudHJ5ICpwOwoKICAgIGlmICh3cml0ZXIgPT0gTlVMTCB8fCBu YW1lID09IE5VTEwgfHwgKm5hbWUgPT0gJ1wwJykKICAgICAgICByZXR1cm4gLTE7CgogICAgc3Vt ID0gMDsKICAgIGxrID0geG1sTGlzdEZyb250KHdyaXRlci0+bm9kZXMpOwogICAgaWYgKGxrID09 IDApIHsKICAgICAgICByZXR1cm4gLTE7CiAgICB9CgogICAgcCA9ICh4bWxUZXh0V3JpdGVyU3Rh Y2tFbnRyeSAqKSB4bWxMaW5rR2V0RGF0YShsayk7CiAgICBpZiAocCA9PSAwKQogICAgICAgIHJl dHVybiAtMTsKCiAgICBzd2l0Y2ggKHAtPnN0YXRlKSB7CiAgICAgICAgY2FzZSBYTUxfVEVYVFdS SVRFUl9EVEQ6CiAgICAgICAgICAgIGNvdW50ID0geG1sT3V0cHV0QnVmZmVyV3JpdGVTdHJpbmco d3JpdGVyLT5vdXQsICIgWyIpOwogICAgICAgICAgICBpZiAoY291bnQgPCAwKQogICAgICAgICAg ICAgICAgcmV0dXJuIC0xOwogICAgICAgICAgICBzdW0gKz0gY291bnQ7CiAgICAgICAgICAgIHAt PnN0YXRlID0gWE1MX1RFWFRXUklURVJfRFREX1RFWFQ7CiAgICAgICAgICAgIC8qIGZhbGx0aHJv dWdoICovCiAgICAgICAgY2FzZSBYTUxfVEVYVFdSSVRFUl9EVERfVEVYVDoKICAgICAgICAgICAg YnJlYWs7CiAgICAgICAgY2FzZSBYTUxfVEVYVFdSSVRFUl9EVERfRUxFTToKICAgICAgICAgICAg Y291bnQgPSB4bWxUZXh0V3JpdGVyRW5kRFRERWxlbWVudCh3cml0ZXIpOwogICAgICAgICAgICBp ZiAoY291bnQgPCAwKQogICAgICAgICAgICAgICAgcmV0dXJuIC0xOwogICAgICAgICAgICBzdW0g Kz0gY291bnQ7CiAgICAgICAgICAgIGJyZWFrOwogICAgICAgIGRlZmF1bHQ6CiAgICAgICAgICAg IHJldHVybiAtMTsKICAgIH0KCiAgICBwID0gKHhtbFRleHRXcml0ZXJTdGFja0VudHJ5ICopCiAg ICAgICAgeG1sTWFsbG9jKHNpemVvZih4bWxUZXh0V3JpdGVyU3RhY2tFbnRyeSkpOwogICAgaWYg KHAgPT0gMCkgewogICAgICAgIHhtbEdlbmVyaWNFcnJvcih4bWxHZW5lcmljRXJyb3JDb250ZXh0 LAogICAgICAgICAgICAgICAgICAgICAgICAieG1sVGV4dFdyaXRlclN0YXJ0RFRERWxlbWVudCA6 IG91dCBvZiBtZW1vcnkhXG4iKTsKICAgICAgICByZXR1cm4gLTE7CiAgICB9CgogICAgcC0+bmFt ZSA9IHhtbFN0cmR1cChuYW1lKTsKICAgIGlmIChwLT5uYW1lID09IDApIHsKICAgICAgICB4bWxH ZW5lcmljRXJyb3IoeG1sR2VuZXJpY0Vycm9yQ29udGV4dCwKICAgICAgICAgICAgICAgICAgICAg ICAgInhtbFRleHRXcml0ZXJTdGFydERUREVsZW1lbnQgOiBvdXQgb2YgbWVtb3J5IVxuIik7CiAg ICAgICAgeG1sRnJlZShwKTsKICAgICAgICByZXR1cm4gLTE7CiAgICB9CiAgICBwLT5zdGF0ZSA9 IFhNTF9URVhUV1JJVEVSX0RURF9FTEVNOwoKICAgIHhtbExpc3RQdXNoRnJvbnQod3JpdGVyLT5u b2RlcywgcCk7CgogICAgY291bnQgPSB4bWxPdXRwdXRCdWZmZXJXcml0ZVN0cmluZyh3cml0ZXIt Pm91dCwgIjwhRUxFTUVOVCAiKTsKICAgIGlmIChjb3VudCA8IDApCiAgICAgICAgcmV0dXJuIC0x OwogICAgc3VtICs9IGNvdW50OwogICAgY291bnQgPSB4bWxPdXRwdXRCdWZmZXJXcml0ZVN0cmlu Zyh3cml0ZXItPm91dCwgbmFtZSk7CiAgICBpZiAoY291bnQgPCAwKQogICAgICAgIHJldHVybiAt MTsKICAgIHN1bSArPSBjb3VudDsKCiAgICByZXR1cm4gc3VtOwp9CgppbnQKeG1sVGV4dFdyaXRl cldyaXRlRm9ybWF0RFRERWxlbWVudCh4bWxUZXh0V3JpdGVyUHRyIHdyaXRlciwKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICogbmFtZSwKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCBjaGFyICpmb3JtYXQsIC4uLikKewogICAg aW50IHJjOwogICAgdmFfbGlzdCBhcDsKCiAgICB2YV9zdGFydChhcCwgZm9ybWF0KTsKCiAgICBy YyA9IHhtbFRleHRXcml0ZXJXcml0ZVZGb3JtYXREVERFbGVtZW50KHdyaXRlciwgbmFtZSwgZm9y bWF0LCBhcCk7CgogICAgdmFfZW5kKGFwKTsKICAgIHJldHVybiByYzsKfQoKaW50CnhtbFRleHRX cml0ZXJXcml0ZVZGb3JtYXREVERFbGVtZW50KHhtbFRleHRXcml0ZXJQdHIgd3JpdGVyLAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFyICogbmFtZSwKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgY2hhciAqZm9ybWF0LCB2YV9s aXN0IGFyZ3B0cikKewogICAgaW50IHJjOwogICAgeG1sQ2hhciAqYnVmOwoKICAgIGlmICh3cml0 ZXIgPT0gTlVMTCkKICAgICAgICByZXR1cm4gLTE7CgogICAgYnVmID0geG1sVGV4dFdyaXRlclZT cHJpbnRmKGZvcm1hdCwgYXJncHRyKTsKICAgIGlmIChidWYgPT0gMCkKICAgICAgICByZXR1cm4g MDsKCiAgICByYyA9IHhtbFRleHRXcml0ZXJXcml0ZURUREVsZW1lbnQod3JpdGVyLCBuYW1lLCBi dWYpOwoKICAgIHhtbEZyZWUoYnVmKTsKICAgIHJldHVybiByYzsKfQoKaW50CnhtbFRleHRXcml0 ZXJXcml0ZURUREVsZW1lbnQoeG1sVGV4dFdyaXRlclB0ciB3cml0ZXIsCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgY29uc3QgeG1sQ2hhciAqIG5hbWUsIGNvbnN0IHhtbENoYXIgKiBjb250 ZW50KQp7CiAgICBpbnQgY291bnQ7CiAgICBpbnQgc3VtOwoKICAgIGlmIChjb250ZW50ID09IE5V TEwpCiAgICAgICAgcmV0dXJuIC0xOwoKICAgIHN1bSA9IDA7CiAgICBjb3VudCA9IHhtbFRleHRX cml0ZXJTdGFydERUREVsZW1lbnQod3JpdGVyLCBuYW1lKTsKICAgIGlmIChjb3VudCA9PSAtMSkK ICAgICAgICByZXR1cm4gLTE7CiAgICBzdW0gKz0gY291bnQ7CgogICAgY291bnQgPSB4bWxUZXh0 V3JpdGVyV3JpdGVTdHJpbmcod3JpdGVyLCAiICIpOwogICAgaWYgKGNvdW50ID09IC0xKQogICAg ICAgIHJldHVybiAtMTsKICAgIHN1bSArPSBjb3VudDsKICAgIGNvdW50ID0geG1sVGV4dFdyaXRl cldyaXRlU3RyaW5nKHdyaXRlciwgY29udGVudCk7CiAgICBpZiAoY291bnQgPT0gLTEpCiAgICAg ICAgcmV0dXJuIC0xOwogICAgc3VtICs9IGNvdW50OwoKICAgIGNvdW50ID0geG1sVGV4dFdyaXRl ckVuZERUREVsZW1lbnQod3JpdGVyKTsKICAgIGlmIChjb3VudCA9PSAtMSkKICAgICAgICByZXR1 cm4gLTE7CiAgICBzdW0gKz0gY291bnQ7CgogICAgcmV0dXJuIHN1bTsKfQoKaW50CnhtbFRleHRX cml0ZXJTdGFydERUREF0dGxpc3QoeG1sVGV4dFdyaXRlclB0ciB3cml0ZXIsIGNvbnN0IHhtbENo YXIgKiBuYW1lKQp7CiAgICBpbnQgY291bnQ7CiAgICBpbnQgc3VtOwogICAgeG1sTGlua1B0ciBs azsKICAgIHhtbFRleHRXcml0ZXJTdGFja0VudHJ5ICpwOwoKICAgIGlmICh3cml0ZXIgPT0gTlVM TCB8fCBuYW1lID09IE5VTEwgfHwgKm5hbWUgPT0gJ1wwJykKICAgICAgICByZXR1cm4gLTE7Cgog ICAgc3VtID0gMDsKICAgIGxrID0geG1sTGlzdEZyb250KHdyaXRlci0+bm9kZXMpOwogICAgaWYg KGxrID09IDApIHsKICAgICAgICByZXR1cm4gLTE7CiAgICB9CgogICAgcCA9ICh4bWxUZXh0V3Jp dGVyU3RhY2tFbnRyeSAqKSB4bWxMaW5rR2V0RGF0YShsayk7CiAgICBpZiAocCA9PSAwKQogICAg ICAgIHJldHVybiAtMTsKCiAgICBzd2l0Y2ggKHAtPnN0YXRlKSB7CiAgICAgICAgY2FzZSBYTUxf VEVYVFdSSVRFUl9EVEQ6CiAgICAgICAgICAgIGNvdW50ID0geG1sT3V0cHV0QnVmZmVyV3JpdGVT dHJpbmcod3JpdGVyLT5vdXQsICIgWyIpOwogICAgICAgICAgICBpZiAoY291bnQgPCAwKQogICAg ICAgICAgICAgICAgcmV0dXJuIC0xOwogICAgICAgICAgICBzdW0gKz0gY291bnQ7CiAgICAgICAg ICAgIHAtPnN0YXRlID0gWE1MX1RFWFRXUklURVJfRFREX1RFWFQ7CiAgICAgICAgICAgIC8qIGZh bGx0aHJvdWdoICovCiAgICAgICAgY2FzZSBYTUxfVEVYVFdSSVRFUl9EVERfVEVYVDoKICAgICAg ICAgICAgYnJlYWs7CiAgICAgICAgY2FzZSBYTUxfVEVYVFdSSVRFUl9EVERfRUxFTToKICAgICAg ICBjYXNlIFhNTF9URVhUV1JJVEVSX0RURF9BVFRMOgogICAgICAgIGNhc2UgWE1MX1RFWFRXUklU RVJfRFREX0VOVFk6CiAgICAgICAgICAgIGNvdW50ID0geG1sVGV4dFdyaXRlckVuZERURCh3cml0 ZXIpOwogICAgICAgICAgICBpZiAoY291bnQgPCAwKQogICAgICAgICAgICAgICAgcmV0dXJuIC0x OwogICAgICAgICAgICBzdW0gKz0gY291bnQ7CiAgICAgICAgICAgIGJyZWFrOwogICAgICAgIGRl ZmF1bHQ6CiAgICAgICAgICAgIHJldHVybiAtMTsKICAgIH0KCiAgICBwID0gKHhtbFRleHRXcml0 ZXJTdGFja0VudHJ5ICopCiAgICAgICAgeG1sTWFsbG9jKHNpemVvZih4bWxUZXh0V3JpdGVyU3Rh Y2tFbnRyeSkpOwogICAgaWYgKHAgPT0gMCkgewogICAgICAgIHhtbEdlbmVyaWNFcnJvcih4bWxH ZW5lcmljRXJyb3JDb250ZXh0LAogICAgICAgICAgICAgICAgICAgICAgICAieG1sVGV4dFdyaXRl clN0YXJ0RFREQXR0bGlzdCA6IG91dCBvZiBtZW1vcnkhXG4iKTsKICAgICAgICByZXR1cm4gLTE7 CiAgICB9CgogICAgcC0+bmFtZSA9IHhtbFN0cmR1cChuYW1lKTsKICAgIGlmIChwLT5uYW1lID09 IDApIHsKICAgICAgICB4bWxHZW5lcmljRXJyb3IoeG1sR2VuZXJpY0Vycm9yQ29udGV4dCwKICAg ICAgICAgICAgICAgICAgICAgICAgInhtbFRleHRXcml0ZXJTdGFydERUREF0dGxpc3QgOiBvdXQg b2YgbWVtb3J5IVxuIik7CiAgICAgICAgeG1sRnJlZShwKTsKICAgICAgICByZXR1cm4gLTE7CiAg ICB9CiAgICBwLT5zdGF0ZSA9IFhNTF9URVhUV1JJVEVSX0RURF9BVFRMOwoKICAgIHhtbExpc3RQ dXNoRnJvbnQod3JpdGVyLT5ub2RlcywgcCk7CgogICAgY291bnQgPSB4bWxPdXRwdXRCdWZmZXJX cml0ZVN0cmluZyh3cml0ZXItPm91dCwgIjwhQVRUTElTVCAiKTsKICAgIGlmIChjb3VudCA8IDAp CiAgICAgICAgcmV0dXJuIC0xOwogICAgc3VtICs9IGNvdW50OwogICAgY291bnQgPSB4bWxPdXRw dXRCdWZmZXJXcml0ZVN0cmluZyh3cml0ZXItPm91dCwgbmFtZSk7CiAgICBpZiAoY291bnQgPCAw KQogICAgICAgIHJldHVybiAtMTsKICAgIHN1bSArPSBjb3VudDsKCiAgICByZXR1cm4gc3VtOwp9 CgppbnQKeG1sVGV4dFdyaXRlcldyaXRlRm9ybWF0RFREQXR0bGlzdCh4bWxUZXh0V3JpdGVyUHRy IHdyaXRlciwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFy ICogbmFtZSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCBjaGFyICpm b3JtYXQsIC4uLikKewogICAgaW50IHJjOwogICAgdmFfbGlzdCBhcDsKCiAgICB2YV9zdGFydChh cCwgZm9ybWF0KTsKCiAgICByYyA9IHhtbFRleHRXcml0ZXJXcml0ZVZGb3JtYXREVERBdHRsaXN0 KHdyaXRlciwgbmFtZSwgZm9ybWF0LCBhcCk7CgogICAgdmFfZW5kKGFwKTsKICAgIHJldHVybiBy YzsKfQoKaW50CnhtbFRleHRXcml0ZXJXcml0ZVZGb3JtYXREVERBdHRsaXN0KHhtbFRleHRXcml0 ZXJQdHIgd3JpdGVyLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4 bWxDaGFyICogbmFtZSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3Qg Y2hhciAqZm9ybWF0LCB2YV9saXN0IGFyZ3B0cikKewogICAgaW50IHJjOwogICAgeG1sQ2hhciAq YnVmOwoKICAgIGlmICh3cml0ZXIgPT0gTlVMTCkKICAgICAgICByZXR1cm4gLTE7CgogICAgYnVm ID0geG1sVGV4dFdyaXRlclZTcHJpbnRmKGZvcm1hdCwgYXJncHRyKTsKICAgIGlmIChidWYgPT0g MCkKICAgICAgICByZXR1cm4gMDsKCiAgICByYyA9IHhtbFRleHRXcml0ZXJXcml0ZURUREF0dGxp c3Qod3JpdGVyLCBuYW1lLCBidWYpOwoKICAgIHhtbEZyZWUoYnVmKTsKICAgIHJldHVybiByYzsK fQoKaW50CnhtbFRleHRXcml0ZXJXcml0ZURUREF0dGxpc3QoeG1sVGV4dFdyaXRlclB0ciB3cml0 ZXIsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgeG1sQ2hhciAqIG5hbWUsIGNv bnN0IHhtbENoYXIgKiBjb250ZW50KQp7CiAgICBpbnQgY291bnQ7CiAgICBpbnQgc3VtOwoKICAg IGlmIChjb250ZW50ID09IE5VTEwpCiAgICAgICAgcmV0dXJuIC0xOwoKICAgIHN1bSA9IDA7CiAg ICBjb3VudCA9IHhtbFRleHRXcml0ZXJTdGFydERUREF0dGxpc3Qod3JpdGVyLCBuYW1lKTsKICAg IGlmIChjb3VudCA9PSAtMSkKICAgICAgICByZXR1cm4gLTE7CiAgICBzdW0gKz0gY291bnQ7Cgog ICAgY291bnQgPSB4bWxUZXh0V3JpdGVyV3JpdGVTdHJpbmcod3JpdGVyLCAiICIpOwogICAgaWYg KGNvdW50ID09IC0xKQogICAgICAgIHJldHVybiAtMTsKICAgIHN1bSArPSBjb3VudDsKICAgIGNv dW50ID0geG1sVGV4dFdyaXRlcldyaXRlU3RyaW5nKHdyaXRlciwgY29udGVudCk7CiAgICBpZiAo Y291bnQgPT0gLTEpCiAgICAgICAgcmV0dXJuIC0xOwogICAgc3VtICs9IGNvdW50OwoKICAgIGNv dW50ID0geG1sVGV4dFdyaXRlckVuZERUREF0dGxpc3Qod3JpdGVyKTsKICAgIGlmIChjb3VudCA9 PSAtMSkKICAgICAgICByZXR1cm4gLTE7CiAgICBzdW0gKz0gY291bnQ7CgogICAgcmV0dXJuIHN1 bTsKfQoKaW50CnhtbFRleHRXcml0ZXJTdGFydERUREVudGl0eSh4bWxUZXh0V3JpdGVyUHRyIHdy aXRlciwKICAgICAgICAgICAgICAgICAgICAgICAgICAgIGludCBwZSwgY29uc3QgeG1sQ2hhciAq IG5hbWUpCnsKICAgIGludCBjb3VudDsKICAgIGludCBzdW07CiAgICB4bWxMaW5rUHRyIGxrOwog ICAgeG1sVGV4dFdyaXRlclN0YWNrRW50cnkgKnA7CgogICAgaWYgKHdyaXRlciA9PSBOVUxMIHx8 IG5hbWUgPT0gTlVMTCB8fCAqbmFtZSA9PSAnXDAnKQogICAgICAgIHJldHVybiAtMTsKCiAgICBz dW0gPSAwOwogICAgbGsgPSB4bWxMaXN0RnJvbnQod3JpdGVyLT5ub2Rlcyk7CiAgICBpZiAobGsg PT0gMCkgewogICAgICAgIHJldHVybiAtMTsKICAgIH0KCiAgICBwID0gKHhtbFRleHRXcml0ZXJT dGFja0VudHJ5ICopIHhtbExpbmtHZXREYXRhKGxrKTsKICAgIGlmIChwID09IDApCiAgICAgICAg cmV0dXJuIC0xOwoKICAgIHN3aXRjaCAocC0+c3RhdGUpIHsKICAgICAgICBjYXNlIFhNTF9URVhU V1JJVEVSX0RURDoKICAgICAgICAgICAgY291bnQgPSB4bWxPdXRwdXRCdWZmZXJXcml0ZVN0cmlu Zyh3cml0ZXItPm91dCwgIiBbIik7CiAgICAgICAgICAgIGlmIChjb3VudCA8IDApCiAgICAgICAg ICAgICAgICByZXR1cm4gLTE7CiAgICAgICAgICAgIHN1bSArPSBjb3VudDsKICAgICAgICAgICAg cC0+c3RhdGUgPSBYTUxfVEVYVFdSSVRFUl9EVERfVEVYVDsKICAgICAgICAgICAgLyogZmFsbHRo cm91Z2ggKi8KICAgICAgICBjYXNlIFhNTF9URVhUV1JJVEVSX0RURF9URVhUOgogICAgICAgICAg ICBicmVhazsKICAgICAgICBjYXNlIFhNTF9URVhUV1JJVEVSX0RURF9FTEVNOgogICAgICAgIGNh c2UgWE1MX1RFWFRXUklURVJfRFREX0FUVEw6CiAgICAgICAgY2FzZSBYTUxfVEVYVFdSSVRFUl9E VERfRU5UWToKICAgICAgICAgICAgY291bnQgPSB4bWxUZXh0V3JpdGVyRW5kRFREKHdyaXRlcik7 CiAgICAgICAgICAgIGlmIChjb3VudCA8IDApCiAgICAgICAgICAgICAgICByZXR1cm4gLTE7CiAg ICAgICAgICAgIHN1bSArPSBjb3VudDsKICAgICAgICAgICAgYnJlYWs7CiAgICAgICAgZGVmYXVs dDoKICAgICAgICAgICAgcmV0dXJuIC0xOwogICAgfQoKICAgIHAgPSAoeG1sVGV4dFdyaXRlclN0 YWNrRW50cnkgKikKICAgICAgICB4bWxNYWxsb2Moc2l6ZW9mKHhtbFRleHRXcml0ZXJTdGFja0Vu dHJ5KSk7CiAgICBpZiAocCA9PSAwKSB7CiAgICAgICAgeG1sR2VuZXJpY0Vycm9yKHhtbEdlbmVy aWNFcnJvckNvbnRleHQsCiAgICAgICAgICAgICAgICAgICAgICAgICJ4bWxUZXh0V3JpdGVyU3Rh cnREVERFbGVtZW50IDogb3V0IG9mIG1lbW9yeSFcbiIpOwogICAgICAgIHJldHVybiAtMTsKICAg IH0KCiAgICBwLT5uYW1lID0geG1sU3RyZHVwKG5hbWUpOwogICAgaWYgKHAtPm5hbWUgPT0gMCkg ewogICAgICAgIHhtbEdlbmVyaWNFcnJvcih4bWxHZW5lcmljRXJyb3JDb250ZXh0LAogICAgICAg ICAgICAgICAgICAgICAgICAieG1sVGV4dFdyaXRlclN0YXJ0RFRERWxlbWVudCA6IG91dCBvZiBt ZW1vcnkhXG4iKTsKICAgICAgICB4bWxGcmVlKHApOwogICAgICAgIHJldHVybiAtMTsKICAgIH0K ICAgIHAtPnN0YXRlID0gWE1MX1RFWFRXUklURVJfRFREX0VOVFk7CgogICAgeG1sTGlzdFB1c2hG cm9udCh3cml0ZXItPm5vZGVzLCBwKTsKCiAgICBjb3VudCA9IHhtbE91dHB1dEJ1ZmZlcldyaXRl U3RyaW5nKHdyaXRlci0+b3V0LCAiPCFFTlRJVFkgIik7CiAgICBpZiAoY291bnQgPCAwKQogICAg ICAgIHJldHVybiAtMTsKICAgIHN1bSArPSBjb3VudDsKCiAgICBpZiAocGUgIT0gMCkgewogICAg ICAgIGNvdW50ID0geG1sT3V0cHV0QnVmZmVyV3JpdGVTdHJpbmcod3JpdGVyLT5vdXQsICIgJSAi KTsKICAgICAgICBpZiAoY291bnQgPCAwKQogICAgICAgICAgICByZXR1cm4gLTE7CiAgICAgICAg c3VtICs9IGNvdW50OwogICAgfQoKICAgIGNvdW50ID0geG1sT3V0cHV0QnVmZmVyV3JpdGVTdHJp bmcod3JpdGVyLT5vdXQsIG5hbWUpOwogICAgaWYgKGNvdW50IDwgMCkKICAgICAgICByZXR1cm4g LTE7CiAgICBzdW0gKz0gY291bnQ7CgogICAgcmV0dXJuIHN1bTsKfQoKaW50CnhtbFRleHRXcml0 ZXJXcml0ZUZvcm1hdERUREludGVybmFsRW50aXR5KHhtbFRleHRXcml0ZXJQdHIgd3JpdGVyLAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnQgcGUsCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHhtbENoYXIgKiBuYW1lLAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCBjaGFyICpmb3Jt YXQsIC4uLikKewogICAgaW50IHJjOwogICAgdmFfbGlzdCBhcDsKCiAgICB2YV9zdGFydChhcCwg Zm9ybWF0KTsKCiAgICByYyA9IHhtbFRleHRXcml0ZXJXcml0ZVZGb3JtYXREVERJbnRlcm5hbEVu dGl0eSh3cml0ZXIsIHBlLCBuYW1lLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgZm9ybWF0LCBhcCk7CgogICAgdmFfZW5kKGFwKTsKICAgIHJldHVy biByYzsKfQoKaW50CnhtbFRleHRXcml0ZXJXcml0ZVZGb3JtYXREVERJbnRlcm5hbEVudGl0eSh4 bWxUZXh0V3JpdGVyUHRyIHdyaXRlciwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGludCBwZSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGNvbnN0IHhtbENoYXIgKiBuYW1lLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgY29uc3QgY2hhciAqZm9ybWF0LAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgdmFfbGlzdCBhcmdwdHIpCnsKICAgIGludCByYzsKICAgIHhtbENo YXIgKmJ1ZjsKCiAgICBpZiAod3JpdGVyID09IE5VTEwpCiAgICAgICAgcmV0dXJuIC0xOwoKICAg IGJ1ZiA9IHhtbFRleHRXcml0ZXJWU3ByaW50Zihmb3JtYXQsIGFyZ3B0cik7CiAgICBpZiAoYnVm ID09IDApCiAgICAgICAgcmV0dXJuIDA7CgogICAgcmMgPSB4bWxUZXh0V3JpdGVyV3JpdGVEVERJ bnRlcm5hbEVudGl0eSh3cml0ZXIsIHBlLCBuYW1lLCBidWYpOwoKICAgIHhtbEZyZWUoYnVmKTsK ICAgIHJldHVybiByYzsKfQoKaW50CnhtbFRleHRXcml0ZXJXcml0ZURUREVudGl0eSh4bWxUZXh0 V3JpdGVyUHRyIHdyaXRlciwKICAgICAgICAgICAgICAgICAgICAgICAgICAgIGludCBwZSwKICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHhtbENoYXIgKiBuYW1lLAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgY29uc3QgeG1sQ2hhciAqIHB1YmlkLAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgY29uc3QgeG1sQ2hhciAqIHN5c2lkLAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgY29uc3QgeG1sQ2hhciAqIG5kYXRhaWQsCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICBjb25zdCB4bWxDaGFyICogY29udGVudCkKewogICAgaWYgKCgoY29udGVudCA9PSBOVUxMKSAm JiAocHViaWQgPT0gTlVMTCkgJiYgKHN5c2lkID09IE5VTEwpKQogICAgICAgIHx8ICgoY29udGVu dCAhPSBOVUxMKSAmJiAoKHB1YmlkICE9IE5VTEwpIHx8IChzeXNpZCAhPSBOVUxMKSkpKQogICAg ICAgIHJldHVybiAtMTsKICAgIGlmICgocGUgIT0gMCkgJiYgKG5kYXRhaWQgIT0gTlVMTCkpCiAg ICAgICAgcmV0dXJuIC0xOwoKICAgIGlmIChjb250ZW50ICE9IDApCiAgICAgICAgcmV0dXJuIHht bFRleHRXcml0ZXJXcml0ZURUREludGVybmFsRW50aXR5KHdyaXRlciwgcGUsIG5hbWUsCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnRlbnQpOwoK ICAgIHJldHVybiB4bWxUZXh0V3JpdGVyV3JpdGVEVERFeHRlcm5hbEVudGl0eSh3cml0ZXIsIHBl LCBuYW1lLCBwdWJpZCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBzeXNpZCwgbmRhdGFpZCk7Cn0KCmludAp4bWxUZXh0V3JpdGVyV3JpdGVEVERJbnRlcm5h bEVudGl0eSh4bWxUZXh0V3JpdGVyUHRyIHdyaXRlciwKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgaW50IHBlLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBj b25zdCB4bWxDaGFyICogbmFtZSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Y29uc3QgeG1sQ2hhciAqIGNvbnRlbnQpCnsKICAgIGludCBjb3VudDsKICAgIGludCBzdW07Cgog ICAgaWYgKChuYW1lID09IE5VTEwpIHx8ICgqbmFtZSA9PSAnXDAnKSB8fCAoY29udGVudCA9PSBO VUxMKSkKICAgICAgICByZXR1cm4gLTE7CgogICAgc3VtID0gMDsKICAgIGNvdW50ID0geG1sVGV4 dFdyaXRlclN0YXJ0RFRERW50aXR5KHdyaXRlciwgcGUsIG5hbWUpOwogICAgaWYgKGNvdW50ID09 IC0xKQogICAgICAgIHJldHVybiAtMTsKICAgIHN1bSArPSBjb3VudDsKCiAgICBjb3VudCA9IHht bFRleHRXcml0ZXJXcml0ZVN0cmluZyh3cml0ZXIsICIgIik7CiAgICBpZiAoY291bnQgPT0gLTEp CiAgICAgICAgcmV0dXJuIC0xOwogICAgc3VtICs9IGNvdW50OwogICAgY291bnQgPSB4bWxPdXRw dXRCdWZmZXJXcml0ZSh3cml0ZXItPm91dCwgMSwgJndyaXRlci0+cWNoYXIpOwogICAgaWYgKGNv dW50IDwgMCkKICAgICAgICByZXR1cm4gLTE7CiAgICBzdW0gKz0gY291bnQ7CiAgICBjb3VudCA9 IHhtbFRleHRXcml0ZXJXcml0ZVN0cmluZyh3cml0ZXIsIGNvbnRlbnQpOwogICAgaWYgKGNvdW50 ID09IC0xKQogICAgICAgIHJldHVybiAtMTsKICAgIHN1bSArPSBjb3VudDsKICAgIGNvdW50ID0g eG1sT3V0cHV0QnVmZmVyV3JpdGUod3JpdGVyLT5vdXQsIDEsICZ3cml0ZXItPnFjaGFyKTsKICAg IGlmIChjb3VudCA8IDApCiAgICAgICAgcmV0dXJuIC0xOwogICAgc3VtICs9IGNvdW50OwoKICAg IGNvdW50ID0geG1sVGV4dFdyaXRlckVuZERUREVudGl0eSh3cml0ZXIpOwogICAgaWYgKGNvdW50 ID09IC0xKQogICAgICAgIHJldHVybiAtMTsKICAgIHN1bSArPSBjb3VudDsKCiAgICByZXR1cm4g c3VtOwp9CgppbnQKeG1sVGV4dFdyaXRlcldyaXRlRFRERXh0ZXJuYWxFbnRpdHkoeG1sVGV4dFdy aXRlclB0ciB3cml0ZXIsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGludCBw ZSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgeG1sQ2hhciAqIG5h bWUsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHhtbENoYXIgKiBw dWJpZCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgeG1sQ2hhciAq IHN5c2lkLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB4bWxDaGFy ICogbmRhdGFpZCkKewogICAgaW50IGNvdW50OwogICAgaW50IHN1bTsKCiAgICBpZiAoKG5hbWUg PT0gTlVMTCkgfHwgKCpuYW1lID09ICdcMCcpCiAgICAgICAgfHwgKChwdWJpZCA9PSBOVUxMKSAm JiAoc3lzaWQgPT0gTlVMTCkpKQogICAgICAgIHJldHVybiAtMTsKICAgIGlmICgocGUgIT0gMCkg JiYgKG5kYXRhaWQgIT0gTlVMTCkpCiAgICAgICAgcmV0dXJuIC0xOwoKICAgIHN1bSA9IDA7CiAg ICBjb3VudCA9IHhtbFRleHRXcml0ZXJTdGFydERUREVudGl0eSh3cml0ZXIsIHBlLCBuYW1lKTsK ICAgIGlmIChjb3VudCA9PSAtMSkKICAgICAgICByZXR1cm4gLTE7CiAgICBzdW0gKz0gY291bnQ7 CgogICAgaWYgKHB1YmlkICE9IDApIHsKICAgICAgICBpZiAoc3lzaWQgPT0gMCkgewogICAgICAg ICAgICB4bWxHZW5lcmljRXJyb3IoeG1sR2VuZXJpY0Vycm9yQ29udGV4dCwKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICJ4bWxUZXh0V3JpdGVyV3JpdGVEVERFbnRpdHkgOiBzeXN0ZW0gaWRl bnRpZmllciBuZWVkZWQhXG4iKTsKICAgICAgICAgICAgcmV0dXJuIC0xOwogICAgICAgIH0KCiAg ICAgICAgY291bnQgPSB4bWxPdXRwdXRCdWZmZXJXcml0ZVN0cmluZyh3cml0ZXItPm91dCwgIiBQ VUJMSUMgIik7CiAgICAgICAgaWYgKGNvdW50IDwgMCkKICAgICAgICAgICAgcmV0dXJuIC0xOwog ICAgICAgIHN1bSArPSBjb3VudDsKCiAgICAgICAgY291bnQgPSB4bWxPdXRwdXRCdWZmZXJXcml0 ZSh3cml0ZXItPm91dCwgMSwgJndyaXRlci0+cWNoYXIpOwogICAgICAgIGlmIChjb3VudCA8IDAp CiAgICAgICAgICAgIHJldHVybiAtMTsKICAgICAgICBzdW0gKz0gY291bnQ7CgogICAgICAgIGNv dW50ID0geG1sT3V0cHV0QnVmZmVyV3JpdGVTdHJpbmcod3JpdGVyLT5vdXQsIHB1YmlkKTsKICAg ICAgICBpZiAoY291bnQgPCAwKQogICAgICAgICAgICByZXR1cm4gLTE7CiAgICAgICAgc3VtICs9 IGNvdW50OwoKICAgICAgICBjb3VudCA9IHhtbE91dHB1dEJ1ZmZlcldyaXRlKHdyaXRlci0+b3V0 LCAxLCAmd3JpdGVyLT5xY2hhcik7CiAgICAgICAgaWYgKGNvdW50IDwgMCkKICAgICAgICAgICAg cmV0dXJuIC0xOwogICAgICAgIHN1bSArPSBjb3VudDsKICAgIH0KCiAgICBpZiAoc3lzaWQgIT0g MCkgewogICAgICAgIGlmIChwdWJpZCA9PSAwKSB7CiAgICAgICAgICAgIGNvdW50ID0geG1sT3V0 cHV0QnVmZmVyV3JpdGVTdHJpbmcod3JpdGVyLT5vdXQsICIgU1lTVEVNIik7CiAgICAgICAgICAg IGlmIChjb3VudCA8IDApCiAgICAgICAgICAgICAgICByZXR1cm4gLTE7CiAgICAgICAgICAgIHN1 bSArPSBjb3VudDsKICAgICAgICB9CgogICAgICAgIGNvdW50ID0geG1sT3V0cHV0QnVmZmVyV3Jp dGVTdHJpbmcod3JpdGVyLT5vdXQsICIgIik7CiAgICAgICAgaWYgKGNvdW50IDwgMCkKICAgICAg ICAgICAgcmV0dXJuIC0xOwogICAgICAgIHN1bSArPSBjb3VudDsKCiAgICAgICAgY291bnQgPSB4 bWxPdXRwdXRCdWZmZXJXcml0ZSh3cml0ZXItPm91dCwgMSwgJndyaXRlci0+cWNoYXIpOwogICAg ICAgIGlmIChjb3VudCA8IDApCiAgICAgICAgICAgIHJldHVybiAtMTsKICAgICAgICBzdW0gKz0g Y291bnQ7CgogICAgICAgIGNvdW50ID0geG1sT3V0cHV0QnVmZmVyV3JpdGVTdHJpbmcod3JpdGVy LT5vdXQsIHN5c2lkKTsKICAgICAgICBpZiAoY291bnQgPCAwKQogICAgICAgICAgICByZXR1cm4g LTE7CiAgICAgICAgc3VtICs9IGNvdW50OwoKICAgICAgICBjb3VudCA9IHhtbE91dHB1dEJ1ZmZl cldyaXRlKHdyaXRlci0+b3V0LCAxLCAmd3JpdGVyLT5xY2hhcik7CiAgICAgICAgaWYgKGNvdW50 IDwgMCkKICAgICAgICAgICAgcmV0dXJuIC0xOwogICAgICAgIHN1bSArPSBjb3VudDsKICAgIH0K CiAgICBpZiAobmRhdGFpZCAhPSBOVUxMKSB7CiAgICAgICAgY291bnQgPSB4bWxPdXRwdXRCdWZm ZXJXcml0ZVN0cmluZyh3cml0ZXItPm91dCwgIiBOREFUQSAiKTsKICAgICAgICBpZiAoY291bnQg PCAwKQogICAgICAgICAgICByZXR1cm4gLTE7CiAgICAgICAgc3VtICs9IGNvdW50OwoKICAgICAg ICBjb3VudCA9IHhtbE91dHB1dEJ1ZmZlcldyaXRlU3RyaW5nKHdyaXRlci0+b3V0LCBuZGF0YWlk KTsKICAgICAgICBpZiAoY291bnQgPCAwKQogICAgICAgICAgICByZXR1cm4gLTE7CiAgICAgICAg c3VtICs9IGNvdW50OwogICAgfQoKICAgIGNvdW50ID0geG1sVGV4dFdyaXRlckVuZERUREVudGl0 eSh3cml0ZXIpOwogICAgaWYgKGNvdW50ID09IC0xKQogICAgICAgIHJldHVybiAtMTsKICAgIHN1 bSArPSBjb3VudDsKCiAgICByZXR1cm4gc3VtOwp9CgppbnQKeG1sVGV4dFdyaXRlcldyaXRlRFRE Tm90YXRpb24oeG1sVGV4dFdyaXRlclB0ciB3cml0ZXIsCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGNvbnN0IHhtbENoYXIgKiBuYW1lLAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBjb25zdCB4bWxDaGFyICogcHViaWQsIGNvbnN0IHhtbENoYXIgKiBzeXNpZCkKewogICAgaW50 IGNvdW50OwogICAgaW50IHN1bTsKICAgIHhtbExpbmtQdHIgbGs7CiAgICB4bWxUZXh0V3JpdGVy U3RhY2tFbnRyeSAqcDsKCiAgICBpZiAod3JpdGVyID09IE5VTEwgfHwgbmFtZSA9PSBOVUxMIHx8 ICpuYW1lID09ICdcMCcpCiAgICAgICAgcmV0dXJuIC0xOwoKICAgIHN1bSA9IDA7CiAgICBsayA9 IHhtbExpc3RGcm9udCh3cml0ZXItPm5vZGVzKTsKICAgIGlmIChsayA9PSAwKSB7CiAgICAgICAg cmV0dXJuIC0xOwogICAgfQoKICAgIHAgPSAoeG1sVGV4dFdyaXRlclN0YWNrRW50cnkgKikgeG1s TGlua0dldERhdGEobGspOwogICAgaWYgKHAgPT0gMCkKICAgICAgICByZXR1cm4gLTE7CgogICAg c3dpdGNoIChwLT5zdGF0ZSkgewogICAgICAgIGNhc2UgWE1MX1RFWFRXUklURVJfRFREOgogICAg ICAgICAgICBjb3VudCA9IHhtbE91dHB1dEJ1ZmZlcldyaXRlU3RyaW5nKHdyaXRlci0+b3V0LCAi IFsiKTsKICAgICAgICAgICAgaWYgKGNvdW50IDwgMCkKICAgICAgICAgICAgICAgIHJldHVybiAt MTsKICAgICAgICAgICAgc3VtICs9IGNvdW50OwogICAgICAgICAgICBwLT5zdGF0ZSA9IFhNTF9U RVhUV1JJVEVSX0RURF9URVhUOwogICAgICAgICAgICAvKiBmYWxsdGhyb3VnaCAqLwogICAgICAg IGNhc2UgWE1MX1RFWFRXUklURVJfRFREX1RFWFQ6CiAgICAgICAgICAgIGJyZWFrOwogICAgICAg IGNhc2UgWE1MX1RFWFRXUklURVJfRFREX0VMRU06CiAgICAgICAgY2FzZSBYTUxfVEVYVFdSSVRF Ul9EVERfQVRUTDoKICAgICAgICBjYXNlIFhNTF9URVhUV1JJVEVSX0RURF9FTlRZOgogICAgICAg ICAgICBjb3VudCA9IHhtbFRleHRXcml0ZXJFbmREVEQod3JpdGVyKTsKICAgICAgICAgICAgaWYg KGNvdW50IDwgMCkKICAgICAgICAgICAgICAgIHJldHVybiAtMTsKICAgICAgICAgICAgc3VtICs9 IGNvdW50OwogICAgICAgICAgICBicmVhazsKICAgICAgICBkZWZhdWx0OgogICAgICAgICAgICBy ZXR1cm4gLTE7CiAgICB9CgogICAgY291bnQgPSB4bWxPdXRwdXRCdWZmZXJXcml0ZVN0cmluZyh3 cml0ZXItPm91dCwgIjwhTk9UQVRJT04gIik7CiAgICBpZiAoY291bnQgPCAwKQogICAgICAgIHJl dHVybiAtMTsKICAgIHN1bSArPSBjb3VudDsKICAgIGNvdW50ID0geG1sT3V0cHV0QnVmZmVyV3Jp dGVTdHJpbmcod3JpdGVyLT5vdXQsIG5hbWUpOwogICAgaWYgKGNvdW50IDwgMCkKICAgICAgICBy ZXR1cm4gLTE7CiAgICBzdW0gKz0gY291bnQ7CgogICAgaWYgKHB1YmlkICE9IDApIHsKICAgICAg ICBjb3VudCA9IHhtbE91dHB1dEJ1ZmZlcldyaXRlU3RyaW5nKHdyaXRlci0+b3V0LCAiIFBVQkxJ QyAiKTsKICAgICAgICBpZiAoY291bnQgPCAwKQogICAgICAgICAgICByZXR1cm4gLTE7CiAgICAg ICAgc3VtICs9IGNvdW50OwogICAgICAgIGNvdW50ID0geG1sT3V0cHV0QnVmZmVyV3JpdGUod3Jp dGVyLT5vdXQsIDEsICZ3cml0ZXItPnFjaGFyKTsKICAgICAgICBpZiAoY291bnQgPCAwKQogICAg ICAgICAgICByZXR1cm4gLTE7CiAgICAgICAgc3VtICs9IGNvdW50OwogICAgICAgIGNvdW50ID0g eG1sT3V0cHV0QnVmZmVyV3JpdGVTdHJpbmcod3JpdGVyLT5vdXQsIHB1YmlkKTsKICAgICAgICBp ZiAoY291bnQgPCAwKQogICAgICAgICAgICByZXR1cm4gLTE7CiAgICAgICAgc3VtICs9IGNvdW50 OwogICAgICAgIGNvdW50ID0geG1sT3V0cHV0QnVmZmVyV3JpdGUod3JpdGVyLT5vdXQsIDEsICZ3 cml0ZXItPnFjaGFyKTsKICAgICAgICBpZiAoY291bnQgPCAwKQogICAgICAgICAgICByZXR1cm4g LTE7CiAgICAgICAgc3VtICs9IGNvdW50OwogICAgfQoKICAgIGlmIChzeXNpZCAhPSAwKSB7CiAg ICAgICAgaWYgKHB1YmlkID09IDApIHsKICAgICAgICAgICAgY291bnQgPSB4bWxPdXRwdXRCdWZm ZXJXcml0ZVN0cmluZyh3cml0ZXItPm91dCwgIiBTWVNURU0iKTsKICAgICAgICAgICAgaWYgKGNv dW50IDwgMCkKICAgICAgICAgICAgICAgIHJldHVybiAtMTsKICAgICAgICAgICAgc3VtICs9IGNv dW50OwogICAgICAgIH0KICAgICAgICBjb3VudCA9IHhtbE91dHB1dEJ1ZmZlcldyaXRlU3RyaW5n KHdyaXRlci0+b3V0LCAiICIpOwogICAgICAgIGlmIChjb3VudCA8IDApCiAgICAgICAgICAgIHJl dHVybiAtMTsKICAgICAgICBzdW0gKz0gY291bnQ7CiAgICAgICAgY291bnQgPSB4bWxPdXRwdXRC dWZmZXJXcml0ZSh3cml0ZXItPm91dCwgMSwgJndyaXRlci0+cWNoYXIpOwogICAgICAgIGlmIChj b3VudCA8IDApCiAgICAgICAgICAgIHJldHVybiAtMTsKICAgICAgICBzdW0gKz0gY291bnQ7CiAg ICAgICAgY291bnQgPSB4bWxPdXRwdXRCdWZmZXJXcml0ZVN0cmluZyh3cml0ZXItPm91dCwgc3lz aWQpOwogICAgICAgIGlmIChjb3VudCA8IDApCiAgICAgICAgICAgIHJldHVybiAtMTsKICAgICAg ICBzdW0gKz0gY291bnQ7CiAgICAgICAgY291bnQgPSB4bWxPdXRwdXRCdWZmZXJXcml0ZSh3cml0 ZXItPm91dCwgMSwgJndyaXRlci0+cWNoYXIpOwogICAgICAgIGlmIChjb3VudCA8IDApCiAgICAg ICAgICAgIHJldHVybiAtMTsKICAgICAgICBzdW0gKz0gY291bnQ7CiAgICB9CgogICAgY291bnQg PSB4bWxPdXRwdXRCdWZmZXJXcml0ZVN0cmluZyh3cml0ZXItPm91dCwgIj4iKTsKICAgIGlmIChj b3VudCA8IDApCiAgICAgICAgcmV0dXJuIC0xOwogICAgc3VtICs9IGNvdW50OwoKICAgIHJldHVy biBzdW07Cn0KCi8qKgogKiB4bWxUZXh0V3JpdGVyRmx1c2g6CiAqIEB3cml0ZXI6ICB0aGUgeG1s VGV4dFdyaXRlclB0cgogKgogKiBGbHVzaCB0aGUgb3V0cHV0IGJ1ZmZlci4KICoKICogUmV0dXJu cyB0aGUgYnl0ZXMgd3JpdHRlbiAobWF5IGJlIDAgYmVjYXVzZSBvZiBidWZmZXJpbmcpIG9yIC0x IGluIGNhc2Ugb2YgZXJyb3IKICovCmludAp4bWxUZXh0V3JpdGVyRmx1c2goeG1sVGV4dFdyaXRl clB0ciB3cml0ZXIpCnsKICAgIGludCBjb3VudDsKCiAgICBpZiAod3JpdGVyID09IE5VTEwpCiAg ICAgICAgcmV0dXJuIC0xOwoKICAgIGlmICh3cml0ZXItPm91dCA9PSBOVUxMKQogICAgICAgIGNv dW50ID0gMDsKICAgIGVsc2UKICAgICAgICBjb3VudCA9IHhtbE91dHB1dEJ1ZmZlckZsdXNoKHdy aXRlci0+b3V0KTsKCiAgICByZXR1cm4gY291bnQ7Cn0KCi8qKgogKiBtaXNjCiAqLwoKLyoqCiAq IHhtbEZyZWVUZXh0V3JpdGVyU3RhY2tFbnRyeToKICogQGxrOiAgdGhlIHhtbExpbmtQdHIKICoK ICogRnJlZSBjYWxsYmFjayBmb3IgdGhlIHhtbExpc3QuCiAqLwpzdGF0aWMgdm9pZAp4bWxGcmVl VGV4dFdyaXRlclN0YWNrRW50cnkoeG1sTGlua1B0ciBsaykKewogICAgeG1sVGV4dFdyaXRlclN0 YWNrRW50cnkgKnA7CgogICAgcCA9ICh4bWxUZXh0V3JpdGVyU3RhY2tFbnRyeSAqKSB4bWxMaW5r R2V0RGF0YShsayk7CiAgICBpZiAocCA9PSAwKQogICAgICAgIHJldHVybjsKCiAgICBpZiAocC0+ bmFtZSAhPSAwKQogICAgICAgIHhtbEZyZWUocC0+bmFtZSk7CiAgICB4bWxGcmVlKHApOwp9Cgov KioKICogeG1sQ21wVGV4dFdyaXRlclN0YWNrRW50cnk6CiAqIEBkYXRhMDogIHRoZSBmaXJzdCBk YXRhCiAqIEBkYXRhMTogIHRoZSBzZWNvbmQgZGF0YQogKgogKiBDb21wYXJlIGNhbGxiYWNrIGZv ciB0aGUgeG1sTGlzdC4KICoKICogUmV0dXJucyAtMSwgMCwgMQogKi8Kc3RhdGljIGludAp4bWxD bXBUZXh0V3JpdGVyU3RhY2tFbnRyeShjb25zdCB2b2lkICpkYXRhMCwgY29uc3Qgdm9pZCAqZGF0 YTEpCnsKICAgIHhtbFRleHRXcml0ZXJTdGFja0VudHJ5ICpwMDsKICAgIHhtbFRleHRXcml0ZXJT dGFja0VudHJ5ICpwMTsKCiAgICBpZiAoZGF0YTAgPT0gZGF0YTEpCiAgICAgICAgcmV0dXJuIDA7 CgogICAgaWYgKGRhdGEwID09IDApCiAgICAgICAgcmV0dXJuIC0xOwoKICAgIGlmIChkYXRhMSA9 PSAwKQogICAgICAgIHJldHVybiAxOwoKICAgIHAwID0gKHhtbFRleHRXcml0ZXJTdGFja0VudHJ5 ICopIGRhdGEwOwogICAgcDEgPSAoeG1sVGV4dFdyaXRlclN0YWNrRW50cnkgKikgZGF0YTE7Cgog ICAgcmV0dXJuIHhtbFN0cmNtcChwMC0+bmFtZSwgcDEtPm5hbWUpOwp9CgovKioKICogbWlzYwog Ki8KCi8qKgogKiB4bWxGcmVlVGV4dFdyaXRlck5zU3RhY2tFbnRyeToKICogQGxrOiAgdGhlIHht bExpbmtQdHIKICoKICogRnJlZSBjYWxsYmFjayBmb3IgdGhlIHhtbExpc3QuCiAqLwpzdGF0aWMg dm9pZAp4bWxGcmVlVGV4dFdyaXRlck5zU3RhY2tFbnRyeSh4bWxMaW5rUHRyIGxrKQp7CiAgICB4 bWxUZXh0V3JpdGVyTnNTdGFja0VudHJ5ICpwOwoKICAgIHAgPSAoeG1sVGV4dFdyaXRlck5zU3Rh Y2tFbnRyeSAqKSB4bWxMaW5rR2V0RGF0YShsayk7CiAgICBpZiAocCA9PSAwKQogICAgICAgIHJl dHVybjsKCiAgICBpZiAocC0+cHJlZml4ICE9IDApCiAgICAgICAgeG1sRnJlZShwLT5wcmVmaXgp OwogICAgaWYgKHAtPnVyaSAhPSAwKQogICAgICAgIHhtbEZyZWUocC0+dXJpKTsKCiAgICB4bWxG cmVlKHApOwp9CgovKioKICogeG1sQ21wVGV4dFdyaXRlck5zU3RhY2tFbnRyeToKICogQGRhdGEw OiAgdGhlIGZpcnN0IGRhdGEKICogQGRhdGExOiAgdGhlIHNlY29uZCBkYXRhCiAqCiAqIENvbXBh cmUgY2FsbGJhY2sgZm9yIHRoZSB4bWxMaXN0LgogKgogKiBSZXR1cm5zIC0xLCAwLCAxCiAqLwpz dGF0aWMgaW50CnhtbENtcFRleHRXcml0ZXJOc1N0YWNrRW50cnkoY29uc3Qgdm9pZCAqZGF0YTAs IGNvbnN0IHZvaWQgKmRhdGExKQp7CiAgICB4bWxUZXh0V3JpdGVyTnNTdGFja0VudHJ5ICpwMDsK ICAgIHhtbFRleHRXcml0ZXJOc1N0YWNrRW50cnkgKnAxOwogICAgaW50IHJjOwoKICAgIGlmIChk YXRhMCA9PSBkYXRhMSkKICAgICAgICByZXR1cm4gMDsKCiAgICBpZiAoZGF0YTAgPT0gMCkKICAg ICAgICByZXR1cm4gLTE7CgogICAgaWYgKGRhdGExID09IDApCiAgICAgICAgcmV0dXJuIDE7Cgog ICAgcDAgPSAoeG1sVGV4dFdyaXRlck5zU3RhY2tFbnRyeSAqKSBkYXRhMDsKICAgIHAxID0gKHht bFRleHRXcml0ZXJOc1N0YWNrRW50cnkgKikgZGF0YTE7CgogICAgcmMgPSB4bWxTdHJjbXAocDAt PnByZWZpeCwgcDEtPnByZWZpeCk7CgogICAgaWYgKHJjID09IDApCiAgICAgICAgcmMgPSBwMC0+ ZWxlbSA9PSBwMS0+ZWxlbTsKCiAgICByZXR1cm4gcmM7Cn0KCi8qKgogKiB4bWxUZXh0V3JpdGVy V3JpdGVNZW1DYWxsYmFjazoKICogQGNvbnRleHQ6ICB0aGUgeG1sQnVmZmVyUHRyCiAqIEBzdHI6 ICB0aGUgZGF0YSB0byB3cml0ZQogKiBAbGVuOiAgdGhlIGxlbmd0aCBvZiB0aGUgZGF0YQogKgog KiBXcml0ZSBjYWxsYmFjayBmb3IgdGhlIHhtbE91dHB1dEJ1ZmZlciB3aXRoIHRhcmdldCB4bWxC dWZmZXIKICoKICogUmV0dXJucyAtMSwgMCwgMQogKi8Kc3RhdGljIGludAp4bWxUZXh0V3JpdGVy V3JpdGVNZW1DYWxsYmFjayh2b2lkICpjb250ZXh0LCBjb25zdCB4bWxDaGFyICogc3RyLCBpbnQg bGVuKQp7CiAgICB4bWxCdWZmZXJQdHIgYnVmID0gKHhtbEJ1ZmZlclB0cikgY29udGV4dDsKCiAg ICB4bWxCdWZmZXJBZGQoYnVmLCBzdHIsIGxlbik7CgogICAgcmV0dXJuIGxlbjsKfQoKLyoqCiAq IHhtbFRleHRXcml0ZXJDbG9zZU1lbUNhbGxiYWNrOgogKiBAY29udGV4dDogIHRoZSB4bWxCdWZm ZXJQdHIKICoKICogQ2xvc2UgY2FsbGJhY2sgZm9yIHRoZSB4bWxPdXRwdXRCdWZmZXIgd2l0aCB0 YXJnZXQgeG1sQnVmZmVyCiAqCiAqIFJldHVybnMgLTEsIDAsIDEKICovCnN0YXRpYyBpbnQKeG1s VGV4dFdyaXRlckNsb3NlTWVtQ2FsbGJhY2sodm9pZCAqY29udGV4dCkKewogICAgcmV0dXJuIDA7 Cn0KCi8qKgogKiB4bWxUZXh0V3JpdGVyVlNwcmludGY6CiAqIEBmb3JtYXQ6ICBzZWUgcHJpbnRm CiAqIEBhcmdwdHI6ICBwb2ludGVyIHRvIHRoZSBmaXJzdCBtZW1iZXIgb2YgdGhlIHZhcmlhYmxl IGFyZ3VtZW50IGxpc3QuCiAqCiAqIFV0aWxpdHkgZnVuY3Rpb24gZm9yIGZvcm1hdHRlZCBvdXRw dXQKICoKICogUmV0dXJucyBhIG5ldyB4bWxDaGFyIGJ1ZmZlciB3aXRoIHRoZSBkYXRhIG9yIE5V TEwgb24gZXJyb3IuIFRoaXMgYnVmZmVyIG11c3QgYmUgZnJlZWQuCiAqLwpzdGF0aWMgeG1sQ2hh ciAqCnhtbFRleHRXcml0ZXJWU3ByaW50Zihjb25zdCBjaGFyICpmb3JtYXQsIHZhX2xpc3QgYXJn cHRyKQp7CiAgICBpbnQgc2l6ZTsKICAgIGludCBjb3VudDsKICAgIHhtbENoYXIgKmJ1ZjsKCiAg ICBzaXplID0gQlVGU0laOwogICAgYnVmID0gKHhtbENoYXIgKikgeG1sTWFsbG9jKHNpemUpOwog ICAgaWYgKGJ1ZiA9PSBOVUxMKSB7CiAgICAgICAgeG1sR2VuZXJpY0Vycm9yKHhtbEdlbmVyaWNF cnJvckNvbnRleHQsCiAgICAgICAgICAgICAgICAgICAgICAgICJ4bWxUZXh0V3JpdGVyVlNwcmlu dGYgOiBvdXQgb2YgbWVtb3J5IVxuIik7CiAgICAgICAgcmV0dXJuIE5VTEw7CiAgICB9CgogICAg d2hpbGUgKCgoY291bnQgPSB2c25wcmludGYoKGNoYXIgKikgYnVmLCBzaXplLCBmb3JtYXQsIGFy Z3B0cikpIDwgMCkKICAgICAgICAgICB8fCAoY291bnQgPT0gc2l6ZSAtIDEpIHx8IChjb3VudCA9 PSBzaXplKSB8fCAoY291bnQgPiBzaXplKSkgewogICAgICAgIHhtbEZyZWUoYnVmKTsKICAgICAg ICBzaXplICs9IEJVRlNJWjsKICAgICAgICBidWYgPSAoeG1sQ2hhciAqKSB4bWxNYWxsb2Moc2l6 ZSk7CiAgICAgICAgaWYgKGJ1ZiA9PSBOVUxMKSB7CiAgICAgICAgICAgIHhtbEdlbmVyaWNFcnJv cih4bWxHZW5lcmljRXJyb3JDb250ZXh0LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgInht bFRleHRXcml0ZXJWU3ByaW50ZiA6IG91dCBvZiBtZW1vcnkhXG4iKTsKICAgICAgICAgICAgcmV0 dXJuIE5VTEw7CiAgICAgICAgfQogICAgfQoKICAgIHJldHVybiBidWY7Cn0K ------=_NextPart_000_48EAD_01C39748.E420F330-- From Eric.Zurcher@csiro.au Mon Oct 20 19:56:24 2003 Return-Path: Delivered-To: xml@gnome.org Received: from csiromail1.act.csiro.au (csiromail1.act.csiro.au [152.83.2.12]) by mail.gnome.org (Postfix) with ESMTP id E9E581853C for ; Mon, 20 Oct 2003 19:56:23 -0400 (EDT) Received: from csiromail1.act.csiro.au (unknown [127.0.0.1]) by localhost.csiro.au (Postfix) with ESMTP id D62E81381F1 for ; Mon, 20 Oct 2003 23:56:37 +0000 (UTC) Received: from gencom-bp.pi.csiro.au (gencom-bp.pi.csiro.au [152.83.161.191]) by csiromail1.act.csiro.au (Postfix) with ESMTP id CA4711381F0 for ; Tue, 21 Oct 2003 09:56:37 +1000 (EST) Received: by gencom-bp.pi.csiro.au with Internet Mail Service (5.5.2657.72) id <406RBY99>; Tue, 21 Oct 2003 09:56:37 +1000 Message-ID: <248A74B34CC6514B8461EB0C481773D40449EA@gencom-bp.pi.csiro.au> From: Eric.Zurcher@csiro.au To: xml@gnome.org Date: Tue, 21 Oct 2003 09:56:37 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: [xml] Very minor patch for tree.c Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: There's a trivial error in tree.c that shows up when LIBXML_HTML_ENABLED is not defined - the node parameter is omitted in the call to xmlSaveErr. Cut between the "++++" lines for a patch. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Index: tree.c =================================================================== RCS file: /cvs/gnome/gnome-xml/tree.c,v retrieving revision 1.289 diff -u -r1.289 tree.c --- tree.c 19 Oct 2003 21:47:14 -0000 1.289 +++ tree.c 20 Oct 2003 23:51:17 -0000 @@ -7208,7 +7208,7 @@ #ifdef LIBXML_HTML_ENABLED htmlNodeDumpOutput(outbuf, doc, cur, NULL); #else - xmlSaveErr(XML_ERR_INTERNAL_ERROR, "HTML support not compiled in\n"); + xmlSaveErr(XML_ERR_INTERNAL_ERROR, cur, "HTML support not compiled in\n"); #endif /* LIBXML_HTML_ENABLED */ } else xmlNodeDumpOutput(outbuf, doc, cur, 0, 1, NULL); +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Eric Zurcher CSIRO Livestock Industries Canberra, Australia Eric.Zurcher@csiro.au From Eric.Zurcher@csiro.au Mon Oct 20 20:05:40 2003 Return-Path: Delivered-To: xml@gnome.org Received: from csiromail2.act.csiro.au (csiromail2.act.csiro.au [152.83.2.13]) by mail.gnome.org (Postfix) with ESMTP id 8CCC51811B for ; Mon, 20 Oct 2003 20:05:39 -0400 (EDT) Received: from csiromail2.act.csiro.au (unknown [127.0.0.1]) by localhost.csiro.au (Postfix) with ESMTP id DEA9E138226 for ; Tue, 21 Oct 2003 00:05:54 +0000 (UTC) Received: from gencom-bp.pi.csiro.au (gencom-bp.pi.csiro.au [152.83.161.191]) by csiromail2.act.csiro.au (Postfix) with ESMTP id D2E16138073 for ; Tue, 21 Oct 2003 10:05:54 +1000 (EST) Received: by gencom-bp.pi.csiro.au with Internet Mail Service (5.5.2657.72) id <406RBY05>; Tue, 21 Oct 2003 10:05:54 +1000 Message-ID: <248A74B34CC6514B8461EB0C481773D40449EB@gencom-bp.pi.csiro.au> From: Eric.Zurcher@csiro.au To: xml@gnome.org Date: Tue, 21 Oct 2003 10:05:54 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: [xml] Very minor patch for xmlIO.c Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: There's a trivial error in xmlIO.c that shows up when LIBXML_HTTP_ENABLED is not defined - the variable "is_http_uri" is referenced in several places, but its declaration (and definition) is conditionally removed. One could either make the definition unconditional, or exclude the references to it conditionally. I chose the former approach. Cut between the "++++" lines for a patch. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Index: xmlIO.c =================================================================== RCS file: /cvs/gnome/gnome-xml/xmlIO.c,v retrieving revision 1.131 diff -u -r1.131 xmlIO.c --- xmlIO.c 19 Oct 2003 21:59:17 -0000 1.131 +++ xmlIO.c 20 Oct 2003 23:59:09 -0000 @@ -2187,9 +2187,7 @@ void *context = NULL; char *unescaped; -#ifdef LIBXML_HTTP_ENABLED int is_http_uri = 0; /* Can't change if HTTP disabled */ -#endif if (xmlOutputCallbackInitialized == 0) xmlRegisterDefaultOutputCallbacks();++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++ Eric Zurcher CSIRO Livestock Industries Canberra, Australia Eric.Zurcher@csiro.au From veillard@redhat.com Mon Oct 20 20:16:01 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 8F4001840E for ; Mon, 20 Oct 2003 20:16:01 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9L0GDZ29254; Mon, 20 Oct 2003 20:16:13 -0400 Date: Mon, 20 Oct 2003 20:16:13 -0400 From: Daniel Veillard To: Eric.Zurcher@csiro.au Cc: xml@gnome.org Subject: Re: [xml] Very minor patch for tree.c Message-ID: <20031020201613.V16905@redhat.com> Reply-To: veillard@redhat.com References: <248A74B34CC6514B8461EB0C481773D40449EA@gencom-bp.pi.csiro.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <248A74B34CC6514B8461EB0C481773D40449EA@gencom-bp.pi.csiro.au>; from Eric.Zurcher@csiro.au on Tue, Oct 21, 2003 at 09:56:37AM +1000 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Tue, Oct 21, 2003 at 09:56:37AM +1000, Eric.Zurcher@csiro.au wrote: > > There's a trivial error in tree.c that shows up when LIBXML_HTML_ENABLED is > not defined - the node parameter is omitted in the call to xmlSaveErr. Cut > between the "++++" lines for a patch. 2 minutes later it would have missed the 2.6.0 train :-) applied and commited, thanks Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard@redhat.com Mon Oct 20 20:17:27 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 1E6C71840E for ; Mon, 20 Oct 2003 20:17:27 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9L0Hdf29703; Mon, 20 Oct 2003 20:17:39 -0400 Date: Mon, 20 Oct 2003 20:17:39 -0400 From: Daniel Veillard To: Eric.Zurcher@csiro.au Cc: xml@gnome.org Subject: Re: [xml] Very minor patch for xmlIO.c Message-ID: <20031020201739.W16905@redhat.com> Reply-To: veillard@redhat.com References: <248A74B34CC6514B8461EB0C481773D40449EB@gencom-bp.pi.csiro.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <248A74B34CC6514B8461EB0C481773D40449EB@gencom-bp.pi.csiro.au>; from Eric.Zurcher@csiro.au on Tue, Oct 21, 2003 at 10:05:54AM +1000 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Tue, Oct 21, 2003 at 10:05:54AM +1000, Eric.Zurcher@csiro.au wrote: > > There's a trivial error in xmlIO.c that shows up when LIBXML_HTTP_ENABLED is > not defined - > the variable "is_http_uri" is referenced in several places, but its > declaration (and definition) is conditionally removed. One could either make > the definition unconditional, or exclude the references to it conditionally. > I chose the former approach. Cut between the "++++" lines for a patch. This one missed the train ! Though I think I fixed it in CVS earlier today, well check against 2.6.0 when it gets available :-) Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard@redhat.com Mon Oct 20 21:03:53 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 8726D185BB for ; Mon, 20 Oct 2003 21:03:53 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9L149I15265 for xml@gnome.org; Mon, 20 Oct 2003 21:04:09 -0400 Date: Mon, 20 Oct 2003 21:04:09 -0400 From: Daniel Veillard To: xml@gnome.org Message-ID: <20031020210409.X16905@redhat.com> Reply-To: veillard@redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i Subject: [xml] Release of libxml2-2.6.0 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Yesssss ! The dragon is out and alive, ftp://xmlsoft.org/ http://xmlsoft.org/ This is the biggest release of libxml2 ever generated in term of objectives, amount of work, number of people involved, line of code changed, API additions, and performance gains. The full ChangeLog are huge, over a thousand lines, here is a condensed version, I hope I didn't forgot to many thing: - Major revision release: should be API and ABI compatible but got a lot of change - Increased the library modularity, far more options can be stripped out, a --with-minimum configuration will weight around 160KBytes - Use per parser and per document dictionnary, allocate names and small text nodes from the dictionnary - Switch to a SAX2 like parser rewrote most of the XML parser core, provides namespace resolution and defaulted attributes, minimize memory allocations and copies, namespace checking and specific error handling, immutable buffers, make predefined entities static structures, etc... - rewrote all the error handling in the library, all errors can be intercepted at a structured level, with precise information available. - New simpler and more generic XML and HTML parser APIs, allowing to easilly modify the parsing options and reuse parser context for multiple consecutive documents. - Similar new APIs for the xmlReader, for options and reuse, provided new functions to access content as const strings, use them for Python bindings - a lot of other smaller API improvements: xmlStrPrintf (Aleksey Sanin), Walker i.e. reader on a document tree based on Alfred Mickautsch code, make room in nodes for line numbers, reference counting and future PSVI extensions, generation of character ranges to be checked with faster algorithm (William), xmlParserMaxDepth (Crutcher Dunnavant), buffer access - New xmlWriter API provided by Alfred Mickautsch - Schemas: base64 support by Anthony Carrico - Parser<->HTTP integration fix, proper processing of the Mime-Type and charset informations if available. - Relax-NG: bug fixes including the one reported by Martijn Faassen and zeroOrMore, better error reporting. - Python bindings (Stéphane Bidoul), never use stdout for errors output - Portability: all the headers have macros for export and calling convention definitions (Igor Zlatkovic), VMS update (Craig A. Berry), Windows: threads (Jesse Pelton), Borland compiler (Eric Zurcher, Igor), Mingw (Igor), typos (Mark Vakoc), beta version (Stephane Bidoul), warning cleanups on AIX and MIPS compilers (William Brack), BeOS (Marcin 'Shard' Konicki) - Documentation fixes and README (William Brack), search fix (William), tutorial updates (John Fleck), namespace docs (Stefan Kost) - Bug fixes: xmlCleanupParser (Dave Beckett), threading uninitialized mutexes, HTML doctype lowercase, SAX/IO (William), compression detection and restore (William), attribute declaration in DTDs (William), namespace on attribute in HTML output (William), input filename (Rob Richards), namespace DTD validation, xmlReplaceNode (Chris Ryland), I/O callbacks (Markus Keim), CDATA serialization (Shaun McCance), xmlReader (Peter Derr), high codepoint charref like 􏿿, buffer access in push mode (Justin Fletcher), TLS threads on Windows (Jesse Pelton), XPath bug (William), xmlCleanupParser (Marc Liyanage), CDATA output (William), HTTP error handling. - xmllint options: --dtdvalidfpi for Tobias Reif, --sax1 for compat testing, --nodict for building without tree dictionnary, --nocdata to replace CDATA by text, --nsclean to remove surperfluous namespace declarations - added xml2-config --libtool-libs option from Kevin P. Fleming - a lot of profiling and tuning of the code, speedup patch for xmlSearchNs() by Luca Padovani. The xmlReader should do far less allocation and it speed should get closer to SAX. Chris Anderson worked on speeding and cleaning up repetitive checking code. - cleanup of "make tests" - libxml-2.0-uninstalled.pc from Malcolm Tredinnick - deactivated the broken docBook SGML parser code and plugged the XML parser instead. there is still some work needed like: + documentation for all the new APIs + python bindings improvements (error handler, xmlWriter) + work toward new specifications like XML-1.1, XPath 2.0, etc ... + a number of bugs which were reported have not yet been fixed. and of course considering the size of the changes I expect a new batch of bugs to show up, but I feel quite better with the new framework ! Enjoy ! Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From h.shibuya@vertexsystems.co.jp Mon Oct 20 21:26:12 2003 Return-Path: Delivered-To: xml@gnome.org Received: from ssemail007.crayfish.net (ssemail007.crayfish.net [210.172.136.3]) by mail.gnome.org (Postfix) with ESMTP id B9EED1821E for ; Mon, 20 Oct 2003 21:26:11 -0400 (EDT) Received: from Dimension4500C (h084.p464.iij4u.or.jp [210.149.208.84]) by ssemail007.crayfish.net (8.9.3p2/3.7W Crayfish POPbeforeSMTP'd) with ESMTP id KAA05638; Tue, 21 Oct 2003 10:26:23 +0900 (JST) From: "Shibuya" To: Cc: Subject: RE: [xml] cannot open include file . xmlwin32version.h Date: Tue, 21 Oct 2003 10:26:19 +0900 Message-ID: <000801c39772$57a82890$1a01a8c0@Dimension4500C> MIME-Version: 1.0 Content-Type: text/plain; charset="shift_jis" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <20031020031604.O16905@redhat.com> Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: =81=84On Mon, Oct 20, 2003 at 03:59:17PM +0900, Shibuya wrote: =81=84> Although I compiled the sauce of libxml, the error message=20 =81=84"can't open=20 =81=84> include file. ../../include/libxml/xmlwin32version.h" comes=20 =81=84out of me.=20 =81=84> Surely the file xmlwin32version.h is not found in source. =81=84 =81=84 What version, what platform, what compiler, what module=20 =81=84raises this error ? I don't see how any code in libxml2 can=20 =81=84address the header with=20 =81=84 "../../include/libxml/xmlwin32version.h" =81=84I never use local include addressing in the source code ! =81=84 =81=84Daniel =81=84 =81=84--=20 Sorry.I had forgotten to write a version. The version is libxml2-2.5.11. From aleksey@aleksey.com Mon Oct 20 22:58:28 2003 Return-Path: Delivered-To: xml@gnome.org Received: from shell.aleksey.com (dsl093-129-176.sfo4.dsl.speakeasy.net [66.93.129.176]) by mail.gnome.org (Postfix) with ESMTP id A7B181836A for ; Mon, 20 Oct 2003 22:58:28 -0400 (EDT) Received: from aleksey.com (unknown [192.168.1.63]) by shell.aleksey.com (Postfix) with ESMTP id 8373CB5BA; Mon, 20 Oct 2003 19:58:44 -0700 (PDT) Message-ID: <3F94A0DF.2090604@aleksey.com> Date: Mon, 20 Oct 2003 19:58:39 -0700 From: Aleksey Sanin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, ru MIME-Version: 1.0 To: veillard@redhat.com Cc: xml@gnome.org Subject: Re: [xml] Release of libxml2-2.6.0 References: <20031020210409.X16905@redhat.com> In-Reply-To: <20031020210409.X16905@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: > Yesssss ! The dragon is out and alive, > And it's a pretty good dragon! Compiled and tested new libxml2 with xmlsec on RH 9.0 and everything looks very good! - No compilation errors/warnings. - All functional tests pass. - Valgrind shows no new errors (I always see UMRs in low level crypto code). - Performance test shows about 10-15% speed increase for most of the test cases with average increase across all tests equal to 8.5%. Thanks for great work! Aleksey From h.shibuya@vertexsystems.co.jp Mon Oct 20 23:31:46 2003 Return-Path: Delivered-To: xml@gnome.org Received: from ssemail007.crayfish.net (ssemail007.crayfish.net [210.172.136.3]) by mail.gnome.org (Postfix) with ESMTP id CC75118109 for ; Mon, 20 Oct 2003 23:31:45 -0400 (EDT) Received: from Dimension4500C (h084.p464.iij4u.or.jp [210.149.208.84]) by ssemail007.crayfish.net (8.9.3p2/3.7W Crayfish POPbeforeSMTP'd) with ESMTP id MAA01074; Tue, 21 Oct 2003 12:31:56 +0900 (JST) From: "Shibuya" To: "'Igor Zlatkovic'" Cc: Subject: RE: [xml] cannot open include file . xmlwin32version.h Date: Tue, 21 Oct 2003 12:31:48 +0900 Message-ID: <001401c39783$defbcde0$1a01a8c0@Dimension4500C> MIME-Version: 1.0 Content-Type: text/plain; charset="shift_jis" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <3F93BB0E.1080903@zlatkovic.com> Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: =81=84Shibuya wrote: =81=84> Although I compiled the sauce of libxml, the error message=20 =81=84"can't open=20 =81=84> include file. ../../include/libxml/xmlwin32version.h" comes=20 =81=84out of me. =81=84 =81=84You compiled a sauce of libxml, now that's nice. The=20 =81=84application in the=20 =81=84kitchen is surely new to all of us. Can we have a recipe?=20 =81=84Goes with fish,=20 =81=84meat or vegetables? =81=84 =81=84If your body produces error messages of the sort, it is=20 =81=84strange, I have=20 =81=84never seen the like of it before. I know few things about=20 =81=84computer-generated=20 =81=84 error messages, but those coming out of you are are perhaps=20 =81=84in the health=20 =81=84domain, no? =81=84 =81=84:-) Sorry. I should keep silent sometimes... :-) :-) =81=84 =81=84Ciao, =81=84Igor I got new version(2.6) & compiled it with VC7. However, it displayed many error messages. ../include/libxml/xmlversion.h(127) : error C2018: The character '0x40' cannot be recognized.=20 The Unicode discernment child is not supported.=20 (Since this translated into English, display purport of a letter is not the same.) ../include/libxml/encoding.h(27) : fatal error C1083: cannot open include file. 'iconv.h' :No such file or directory. .etc...:-<) It is more desirable to offer a project file (.proj or.sln) individually. From bauch@struktur.de Tue Oct 21 04:17:43 2003 Return-Path: Delivered-To: xml@gnome.org Received: from amun.struktur.de (ns1.struktur.de [213.61.168.254]) by mail.gnome.org (Postfix) with ESMTP id D8F9618110 for ; Tue, 21 Oct 2003 04:17:40 -0400 (EDT) Received: (qmail 28287 invoked by uid 5004); 21 Oct 2003 08:17:58 -0000 Received: from bauch@struktur.de by amun by uid 5001 with qmail-scanner-1.20rc1 (sweep: 2.14/3.69. spamassassin: 2.44. Clear:RC:1:. Processed in 0.694291 secs); 21 Oct 2003 08:17:58 -0000 X-Qmail-Scanner-Mail-From: bauch@struktur.de via amun X-Qmail-Scanner: 1.20rc1 (Clear:RC:1:. Processed in 0.694291 secs) Received: from radon.struktur.de (HELO radon) ([10.1.1.67]) (envelope-sender ) by amun.struktur.de (qmail-ldap-1.03) with SMTP for ; 21 Oct 2003 08:17:57 -0000 Date: Tue, 21 Oct 2003 10:18:34 +0200 To: veillard@redhat.com Subject: Re: [xml] Release of libxml2-2.6.0 References: <20031020210409.X16905@redhat.com> Cc: xml@gnome.org From: Joachim Bauch Organization: struktur AG Content-Type: multipart/mixed; boundary="----------VdJ8na7VPYfWwnEMn0ue8y" MIME-Version: 1.0 Message-ID: In-Reply-To: <20031020210409.X16905@redhat.com> User-Agent: Opera7.11/Win32 M2 build 2887 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: ------------VdJ8na7VPYfWwnEMn0ue8y Content-Type: text/plain; charset=utf-8; format=flowed Hi Daniel! On Mon, 20 Oct 2003 21:04:09 -0400, Daniel Veillard wrote: > Yesssss ! The dragon is out and alive, First of all, thanks for this great new release. Attached you can find a patch against the CVS version, that fixes some issues with compiling with MSVC on Windows: - allowes you to configure the usage of the xmlWriter interface (configure.js) - adds missing file for character validation to Makefile (chvalid.obj) Greetings, Joachim -- Joachim Bauch struktur AG Fon.: +49 (0)711 896656 69 Junghansstr. 5 Fax.: +49 (0)711 896656 10 D-70469 Stuttgart eMail: bauch@struktur.de solutions for Germany Web: http://www.struktur.de digital business Download icoya OpenContent 1.3 for FREE! visit http://www.icoya.de/iOC4free <- ------------VdJ8na7VPYfWwnEMn0ue8y Content-Disposition: attachment; filename="win32_configs.diff" Content-Type: application/octet-stream; name="win32_configs.diff" Content-Transfer-Encoding: Base64 SW5kZXg6IHdpbjMyL01ha2VmaWxlLmJjYg0KPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQ0KUkNTIGZpbGU6IC9jdnMvZ25vbWUvZ25vbWUteG1sL3dpbjMyL01h a2VmaWxlLmJjYix2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMw0KZGlmZiAt YyAtcjEuMyBNYWtlZmlsZS5iY2INCioqKiB3aW4zMi9NYWtlZmlsZS5iY2IJ NiBPY3QgMjAwMyAwODo0Nzo1NiAtMDAwMAkxLjMNCi0tLSB3aW4zMi9NYWtl ZmlsZS5iY2IJMjEgT2N0IDIwMDMgMDg6MTI6NTEgLTAwMDANCioqKioqKioq KioqKioqKg0KKioqIDE0OCwxNTMgKioqKg0KLS0tIDE0OCwxNTQgLS0tLQ0K ICAjIExpYnhtbCBvYmplY3QgZmlsZXMuDQogIFhNTF9PQkpTID0gJChYTUxf SU5URElSKVxjMTRuLm9ialwNCiAgCSQoWE1MX0lOVERJUilcY2F0YWxvZy5v YmpcDQorIAkkKFhNTF9JTlRESVIpXGNodmFsaWQub2JqXA0KICAJJChYTUxf SU5URElSKVxkZWJ1Z1hNTC5vYmpcDQogIAkkKFhNTF9JTlRESVIpXGRpY3Qu b2JqXA0KICAJJChYTUxfSU5URElSKVxET0NCcGFyc2VyLm9ialwNCioqKioq KioqKioqKioqKg0KKioqIDE4NiwxOTEgKioqKg0KLS0tIDE4NywxOTMgLS0t LQ0KICAjIFN0YXRpYyBsaWJ4bWwgb2JqZWN0IGZpbGVzLg0KICBYTUxfT0JK U19BID0gJChYTUxfSU5URElSX0EpXGMxNG4ub2JqXA0KICAJJChYTUxfSU5U RElSX0EpXGNhdGFsb2cub2JqXA0KKyAJJChYTUxfSU5URElSX0EpXGNodmFs aWQub2JqXA0KICAJJChYTUxfSU5URElSX0EpXGRlYnVnWE1MLm9ialwNCiAg CSQoWE1MX0lOVERJUl9BKVxkaWN0Lm9ialwNCiAgCSQoWE1MX0lOVERJUl9B KVxET0NCcGFyc2VyLm9ialwNCkluZGV4OiB3aW4zMi9NYWtlZmlsZS5taW5n dw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC9jdnMvZ25v bWUvZ25vbWUteG1sL3dpbjMyL01ha2VmaWxlLm1pbmd3LHYNCnJldHJpZXZp bmcgcmV2aXNpb24gMS4xMg0KZGlmZiAtYyAtcjEuMTIgTWFrZWZpbGUubWlu Z3cNCioqKiB3aW4zMi9NYWtlZmlsZS5taW5ndwk2IE9jdCAyMDAzIDA4OjQ3 OjU2IC0wMDAwCTEuMTINCi0tLSB3aW4zMi9NYWtlZmlsZS5taW5ndwkyMSBP Y3QgMjAwMyAwODoxMjo1MSAtMDAwMA0KKioqKioqKioqKioqKioqDQoqKiog MTM4LDE0MyAqKioqDQotLS0gMTM4LDE0NCAtLS0tDQogICMgTGlieG1sIG9i amVjdCBmaWxlcy4NCiAgWE1MX09CSlMgPSAkKFhNTF9JTlRESVIpL2MxNG4u b1wNCiAgCSQoWE1MX0lOVERJUikvY2F0YWxvZy5vXA0KKyAJJChYTUxfSU5U RElSKS9jaHZhbGlkLm9ialwNCiAgCSQoWE1MX0lOVERJUikvZGVidWdYTUwu b1wNCiAgCSQoWE1MX0lOVERJUikvZGljdC5vXA0KICAJJChYTUxfSU5URElS KS9ET0NCcGFyc2VyLm9cDQoqKioqKioqKioqKioqKioNCioqKiAxNzgsMTgz ICoqKioNCi0tLSAxNzksMTg1IC0tLS0NCiAgIyBTdGF0aWMgbGlieG1sIG9i amVjdCBmaWxlcy4NCiAgWE1MX09CSlNfQSA9ICQoWE1MX0lOVERJUl9BKS9j MTRuLm9cDQogIAkkKFhNTF9JTlRESVJfQSkvY2F0YWxvZy5vXA0KKyAJJChY TUxfSU5URElSX0EpL2NodmFsaWQub2JqXA0KICAJJChYTUxfSU5URElSX0Ep L2RlYnVnWE1MLm9cDQogIAkkKFhNTF9JTlRESVJfQSkvZGljdC5vXA0KICAJ JChYTUxfSU5URElSX0EpL0RPQ0JwYXJzZXIub1wNCkluZGV4OiB3aW4zMi9N YWtlZmlsZS5tc3ZjDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmls ZTogL2N2cy9nbm9tZS9nbm9tZS14bWwvd2luMzIvTWFrZWZpbGUubXN2Yyx2 DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMTUNCmRpZmYgLWMgLXIxLjE1IE1h a2VmaWxlLm1zdmMNCioqKiB3aW4zMi9NYWtlZmlsZS5tc3ZjCTYgT2N0IDIw MDMgMDg6NDc6NTYgLTAwMDAJMS4xNQ0KLS0tIHdpbjMyL01ha2VmaWxlLm1z dmMJMjEgT2N0IDIwMDMgMDg6MTI6NTEgLTAwMDANCioqKioqKioqKioqKioq Kg0KKioqIDEyNywxMzIgKioqKg0KLS0tIDEyNywxMzMgLS0tLQ0KICAjIExp YnhtbCBvYmplY3QgZmlsZXMuDQogIFhNTF9PQkpTID0gJChYTUxfSU5URElS KVxjMTRuLm9ialwNCiAgCSQoWE1MX0lOVERJUilcY2F0YWxvZy5vYmpcDQor IAkkKFhNTF9JTlRESVIpXGNodmFsaWQub2JqXA0KICAJJChYTUxfSU5URElS KVxkZWJ1Z1hNTC5vYmpcDQogIAkkKFhNTF9JTlRESVIpXGRpY3Qub2JqXA0K ICAJJChYTUxfSU5URElSKVxET0NCcGFyc2VyLm9ialwNCioqKioqKioqKioq KioqKg0KKioqIDE2NSwxNzAgKioqKg0KLS0tIDE2NiwxNzIgLS0tLQ0KICAj IFN0YXRpYyBsaWJ4bWwgb2JqZWN0IGZpbGVzLg0KICBYTUxfT0JKU19BID0g JChYTUxfSU5URElSX0EpXGMxNG4ub2JqXA0KICAJJChYTUxfSU5URElSX0Ep XGNhdGFsb2cub2JqXA0KKyAJJChYTUxfSU5URElSX0EpXGNodmFsaWQub2Jq XA0KICAJJChYTUxfSU5URElSX0EpXGRlYnVnWE1MLm9ialwNCiAgCSQoWE1M X0lOVERJUl9BKVxkaWN0Lm9ialwNCiAgCSQoWE1MX0lOVERJUl9BKVxET0NC cGFyc2VyLm9ialwNCkluZGV4OiB3aW4zMi9jb25maWd1cmUuanMNCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0NClJDUyBmaWxlOiAvY3ZzL2dub21lL2dub21l LXhtbC93aW4zMi9jb25maWd1cmUuanMsdg0KcmV0cmlldmluZyByZXZpc2lv biAxLjIyDQpkaWZmIC1jIC1yMS4yMiBjb25maWd1cmUuanMNCioqKiB3aW4z Mi9jb25maWd1cmUuanMJNiBPY3QgMjAwMyAwODo0Nzo1NiAtMDAwMAkxLjIy DQotLS0gd2luMzIvY29uZmlndXJlLmpzCTIxIE9jdCAyMDAzIDA4OjEyOjUx IC0wMDAwDQoqKioqKioqKioqKioqKioNCioqKiA0Nyw1MiAqKioqDQotLS0g NDcsNTMgLS0tLQ0KICB2YXIgd2l0aFJlZ0V4cHMgPSB0cnVlOw0KICB2YXIg d2l0aFRyZWUgPSB0cnVlOw0KICB2YXIgd2l0aFJlYWRlciA9IHRydWU7DQor IHZhciB3aXRoV3JpdGVyID0gdHJ1ZTsNCiAgdmFyIHdpdGhXYWxrZXIgPSB0 cnVlOw0KICB2YXIgd2l0aFB1c2ggPSB0cnVlOw0KICB2YXIgd2l0aFZhbGlk ID0gdHJ1ZTsNCioqKioqKioqKioqKioqKg0KKioqIDEyMiwxMjcgKioqKg0K LS0tIDEyMywxMjkgLS0tLQ0KICAJdHh0ICs9ICIgIHJlZ2V4cHM6ICAgIEVu YWJsZSByZWd1bGFyIGV4cHJlc3Npb25zICgiICsgKHdpdGhSZWdFeHBzPyAi eWVzIiA6ICJubyIpICsgIilcbiI7DQogIAl0eHQgKz0gIiAgdHJlZTogICAg ICAgRW5hYmxlIHRyZWUgYXBpICgiICsgKHdpdGhUcmVlPyAieWVzIiA6ICJu byIpICsgIilcbiI7DQogIAl0eHQgKz0gIiAgcmVhZGVyOiAgICAgRW5hYmxl IHhtbFJlYWRlciBhcGkgKCIgKyAod2l0aFJlYWRlcj8gInllcyIgOiAibm8i KSArICIpXG4iOw0KKyAJdHh0ICs9ICIgIHdyaXRlcjogICAgIEVuYWJsZSB4 bWxXcml0ZXIgYXBpICgiICsgKHdpdGhXcml0ZXI/ICJ5ZXMiIDogIm5vIikg KyAiKVxuIjsNCiAgCXR4dCArPSAiICB3YWxrZXI6ICAgICBFbmFibGUgeG1s RG9jV2Fsa2VyIGFwaSAoIiArICh3aXRoV2Fsa2VyPyAieWVzIiA6ICJubyIp ICsgIilcbiI7DQogIAl0eHQgKz0gIiAgcHVzaDogICAgICAgRW5hYmxlIHB1 c2ggYXBpICgiICsgKHdpdGhQdXNoPyAieWVzIiA6ICJubyIpICsgIilcbiI7 DQogIAl0eHQgKz0gIiAgdmFsaWQ6ICAgICAgRW5hYmxlIERURCB2YWxpZGF0 aW9uIHN1cHBvcnQgKCIgKyAod2l0aFZhbGlkPyAieWVzIiA6ICJubyIpICsg IilcbiI7DQoqKioqKioqKioqKioqKioNCioqKiAyMDksMjE0ICoqKioNCi0t LSAyMTEsMjE3IC0tLS0NCiAgCXZmLldyaXRlTGluZSgiV0lUSF9SRUdFWFBT PSIgKyAod2l0aFJlZ0V4cHM/ICIxIiA6ICIwIikpOw0KICAJdmYuV3JpdGVM aW5lKCJXSVRIX1RSRUU9IiArICh3aXRoVHJlZT8gIjEiIDogIjAiKSk7DQog IAl2Zi5Xcml0ZUxpbmUoIldJVEhfUkVBREVSPSIgKyAod2l0aFJlYWRlcj8g IjEiIDogIjAiKSk7DQorIAl2Zi5Xcml0ZUxpbmUoIldJVEhfV1JJVEVSPSIg KyAod2l0aFdyaXRlcj8gIjEiIDogIjAiKSk7DQogIAl2Zi5Xcml0ZUxpbmUo IldJVEhfV0FMS0VSPSIgKyAod2l0aFdhbGtlcj8gIjEiIDogIjAiKSk7DQog IAl2Zi5Xcml0ZUxpbmUoIldJVEhfUFVTSD0iICsgKHdpdGhQdXNoPyAiMSIg OiAiMCIpKTsNCiAgCXZmLldyaXRlTGluZSgiV0lUSF9WQUxJRD0iICsgKHdp dGhWYWxpZD8gIjEiIDogIjAiKSk7DQoqKioqKioqKioqKioqKioNCioqKiAy OTMsMjk4ICoqKioNCi0tLSAyOTYsMzAzIC0tLS0NCiAgCQkJb2YuV3JpdGVM aW5lKHMucmVwbGFjZSgvXEBXSVRIX1RSRUVcQC8sIHdpdGhUcmVlPyAiMSIg OiAiMCIpKTsNCiAgCQl9IGVsc2UgaWYgKHMuc2VhcmNoKC9cQFdJVEhfUkVB REVSXEAvKSAhPSAtMSkgew0KICAJCQlvZi5Xcml0ZUxpbmUocy5yZXBsYWNl KC9cQFdJVEhfUkVBREVSXEAvLCB3aXRoUmVhZGVyPyAiMSIgOiAiMCIpKTsN CisgCQl9IGVsc2UgaWYgKHMuc2VhcmNoKC9cQFdJVEhfV1JJVEVSXEAvKSAh PSAtMSkgew0KKyAJCQlvZi5Xcml0ZUxpbmUocy5yZXBsYWNlKC9cQFdJVEhf V1JJVEVSXEAvLCB3aXRoV3JpdGVyPyAiMSIgOiAiMCIpKTsNCiAgCQl9IGVs c2UgaWYgKHMuc2VhcmNoKC9cQFdJVEhfV0FMS0VSXEAvKSAhPSAtMSkgew0K ICAJCQlvZi5Xcml0ZUxpbmUocy5yZXBsYWNlKC9cQFdJVEhfV0FMS0VSXEAv LCB3aXRoV2Fsa2VyPyAiMSIgOiAiMCIpKTsNCiAgCQl9IGVsc2UgaWYgKHMu c2VhcmNoKC9cQFdJVEhfUFVTSFxALykgIT0gLTEpIHsNCioqKioqKioqKioq KioqKg0KKioqIDQ0NCw0NDkgKioqKg0KLS0tIDQ0OSw0NTYgLS0tLQ0KICAJ CQl3aXRoVHJlZSA9IHN0clRvQm9vbChhcmcuc3Vic3RyaW5nKG9wdC5sZW5n dGggKyAxLCBhcmcubGVuZ3RoKSk7DQogIAkJZWxzZSBpZiAob3B0ID09ICJy ZWFkZXIiKQ0KICAJCQl3aXRoUmVhZGVyID0gc3RyVG9Cb29sKGFyZy5zdWJz dHJpbmcob3B0Lmxlbmd0aCArIDEsIGFyZy5sZW5ndGgpKTsNCisgCQllbHNl IGlmIChvcHQgPT0gIndyaXRlciIpDQorIAkJCXdpdGhXcml0ZXIgPSBzdHJU b0Jvb2woYXJnLnN1YnN0cmluZyhvcHQubGVuZ3RoICsgMSwgYXJnLmxlbmd0 aCkpOw0KICAJCWVsc2UgaWYgKG9wdCA9PSAid2Fsa2VyIikNCiAgCQkJd2l0 aFdhbGtlciA9IHN0clRvQm9vbChhcmcuc3Vic3RyaW5nKG9wdC5sZW5ndGgg KyAxLCBhcmcubGVuZ3RoKSk7DQogIAkJZWxzZSBpZiAob3B0ID09ICJwdXNo IikNCioqKioqKioqKioqKioqKg0KKioqIDU3OSw1ODQgKioqKg0KLS0tIDU4 Niw1OTIgLS0tLQ0KICB0eHRPdXQgKz0gIiAgICBSZWdleHAgc3VwcG9ydDog IiArIGJvb2xUb1N0cih3aXRoUmVnRXhwcykgKyAiXG4iOw0KICB0eHRPdXQg Kz0gIiAgICAgIFRyZWUgc3VwcG9ydDogIiArIGJvb2xUb1N0cih3aXRoVHJl ZSkgKyAiXG4iOw0KICB0eHRPdXQgKz0gIiAgICBSZWFkZXIgc3VwcG9ydDog IiArIGJvb2xUb1N0cih3aXRoUmVhZGVyKSArICJcbiI7DQorIHR4dE91dCAr PSAiICAgIFdyaXRlciBzdXBwb3J0OiAiICsgYm9vbFRvU3RyKHdpdGhXcml0 ZXIpICsgIlxuIjsNCiAgdHh0T3V0ICs9ICIgICAgV2Fsa2VyIHN1cHBvcnQ6 ICIgKyBib29sVG9TdHIod2l0aFdhbGtlcikgKyAiXG4iOw0KICB0eHRPdXQg Kz0gIiAgICAgIFB1c2ggc3VwcG9ydDogIiArIGJvb2xUb1N0cih3aXRoUHVz aCkgKyAiXG4iOw0KICB0eHRPdXQgKz0gIlZhbGlkYXRpb24gc3VwcG9ydDog IiArIGJvb2xUb1N0cih3aXRoVmFsaWQpICsgIlxuIjsNCg== ------------VdJ8na7VPYfWwnEMn0ue8y-- From veillard@redhat.com Tue Oct 21 05:27:55 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id E88451888F for ; Tue, 21 Oct 2003 05:27:54 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9L9S9427346; Tue, 21 Oct 2003 05:28:09 -0400 Date: Tue, 21 Oct 2003 05:28:09 -0400 From: Daniel Veillard To: Joachim Bauch Cc: xml@gnome.org Subject: Re: [xml] Release of libxml2-2.6.0 Message-ID: <20031021052809.Y16905@redhat.com> Reply-To: veillard@redhat.com References: <20031020210409.X16905@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from bauch@struktur.de on Tue, Oct 21, 2003 at 10:18:34AM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Tue, Oct 21, 2003 at 10:18:34AM +0200, Joachim Bauch wrote: > Attached you can find a patch against the CVS version, that fixes some issues with > compiling with MSVC on Windows: > - allowes you to configure the usage of the xmlWriter interface (configure.js) > - adds missing file for character validation to Makefile (chvalid.obj) okay, this looks good, applied and commited ! thanks, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From oliverst@online.de Tue Oct 21 09:09:52 2003 Return-Path: Delivered-To: xml@gnome.org Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mail.gnome.org (Postfix) with ESMTP id 139AC1816B for ; Tue, 21 Oct 2003 09:09:52 -0400 (EDT) Received: from [212.227.126.200] (helo=mrvnet.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1ABwGx-0007WC-01; Tue, 21 Oct 2003 15:10:03 +0200 Received: from [172.23.4.134] (helo=config7.kundenserver.de) by mrvnet.kundenserver.de with esmtp (Exim 3.35 #1) id 1ABwGw-0001DN-00; Tue, 21 Oct 2003 15:10:02 +0200 Received: from www-data by config7.kundenserver.de with local (Exim 3.35 #1 (Debian)) id 1ABwGw-0005iW-00; Tue, 21 Oct 2003 15:10:02 +0200 To: Subject: RE: [xml] cannot open include file . xmlwin32version.h From: Cc: Message-Id: <5074873$10667413103f952e3e653991.72661322@config7.schlund.de> X-Binford: 6100 (more power) X-Originating-From: 5074873 X-Mailer: Webmail X-Routing: DE X-Received: from config7 by 213.252.152.112 with HTTP id 5074873 for xml@gnome.org; Tue, 21 Oct 2003 15:08:03 +0200 Content-Type: text/plain; charset="iso-8859-1" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Priority: 3 Date: Tue, 21 Oct 2003 15:08:03 +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: > I got new version(2.6) & compiled it with VC7. However, it displayed > many error messages. > ../include/libxml/xmlversion.h(127) : error C2018: The character '0x40' cannot be recognized. I had the same problem, caused by a little bug in the configure.js, that put a define name in the xmlversion.h instead of a value (xmlWriter interface), was fixed in CVS earlier today > ../include/libxml/encoding.h(27) : fatal error C1083: cannot open include file. 'iconv.h' :No such file or directory. You have iconv support enabled, but you don't have the inconv sources. you should either disable it and get the sources and add the "include" dir of it to your project file > It is more desirable to offer a project file (.proj or.sln) individually. the files have been removed in the 2.6.0 release, because nobody felt like maintaining them and the "configure.js" script rendered them quite obsolete. try to run "cscript configure.js compiler=msvc iconv=no" and "nmake" after that in the win32 subfolder of the 2.6.0 distribution. I am just using MSVC 6. does the libxml2 even compile successfully with MSVC .NET 2002/2003? From steve.hay@uk.radan.com Tue Oct 21 10:44:15 2003 Return-Path: Delivered-To: xml@gnome.org Received: from radan.com (cerberus.radan.com [195.166.67.75]) by mail.gnome.org (Postfix) with ESMTP id EB1AA18949 for ; Tue, 21 Oct 2003 10:44:14 -0400 (EDT) Received: by radan.com; id PAA14552; Tue, 21 Oct 2003 15:44:18 +0100 (BST) Received: from sonicwall.radan.com(195.166.67.78) by cerberus.radan.com via csmap (V4.1) id srcAAAG3a4AC; Tue, 21 Oct 03 15:44:17 +0100 Organisation: Radan Computational Ltd., Bath, UK. Phone: +44 1225 320320 Fax: +44 1225 320311 Web: http://www.radan.com/ Received: from uk.radan.com (dhcp-b-13 [172.16.51.13]) by uk.radan.com (8.9.1b+Sun/8.9.1) with ESMTP id PAA23538; Tue, 21 Oct 2003 15:44:16 +0100 (BST) Message-ID: <3F9546DB.1070701@uk.radan.com> Date: Tue, 21 Oct 2003 15:46:51 +0100 From: Steve Hay User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: daniel@veillard.com Cc: xml@gnome.org References: <20031021135705.1200B40440@widget.gnome.org> In-Reply-To: <20031021135705.1200B40440@widget.gnome.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [xml] Re: [Bug 125110] Changed - libxml2 2.6.0 doesn't build on Windows Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi Daniel, bugzilla-daemon@widget.gnome.org wrote: >http://bugzilla.gnome.org/show_bug.cgi?id=125110 > > parser.obj : error LNK2001: unresolved external symbol _xmlCharInRange > parserInternals.obj : error LNK2001: unresolved external symbol _xmlCharInRange > binaries\libxml2.dll : fatal error LNK1120: 1 unresolved externals > > Regards, > - Steve >+ >+------- Additional Comments From daniel@veillard.com 2003-10-21 09:57 ------- >+Should be fixed in CVS, check the mailing list in case of Windows >+problems before reporting to bugzilla ! >+ >+Daniel > > My apologies - Guilty as charged. However, I still can't get at the change in question. The mailing list archive contains a message that included a patch, but the archive itself doesn't include the patch (http://mail.gnome.org/archives/xml/2003-October/msg00239.html)! I tried doing a CVS checkout, but that didn't seem to get the very latest version with that change in it. The command I used was: cvs -z3 -d :pserver:anonymous@anoncvs.gnome.org:/cvs/gnome co libxml2 Is that the correct address? I can see the change in the Bonsai viewer at, e.g. http://cvs.gnome.org/bonsai/cvslog.cgi?file=gnome-xml%2Fwin32/configure.js&rev=&root=/cvs/gnome so why doesn't the CVS checkout pick it up? Thanks, - Steve From veillard@veillard.com Tue Oct 21 11:15:18 2003 Return-Path: Delivered-To: xml@gnome.org Received: from veillard.com (veillard.com [82.67.66.12]) by mail.gnome.org (Postfix) with ESMTP id 6875B18776 for ; Tue, 21 Oct 2003 11:15:17 -0400 (EDT) Received: (from veillard@localhost) by veillard.com (8.11.6/8.11.2) id h9LFFHS08099; Tue, 21 Oct 2003 17:15:17 +0200 Date: Tue, 21 Oct 2003 17:15:17 +0200 From: Daniel Veillard To: Steve Hay Cc: daniel@veillard.com, xml@gnome.org Message-ID: <20031021151517.GJ17357@daniel.veillard.com> Reply-To: daniel@veillard.com References: <20031021135705.1200B40440@widget.gnome.org> <3F9546DB.1070701@uk.radan.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F9546DB.1070701@uk.radan.com> User-Agent: Mutt/1.4.1i Subject: [xml] Re: [Bug 125110] Changed - libxml2 2.6.0 doesn't build on Windows Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Tue, Oct 21, 2003 at 03:46:51PM +0100, Steve Hay wrote: > Hi Daniel, Hi Steve, ` > bugzilla-daemon@widget.gnome.org wrote: > > >http://bugzilla.gnome.org/show_bug.cgi?id=125110 > > > >parser.obj : error LNK2001: unresolved external symbol _xmlCharInRange > >parserInternals.obj : error LNK2001: unresolved external symbol > >_xmlCharInRange > >binaries\libxml2.dll : fatal error LNK1120: 1 unresolved externals > > > >Regards, > >- Steve > >+ > >+------- Additional Comments From daniel@veillard.com 2003-10-21 09:57 > >------- > >+Should be fixed in CVS, check the mailing list in case of Windows > >+problems before reporting to bugzilla ! > >+ > >+Daniel > > > > > My apologies - Guilty as charged. > > However, I still can't get at the change in question. The mailing list > archive contains a message that included a patch, but the archive itself > doesn't include the patch > (http://mail.gnome.org/archives/xml/2003-October/msg00239.html)! yes it's there win32_configs.diff link at the bottom > I tried doing a CVS checkout, but that didn't seem to get the very > latest version with that change in it. The command I used was: > > cvs -z3 -d :pserver:anonymous@anoncvs.gnome.org:/cvs/gnome co libxml2 > > Is that the correct address? yes but changes may take a little while for propagating to anonymous > so why doesn't the CVS checkout pick it up? because the anonymous cvs is on mirrors and propagation takes time, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | From kbuchcik@4commerce.de Tue Oct 21 11:41:52 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mx01.qsc.de (mx01.qsc.de [213.148.129.14]) by mail.gnome.org (Postfix) with ESMTP id 7F91418776 for ; Tue, 21 Oct 2003 11:41:52 -0400 (EDT) Received: from port-212-202-229-162.reverse.qsc.de ([212.202.229.162] helo=kisone) by mx01.qsc.de with smtp (Exim 3.35 #1) id 1ABye3-0003Qf-00 for xml@gnome.org; Tue, 21 Oct 2003 17:42:04 +0200 From: Kasimier Buchcik To: X-Priority: 3 Received: from emission [10.254.2.2] by kisone [10.254.2.2] with SMTP eMission ESMTPServer; Tue, 21 Oct 2003 17:35:07 +0200 Received: from 4commerce.de (10.1.72.2 [10.1.72.2]) by kisone.kisnet.de with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VJHJYGWB; Tue, 21 Oct 2003 17:35:07 +0200 Message-ID: <3F9552C5.1030805@4commerce.de> Date: Tue, 21 Oct 2003 17:37:41 +0200 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en References: <20031020210409.X16905@redhat.com> In-Reply-To: <20031020210409.X16905@redhat.com> X-eMessageService: eMission.SMTPServer Subject: "Re: [xml] Release of libxml2-2.6.0" Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi, Daniel wrote: > Yesssss ! The dragon is out and alive, hey cool! I was about to write some greasy words about how I like this=20 libxml2 & libxslt stuff, but I think I won't torture you with that :-) Nice to see this stuff+people out there. Greetings, Kasimier Buchcik From steve.hay@uk.radan.com Tue Oct 21 12:06:29 2003 Return-Path: Delivered-To: xml@gnome.org Received: from radan.com (cerberus.radan.com [195.166.67.75]) by mail.gnome.org (Postfix) with ESMTP id 9E843189B6 for ; Tue, 21 Oct 2003 12:06:28 -0400 (EDT) Received: by radan.com; id RAA15037; Tue, 21 Oct 2003 17:06:37 +0100 (BST) Received: from sonicwall.radan.com(195.166.67.78) by cerberus.radan.com via csmap (V4.1) id srcAAA5UaGxD; Tue, 21 Oct 03 17:06:36 +0100 Organisation: Radan Computational Ltd., Bath, UK. Phone: +44 1225 320320 Fax: +44 1225 320311 Web: http://www.radan.com/ Received: from uk.radan.com (dhcp-b-13 [172.16.51.13]) by uk.radan.com (8.9.1b+Sun/8.9.1) with ESMTP id RAA27696; Tue, 21 Oct 2003 17:06:35 +0100 (BST) Message-ID: <3F955A26.8010509@uk.radan.com> Date: Tue, 21 Oct 2003 17:09:10 +0100 From: Steve Hay User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: daniel@veillard.com Cc: xml@gnome.org References: <20031021135705.1200B40440@widget.gnome.org> <3F9546DB.1070701@uk.radan.com> <20031021151517.GJ17357@daniel.veillard.com> In-Reply-To: <20031021151517.GJ17357@daniel.veillard.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [xml] Re: [Bug 125110] Changed - libxml2 2.6.0 doesn't build on Windows Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi Daniel, Daniel Veillard wrote: >On Tue, Oct 21, 2003 at 03:46:51PM +0100, Steve Hay wrote: > > >>bugzilla-daemon@widget.gnome.org wrote: >> >> >> >>>http://bugzilla.gnome.org/show_bug.cgi?id=125110 >>> >>>parser.obj : error LNK2001: unresolved external symbol _xmlCharInRange >>>parserInternals.obj : error LNK2001: unresolved external symbol >>>_xmlCharInRange >>>binaries\libxml2.dll : fatal error LNK1120: 1 unresolved externals >>> >>>Regards, >>>- Steve >>>+ >>>+------- Additional Comments From daniel@veillard.com 2003-10-21 09:57 >>>------- >>>+Should be fixed in CVS, check the mailing list in case of Windows >>>+problems before reporting to bugzilla ! >>>+ >>>+Daniel >>> >>> >>> >>> >>My apologies - Guilty as charged. >> >>However, I still can't get at the change in question. The mailing list >>archive contains a message that included a patch, but the archive itself >>doesn't include the patch >>(http://mail.gnome.org/archives/xml/2003-October/msg00239.html)! >> >> > > yes it's there > win32_configs.diff link at the bottom > Doh! I'm obviously not drinking enough coffee ;) > > > >>I tried doing a CVS checkout, but that didn't seem to get the very >>latest version with that change in it. The command I used was: >> >> cvs -z3 -d :pserver:anonymous@anoncvs.gnome.org:/cvs/gnome co libxml2 >> >>Is that the correct address? >> >> > > yes but changes may take a little while for propagating to anonymous > > > >>so why doesn't the CVS checkout pick it up? >> >> > > because the anonymous cvs is on mirrors and propagation takes time, > Ah, right. Excuse my impatience. I've got the patch from the above link now and it does indeed fix the Windows build problems. Now all I need is to get the Perl XML::LibXML interface changed to build with 2.6.0 and to support the new --nsclean option... Thanks! - Steve From j.cranendonk@emaxx.nl Tue Oct 21 12:44:38 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail.emaxx.nl (mail.emaxx.nl [217.119.230.65]) by mail.gnome.org (Postfix) with ESMTP id 82233180EC for ; Tue, 21 Oct 2003 12:44:38 -0400 (EDT) Received: from dolphin.student.utwente.nl ([130.89.165.151] helo=dolphin2) by mail.emaxx.nl with smtp (Exim 3.22 #1) id 1ABzcs-000DRo-00; Tue, 21 Oct 2003 18:44:54 +0200 Message-ID: <002301c397f3$ac767f80$0200a8c0@student.utwente.nl> From: "Jeroen Cranendonk" To: "Mickautsch, Alfred" , References: <4F38C8B9DAB1014DBDCB29538BBFD6A128508E@pandora.schuler-ag.com> Subject: Re: [xml] xmlwriter - the next step Date: Tue, 21 Oct 2003 18:52:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Cool, looks like you wrote it to be more conform the original .net xmlwriter too, yay ^.^ I'll happily give it a spin and a prod when I've got some time, whenever that might be ^.^ Keep up the good work :) Jeroen C. >Hello, > >I did a little work on the xmlWriter last weekend. >It still lacks a lot of functionality and it does not >make any validation checks, but I was able to write a >usable xml file :-). >However, it is only partially tested :-(. > >Servus -- Alfred From veillard@redhat.com Tue Oct 21 12:57:14 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id D6B9D189D5 for ; Tue, 21 Oct 2003 12:57:13 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9LGvRE21873; Tue, 21 Oct 2003 12:57:27 -0400 Date: Tue, 21 Oct 2003 12:57:27 -0400 From: Daniel Veillard To: "Mickautsch, Alfred" , Jeroen Cranendonk Cc: xml@gnome.org Subject: Re: [xml] xmlwriter - the next step Message-ID: <20031021125727.A17879@redhat.com> Reply-To: veillard@redhat.com References: <4F38C8B9DAB1014DBDCB29538BBFD6A128508E@pandora.schuler-ag.com> <002301c397f3$ac767f80$0200a8c0@student.utwente.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <002301c397f3$ac767f80$0200a8c0@student.utwente.nl>; from j.cranendonk@emaxx.nl on Tue, Oct 21, 2003 at 06:52:11PM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Alfred, sorry I didn't replied to your mail with teh patch, I integrated it at the last moment into 2.6.0, it's in, I did a number of changes, mostly small ones, but I suggest you grab 2.6.0, and work from there. I did a number of cleanup changes a a few fixes especially for the header not at the code level. W.r.t. the Walker, I removed the module and integrated the functionality directly into the xmlReader interface, it's cleaner, and allow code reuse, c.f.: XMLPUBFUN xmlTextReaderPtr XMLCALL xmlReaderWalker (xmlDocPtr doc); XMLPUBFUN int XMLCALL xmlReaderNewWalker (xmlTextReaderPtr reader, xmlDocPtr doc); the test python/tests/walker.py does basic testing about it. Daniel On Tue, Oct 21, 2003 at 06:52:11PM +0200, Jeroen Cranendonk wrote: > Cool, looks like you wrote it to be more conform the original .net xmlwriter > too, yay ^.^ > > I'll happily give it a spin and a prod when I've got some time, whenever > that might be ^.^ > > Keep up the good work :) > Jeroen C. > > >Hello, > > > >I did a little work on the xmlWriter last weekend. > >It still lacks a lot of functionality and it does not > >make any validation checks, but I was able to write a > >usable xml file :-). > >However, it is only partially tested :-(. > > > >Servus -- Alfred > > _______________________________________________ > xml mailing list, project page http://xmlsoft.org/ > xml@gnome.org > http://mail.gnome.org/mailman/listinfo/xml -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From stephane.bidoul@softwareag.com Tue Oct 21 14:45:50 2003 Return-Path: Delivered-To: xml@gnome.org Received: from server8a.software-ag.de (server8a.software-ag.de [193.26.193.47]) by mail.gnome.org (Postfix) with ESMTP id BD36218305 for ; Tue, 21 Oct 2003 14:45:49 -0400 (EDT) Received: from acsesbi by server8a.software-ag.de; (8.11.6/8.9.3) id h9LIjrF16681; Tue, 21 Oct 2003 20:45:54 +0200 From: "Stephane Bidoul" To: Cc: , "'Joachim Bauch'" Subject: RE: [xml] Release of libxml2-2.6.0 Date: Tue, 21 Oct 2003 20:46:26 +0200 Message-ID: <005301c39803$a387dda0$1a67140a@acsesbi> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <20031021052809.Y16905@redhat.com> Importance: Normal Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: A cut & paste typo... Index: Makefile.mingw =================================================================== RCS file: /cvs/gnome/gnome-xml/win32/Makefile.mingw,v retrieving revision 1.13 diff -r1.13 Makefile.mingw 141c141 < $(XML_INTDIR)/chvalid.obj\ --- > $(XML_INTDIR)/chvalid.o\ 182c182 < $(XML_INTDIR_A)/chvalid.obj\ --- > $(XML_INTDIR_A)/chvalid.o\ -sbi From cpr@emsoftware.com Tue Oct 21 15:05:19 2003 Return-Path: Delivered-To: xml@gnome.org Received: from emsoftware.com (emsoftware.com [64.89.1.33]) by mail.gnome.org (Postfix) with SMTP id 3C6E8180FD for ; Tue, 21 Oct 2003 15:05:19 -0400 (EDT) Received: (qmail 19688 invoked by uid 528); 21 Oct 2003 19:05:33 -0000 Received: from cpr@emsoftware.com by emsoftware.com by uid 525 with qmail-scanner-1.20rc1 (clamscan: 0.60. Clear:RC:0:. Processed in 0.023268 secs); 21 Oct 2003 19:05:33 -0000 Received: from unknown (HELO emsoftware.com) (cpr@12.226.241.140) by emsoftware.com with SMTP; 21 Oct 2003 19:05:33 -0000 Date: Tue, 21 Oct 2003 15:06:04 -0400 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Chris Ryland To: XML List Content-Transfer-Encoding: 7bit Message-Id: <9E942986-03F9-11D8-83CC-000393DC534A@emsoftware.com> X-Mailer: Apple Mail (2.551) Subject: [xml] UTF-8+names encoding space Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Has anyone seen this? http://tbray.org/ongoing/When/200x/2003/10/17/UTF8-plus 'Twould be nice to have an encoder/decoder for it in libxml2. Cheers! --Chris Ryland / Em Software, Inc. / www.emsoftware.com From veillard@redhat.com Tue Oct 21 15:17:54 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 3C2DC180E0 for ; Tue, 21 Oct 2003 15:17:54 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9LJI3926179; Tue, 21 Oct 2003 15:18:03 -0400 Date: Tue, 21 Oct 2003 15:18:03 -0400 From: Daniel Veillard To: Chris Ryland Cc: XML List Subject: Re: [xml] UTF-8+names encoding space Message-ID: <20031021151803.D17879@redhat.com> Reply-To: veillard@redhat.com References: <9E942986-03F9-11D8-83CC-000393DC534A@emsoftware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <9E942986-03F9-11D8-83CC-000393DC534A@emsoftware.com>; from cpr@emsoftware.com on Tue, Oct 21, 2003 at 03:06:04PM -0400 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Tue, Oct 21, 2003 at 03:06:04PM -0400, Chris Ryland wrote: > Has anyone seen this? > > http://tbray.org/ongoing/When/200x/2003/10/17/UTF8-plus > > 'Twould be nice to have an encoder/decoder for it in libxml2. As I said on the W3C plenary mailing list, it makes some sense. On the other hand Tim Bray retracted his proposal considering the opposition to his suggestion. As usual, when James Clark has an opinion, it's a good idea to listen :-) Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard@redhat.com Tue Oct 21 15:15:56 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 6F8A2180E0 for ; Tue, 21 Oct 2003 15:15:56 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9LJG6524548; Tue, 21 Oct 2003 15:16:06 -0400 Date: Tue, 21 Oct 2003 15:16:06 -0400 From: Daniel Veillard To: Stephane Bidoul Cc: xml@gnome.org, "'Joachim Bauch'" Subject: Re: [xml] Release of libxml2-2.6.0 Message-ID: <20031021151605.C17879@redhat.com> Reply-To: veillard@redhat.com References: <20031021052809.Y16905@redhat.com> <005301c39803$a387dda0$1a67140a@acsesbi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <005301c39803$a387dda0$1a67140a@acsesbi>; from stephane.bidoul@softwareag.com on Tue, Oct 21, 2003 at 08:46:26PM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Tue, Oct 21, 2003 at 08:46:26PM +0200, Stephane Bidoul wrote: > A cut & paste typo... makes sense, applied and commited, thanks, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From pj@walter-graphtek.com Tue Oct 21 15:24:43 2003 Return-Path: Delivered-To: xml@gnome.org Received: from jessenlenz.com (mail.jessenlenz.com [212.79.192.34]) by mail.gnome.org (Postfix) with ESMTP id 7C5D6180E0 for ; Tue, 21 Oct 2003 15:24:42 -0400 (EDT) Received: from SOFTDEV8 (217.0.70.111) by jessenlenz.com with ESMTP (Eudora Internet Mail Server 3.1.4); Tue, 21 Oct 2003 21:21:44 +0200 From: "Peter Jacobi" To: Chris Ryland Date: Tue, 21 Oct 2003 21:26:02 +0200 MIME-Version: 1.0 Subject: Re: [xml] UTF-8+names encoding space Cc: xml@gnome.org Message-ID: <3F95A46A.13949.822FD8@localhost> Priority: normal In-reply-to: <9E942986-03F9-11D8-83CC-000393DC534A@emsoftware.com> X-mailer: Pegasus Mail for Windows (v4.02) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi Chris, All, > http://tbray.org/ongoing/When/200x/2003/10/17/UTF8-plus This is nice, but I suspect there are still enough TeXies around, who would vote for TeX pseudo character set. Anyway, you should move your evangelism to the IETF for standardization and to the GNU libc and libiconv projects for implementation. Only charsets which are easy to implement and very widely used tend to go into libxml itself. Regards, Peter Jacobi From nick@webthing.com Tue Oct 21 16:26:06 2003 Return-Path: Delivered-To: xml@gnome.org Received: from jarl.webthing.com (81-174-208-160.pth-as1.dial.plus.net [81.174.208.160]) by mail.gnome.org (Postfix) with ESMTP id A21E118441 for ; Tue, 21 Oct 2003 16:26:05 -0400 (EDT) Received: from fenris.webthing.com (fenris.webthing.com [192.168.10.5]) by jarl.webthing.com (Postfix) with ESMTP id D448160B6; Tue, 21 Oct 2003 21:18:54 +0100 (BST) Received: by fenris.webthing.com (Postfix, from userid 1000) id 4010E173; Tue, 21 Oct 2003 16:04:19 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by fenris.webthing.com (Postfix) with ESMTP id C475D16C; Tue, 21 Oct 2003 16:04:19 +0100 (BST) Date: Tue, 21 Oct 2003 16:04:19 +0100 (BST) From: Nick Kew To: Jerome Pesenti Cc: Subject: Re: [xml] htmlParseFile vs htmlParseDoc Message-ID: <20031021154534.K1384-100000@fenris.webthing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, 16 Oct 2003, Jerome Pesenti wrote: > Yes, here is a little program showing the problem. That'll be slowness parsing big chunks. Pass it smaller chunks in memory and it's faster. Give it a sax context and of course it'll go much faster again! Here's your demo prog hacked to show parsing in smaller chunks. (FWIW, I regularly use chunked SAX parsing in the Apache Filter chain; I have a talk about using Apache as a smart markup-aware platform at ApacheCon in November.) #include #include #include #include #define SIZE (10*1024*1024) char * read_all(const char *name, int* sz) { FILE *f = fopen(name, "r"); char *s; if (! f) { perror(name); exit(1); } s = malloc(sizeof(*s)*SIZE); if ((*sz = fread(s, 1, SIZE, f)) < 0 || *sz == SIZE) { /* error or file too large */ fprintf(stderr, "Could not load file, got %d bytes\n", *sz); exit(1); } s[*sz] = '\0'; fclose(f) ; return s; } int main(int argc, char **argv) { int buflen ; char *str; htmlParserCtxtPtr ctxt; size_t bytes = 0 ; size_t count ; str = read_all(argv[1], &count); printf("%ld - parsing with htmlParseDocument\n", time(NULL)); ctxt = htmlCreateMemoryParserCtxt(str, strlen(str)); htmlParseDocument(ctxt); htmlFreeParserCtxt(ctxt) ; printf("%ld - done\n", time(NULL)); printf("%ld - parsing with htmlParseDoc\n", time(NULL)); htmlParseDoc(str, NULL); printf("%ld - done\n", time(NULL)); printf("%ld - parsing with htmlParseFile\n", time(NULL)); htmlParseFile(argv[1], NULL); printf("%ld - done\n", time(NULL)); for ( buflen = 4 ; buflen < count ; buflen *= 2 ) { ctxt = NULL ; printf("%ld - parsing with htmlParseChunk size %d\n", time(NULL), buflen); for ( bytes = 0 ; bytes < count - buflen ; bytes += buflen) if ( ! ctxt ) ctxt = htmlCreatePushParserCtxt(NULL, NULL, str, buflen, 0, 0) ; else htmlParseChunk(ctxt, (str+bytes), buflen, 0) ; htmlParseChunk(ctxt, (str+bytes), (count-bytes), 1) ; htmlFreeParserCtxt(ctxt) ; printf("%ld - done\n", time(NULL)); } free(str) ; return 0; } From graham-libxml@simulcra.org Tue Oct 21 17:19:30 2003 Return-Path: Delivered-To: xml@gnome.org Received: from lamity.org (lamity.org [212.13.197.69]) by mail.gnome.org (Postfix) with SMTP id 36EE618A4E for ; Tue, 21 Oct 2003 17:19:30 -0400 (EDT) Received: (qmail 17612 invoked by uid 1001); 21 Oct 2003 21:19:43 -0000 Date: Tue, 21 Oct 2003 22:19:43 +0100 From: Graham Bennett To: xml@gnome.org Message-ID: <20031021211943.GC12643@lamity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Subject: [xml] context reuse for push parser Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi all, I added the following function to enable me to reuse the parser context using the push parser. It corresponds to xmlCreatePushParserCtxt, but takes an existing context. Not sure if it's generally useful but it seems to work for my code. static void xmlCtxtInitPushParser(xmlParserCtxtPtr ctxt, const char *chunk, int size, const char *filename) { xmlParserInputPtr inputStream; xmlParserInputBufferPtr buf; xmlCharEncoding enc = XML_CHAR_ENCODING_NONE; if ((chunk != NULL) && (size >= 4)) enc = xmlDetectCharEncoding((const xmlChar *) chunk, size); buf = xmlAllocParserInputBuffer(enc); if (buf == NULL) return; if (ctxt == NULL) { xmlErrMemory(NULL, "No parser context\n"); xmlFreeParserInputBuffer(buf); return; } xmlCtxtReset(ctxt); ctxt->pushTab = (void **) xmlMalloc(ctxt->nameMax * 3 * sizeof(xmlChar *)); if (ctxt->pushTab == NULL) { xmlErrMemory(ctxt, NULL); xmlFreeParserInputBuffer(buf); return; } if (filename == NULL) { ctxt->directory = NULL; } else { ctxt->directory = xmlParserGetDirectory(filename); } inputStream = xmlNewInputStream(ctxt); if (inputStream == NULL) { xmlFreeParserInputBuffer(buf); return; } if (filename == NULL) inputStream->filename = NULL; else inputStream->filename = (char *) xmlCanonicPath((const xmlChar *) filename); inputStream->buf = buf; inputStream->base = inputStream->buf->buffer->content; inputStream->cur = inputStream->buf->buffer->content; inputStream->end = &inputStream->buf->buffer->content[inputStream->buf->buffer->use]; inputPush(ctxt, inputStream); if ((size > 0) && (chunk != NULL) && (ctxt->input != NULL) && (ctxt->input->buf != NULL)) { int base = ctxt->input->base - ctxt->input->buf->buffer->content; int cur = ctxt->input->cur - ctxt->input->base; xmlParserInputBufferPush(ctxt->input->buf, size, chunk); ctxt->input->base = ctxt->input->buf->buffer->content + base; ctxt->input->cur = ctxt->input->base + cur; ctxt->input->end = &ctxt->input->buf->buffer->content[ctxt->input->buf->buffer->use]; #ifdef DEBUG_PUSH xmlGenericError(xmlGenericErrorContext, "PP: pushed %d\n", size); #endif } if (enc != XML_CHAR_ENCODING_NONE) { xmlSwitchEncoding(ctxt, enc); } } cheers, Graham. -- Graham Bennett From veillard@redhat.com Tue Oct 21 17:58:36 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id D935F18A2E for ; Tue, 21 Oct 2003 17:58:33 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9LLwjV30351; Tue, 21 Oct 2003 17:58:45 -0400 Date: Tue, 21 Oct 2003 17:58:45 -0400 From: Daniel Veillard To: Graham Bennett Cc: xml@gnome.org Subject: Re: [xml] context reuse for push parser Message-ID: <20031021175845.E17879@redhat.com> Reply-To: veillard@redhat.com References: <20031021211943.GC12643@lamity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031021211943.GC12643@lamity.org>; from graham-libxml@simulcra.org on Tue, Oct 21, 2003 at 10:19:43PM +0100 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Tue, Oct 21, 2003 at 10:19:43PM +0100, Graham Bennett wrote: > Hi all, > > I added the following function to enable me to reuse the parser context > using the push parser. It corresponds to xmlCreatePushParserCtxt, but > takes an existing context. Not sure if it's generally useful but it > seems to work for my code. Okay might make a good addition to the new parser interfaces. > static void xmlCtxtInitPushParser(xmlParserCtxtPtr ctxt, const char > *chunk, int size, const char *filename) > { > xmlParserInputPtr inputStream; > xmlParserInputBufferPtr buf; > xmlCharEncoding enc = XML_CHAR_ENCODING_NONE; > > if ((chunk != NULL) && (size >= 4)) > enc = xmlDetectCharEncoding((const xmlChar *) chunk, size); > > buf = xmlAllocParserInputBuffer(enc); > if (buf == NULL) return; > > if (ctxt == NULL) { > xmlErrMemory(NULL, "No parser context\n"); Hum, this isn't really a memory error. It's an API use error, I would rather make the function return 0 in case of success and -1 in case of error, and return -1 in that case (and check on function entry). > xmlFreeParserInputBuffer(buf); > return; > } > > xmlCtxtReset(ctxt); > > ctxt->pushTab = (void **) xmlMalloc(ctxt->nameMax * 3 * sizeof(xmlChar > *)); Hum, you're likely to memleak there. ctxt->pushTab is probably not NULL, > if (ctxt->pushTab == NULL) { > xmlErrMemory(ctxt, NULL); > xmlFreeParserInputBuffer(buf); > return; > } > > if (filename == NULL) { > ctxt->directory = NULL; > } else { > ctxt->directory = xmlParserGetDirectory(filename); > } > > inputStream = xmlNewInputStream(ctxt); > if (inputStream == NULL) { > xmlFreeParserInputBuffer(buf); > return; > } > > if (filename == NULL) > inputStream->filename = NULL; > else > inputStream->filename = (char *) > xmlCanonicPath((const xmlChar *) filename); > inputStream->buf = buf; > inputStream->base = inputStream->buf->buffer->content; > inputStream->cur = inputStream->buf->buffer->content; > inputStream->end = > &inputStream->buf->buffer->content[inputStream->buf->buffer->use]; > > inputPush(ctxt, inputStream); > > if ((size > 0) && (chunk != NULL) && (ctxt->input != NULL) && > (ctxt->input->buf != NULL)) { > int base = ctxt->input->base - ctxt->input->buf->buffer->content; > int cur = ctxt->input->cur - ctxt->input->base; > > xmlParserInputBufferPush(ctxt->input->buf, size, chunk); > > ctxt->input->base = ctxt->input->buf->buffer->content + base; > ctxt->input->cur = ctxt->input->base + cur; > ctxt->input->end = > &ctxt->input->buf->buffer->content[ctxt->input->buf->buffer->use]; > #ifdef DEBUG_PUSH > xmlGenericError(xmlGenericErrorContext, "PP: pushed %d\n", size); > #endif > } > > if (enc != XML_CHAR_ENCODING_NONE) { > xmlSwitchEncoding(ctxt, enc); > } maybe an extra encoding passed as a const char * is needed. C.f. section F.2. of the spec: http://www.w3.org/TR/REC-xml#sec-guessing-with-ext-info in that case the context encoding overrides the one fine in the XML declaration or autodetected by xmlDetectCharEncoding() which implement the F.1. detection algorithm. > } it's a good idea, that could be reused within the xmlreader code. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From h.shibuya@vertexsystems.co.jp Tue Oct 21 20:31:39 2003 Return-Path: Delivered-To: xml@gnome.org Received: from ssemail007.crayfish.net (ssemail007.crayfish.net [210.172.136.3]) by mail.gnome.org (Postfix) with ESMTP id 72B69181B4 for ; Tue, 21 Oct 2003 20:31:38 -0400 (EDT) Received: from Dimension4500C (h084.p464.iij4u.or.jp [210.149.208.84]) by ssemail007.crayfish.net (8.9.3p2/3.7W Crayfish POPbeforeSMTP'd) with ESMTP id JAA07536; Wed, 22 Oct 2003 09:31:44 +0900 (JST) From: "Shibuya" To: , Subject: RE: [xml] cannot open include file . xmlwin32version.h Date: Wed, 22 Oct 2003 09:31:41 +0900 Message-ID: <001c01c39833$e078e800$1a01a8c0@Dimension4500C> MIME-Version: 1.0 Content-Type: text/plain; charset="shift_jis" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <5074873$10667413103f952e3e653991.72661322@config7.schlund.de> Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: =81=84> I got new version(2.6) & compiled it with VC7. However, it=20 =81=84displayed=20 =81=84> many error messages. =81=84 =81=84> ../include/libxml/xmlversion.h(127) : error C2018: The character = =81=84> '0x40' cannot be recognized. =81=84 =81=84I had the same problem, caused by a little bug in the=20 =81=84configure.js, that put a define name in the xmlversion.h=20 =81=84instead of a value (xmlWriter interface), was fixed in CVS=20 =81=84earlier today Although I got 'cvs-snapshot.tar.gz' and compiled it, the same error message was displayed.=20 Had I downloaded a diverse file?=20 =81=84 =81=84> ../include/libxml/encoding.h(27) : fatal error C1083: cannot = open=20 =81=84> include file. 'iconv.h' :No such file or directory. =81=84 =81=84the files have been removed in the 2.6.0 release, because=20 =81=84nobody felt like maintaining them and the "configure.js"=20 =81=84script rendered them quite obsolete. =81=84 =81=84try to run "cscript configure.js compiler=3Dmsvc iconv=3Dno" and=20 =81=84"nmake" after that in the win32 subfolder of the 2.6.0 = distribution. =81=84 =81=84I am just using MSVC 6. does the libxml2 even compile=20 =81=84successfully with MSVC .NET 2002/2003? Also including the command line option of 'cl.exe',=20 since I am compatibility with a higher rank, I expect that it can compile. Thak you so much for your help. by h.Shibuya From jfleck@inkstain.net Tue Oct 21 23:01:29 2003 Return-Path: Delivered-To: xml@gnome.org Received: from taka.swcp.com (taka.swcp.com [198.59.115.12]) by mail.gnome.org (Postfix) with ESMTP id 862951810B for ; Tue, 21 Oct 2003 23:01:29 -0400 (EDT) Received: from jelloiii (216.184.14.36.unused.swcp.com [216.184.14.36]) by taka.swcp.com (8.12.9/8.12.9) with ESMTP id h9M31fo6040537; Tue, 21 Oct 2003 21:01:41 -0600 (MDT) Subject: Re: [xml] extend xml Document with new rootNode From: John Fleck To: Marc Giger Cc: xml@gnome.org In-Reply-To: <20031019124544.6acb7795.gigerstyle@gmx.ch> References: <20031019124544.6acb7795.gigerstyle@gmx.ch> Content-Type: text/plain Message-Id: <1066791765.1036.30.camel@jelloiii> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Tue, 21 Oct 2003 21:02:45 -0600 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on kaimen.swcp.com X-Spam-Status: No, hits=0.5 required=10.0 tests=HTML_MESSAGE, HTML_TAG_BALANCE_BODY autolearn=no version=2.60 X-Spam-Level: Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Sun, 2003-10-19 at 04:45, Marc Giger wrote: > Hi list, > > I'm new to libxml and need some help. > > What I try to do is to extend an existing xml-document with a new root > node. I've already tried some things... > > To illustrate the "problem", the actual xml file is something like the > following: > Call this doc1 > > [snip] > > > And the goal should be: > And this is doc2 > > > > > > [snip] > > > > > What is the best way to achieve this? > Perhaps it is relevant that the xml-tree will never be written out to a > file. It's processed "in memory". > >From doc1 use xmlDocGetRootElement to get the xmlNodePtr for the root node (). Then in doc2 walk the tree*, and when you got to , use xmlAddChildList to add the root node tree bit from doc1. Cheers, John * http://www.xmlsoft.org/tutorial/ar01s04.html or http://www.xmlsoft.org/example.html for how to walk the tree -- John Fleck jfleck@inkstain.net (h) http://www.inkstain.net "It makes me mad when someone writes or draws something that I can't get right away!" - Zippy the Pinhead From graham-libxml@simulcra.org Wed Oct 22 03:06:20 2003 Return-Path: Delivered-To: xml@gnome.org Received: from lamity.org (lamity.org [212.13.197.69]) by mail.gnome.org (Postfix) with SMTP id 407A518270 for ; Wed, 22 Oct 2003 03:06:20 -0400 (EDT) Received: (qmail 17526 invoked by uid 1001); 22 Oct 2003 07:06:35 -0000 Date: Wed, 22 Oct 2003 08:06:35 +0100 From: Graham Bennett To: Daniel Veillard Cc: xml@gnome.org Subject: Re: [xml] context reuse for push parser Message-ID: <20031022070635.GA17027@lamity.org> References: <20031021211943.GC12643@lamity.org> <20031021175845.E17879@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031021175845.E17879@redhat.com> User-Agent: Mutt/1.3.28i Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Tue, Oct 21, 2003 at 05:58:45PM -0400, Daniel Veillard wrote: > On Tue, Oct 21, 2003 at 10:19:43PM +0100, Graham Bennett wrote: > > Hi all, > > > > I added the following function to enable me to reuse the parser context > > using the push parser. It corresponds to xmlCreatePushParserCtxt, but > > takes an existing context. Not sure if it's generally useful but it > > seems to work for my code. > > Okay might make a good addition to the new parser interfaces. [ snip ] > > if (ctxt == NULL) { > > xmlErrMemory(NULL, "No parser context\n"); > > Hum, this isn't really a memory error. It's an API use error, I would rather > make the function return 0 in case of success and -1 in case of error, and > return -1 in that case (and check on function entry). Yep sounds better. I'm sure a lot of it needs to be cleaned up, I just did the bare minimum to get it working. > > xmlFreeParserInputBuffer(buf); > > return; > > } > > > > xmlCtxtReset(ctxt); > > > > ctxt->pushTab = (void **) xmlMalloc(ctxt->nameMax * 3 * sizeof(xmlChar > > *)); > > Hum, you're likely to memleak there. ctxt->pushTab is probably not NULL, Oops yes, that's wrong :) [ snip ] > > if (enc != XML_CHAR_ENCODING_NONE) { > > xmlSwitchEncoding(ctxt, enc); > > } > > maybe an extra encoding passed as a const char * is needed. C.f. > section F.2. of the spec: > http://www.w3.org/TR/REC-xml#sec-guessing-with-ext-info > in that case the context encoding overrides the one fine in the XML > declaration or autodetected by xmlDetectCharEncoding() which implement > the F.1. detection algorithm. Sounds reasonable. In my case I think I'd always want to autodetect it, but still it would be useful. > it's a good idea, that could be reused within the xmlreader code. Ok cool. Thanks, Graham. -- Graham Bennett From veillard@redhat.com Wed Oct 22 04:48:30 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id A3BBD18A71 for ; Wed, 22 Oct 2003 04:48:29 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9M8mhb32369; Wed, 22 Oct 2003 04:48:43 -0400 Date: Wed, 22 Oct 2003 04:48:42 -0400 From: Daniel Veillard To: Bidoul Stephane Cc: xml@gnome.org Subject: Re: [xml] Release of libxml2-2.6.0 Message-ID: <20031022044842.G17879@redhat.com> Reply-To: veillard@redhat.com References: <99E9D09588AB9F49B5C66BCF77A07843245344@isoexc23.elia.be> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <99E9D09588AB9F49B5C66BCF77A07843245344@isoexc23.elia.be>; from STEPHANE.BIDOUL@externel.be on Wed, Oct 22, 2003 at 09:27:45AM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, Oct 22, 2003 at 09:27:45AM +0200, Bidoul Stephane wrote: > A small patch for a compiler warning > (the implementation of xmlCharInRange > does not match the declaration) That makes sense, patching the genChRanges.py script too since chvalid.c is generated by it. thanks, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From STEPHANE.BIDOUL@externel.be Wed Oct 22 03:28:22 2003 Return-Path: Delivered-To: xml@gnome.org Received: from isomrl04.elia.be (unknown [194.196.29.40]) by mail.gnome.org (Postfix) with ESMTP id 3D94318139 for ; Wed, 22 Oct 2003 03:28:22 -0400 (EDT) Received: from isoexc23.elia.be (ISOEXC23.ELIA.BE [172.30.17.88]) by isomrl04.elia.be (3.05.6.9) with ESMTP id IAA20720; Wed, 22 Oct 2003 08:28:16 +0100 Received: by isoexc23.elia.be with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Oct 2003 09:27:47 +0200 Message-ID: <99E9D09588AB9F49B5C66BCF77A07843245344@isoexc23.elia.be> From: Bidoul Stephane To: veillard@redhat.com Cc: xml@gnome.org Subject: RE: [xml] Release of libxml2-2.6.0 Date: Wed, 22 Oct 2003 09:27:45 +0200 X-Mailer: Internet Mail Service (5.5.2653.19) MIME-Version: 1.0 (Generated by NET-TEL Mailguard SMTP version 3.5.6.9) Content-Type: text/plain; charset="iso-8859-1" Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: A small patch for a compiler warning (the implementation of xmlCharInRange does not match the declaration) -sbi Index: chvalid.c =================================================================== RCS file: /cvs/gnome/gnome-xml/chvalid.c,v retrieving revision 1.8 diff -c -r1.8 chvalid.c *** chvalid.c 18 Oct 2003 12:42:40 -0000 1.8 --- chvalid.c 21 Oct 2003 19:07:16 -0000 *************** *** 160,166 **** * Returns: true if character valid, false otherwise */ int ! xmlCharInRange (unsigned int val, xmlChRangeGroupPtr rptr) { int low, high, mid; xmlChSRangePtr sptr; xmlChLRangePtr lptr; --- 160,166 ---- * Returns: true if character valid, false otherwise */ int ! xmlCharInRange (unsigned int val, const xmlChRangeGroupPtr rptr) { int low, high, mid; xmlChSRangePtr sptr; xmlChLRangePtr lptr; From Murray.Cumming@Comneon.com Wed Oct 22 05:15:51 2003 Return-Path: Delivered-To: xml@gnome.org Received: from smtp1.infineon.com (smtp1.infineon.com [194.175.117.76]) by mail.gnome.org (Postfix) with ESMTP id 482F01813C for ; Wed, 22 Oct 2003 05:15:51 -0400 (EDT) Received: from vihsx03a.vih.infineon.com (vih.ifx-mail3.com [172.31.163.97]) by smtp1.infineon.com (8.12.10/8.12.10) with ESMTP id h9M9DOSF009657 for ; Wed, 22 Oct 2003 11:13:24 +0200 (MEST) Received: by vihsx03a.vih.infineon.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Oct 2003 11:16:17 +0200 Message-ID: <258B0164D480D5118D900800062B385801840128@vihsx09a.vih.infineon.com> From: Murray.Cumming@Comneon.com To: xml@gnome.org Date: Wed, 22 Oct 2003 11:16:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [xml] SaxParser: getEntity() callback Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Has anyone ever successfully used the getEntity() callback? It needs to return an xmlEntity instance, but I can't imagine that anyone could create one with all the right voodoo contents: http://xmlsoft.org/html/libxml-tree.html#xmlEntity I can't find any way to get the xmlEntity that would have been created by libxml automatically if I had set the getEntity() to NULL. That might at least be a starting point. I know this is difficult, but I hope it isn't impossible. Murray Cumming www.murrayc.com murrayc@usa.net From bj@ph.ed.ac.uk Wed Oct 22 05:33:55 2003 Return-Path: Delivered-To: xml@gnome.org Received: from envy.ph.ed.ac.uk (envy.ph.ed.ac.uk [129.215.72.168]) by mail.gnome.org (Postfix) with ESMTP id 705A418188 for ; Wed, 22 Oct 2003 05:33:55 -0400 (EDT) Received: from ph.ed.ac.uk (prudence.ph.ed.ac.uk [129.215.72.8]) by envy.ph.ed.ac.uk (8.9.3p3/8.9.3) with ESMTP id KAA25177 for ; Wed, 22 Oct 2003 10:34:11 +0100 (BST) Message-ID: <3F964F13.4080607@ph.ed.ac.uk> Date: Wed, 22 Oct 2003 10:34:11 +0100 From: Balint Joo User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: xml@gnome.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [xml] libxml port to QCDOC. Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi, I have compiled up libxml2 (version 2.5.1 for now) on a prototype node of a QCDOC supercomputer. I am really impressed that fundamentally the whole thing just worked (even though it went through a cross compile) Well done you all. (Incidentally for more info on the QCDOC supercomputer, visit: http://www.phys.columbia.edu/~cqft or just type QCDOC into Google) However, our toolchain and operating system is restricted on the QCDOC, in particular a couple of UNIX/POSIX functions are missing from our OS or are not available to users (such as getcwd and stat). Alas this is the sorrow of having a homebrew OS. In any case, I found that in the config.h file, I can #undef HAVE_STAT, and for getcwd I just return "/" all the time. However, it would be nice if I could somehow tell ./configure to #undef HAVE_STAT. As it is it will probe for stat and find the newlib stub (which is not really functional in our case). For the now we could certainly proceed in such a way, that I configure as normal, and some post processing script undefines HAVE_STAT in the config.h file. The ultimate cleanest way of doing things would be to hide our stat function stub so that the configure script won't find it, however this may be invasive to newlib which is also undersirable. Would it perhaps be reasonable possible to patch the configure script by adding a --disable-statfunc switch? I Any ideas or comments would be appreciated. Balint -- ------------------------------------------------------------------- Dr Balint Joo Post Doctoral Research Fellow School of Physics University of Edinburgh Mayfield Road, Edinburgh EH9 3JZ Scotland UK Tel: 0131 650 6469 (from UK) +44-131-650-6469 (from outwith UK) Fax: 0131 650 5902 (from UK) +44-131-650-5902 (from outwith UK) email: bj@ph.ed.ac.uk bj@phys.columbia.edu WWW : http://www.ph.ed.ac.uk/~bj ------------------------------------------------------------------- From kbuchcik@4commerce.de Wed Oct 22 05:36:52 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mx01.qsc.de (mx01.qsc.de [213.148.129.14]) by mail.gnome.org (Postfix) with ESMTP id 5AD3D18188 for ; Wed, 22 Oct 2003 05:36:52 -0400 (EDT) Received: from port-212-202-229-162.reverse.qsc.de ([212.202.229.162] helo=kisone) by mx01.qsc.de with smtp (Exim 3.35 #1) id 1ACFQR-0002ZY-00 for xml@gnome.org; Wed, 22 Oct 2003 11:37:07 +0200 From: Kasimier Buchcik To: X-Priority: 3 Received: from emission [10.254.2.2] by kisone [10.254.2.2] with SMTP eMission ESMTPServer; Wed, 22 Oct 2003 11:31:45 +0200 Received: from 4commerce.de (10.1.72.2 [10.1.72.2]) by kisone.kisnet.de with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VJHJYG8Y; Wed, 22 Oct 2003 11:31:45 +0200 Message-ID: <3F964F18.8090101@4commerce.de> Date: Wed, 22 Oct 2003 11:34:16 +0200 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en X-eMessageService: eMission.SMTPServer Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [xml] xmlParseDocument with a specified encoding Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi, Is it possible to have a document (as string) in UTF-16 but with an=20 other encoding declared in the document prolog, that I can pass to xmlCreateDocParserCtxt and parse with xmlParseDocument? I.e. can I force=20 the parser to handle the document with a specified encoding? Or will the=20 parser autodetect somehow the UTF-16 encoding of the passed string and=20 don't care for the declaration in the prolog? Any hints? Thanks, Kasimier Buchcik From veillard@redhat.com Wed Oct 22 05:40:39 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 9855B18269 for ; Wed, 22 Oct 2003 05:40:39 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9M9esQ20454; Wed, 22 Oct 2003 05:40:54 -0400 Date: Wed, 22 Oct 2003 05:40:54 -0400 From: Daniel Veillard To: Murray.Cumming@Comneon.com Cc: xml@gnome.org Subject: Re: [xml] SaxParser: getEntity() callback Message-ID: <20031022054054.L17879@redhat.com> Reply-To: veillard@redhat.com References: <258B0164D480D5118D900800062B385801840128@vihsx09a.vih.infineon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <258B0164D480D5118D900800062B385801840128@vihsx09a.vih.infineon.com>; from Murray.Cumming@Comneon.com on Wed, Oct 22, 2003 at 11:16:03AM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, Oct 22, 2003 at 11:16:03AM +0200, Murray.Cumming@Comneon.com wrote: > Has anyone ever successfully used the getEntity() callback? It needs to > return an xmlEntity instance, but I can't imagine that anyone could create > one with all the right voodoo contents: > http://xmlsoft.org/html/libxml-tree.html#xmlEntity > > I can't find any way to get the xmlEntity that would have been created by > libxml automatically if I had set the getEntity() to NULL. That might at > least be a starting point. > > I know this is difficult, but I hope it isn't impossible. 1/ Look at SAX2.c implementation 2/ Look at entities.c in 2.6.0 for the predefined static entities 3/ Look at the XML-1.0 spec about the various processing of entities http://www.w3.org/TR/REC-xml#entproc consider the complexity of the given table 4/ Consider the fact that libxml2 may either substitute entities or keep them in the tree (including in attributes content) You will get an idea of what's difficult, that it's not impossible (since libxml2 does it !), but that you will have to duplicate code behaviour from libxml2 in your SAX handler. If you want proper entities processing the tree or xmlReader based approach are definitely simpler since libxml2 take care of the complexity. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard@redhat.com Wed Oct 22 05:50:46 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 1112618269 for ; Wed, 22 Oct 2003 05:50:46 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9M9p1e23994; Wed, 22 Oct 2003 05:51:01 -0400 Date: Wed, 22 Oct 2003 05:51:01 -0400 From: Daniel Veillard To: Balint Joo Cc: xml@gnome.org Subject: Re: [xml] libxml port to QCDOC. Message-ID: <20031022055101.M17879@redhat.com> Reply-To: veillard@redhat.com References: <3F964F13.4080607@ph.ed.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3F964F13.4080607@ph.ed.ac.uk>; from bj@ph.ed.ac.uk on Wed, Oct 22, 2003 at 10:34:11AM +0100 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, Oct 22, 2003 at 10:34:11AM +0100, Balint Joo wrote: > > Hi, > I have compiled up libxml2 (version 2.5.1 for now) on a > prototype node of a QCDOC supercomputer. I am really impressed > that fundamentally the whole thing just worked (even though > it went through a cross compile) Well done you all. > (Incidentally for more info on the QCDOC supercomputer, visit: > http://www.phys.columbia.edu/~cqft or just type QCDOC into Google) "Runs everywhere" ! That looks like a fun box to work with :-) > However, our toolchain and operating system is restricted on the QCDOC, > in particular a couple of UNIX/POSIX functions are missing from > our OS or are not available to users (such as getcwd and stat). > > Alas this is the sorrow of having a homebrew OS. In any case, I found > that in the config.h file, I can #undef HAVE_STAT, and for getcwd > I just return "/" all the time. However, it would be nice if I could > somehow tell ./configure to #undef HAVE_STAT. As it is it will probe > for stat and find the newlib stub (which is not really functional in > our case). Hum, the simplest would be to change configure.in to detect your specific target (the one your use for the cross compile) and then undo the configure probes, or avoid doing them. > For the now we could certainly proceed in such a way, that I configure > as normal, and some post processing script undefines HAVE_STAT in the > config.h file. The ultimate cleanest way of doing things would be > to hide our stat function stub so that the configure script won't find it, > however this may be invasive to newlib which is also undersirable. > Would it perhaps be reasonable possible to patch the configure script > by adding a --disable-statfunc switch? I Hum, no, patching the configure.in to make special work for your target is the cleanest option in my opinion. I take patches (to configure.in not to configure, which is generated from it). Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard@redhat.com Wed Oct 22 05:53:05 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 2617618AB6 for ; Wed, 22 Oct 2003 05:53:05 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9M9rJe24832; Wed, 22 Oct 2003 05:53:19 -0400 Date: Wed, 22 Oct 2003 05:53:19 -0400 From: Daniel Veillard To: Kasimier Buchcik Cc: xml@gnome.org Subject: Re: [xml] xmlParseDocument with a specified encoding Message-ID: <20031022055319.N17879@redhat.com> Reply-To: veillard@redhat.com References: <3F964F18.8090101@4commerce.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3F964F18.8090101@4commerce.de>; from kbuchcik@4commerce.de on Wed, Oct 22, 2003 at 11:34:16AM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, Oct 22, 2003 at 11:34:16AM +0200, Kasimier Buchcik wrote: > Hi, > > Is it possible to have a document (as string) in UTF-16 but with an > other encoding declared in the document prolog, that I can pass to > xmlCreateDocParserCtxt and parse with xmlParseDocument? I.e. can I force > the parser to handle the document with a specified encoding? Or will the > parser autodetect somehow the UTF-16 encoding of the passed string and > don't care for the declaration in the prolog? > Any hints? try xmlCtxtReadMemory() and by specifying the encoding, this may work, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From bj@ph.ed.ac.uk Wed Oct 22 06:03:19 2003 Return-Path: Delivered-To: xml@gnome.org Received: from envy.ph.ed.ac.uk (envy.ph.ed.ac.uk [129.215.72.168]) by mail.gnome.org (Postfix) with ESMTP id D2D75180DA for ; Wed, 22 Oct 2003 06:03:18 -0400 (EDT) Received: from ph.ed.ac.uk (prudence.ph.ed.ac.uk [129.215.72.8]) by envy.ph.ed.ac.uk (8.9.3p3/8.9.3) with ESMTP id LAA28419 for ; Wed, 22 Oct 2003 11:03:35 +0100 (BST) Message-ID: <3F9655F7.3090308@ph.ed.ac.uk> Date: Wed, 22 Oct 2003 11:03:35 +0100 From: Balint Joo User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: xml@gnome.org Subject: Re: [xml] libxml port to QCDOC References: <3F964F13.4080607@ph.ed.ac.uk> <20031022055101.M17879@redhat.com> In-Reply-To: <20031022055101.M17879@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi Daniel, I can patch the configure stuff. I'll send you a patch when done. I didn't want to suggest it as I thought it would be too invasive to your code. If you are happy to take a target (I mean --host=) with specific configuration, I'll get on and put one in. Thanks, Balint -- ------------------------------------------------------------------- Dr Balint Joo Post Doctoral Research Fellow School of Physics University of Edinburgh Mayfield Road, Edinburgh EH9 3JZ Scotland UK Tel: 0131 650 6469 (from UK) +44-131-650-6469 (from outwith UK) Fax: 0131 650 5902 (from UK) +44-131-650-5902 (from outwith UK) email: bj@ph.ed.ac.uk bj@phys.columbia.edu WWW : http://www.ph.ed.ac.uk/~bj ------------------------------------------------------------------- From veillard@redhat.com Wed Oct 22 06:08:32 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 1B181180DA for ; Wed, 22 Oct 2003 06:08:32 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9MA8Ej31001; Wed, 22 Oct 2003 06:08:14 -0400 Date: Wed, 22 Oct 2003 06:08:14 -0400 From: Daniel Veillard To: Balint Joo Cc: xml@gnome.org Subject: Re: [xml] libxml port to QCDOC Message-ID: <20031022060814.Q17879@redhat.com> Reply-To: veillard@redhat.com References: <3F964F13.4080607@ph.ed.ac.uk> <20031022055101.M17879@redhat.com> <3F9655F7.3090308@ph.ed.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3F9655F7.3090308@ph.ed.ac.uk>; from bj@ph.ed.ac.uk on Wed, Oct 22, 2003 at 11:03:35AM +0100 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, Oct 22, 2003 at 11:03:35AM +0100, Balint Joo wrote: > > Hi Daniel, > I can patch the configure stuff. I'll send you a patch > when done. I didn't want to suggest it as I thought it would be > too invasive to your code. If you are happy to take a target > (I mean --host=) with specific configuration, I'll get on and > put one in. okay, contextual patch against libxml2-2.6.0 configure.in would work fine. That will give you the opportunity to test the new build. Use the autogen.sh script to rebuild configure from configure.in (should be in CVS if not in the tarball distrib). Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From alfred.mickautsch@schuler-ag.com Wed Oct 22 06:18:17 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail-relay1 (mail-relay1.schuler-ag.com [62.156.183.20]) by mail.gnome.org (Postfix) with ESMTP id B366C18A7B for ; Wed, 22 Oct 2003 06:18:16 -0400 (EDT) Received: from sbs-proxy-test.schuler-ag.com ([192.168.16.254]) by mail-relay1 with Microsoft SMTPSVC(6.0.3790.0); Wed, 22 Oct 2003 12:23:52 +0200 Received: from mail pickup service by sbs-proxy-test.schuler-ag.com with Microsoft SMTPSVC; Wed, 22 Oct 2003 12:18:32 +0200 x-gfisavedcharset: iso-8859-1 Content-Type: text/plain; charset="iso-8859-1" Received: from pandora.schuler-ag.com ([192.168.16.20]) by sbs-proxy-test.schuler-ag.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 22 Oct 2003 12:18:31 +0200 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: AW: [xml] xmlwriter - the next step Date: Wed, 22 Oct 2003 12:18:30 +0200 Message-ID: <4F38C8B9DAB1014DBDCB29538BBFD6A12E4E7E@pandora.schuler-ag.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [xml] xmlwriter - the next step thread-index: AcOX8qiryT744mpMTiayi3Fgyehv2AAk0fuA From: "Mickautsch, Alfred" To: X-OriginalArrivalTime: 22 Oct 2003 10:18:31.0252 (UTC) FILETIME=[D7A56940:01C39885] Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: > -----Urspr=FCngliche Nachricht----- > Von: Jeroen Cranendonk [mailto:j.cranendonk@emaxx.nl] > Cool, looks like you wrote it to be more conform the original=20 > .net xmlwriter > too, yay ^.^ Well, at least I tried, but there is still some work to do. Your point = to the pnetlib-doc was a great help. Thanks. >=20 > I'll happily give it a spin and a prod when I've got some=20 > time, whenever > that might be ^.^ Yes please, and patches are welcome :-). Servus -- Alfred From veillard@redhat.com Wed Oct 22 06:30:27 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 94F7B18219 for ; Wed, 22 Oct 2003 06:30:27 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9MAUhQ06648; Wed, 22 Oct 2003 06:30:43 -0400 Date: Wed, 22 Oct 2003 06:30:42 -0400 From: Daniel Veillard To: "Mickautsch, Alfred" Cc: xml@gnome.org Subject: Re: AW: [xml] xmlwriter - the next step Message-ID: <20031022063042.A4507@redhat.com> Reply-To: veillard@redhat.com References: <4F38C8B9DAB1014DBDCB29538BBFD6A12E4E7E@pandora.schuler-ag.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <4F38C8B9DAB1014DBDCB29538BBFD6A12E4E7E@pandora.schuler-ag.com>; from alfred.mickautsch@schuler-ag.com on Wed, Oct 22, 2003 at 12:18:30PM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, Oct 22, 2003 at 12:18:30PM +0200, Mickautsch, Alfred wrote: > > > > I'll happily give it a spin and a prod when I've got some > > time, whenever > > that might be ^.^ > > Yes please, and patches are welcome :-). Hum, xmlOutputBufferWriteBase64() seems seriously broken, see http://bugzilla.gnome.org/show_bug.cgi?id=125180 please check and sens a patch against 2.6.0, thanks, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From alfred.mickautsch@schuler-ag.com Wed Oct 22 07:11:18 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail-relay1 (mail-relay1.schuler-ag.com [62.156.183.20]) by mail.gnome.org (Postfix) with ESMTP id 1A90D1835E for ; Wed, 22 Oct 2003 07:11:18 -0400 (EDT) Received: from sbs-proxy-test.schuler-ag.com ([192.168.16.254]) by mail-relay1 with Microsoft SMTPSVC(6.0.3790.0); Wed, 22 Oct 2003 13:16:54 +0200 Received: from mail pickup service by sbs-proxy-test.schuler-ag.com with Microsoft SMTPSVC; Wed, 22 Oct 2003 13:11:34 +0200 Content-Type: multipart/mixed; boundary="----=_NextPart_000_4D63F_01C3989E.045993E0" Received: from pandora.schuler-ag.com ([192.168.16.20]) by sbs-proxy-test.schuler-ag.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 22 Oct 2003 13:11:32 +0200 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: WG: AW: [xml] xmlwriter - the next step Date: Wed, 22 Oct 2003 13:11:32 +0200 Message-ID: <4F38C8B9DAB1014DBDCB29538BBFD6A1285093@pandora.schuler-ag.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: AW: [xml] xmlwriter - the next step thread-index: AcOYh42Pv420HdGLQ/GeTr6xztMjFwABkqrwAAAT1wA= From: "Mickautsch, Alfred" To: X-OriginalArrivalTime: 22 Oct 2003 11:11:32.0421 (UTC) FILETIME=[3FC54750:01C3988D] Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_4D63F_01C3989E.045993E0 x-gfisavedcharset: iso-8859-1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Oops, I sent my mail to the wrong address... -----Urspr=FCngliche Nachricht----- Von: Mickautsch, Alfred=20 Gesendet: Mittwoch, 22. Oktober 2003 13:10 An: 'veillard@redhat.com' Betreff: AW: AW: [xml] xmlwriter - the next step > Hum, xmlOutputBufferWriteBase64() seems seriously broken, see > http://bugzilla.gnome.org/show_bug.cgi?id=3D125180 > please check and sens a patch against 2.6.0,=20 >=20 Oops, that is a serious one. The patch is attached. Servus -- Alfred > --=20 > Daniel Veillard | Red Hat Network https://rhn.redhat.com/ > veillard@redhat.com | libxml GNOME XML XSLT toolkit =20 > http://xmlsoft.org/ > http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ >=20 ------=_NextPart_000_4D63F_01C3989E.045993E0 Content-Disposition: attachment; filename="xmlwriter.diff" Content-Description: xmlwriter.diff Content-Type: application/octet-stream; name="xmlwriter.diff"; name="xmlwriter.diff" Content-Transfer-Encoding: base64 KioqIHhtbHdyaXRlci5jIE1vbiBPY3QgMjAgMjM6NDQ6MDYgMjAwMw0KLS0tIGY6XHRtcFx4bWx3 cml0ZXIuYyBXZWQgT2N0IDIyIDEzOjA4OjAwIDIwMDMNCioqKioqKioqKioqKioqKg0KKioqIDEx MTcsMTEyMiAqKioqDQotLS0gMTExNywxMTI1IC0tLS0NCiAgDQogICAgICAgICAgICAgIGxpbmVs ZW4gKz0gNDsNCiAgICAgICAgICB9DQorIA0KKyAgICAgICAgIGlmIChpID49IGxlbikNCisgICAg ICAgICAgICAgYnJlYWs7DQogICAgICB9DQogIA0KICAgICAgY291bnQgPSB4bWxPdXRwdXRCdWZm ZXJXcml0ZShvdXQsIDIsIEI2NENSTEYpOw0K ------=_NextPart_000_4D63F_01C3989E.045993E0-- From Murray.Cumming@Comneon.com Wed Oct 22 07:39:23 2003 Return-Path: Delivered-To: xml@gnome.org Received: from smtp1.infineon.com (smtp1.infineon.com [194.175.117.76]) by mail.gnome.org (Postfix) with ESMTP id 0ED7118118 for ; Wed, 22 Oct 2003 07:39:23 -0400 (EDT) Received: from vihsx03a.vih.infineon.com (vih.ifx-mail3.com [172.31.163.97]) by smtp1.infineon.com (8.12.10/8.12.10) with ESMTP id h9MBauSF027475; Wed, 22 Oct 2003 13:36:56 +0200 (MEST) Received: by vihsx03a.vih.infineon.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Oct 2003 13:39:49 +0200 Message-ID: <258B0164D480D5118D900800062B385801840163@vihsx09a.vih.infineon.com> From: Murray.Cumming@Comneon.com To: veillard@redhat.com Cc: xml@gnome.org, libxmlplusplus-general@lists.sourceforge.net Subject: RE: [xml] SaxParser: getEntity() callback Date: Wed, 22 Oct 2003 13:39:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: > From: Daniel Veillard [mailto:veillard@redhat.com] > On Wed, Oct 22, 2003 at 11:16:03AM +0200, > Murray.Cumming@Comneon.com wrote: > > Has anyone ever successfully used the getEntity() callback? > It needs > > to return an xmlEntity instance, but I can't imagine that > anyone could > > create one with all the right voodoo contents: > > http://xmlsoft.org/html/libxml-tree.html#xmlEntity > > > > I can't find any way to get the xmlEntity that would have > been created > > by libxml automatically if I had set the getEntity() to NULL. That > > might at least be a starting point. > > > > I know this is difficult, but I hope it isn't impossible. > > 1/ Look at SAX2.c implementation I think this might be easier if that default implementation was publically accessible. I think that's why it's easier with the DOM Parser. The DOM Parser lets us resolve the entity reference if we like, or do our own thing. With the SAX parser it's all or nothing. I'm not sure exactly what part of SAX2.c would need to be public API. > 2/ Look at entities.c in 2.6.0 for the predefined static entities > 3/ Look at the XML-1.0 spec about the various processing of entities > http://www.w3.org/TR/REC-xml#entproc > consider the complexity of the given table > 4/ Consider the fact that libxml2 may either substitute entities or > keep them in the tree (including in attributes content) > > You will get an idea of what's difficult, that it's not > impossible (since libxml2 does it !), but that you will have > to duplicate code behaviour from libxml2 in your SAX handler. > If you want proper entities processing the tree or xmlReader > based approach are definitely simpler since libxml2 take care > of the complexity. Thanks. I think I'll just explain the complexity in the libxml++ reference documentation, and leave it to future generations to make it simpler and/or provide an example. Murray Cumming www.murrayc.com murrayc@usa.net From veillard@redhat.com Wed Oct 22 08:57:45 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 6721418504 for ; Wed, 22 Oct 2003 08:57:45 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9MCw0a01170; Wed, 22 Oct 2003 08:58:00 -0400 Date: Wed, 22 Oct 2003 08:58:00 -0400 From: Daniel Veillard To: "Mickautsch, Alfred" Cc: xml@gnome.org Subject: Re: WG: AW: [xml] xmlwriter - the next step Message-ID: <20031022085800.C4507@redhat.com> Reply-To: veillard@redhat.com References: <4F38C8B9DAB1014DBDCB29538BBFD6A1285093@pandora.schuler-ag.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <4F38C8B9DAB1014DBDCB29538BBFD6A1285093@pandora.schuler-ag.com>; from alfred.mickautsch@schuler-ag.com on Wed, Oct 22, 2003 at 01:11:32PM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, Oct 22, 2003 at 01:11:32PM +0200, Mickautsch, Alfred wrote: > > Hum, xmlOutputBufferWriteBase64() seems seriously broken, see > > http://bugzilla.gnome.org/show_bug.cgi?id=125180 > > please check and sens a patch against 2.6.0, > > > Oops, that is a serious one. > The patch is attached. okay, applied and commited, I think the next step for the xmlWriter, like for the xmlWalker will be to add support to generate a tree or a subtree using this API. Just too many people are confused by the basic tree operations. thanks, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From jdaily@progeny.com Wed Oct 22 15:22:34 2003 Return-Path: Delivered-To: xml@gnome.org Received: from morimoto.progeny.com (morimoto.progeny.com [216.37.46.163]) by mail.gnome.org (Postfix) with ESMTP id 17F981814A for ; Wed, 22 Oct 2003 15:22:34 -0400 (EDT) Received: from pigwidgeon.progeny.com (dhcp-1-203.progeny.com [192.168.1.203]) by morimoto.progeny.com (Postfix) with ESMTP id E143B636A8 for ; Wed, 22 Oct 2003 14:22:50 -0500 (EST) From: "John R. Daily" To: xml@gnome.org X-Mailer: mh-e 6.1; nmh 1.1-RC1; Emacs 21.2 Date: Wed, 22 Oct 2003 14:19:02 -0500 Message-Id: <20031022192250.E143B636A8@morimoto.progeny.com> Subject: [xml] Entity output query Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: In xmlEncodeEntitiesReentrant() in entities.c, the following logic appears at line 481 (as of version 2.6.0): } else if (*cur >= 0x80) { if (((doc != NULL) && (doc->encoding != NULL)) || (html)) { /* Simply copy the character */ } else { /* Translate into an entity */ } The decision of whether to copy an 8-bit character or turn it into an entity seems to be: If we have an encoding for the output, or if we are generating HTML, don't construct an entity. Thus the probability of turning an 8-bit character into an entity would seem to be very low. This strikes me as a rather strange way to make the decision; when I'm converting to HTML, I'd much rather have the entity than the raw character. In fact, the else clause knows how to generate HTML entities, but will never do so. I don't know what the "right" logic is; I'm definitely curious under what circumstances it is desirable to _not_ generate entities in XML/HTML output. -- John R. Daily jdaily@progeny.com Director of Technology Progeny Linux Systems Master of the ephemeral epiphany From graham-libxml@simulcra.org Wed Oct 22 16:48:06 2003 Return-Path: Delivered-To: xml@gnome.org Received: from lamity.org (lamity.org [212.13.197.69]) by mail.gnome.org (Postfix) with SMTP id 6BF8618234 for ; Wed, 22 Oct 2003 16:48:06 -0400 (EDT) Received: (qmail 447 invoked by uid 1001); 22 Oct 2003 20:48:21 -0000 Date: Wed, 22 Oct 2003 21:48:21 +0100 From: Graham Bennett To: Daniel Veillard Cc: xml@gnome.org Subject: Re: [xml] context reuse for push parser Message-ID: <20031022204821.GA26585@lamity.org> References: <20031021211943.GC12643@lamity.org> <20031021175845.E17879@redhat.com> <20031022070635.GA17027@lamity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031022070635.GA17027@lamity.org> User-Agent: Mutt/1.3.28i Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: I have updated my function: static int xmlCtxtInitPushParser(xmlParserCtxtPtr ctxt, const char *chunk, int size, const char *filename, xmlCharEncoding enc) { xmlParserInputPtr inputStream; xmlParserInputBufferPtr buf; if (enc == XML_CHAR_ENCODING_NONE && (chunk != NULL) && (size >= 4)) enc = xmlDetectCharEncoding((const xmlChar *) chunk, size); buf = xmlAllocParserInputBuffer(enc); if (buf == NULL) return 1; if (ctxt == NULL) { xmlFreeParserInputBuffer(buf); return 1; } xmlCtxtReset(ctxt); if (ctxt->pushTab == NULL) { if ((ctxt->pushTab = (void **) xmlMalloc(ctxt->nameMax * 3 * sizeof(xmlChar *))) == NULL) { xmlFreeParserInputBuffer(buf); return 1; } } if (filename == NULL) { ctxt->directory = NULL; } else { ctxt->directory = xmlParserGetDirectory(filename); } inputStream = xmlNewInputStream(ctxt); if (inputStream == NULL) { xmlFreeParserInputBuffer(buf); return 1; } if (filename == NULL) inputStream->filename = NULL; else inputStream->filename = (char *) xmlCanonicPath((const xmlChar *) filename); inputStream->buf = buf; inputStream->base = inputStream->buf->buffer->content; inputStream->cur = inputStream->buf->buffer->content; inputStream->end = &inputStream->buf->buffer->content[inputStream->buf->buffer->use]; inputPush(ctxt, inputStream); if ((size > 0) && (chunk != NULL) && (ctxt->input != NULL) && (ctxt->input->buf != NULL)) { int base = ctxt->input->base - ctxt->input->buf->buffer->content; int cur = ctxt->input->cur - ctxt->input->base; xmlParserInputBufferPush(ctxt->input->buf, size, chunk); ctxt->input->base = ctxt->input->buf->buffer->content + base; ctxt->input->cur = ctxt->input->base + cur; ctxt->input->end = &ctxt->input->buf->buffer->content[ctxt->input->buf->buffer->use]; #ifdef DEBUG_PUSH xmlGenericError(xmlGenericErrorContext, "PP: pushed %d\n", size); #endif } if (enc != XML_CHAR_ENCODING_NONE) { xmlSwitchEncoding(ctxt, enc); } return 0; } On Wed, Oct 22, 2003 at 08:06:35AM +0100, Graham Bennett wrote: > On Tue, Oct 21, 2003 at 05:58:45PM -0400, Daniel Veillard wrote: > > On Tue, Oct 21, 2003 at 10:19:43PM +0100, Graham Bennett wrote: > > > Hi all, > > > > > > I added the following function to enable me to reuse the parser context > > > using the push parser. It corresponds to xmlCreatePushParserCtxt, but > > > takes an existing context. Not sure if it's generally useful but it > > > seems to work for my code. > > > > Okay might make a good addition to the new parser interfaces. > > [ snip ] > > > > if (ctxt == NULL) { > > > xmlErrMemory(NULL, "No parser context\n"); > > > > Hum, this isn't really a memory error. It's an API use error, I would rather > > make the function return 0 in case of success and -1 in case of error, and > > return -1 in that case (and check on function entry). > > Yep sounds better. I'm sure a lot of it needs to be cleaned up, I just > did the bare minimum to get it working. > > > > xmlFreeParserInputBuffer(buf); > > > return; > > > } > > > > > > xmlCtxtReset(ctxt); > > > > > > ctxt->pushTab = (void **) xmlMalloc(ctxt->nameMax * 3 * sizeof(xmlChar > > > *)); > > > > Hum, you're likely to memleak there. ctxt->pushTab is probably not NULL, > > Oops yes, that's wrong :) > > [ snip ] > > > > if (enc != XML_CHAR_ENCODING_NONE) { > > > xmlSwitchEncoding(ctxt, enc); > > > } > > > > maybe an extra encoding passed as a const char * is needed. C.f. > > section F.2. of the spec: > > http://www.w3.org/TR/REC-xml#sec-guessing-with-ext-info > > in that case the context encoding overrides the one fine in the XML > > declaration or autodetected by xmlDetectCharEncoding() which implement > > the F.1. detection algorithm. > > Sounds reasonable. In my case I think I'd always want to autodetect it, > but still it would be useful. > > > it's a good idea, that could be reused within the xmlreader code. > > Ok cool. > > Thanks, > > Graham. > > -- > Graham Bennett > _______________________________________________ > xml mailing list, project page http://xmlsoft.org/ > xml@gnome.org > http://mail.gnome.org/mailman/listinfo/xml -- Graham Bennett From gnome-xml@m.gmane.org Wed Oct 22 17:20:38 2003 Return-Path: Delivered-To: xml@gnome.org Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by mail.gnome.org (Postfix) with ESMTP id A2FBC182D7 for ; Wed, 22 Oct 2003 17:20:38 -0400 (EDT) Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1ACQPV-00008k-00 for ; Wed, 22 Oct 2003 23:20:53 +0200 Mail-Followup-To: xml@gnome.org X-Injected-Via-Gmane: http://gmane.org/ To: xml@gnome.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1ACQLG-00004v-00 for ; Wed, 22 Oct 2003 23:16:30 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1ACQLG-00030I-00 for ; Wed, 22 Oct 2003 23:16:30 +0200 From: Steinar Bang Date: Wed, 22 Oct 2003 23:16:29 +0200 Organization: Probably a good idea Lines: 23 Message-ID: <87ad7tug5u.fsf@doohan.bang.priv.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org Mail-Copies-To: never User-Agent: Gnus/5.1003 (Gnus v5.10.3) XEmacs/21.4 (Common Lisp, linux) Cancel-Lock: sha1:NIN/oCBBHH5yaxipyxx5BqKAV+A= Subject: [xml] A method for associating documents and Relax NG schemas Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: The Relax NG schema language, doesn't define a standard way for associating an XML document with a Relax NG schema. A bit of the reasoning behind this, can be found here: http://www.thaiopensource.com/relaxng/design.html#section:17 For his Emacs XML mode, nXML, James Clark plans to implement association between document and schema, in the manner described in this email: http://groups.yahoo.com/group/emacs-nxml-mode/message/259 The email describes an XML format that can be used to locate schemas for documents, in a myriad ways. The XML format can be chained in the same way as OASIS catalogs, and OASIS XML Catalogs, so a similar structure to what the debian policy document describes for DTDs, can be adopted for locating Relax NG schemas. I'm not sure if this format is appropriate for libxml2, or not. But it might be a good idea to pick the same method as another free tool can be used...? - Steinar From veillard@redhat.com Wed Oct 22 18:43:21 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id D1A7D1828F for ; Wed, 22 Oct 2003 18:43:20 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9MMhbU28005 for xml@gnome.org; Wed, 22 Oct 2003 18:43:37 -0400 Date: Wed, 22 Oct 2003 18:43:36 -0400 From: Daniel Veillard To: xml@gnome.org Subject: Re: [xml] A method for associating documents and Relax NG schemas Message-ID: <20031022184336.J4507@redhat.com> Reply-To: veillard@redhat.com References: <87ad7tug5u.fsf@doohan.bang.priv.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <87ad7tug5u.fsf@doohan.bang.priv.no>; from sb@dod.no on Wed, Oct 22, 2003 at 11:16:29PM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, Oct 22, 2003 at 11:16:29PM +0200, Steinar Bang wrote: > The Relax NG schema language, doesn't define a standard way for > associating an XML document with a Relax NG schema. > > A bit of the reasoning behind this, can be found here: > http://www.thaiopensource.com/relaxng/design.html#section:17 > > For his Emacs XML mode, nXML, James Clark plans to implement > association between document and schema, in the manner described in > this email: > http://groups.yahoo.com/group/emacs-nxml-mode/message/259 > > The email describes an XML format that can be used to locate schemas > for documents, in a myriad ways. The XML format can be chained in the > same way as OASIS catalogs, and OASIS XML Catalogs, so a similar > structure to what the debian policy document describes for DTDs, can > be adopted for locating Relax NG schemas. > > I'm not sure if this format is appropriate for libxml2, or not. But > it might be a good idea to pick the same method as another free tool > can be used...? Sounds like a request for enhancement, please bugzilla it. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From gnome-xml@m.gmane.org Thu Oct 23 01:30:17 2003 Return-Path: Delivered-To: xml@gnome.org Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by mail.gnome.org (Postfix) with ESMTP id E7BBD18106 for ; Thu, 23 Oct 2003 01:30:16 -0400 (EDT) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1ACY3J-0004Fc-00 for ; Thu, 23 Oct 2003 07:30:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: xml@gnome.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1ACY3H-0004FU-00 for ; Thu, 23 Oct 2003 07:30:27 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1ACY3H-0000aA-00 for ; Thu, 23 Oct 2003 07:30:27 +0200 From: Steinar Bang Date: Thu, 23 Oct 2003 07:30:27 +0200 Organization: Probably a good idea Lines: 7 Message-ID: <87znfsy0zw.fsf@home.lan> References: <87ad7tug5u.fsf@doohan.bang.priv.no> <20031022184336.J4507@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org User-Agent: Gnus/5.1003 (Gnus v5.10.3) XEmacs/21.4 (Common Lisp, linux) Cancel-Lock: sha1:VEmP9nNDOnAkkh+79r+6tg6JyLU= Subject: [xml] Re: A method for associating documents and Relax NG schemas Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: >>>>> Daniel Veillard : > Sounds like a request for enhancement, please bugzilla it. Done. http://bugzilla.gnome.org/show_bug.cgi?id=125266 From veillard@redhat.com Thu Oct 23 04:49:39 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id ADB2618736 for ; Thu, 23 Oct 2003 04:49:39 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9N8nkY00961; Thu, 23 Oct 2003 04:49:46 -0400 Date: Thu, 23 Oct 2003 04:49:46 -0400 From: Daniel Veillard To: Steinar Bang Cc: xml@gnome.org Subject: Re: [xml] Re: A method for associating documents and Relax NG schemas Message-ID: <20031023044946.K4507@redhat.com> Reply-To: veillard@redhat.com References: <87ad7tug5u.fsf@doohan.bang.priv.no> <20031022184336.J4507@redhat.com> <87znfsy0zw.fsf@home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <87znfsy0zw.fsf@home.lan>; from sb@dod.no on Thu, Oct 23, 2003 at 07:30:27AM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, Oct 23, 2003 at 07:30:27AM +0200, Steinar Bang wrote: > >>>>> Daniel Veillard : > > > Sounds like a request for enhancement, please bugzilla it. > > Done. > http://bugzilla.gnome.org/show_bug.cgi?id=125266 Okay, wrong module though, you assigned it to libgnome and not libxml2 ! fixed, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From alfred.mickautsch@schuler-ag.com Thu Oct 23 06:40:16 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail-relay1 (mail-relay1.schuler-ag.com [62.156.183.20]) by mail.gnome.org (Postfix) with ESMTP id 93ACD188BB for ; Thu, 23 Oct 2003 06:40:15 -0400 (EDT) Received: from sbs-proxy-test.schuler-ag.com ([192.168.16.254]) by mail-relay1 with Microsoft SMTPSVC(6.0.3790.0); Thu, 23 Oct 2003 12:45:44 +0200 Received: from mail pickup service by sbs-proxy-test.schuler-ag.com with Microsoft SMTPSVC; Thu, 23 Oct 2003 12:40:31 +0200 x-gfisavedcharset: iso-8859-1 Content-Type: text/plain; charset="iso-8859-1" Received: from pandora.schuler-ag.com ([192.168.16.20]) by sbs-proxy-test.schuler-ag.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 23 Oct 2003 12:40:28 +0200 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: AW: WG: AW: [xml] xmlwriter - the next step Date: Thu, 23 Oct 2003 12:40:28 +0200 Message-ID: <4F38C8B9DAB1014DBDCB29538BBFD6A12E4E80@pandora.schuler-ag.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG: AW: [xml] xmlwriter - the next step thread-index: AcOYnCJPf/FjEWeTQ9O2W5ybvsMcpgAtReZQ From: "Mickautsch, Alfred" To: X-OriginalArrivalTime: 23 Oct 2003 10:40:28.0833 (UTC) FILETIME=[13661110:01C39952] Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: > -----Urspr=FCngliche Nachricht----- > Von: Daniel Veillard [mailto:veillard@redhat.com] ... > I think the next step for the xmlWriter, like for the xmlWalker will > be to add support to generate a tree or a subtree using this API. > Just too many people are confused by the basic tree operations. Yes, you are right. What do you think, would something like xmlNewTextWriterDoc for a document tree and xmlNewTextWriterTree for a subtree do or should there be just one function, which checks the node type and sets the behavior automagically? Besides: is there any difference at all or am I just inventing one? :-) Servus -- Alfred From veillard@redhat.com Thu Oct 23 07:22:06 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 5E7F8188BB for ; Thu, 23 Oct 2003 07:22:06 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9NBMMv20013; Thu, 23 Oct 2003 07:22:22 -0400 Date: Thu, 23 Oct 2003 07:22:21 -0400 From: Daniel Veillard To: "Mickautsch, Alfred" Cc: xml@gnome.org Subject: Re: AW: WG: AW: [xml] xmlwriter - the next step Message-ID: <20031023072221.M4507@redhat.com> Reply-To: veillard@redhat.com References: <4F38C8B9DAB1014DBDCB29538BBFD6A12E4E80@pandora.schuler-ag.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <4F38C8B9DAB1014DBDCB29538BBFD6A12E4E80@pandora.schuler-ag.com>; from alfred.mickautsch@schuler-ag.com on Thu, Oct 23, 2003 at 12:40:28PM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, Oct 23, 2003 at 12:40:28PM +0200, Mickautsch, Alfred wrote: > > -----Ursprüngliche Nachricht----- > > Von: Daniel Veillard [mailto:veillard@redhat.com] > ... > > I think the next step for the xmlWriter, like for the xmlWalker will > > be to add support to generate a tree or a subtree using this API. > > Just too many people are confused by the basic tree operations. > Yes, you are right. > What do you think, would something like xmlNewTextWriterDoc for a > document tree and xmlNewTextWriterTree for a subtree do or should > there be just one function, which checks the node type and sets the > behavior automagically? Besides: is there any difference at all or > am I just inventing one? :-) I would separate both APIs xmlNewTextWriterDoc() would return a new xmlDocPtr xmlNewTextWriterTree() would take a doc and an existing node within that doc, and add any new elements as last child of the given node. It should IMHO return the first element added that way. The only danger is to be careful about text node coalescing done by libxml2 if adding text sibling to existing text nodes. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From dan@dennedy.org Wed Oct 22 13:52:21 2003 Return-Path: Delivered-To: xml@gnome.org Received: from smtp02.gvl-priv.sys.nuvox.net (smtp.nuvox.net [64.89.70.9]) by mail.gnome.org (Postfix) with ESMTP id 93AEB181DD for ; Wed, 22 Oct 2003 13:52:21 -0400 (EDT) Received: from xtremedia.dennedy.org (ip-216-23-52-229.adsl.one.net [216.23.52.229]) by smtp02.gvl-priv.sys.nuvox.net (8.12.8/8.12.8) with ESMTP id h9MHqZgb008500; Wed, 22 Oct 2003 13:52:35 -0400 Received: from [10.143.0.98] (helo=kino.dennedy.org) by xtremedia.dennedy.org with esmtp (Exim 3.35 #1 (Debian)) id 1ACN9u-0006VX-00; Wed, 22 Oct 2003 13:52:34 -0400 Subject: Re: [libxml++] RE: [xml] SaxParser: getEntity() callback From: Dan Dennedy To: libxmlpp Cc: veillard@redhat.com, xml@gnome.org In-Reply-To: <258B0164D480D5118D900800062B385801840163@vihsx09a.vih.infineon.com> References: <258B0164D480D5118D900800062B385801840163@vihsx09a.vih.infineon.com> Content-Type: text/plain Message-Id: <1066845154.9253.73.camel@kino.dennedy.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4-5mdk Date: Wed, 22 Oct 2003 13:52:34 -0400 Content-Transfer-Encoding: 7bit Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, 2003-10-22 at 07:39, Murray.Cumming@Comneon.com wrote: > > From: Daniel Veillard [mailto:veillard@redhat.com] > > On Wed, Oct 22, 2003 at 11:16:03AM +0200, > > Murray.Cumming@Comneon.com wrote: > > > Has anyone ever successfully used the getEntity() callback? Yes, I have in my libxml++ working copy. It accomplishes proper substitution when the sax parser generates the content for the characters() callback. > > It needs > > > to return an xmlEntity instance, but I can't imagine that > > anyone could > > > create one with all the right voodoo contents: > > > http://xmlsoft.org/html/libxml-tree.html#xmlEntity The abbreviated code to do it, at least for internal general/parsed entities, looks like this: with parser_context.replaceEntities = 1; void on_entity_declaration() { xmlAddDocEntity(); } xmlEntity* on_get_entity() { return xmlGetDocEntity(); } Problem is, I don't want getEntity() to be called. I want characters()... entityReference()... characters()... so I can stick the entity reference into the tree. This is the complicated part Daniel VEILLARD refers to, and I believe him especially after the friendly IRC chat ;-) and reviewing the spec further. I realize, it may be undesirable to duplicate some of the libxml2 code, and that may be unacceptable for inclusion into libxml++. I just have not had time yet to review the libxml2 source in this area. I do appreciate Daniel's pointers. Maybe, eventually, we can find a way to expose some of the facilities within publicly. Necessity is the mother of invention. Either it will be necessary enough for me that I make something work for my project alone or libxml2/libxml++, or I take the different approach Daniel suggests and totally re-think my architecture. +-DRD-+ From markus_keim@ordat.com Thu Oct 23 10:11:38 2003 Return-Path: Delivered-To: xml@gnome.org Received: from scom03.giessen.ordat (comm-int.ordat.com [195.226.66.99]) by mail.gnome.org (Postfix) with SMTP id 71B4318BC2 for ; Thu, 23 Oct 2003 10:11:37 -0400 (EDT) Received: by scom03.giessen.ordat with Internet Mail Service (5.5.2657.72) id ; Thu, 23 Oct 2003 16:11:51 +0200 Message-ID: <9CED3C426350A947BF52D73899FAA0F420EB92@scom03.giessen.ordat> From: "Keim, Markus" To: "libxml2 mailing List (E-Mail)" Date: Thu, 23 Oct 2003 16:11:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [xml] Ignore external subset Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hello all, i want to parse memory blocks using "xmlParseDocument" with a pre-build parser context (special I/O callbacks since we're using an abstraction layer for all I/O and memory related tasks). Obvious there is no base path for the documents, although they possibly include relative references to external DTD subsets. So i want to ignore the external subsets while parsing and validate the documents subsequently after providing a base path. I've found that setting "parserCtxt->loadsubset" to zero (provided that "parserCtxt" is an "xmlParserCtxt") seems to work for me. I wonder if direct access of the "xmlParserCtxt" member is the supposed way to do such things, or is there a better way / API for it? Thanx & Ciao, Markus Mit freundlichen Gruessen - Kind regards Markus Keim ________________________Addressed by:________________________ ORDAT GmbH & Co. KG - Serversystems / eCom=20 Dipl.-Inf. (FH) Markus Keim Fon: +49 (641) 7941-0 Rathenaustr. 1 Fax: +49 (641) 7941-132 35394 Gie=DFen mailto:markus_keim@ordat.com See: http://www.ordat.com _____________________________________________________________ I love deadlines. I like the whooshing sound they make as they fly by. -- Douglas Adams From veillard@redhat.com Thu Oct 23 12:07:49 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 2A28418BE9 for ; Thu, 23 Oct 2003 12:07:48 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9NG80c11357; Thu, 23 Oct 2003 12:08:00 -0400 Date: Thu, 23 Oct 2003 12:08:00 -0400 From: Daniel Veillard To: "Keim, Markus" Cc: "libxml2 mailing List (E-Mail)" Subject: Re: [xml] Ignore external subset Message-ID: <20031023120800.S4507@redhat.com> Reply-To: veillard@redhat.com References: <9CED3C426350A947BF52D73899FAA0F420EB92@scom03.giessen.ordat> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <9CED3C426350A947BF52D73899FAA0F420EB92@scom03.giessen.ordat>; from markus_keim@ordat.com on Thu, Oct 23, 2003 at 04:11:50PM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, Oct 23, 2003 at 04:11:50PM +0200, Keim, Markus wrote: > Hello all, > > i want to parse memory blocks using "xmlParseDocument" with a > pre-build parser context (special I/O callbacks since we're using > an abstraction layer for all I/O and memory related tasks). > Obvious there is no base path for the documents, although they possibly > include relative references to external DTD subsets. > So i want to ignore the external subsets while parsing and validate the > documents subsequently after providing a base path. How can you expect to "validate" without fetching the external subset if there is one ? I cannot understand such a requirement. > I've found that setting "parserCtxt->loadsubset" to zero (provided that > "parserCtxt" is an "xmlParserCtxt") seems to work for me. > I wonder if direct access of the "xmlParserCtxt" member is the supposed > way to do such things, or is there a better way / API for it? > The new xmlReadxxx() APIs allows to both set the base and parser options. I will write the docs as soon as I have time, you can check the archives from last month about them, I explained how they worked. The xmllint.c code has also been updated to use those, look at it. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From johnc@seewind.com Thu Oct 23 15:21:48 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail.trytel.com (mail.trytel.com [207.164.146.15]) by mail.gnome.org (Postfix) with ESMTP id 2226A18C5C for ; Thu, 23 Oct 2003 15:21:48 -0400 (EDT) Received: from test ([24.112.186.225]) by mail.trytel.com (Post.Office MTA v3.5.3 release 223 ID# 0-49478U5000L100S0V35) with ESMTP id com for ; Thu, 23 Oct 2003 15:14:10 -0400 From: "John Coyle" To: Date: Thu, 23 Oct 2003 15:23:55 -0400 Message-ID: <000501c3999b$33684d40$6401a8c0@test> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C39979.AC56AD40" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: [xml] Custom Error Handling Dilemma Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C39979.AC56AD40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi All, I'm new to libxml2 community so I'm not sure how relevant my problem is to others . I am using libxml2 (2.2.6) for validating XML docs against XML schemas and have implemented custom error handlers to catch the great parsing and validation warnings and errors. The current implementation of xmlReportError() invokes the error handlers multiple times for the same error, this makes it tricky to implement any kind of predictable error handling. i.e if you want to catch the error and log it or report it to another system. Why does xmlReportError() not buffer the entire error msg and report it to the generic or user defined handler in a single call ? That way people who implement their own error handlers could assume that they would only here about an error or warning once. Is there another way to achieve this effect that I have overlooked? Thanks in advance, John ------=_NextPart_000_0006_01C39979.AC56AD40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Custom Error Handling Dilemma

Hi All,

        I'm new to libxml2 community so I'm not sure how relevant = my problem is to others … I am using libxml2 (2.2.6) for = validating XML docs against XML schemas and have implemented custom = error handlers to catch the great parsing and validation warnings and = errors. The current implementation of xmlReportError() invokes the error = handlers multiple times for the same error, this makes it tricky to = implement any kind of predictable error handling. i.e if you want to = catch the error and log it or report it to another system. Why does = xmlReportError() not buffer the entire error msg and report it to the = generic or user defined handler in a single call ? That way people who = implement their own error handlers could assume that they would only = here about an error or warning once.

Is there another way to achieve this = effect that I have overlooked?

Thanks in advance,

John

------=_NextPart_000_0006_01C39979.AC56AD40-- From veillard@redhat.com Thu Oct 23 17:00:21 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 8514D185BD for ; Thu, 23 Oct 2003 17:00:19 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9NL0R622912; Thu, 23 Oct 2003 17:00:27 -0400 Date: Thu, 23 Oct 2003 17:00:27 -0400 From: Daniel Veillard To: John Coyle Cc: xml@gnome.org Subject: Re: [xml] Custom Error Handling Dilemma Message-ID: <20031023170027.V4507@redhat.com> Reply-To: veillard@redhat.com References: <000501c3999b$33684d40$6401a8c0@test> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <000501c3999b$33684d40$6401a8c0@test>; from johnc@seewind.com on Thu, Oct 23, 2003 at 03:23:55PM -0400 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, Oct 23, 2003 at 03:23:55PM -0400, John Coyle wrote: > Hi All, > > I'm new to libxml2 community so I'm not sure how relevant my > problem is to others . I am using libxml2 (2.2.6) for validating XML > docs against XML schemas and have implemented custom error handlers to > catch the great parsing and validation warnings and errors. The current > implementation of xmlReportError() invokes the error handlers multiple > times for the same error, this makes it tricky to implement any kind of > predictable error handling. i.e if you want to catch the error and log > it or report it to another system. Why does xmlReportError() not buffer > the entire error msg and report it to the generic or user defined > handler in a single call ? That way people who implement their own error > handlers could assume that they would only here about an error or > warning once. > > Is there another way to achieve this effect that I have overlooked? The error layer have been completely rewritten in 2.6.0, I suggest you have a look at the new code in that version. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From markus_keim@ordat.com Fri Oct 24 12:28:14 2003 Return-Path: Delivered-To: xml@gnome.org Received: from scom03.giessen.ordat (comm-int.ordat.com [195.226.66.99]) by mail.gnome.org (Postfix) with SMTP id A4A5F18BCD for ; Fri, 24 Oct 2003 12:28:13 -0400 (EDT) Received: by scom03.giessen.ordat with Internet Mail Service (5.5.2657.72) id ; Fri, 24 Oct 2003 18:28:28 +0200 Message-ID: <9CED3C426350A947BF52D73899FAA0F420EB9C@scom03.giessen.ordat> From: "Keim, Markus" To: "libxml2 mailing List (E-Mail)" Subject: RE: [xml] Ignore external subset Date: Fri, 24 Oct 2003 18:28:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hello, > -----Original Message----- > From: Daniel Veillard [mailto:veillard@redhat.com] > Sent: Thursday, October 23, 2003 6:08 PM > To: Keim, Markus > Cc: libxml2 mailing List (E-Mail) > Subject: Re: [xml] Ignore external subset > > > On Thu, Oct 23, 2003 at 04:11:50PM +0200, Keim, Markus wrote: > > Hello all, > > > > i want to parse memory blocks using "xmlParseDocument" with a > > pre-build parser context (special I/O callbacks since we're using > > an abstraction layer for all I/O and memory related tasks). > > Obvious there is no base path for the documents, although > they possibly > > include relative references to external DTD subsets. > > So i want to ignore the external subsets while parsing and > validate the > > documents subsequently after providing a base path. > > How can you expect to "validate" without fetching the external > subset if there is one ? I cannot understand such a requirement. Hum, i *don't* want to validate while parsing. On the contrary, i want to completely ignore the external subset, even if it's present, just parse in the document. Precise: The documents are contained in memory blocks that are provided from our OS abstraction layer (therefore i access them via an I/O parser context with read callbacks that use APIs from that layer). While parsing i *can't* determine a base path for that documents, so, if "parseCtxt->loadsubset" is true (the default), the parser complains about that he can't load the external subset (and for sure he's right) and fails. But i'm able to provide a base path after parsing (don't ask why, it's a long and sad story...). Using an own external entity loader, i want to validate the document subsequently. Well, as i said, setting "parseCtxt->loadsubset" to false works for me, i just want to know if it's the appropriate way to do so. > Daniel Thanx & Ciao, Markus > -- > Daniel Veillard | Red Hat Network https://rhn.redhat.com/ > veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard@redhat.com Fri Oct 24 16:50:18 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 38EE0186EE for ; Fri, 24 Oct 2003 16:50:18 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9OKoWK06147; Fri, 24 Oct 2003 16:50:32 -0400 Date: Fri, 24 Oct 2003 16:50:32 -0400 From: Daniel Veillard To: "Keim, Markus" Cc: "libxml2 mailing List (E-Mail)" Subject: Re: [xml] Ignore external subset Message-ID: <20031024165032.F4507@redhat.com> Reply-To: veillard@redhat.com References: <9CED3C426350A947BF52D73899FAA0F420EB9C@scom03.giessen.ordat> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <9CED3C426350A947BF52D73899FAA0F420EB9C@scom03.giessen.ordat>; from markus_keim@ordat.com on Fri, Oct 24, 2003 at 06:28:27PM +0200 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Fri, Oct 24, 2003 at 06:28:27PM +0200, Keim, Markus wrote: > > How can you expect to "validate" without fetching the external > > subset if there is one ? I cannot understand such a requirement. > > Hum, i *don't* want to validate while parsing. > On the contrary, i want to completely ignore the external subset, > even if it's present, just parse in the document. Excellent, then you don't have anything to do, it's libxml2 default behaviour. > While parsing i *can't* determine a base path for that documents, > so, if "parseCtxt->loadsubset" is true (the default), the No that should not be the default. Something has changed that value. > Using an own external entity loader, i want to validate the > document subsequently. If there is an internal subset that won't work. If there is only an external subset compute the URI-Reference (uri.h) parse it as a DTD (xmlParseDTD) and validate the resulting tree (see valid.h). Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From Hans.Feder@gfk.de Sat Oct 25 11:40:27 2003 Return-Path: Delivered-To: xml@gnome.org Received: from dns3.gfk.de (unknown [62.146.192.207]) by mail.gnome.org (Postfix) with ESMTP id 53A2818EBA for ; Sat, 25 Oct 2003 11:40:27 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by dns3.gfk.de (Postfix on SuSE SLES-7 (i386)) with ESMTP id 114615DE for ; Sat, 25 Oct 2003 17:40:44 +0200 (CEST) Received: from gfk-smtp.gfk.de (gfk-smtp.gfk.de [10.10.4.46]) by dns3.gfk.de (Postfix on SuSE SLES-7 (i386)) with ESMTP id 0D6EC5DC for ; Sat, 25 Oct 2003 17:40:43 +0200 (CEST) To: xml@gnome.org X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: Hans.Feder@gfk.de Date: Sat, 25 Oct 2003 17:40:40 +0200 X-MIMETrack: Serialize by Router on GFK-SMTP/GFK/DE(Release 5.0.10 |March 22, 2002) at 25.10.2003 17:40:43 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Virus-Scanned: by AMaViS perl-11 Subject: [xml] Unresolved external ... Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi, I'm trying to use libxml within a bcb-project (CBUILDER5). I have used = the LIB which was created by the procect from libxml2-2.5.9/win32/bsb. When I'm linking my project I receive some errors from the Linker like = this example: [Linker ERROR] Unresolved external '_xmlGenericError' referenced from D= : \PROJECTS\XML\XMLPARSER\MAIN.OBJ What went wrong? Ciao Hans _____________________________________________________________________ Diese E-Mail (ggf. nebst Anhang) enth=E4lt vertrauliche und/oder rechtl= ich gesch=FCtzte Informationen. Wenn Sie nicht der richtige Adressat sind o= der diese E-Mail irrt=FCmlich erhalten haben, informieren Sie bitte sofort = den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail (and any attachment/s) contains confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. _____________________________________________________________________ = From igor@zlatkovic.com Sat Oct 25 11:46:51 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail.zlatkovic.com (spell.zlatkovic.com [62.75.159.112]) by mail.gnome.org (Postfix) with ESMTP id 1CF2A180F6 for ; Sat, 25 Oct 2003 11:46:51 -0400 (EDT) Received: from raven (pD951B95B.dip.t-dialin.net [217.81.185.91]) (authenticated bits=0) by mail.zlatkovic.com (8.12.8/8.12.8) with ESMTP id h9PFl5t6029530 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 25 Oct 2003 17:47:06 +0200 Message-ID: <005601c39b0f$3ffc7430$352ffea9@raven> From: "Igor Zlatkovic" To: , References: Subject: Re: [xml] Unresolved external ... Date: Sat, 25 Oct 2003 17:47:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: > Hi, > > I'm trying to use libxml within a bcb-project (CBUILDER5). I have used the > LIB which was created by the procect from libxml2-2.5.9/win32/bsb. > When I'm linking my project I receive some errors from the Linker like this > example: > > [Linker ERROR] Unresolved external '_xmlGenericError' referenced from D: > \PROJECTS\XML\XMLPARSER\MAIN.OBJ > > What went wrong? Well, the library you produced doesn't export that symbol. The BCB project files weren't maintained, so they were excluded from the source. Get a newer version and check win32\readme.txt for how to build libxml using Borland compiler. Ciao, Igor From cdevienne@alphacent.com Sun Oct 26 06:31:04 2003 Return-Path: Delivered-To: xml@gnome.org Received: from belgarath.arendia.home (ABoulogne-106-1-4-68.w80-14.abo.wanadoo.fr [80.14.33.68]) by mail.gnome.org (Postfix) with ESMTP id 0C4AC18367 for ; Sun, 26 Oct 2003 06:31:04 -0500 (EST) Received: from alphacent.com (tryo.arendia.home [192.168.2.50]) by belgarath.arendia.home (Postfix) with ESMTP id 33847328B; Sun, 26 Oct 2003 12:26:04 +0100 (CET) Message-ID: <3F9BB071.9080309@alphacent.com> Date: Sun, 26 Oct 2003 12:30:57 +0100 From: Christophe de Vienne User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031023 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: xml@gnome.org Cc: libxmlplusplus-general@lists.sourceforge.net Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [xml] xmlReader and _private Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi, While implementing xmlReader wrapper for libxml++ I faced a little problem with the _private field of xmlNode. xmlReader implementation in libxml2 do use this field, and since we use it in libxml++ to store a pointer to a xmlpp::Node which is automatically instanciated in the xmlRegisterNodeDefault callback, it leads to a segfault when it is deleted in the xmlDeregisterNodeDefault callback. I see 2 potential solutions to the problem : 1) Change libxml xmlreader implementation so it does not use _xmlNode._private. 2) Detect in the callbacks wether or not the node is created by xmlReader, and then don't do anything if it is the case. I would then implement Expand by copying the subtree to avoid some non wrapped nodes to be given to libxml++ user. Is one of this options possible ? And if not is there any other way to solve this issue ? Thanks, Christophe de Vienne From Murray.Cumming@Comneon.com Mon Oct 27 01:37:02 2003 Return-Path: Delivered-To: xml@gnome.org Received: from smtp1.infineon.com (smtp1.infineon.com [194.175.117.76]) by mail.gnome.org (Postfix) with ESMTP id E5AE31857F for ; Mon, 27 Oct 2003 01:37:01 -0500 (EST) Received: from vihsx03a.vih.infineon.com (vih.ifx-mail3.com [172.31.163.97]) by smtp1.infineon.com (8.12.10/8.12.10) with ESMTP id h9R6YTAl002263; Mon, 27 Oct 2003 07:34:30 +0100 (MET) Received: by vihsx03a.vih.infineon.com with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Oct 2003 07:37:29 +0100 Message-ID: <258B0164D480D5118D900800062B3858018403AF@vihsx09a.vih.infineon.com> From: Murray.Cumming@Comneon.com To: cdevienne@alphacent.com, xml@gnome.org Cc: libxmlplusplus-general@lists.sourceforge.net Subject: RE: [xml] xmlReader and _private Date: Mon, 27 Oct 2003 07:37:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: > From: xml-admin@gnome.org [mailto:xml-admin@gnome.org] On > I see 2 potential solutions to the problem : > 1) Change libxml xmlreader implementation so it does not use > _xmlNode._private. As xmlreader is part of libxml itself, I consider this a bug. > 2) Detect in the callbacks wether or not the node is created by > xmlReader, and then don't do anything if it is the case. I would then > implement Expand by copying the subtree to avoid some non > wrapped nodes > to be given to libxml++ user. That would be unpleasant. How about using a std::map of C++ instances to C instances instead of _private. But first, I'd ask about fixing xmlreader. > Is one of this options possible ? And if not is there any > other way to > solve this issue ? Murray Cumming www.murrayc.com murrayc@usa.net From mh@glandium.org Mon Oct 27 02:09:42 2003 Return-Path: Delivered-To: xml@gnome.org Received: from vaio.glandium.org (unknown [202.215.53.66]) by mail.gnome.org (Postfix) with ESMTP id DE3EB18874 for ; Mon, 27 Oct 2003 02:09:40 -0500 (EST) Received: from localhost ([127.0.0.1]) by vaio.glandium.org with esmtp (Exim 3.36 #1 (Debian)) id 1AE1VZ-0004ZG-00 for ; Mon, 27 Oct 2003 16:09:45 +0900 From: Mike Hommey Organization: glandium To: xml@gnome.org Date: Mon, 27 Oct 2003 16:09:43 +0900 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200310271609.43461.mh@glandium.org> Subject: [xml] New error layer seems to break ABI compatibility... Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hello Running a scrollkeeper-update linked against libxml2 2.5.11, with a 2.6.0=20 leads to a segmentation fault. Backtrace is as follows : Starting program: /usr/bin/scrollkeeper-update (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...[New Thread 16384 (LWP 17531)] (no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 17531)] 0x4007ac53 in __xmlRaiseError () from /usr/lib/libxml2.so.2 (gdb) backtrace #0 0x4007ac53 in __xmlRaiseError () from /usr/lib/libxml2.so.2 #1 0x400a874b in xmlCanonicPath () from /usr/lib/libxml2.so.2 #2 0x400afd6b in xmlValidateOneElement () from /usr/lib/libxml2.so.2 #3 0x400b0781 in xmlValidateElement () from /usr/lib/libxml2.so.2 #4 0x400b0816 in xmlValidateElement () from /usr/lib/libxml2.so.2 #5 0x400b0816 in xmlValidateElement () from /usr/lib/libxml2.so.2 #6 0x400b0ce9 in xmlValidateDtd () from /usr/lib/libxml2.so.2 #7 0x40026ad7 in install () from /usr/lib/libscrollkeeper.so.0 #8 0x08049a99 in bsearch () #9 0x4018ce3e in __libc_start_main () from /lib/libc.so.6 Which may lead to conclude that there is something incompatible with the ne= w=20 error management layer. I did not have time to investigate further, but if you have paths you want = me=20 to follow to track this incompatibility bug, I'll be happy to give a hand. Mike =2D-=20 "I have sampled every language, french is my favorite. Fantastic language, especially to curse with. Nom de dieu de putain de bordel de merde de saloperie de connard d'encul=E9 de ta m=E8re. It's like wiping your ass with silk! I love it." -- The Merovingian, in the Matrix Reloaded From mh@glandium.org Mon Oct 27 02:38:25 2003 Return-Path: Delivered-To: xml@gnome.org Received: from vaio.glandium.org (unknown [202.215.53.66]) by mail.gnome.org (Postfix) with ESMTP id 30F26181A4 for ; Mon, 27 Oct 2003 02:38:25 -0500 (EST) Received: from localhost ([127.0.0.1]) by vaio.glandium.org with esmtp (Exim 3.36 #1 (Debian)) id 1AE1xQ-0007X2-00 for ; Mon, 27 Oct 2003 16:38:32 +0900 From: Mike Hommey Organization: glandium To: xml@gnome.org Subject: Re: [xml] New error layer seems to break ABI compatibility... Date: Mon, 27 Oct 2003 16:38:31 +0900 User-Agent: KMail/1.5.4 References: <200310271609.43461.mh@glandium.org> In-Reply-To: <200310271609.43461.mh@glandium.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200310271638.31650.mh@glandium.org> Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Monday October 27 2003 16:09, Mike Hommey wrote: [...] > Which may lead to conclude that there is something incompatible with the > new error management layer. > > I did not have time to investigate further, but if you have paths you want > me to follow to track this incompatibility bug, I'll be happy to give a > hand. Investigating a bit further shows it is not an API breakage, but only an AB= I=20 breakage : recompiling scrollkeeper against libxml2 2.6.0 make it work=20 perfectly. Additional note about the initial problem : the segfault only happens on my= =20 system (Debian) when the gnome-applets package is installed, because it may= =20 contain invalid data for scrollkeeper (cf. backtrace calls) =2D-=20 "I have sampled every language, french is my favorite. Fantastic language, especially to curse with. Nom de dieu de putain de bordel de merde de saloperie de connard d'encul=E9 de ta m=E8re. It's like wiping your ass with silk! I love it." -- The Merovingian, in the Matrix Reloaded From malcolm@commsecure.com.au Mon Oct 27 04:08:12 2003 Return-Path: Delivered-To: xml@gnome.org Received: from commsecure.com.au (CommSecureAustPtyLtd.sb1.optus.net.au [203.202.148.106]) by mail.gnome.org (Postfix) with ESMTP id 5AFD018874 for ; Mon, 27 Oct 2003 04:08:08 -0500 (EST) Received: from sunhill.commsecure.com.au (sunhill.commsecure.com.au [172.16.15.1]) by commsecure.com.au (8.11.6/8.11.6) with ESMTP id h9R98L713757 for ; Mon, 27 Oct 2003 20:08:21 +1100 Received: from dialin-03.commsecure.com.au (dialin-03.commsecure.com.au [172.16.14.3]) by sunhill.commsecure.com.au (8.11.6/8.11.6) with ESMTP id h9R98Oe18900 for ; Mon, 27 Oct 2003 20:08:24 +1100 Subject: Re: [xml] New error layer seems to break ABI compatibility... From: Malcolm Tredinnick To: xml@gnome.org In-Reply-To: <200310271638.31650.mh@glandium.org> References: <200310271609.43461.mh@glandium.org> <200310271638.31650.mh@glandium.org> Content-Type: text/plain Message-Id: <1067245700.10935.6.camel@quirm.tredinnick.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 27 Oct 2003 20:08:21 +1100 Content-Transfer-Encoding: 7bit Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Mon, 2003-10-27 at 18:38, Mike Hommey wrote: > On Monday October 27 2003 16:09, Mike Hommey wrote: > [...] > > Which may lead to conclude that there is something incompatible with the > > new error management layer. > > > > I did not have time to investigate further, but if you have paths you want > > me to follow to track this incompatibility bug, I'll be happy to give a > > hand. > > Investigating a bit further shows it is not an API breakage, but only an ABI > breakage : recompiling scrollkeeper against libxml2 2.6.0 make it work > perfectly. I had seen the problem you mentioned, but had not realised it was due to an ABI problem. I have started to track it down and it's not inconceivable that the next scrollkeeper version will just detect the difference at runtime if possible. The problem is that it is hardly unlikely that scrollkeeper is doing something untoward under the covers. I shall poke at this a bit more and see if it's a problem of using non-public APIs or something. Thanks for narrowing it down a bit more. Malcolm From kbuchcik@4commerce.de Mon Oct 27 04:47:35 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mx01.qsc.de (mx01.qsc.de [213.148.129.14]) by mail.gnome.org (Postfix) with ESMTP id 72B5F189F9 for ; Mon, 27 Oct 2003 04:47:35 -0500 (EST) Received: from port-212-202-229-162.reverse.qsc.de ([212.202.229.162] helo=kisone) by mx01.qsc.de with smtp (Exim 3.35 #1) id 1AE3ya-0001Bh-00 for xml@gnome.org; Mon, 27 Oct 2003 10:47:52 +0100 From: Kasimier Buchcik To: X-Priority: 3 Received: from emission [10.254.2.2] by kisone [10.254.2.2] with SMTP eMission ESMTPServer; Mon, 27 Oct 2003 10:42:12 +0100 Received: from 4commerce.de (10.1.72.2 [10.1.72.2]) by kisone.kisnet.de with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VR3AG13Y; Mon, 27 Oct 2003 10:42:11 +0100 Message-ID: <3F9CE92E.2090207@4commerce.de> Date: Mon, 27 Oct 2003 10:45:18 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en X-eMessageService: eMission.SMTPServer Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [xml] unresolved external symbol Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi, I wrote this to the xslt mailing list, but no answer came, so I'll try=20 it here: I know this was asked many times before, but it seems that I still cannot manage the problem; linking libxslt 1.0.33 (from cvs) against=20 libxml2 2.6.0 (from cvs), I get the following errors: numbers.obj : error LNK2001: unresolved external symbol _xmlCharInRange pattern.obj : error LNK2001: unresolved external symbol _xmlCharInRange I added xmlCharInRange to the win32/libxml2.def.src file and recompiled;=20 the linker is still unhappy. Any hints about what is still missing? Kasimier From markus_keim@ordat.com Mon Oct 27 04:49:52 2003 Return-Path: Delivered-To: xml@gnome.org Received: from scom03.giessen.ordat (comm-int.ordat.com [195.226.66.99]) by mail.gnome.org (Postfix) with SMTP id 0B2C618A10 for ; Mon, 27 Oct 2003 04:49:52 -0500 (EST) Received: by scom03.giessen.ordat with Internet Mail Service (5.5.2657.72) id ; Mon, 27 Oct 2003 10:50:07 +0100 Message-ID: <9CED3C426350A947BF52D73899FAA0F420EB9D@scom03.giessen.ordat> From: "Keim, Markus" To: "libxml2 mailing List (E-Mail)" Subject: RE: [xml] Ignore external subset Date: Mon, 27 Oct 2003 10:50:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: > -----Original Message----- > From: Daniel Veillard [mailto:veillard@redhat.com] > Sent: Friday, October 24, 2003 10:51 PM > To: Keim, Markus > Cc: libxml2 mailing List (E-Mail) > Subject: Re: [xml] Ignore external subset > > > On Fri, Oct 24, 2003 at 06:28:27PM +0200, Keim, Markus wrote: > > > How can you expect to "validate" without fetching the external > > > subset if there is one ? I cannot understand such a requirement. > > > > Hum, i *don't* want to validate while parsing. > > On the contrary, i want to completely ignore the external subset, > > even if it's present, just parse in the document. > > Excellent, then you don't have anything to do, it's libxml2 > default behaviour. > > > While parsing i *can't* determine a base path for that documents, > > so, if "parseCtxt->loadsubset" is true (the default), the > > No that should not be the default. Something has changed that value. Oh, than i've to search that "something" in my code, i'm not aware to set it explicitly. > > Using an own external entity loader, i want to validate the > > document subsequently. > > If there is an internal subset that won't work. If there is only > an external subset compute the URI-Reference (uri.h) parse it as a DTD > (xmlParseDTD) and validate the resulting tree (see valid.h). Jep, that part is already working, just the "unwished" loading of the external subset dulls the picture... > Daniel Ciao, Markus From igor@zlatkovic.com Mon Oct 27 04:55:42 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail.zlatkovic.com (spell.zlatkovic.com [62.75.159.112]) by mail.gnome.org (Postfix) with ESMTP id 92560189A9 for ; Mon, 27 Oct 2003 04:55:41 -0500 (EST) Received: from zlatkovic.com (pD951B865.dip.t-dialin.net [217.81.184.101]) (authenticated bits=0) by mail.zlatkovic.com (8.12.8/8.12.8) with ESMTP id h9R9ttt6024468 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 27 Oct 2003 10:55:57 +0100 Message-ID: <3F9CEBAB.7040301@zlatkovic.com> Date: Mon, 27 Oct 2003 10:55:55 +0100 From: Igor Zlatkovic Organization: zlatkovic.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031008 X-Accept-Language: en, de MIME-Version: 1.0 To: Kasimier Buchcik Cc: xml@gnome.org Subject: Re: [xml] unresolved external symbol References: <3F9CE92E.2090207@4commerce.de> In-Reply-To: <3F9CE92E.2090207@4commerce.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Kasimier Buchcik wrote: > Hi, > > I wrote this to the xslt mailing list, but no answer came, so I'll try > it here: > > I know this was asked many times before, but it seems that I still > cannot manage the problem; linking libxslt 1.0.33 (from cvs) against > libxml2 2.6.0 (from cvs), I get the following errors: > > numbers.obj : error LNK2001: unresolved external symbol _xmlCharInRange > pattern.obj : error LNK2001: unresolved external symbol _xmlCharInRange > > I added xmlCharInRange to the win32/libxml2.def.src file and recompiled; > the linker is still unhappy. Any hints about what is still missing? This has been fixed, current CVS is okay. Besides, the libxml2.def.src file is no longer being used. Symbols now have declarations which mark them as exportable. Ciao, Igor From stephane.bidoul@softwareag.com Mon Oct 27 05:35:17 2003 Return-Path: Delivered-To: xml@gnome.org Received: from server8a.software-ag.de (server8a.software-ag.de [193.26.193.47]) by mail.gnome.org (Postfix) with ESMTP id 6427118A1E for ; Mon, 27 Oct 2003 05:35:16 -0500 (EST) Received: from acsesbi by server8a.software-ag.de; (8.11.6/8.9.3) id h9RAZ6F02202; Mon, 27 Oct 2003 11:35:16 +0100 From: "Stephane Bidoul" To: "'Igor Zlatkovic'" Cc: Subject: RE: [xml] unresolved external symbol Date: Mon, 27 Oct 2003 11:35:11 +0100 Message-ID: <005f01c39c76$017cdca0$5514200a@acsesbi> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <3F9CEBAB.7040301@zlatkovic.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: > Besides, the libxml2.def.src file is no longer being used. > Symbols now have > declarations which mark them as exportable. Maybe then libxml2.def.src and defgen.xsl should be removed from CVS? And, while you are at it, it seems that xmlwin32version.h is not used anymore either. -sbi From igor@zlatkovic.com Mon Oct 27 05:39:25 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail.zlatkovic.com (spell.zlatkovic.com [62.75.159.112]) by mail.gnome.org (Postfix) with ESMTP id 69AC018A06 for ; Mon, 27 Oct 2003 05:39:24 -0500 (EST) Received: from zlatkovic.com (pD951B865.dip.t-dialin.net [217.81.184.101]) (authenticated bits=0) by mail.zlatkovic.com (8.12.8/8.12.8) with ESMTP id h9RAdet6015685 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 27 Oct 2003 11:39:41 +0100 Message-ID: <3F9CF5EC.7030101@zlatkovic.com> Date: Mon, 27 Oct 2003 11:39:40 +0100 From: Igor Zlatkovic User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031008 X-Accept-Language: en, de MIME-Version: 1.0 To: Stephane Bidoul Cc: xml@gnome.org Subject: Re: [xml] unresolved external symbol References: <005f01c39c76$017cdca0$5514200a@acsesbi> In-Reply-To: <005f01c39c76$017cdca0$5514200a@acsesbi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Stephane Bidoul wrote: >>Besides, the libxml2.def.src file is no longer being used. >>Symbols now have >>declarations which mark them as exportable. > > > Maybe then libxml2.def.src and defgen.xsl > should be removed from CVS? > And, while you are at it, it seems that xmlwin32version.h > is not used anymore either. I don't know, is anyone using these? It can be that someone has a local setup which uses that .def.src thing. Give it a proper period of mourning :-) Ciao, Igor From veillard@redhat.com Mon Oct 27 06:25:17 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 923BC18183 for ; Mon, 27 Oct 2003 06:25:17 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9RBPXW29957; Mon, 27 Oct 2003 06:25:33 -0500 Date: Mon, 27 Oct 2003 06:25:33 -0500 From: Daniel Veillard To: Christophe de Vienne Cc: xml@gnome.org, libxmlplusplus-general@lists.sourceforge.net Subject: Re: [xml] xmlReader and _private Message-ID: <20031027062533.A19928@redhat.com> Reply-To: veillard@redhat.com References: <3F9BB071.9080309@alphacent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3F9BB071.9080309@alphacent.com>; from cdevienne@alphacent.com on Sun, Oct 26, 2003 at 12:30:57PM +0100 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Sun, Oct 26, 2003 at 12:30:57PM +0100, Christophe de Vienne wrote: > I see 2 potential solutions to the problem : > 1) Change libxml xmlreader implementation so it does not use > _xmlNode._private. This wasn't possible before 2.6.0 , I commited the change to CVS Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard@redhat.com Mon Oct 27 06:29:59 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 81C84187EB for ; Mon, 27 Oct 2003 06:29:59 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9RBUD132137; Mon, 27 Oct 2003 06:30:13 -0500 Date: Mon, 27 Oct 2003 06:30:13 -0500 From: Daniel Veillard To: Murray.Cumming@Comneon.com Cc: cdevienne@alphacent.com, xml@gnome.org, libxmlplusplus-general@lists.sourceforge.net Subject: Re: [xml] xmlReader and _private Message-ID: <20031027063013.B19928@redhat.com> Reply-To: veillard@redhat.com References: <258B0164D480D5118D900800062B3858018403AF@vihsx09a.vih.infineon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <258B0164D480D5118D900800062B3858018403AF@vihsx09a.vih.infineon.com>; from Murray.Cumming@Comneon.com on Mon, Oct 27, 2003 at 07:37:16AM +0100 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Mon, Oct 27, 2003 at 07:37:16AM +0100, Murray.Cumming@Comneon.com wrote: > > From: xml-admin@gnome.org [mailto:xml-admin@gnome.org] On > > I see 2 potential solutions to the problem : > > 1) Change libxml xmlreader implementation so it does not use > > _xmlNode._private. > > As xmlreader is part of libxml itself, I consider this a bug. Initially the xmlreader wasn't supposed to ever show the tree i.e. restricting itself to the C# API which only allows callback. The xmlNode and xmlDoc have only be made available later by extension functions from the core implementation. Anyway, fixed in CVS. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From Murray.Cumming@Comneon.com Mon Oct 27 06:31:20 2003 Return-Path: Delivered-To: xml@gnome.org Received: from smtp1.infineon.com (smtp1.infineon.com [194.175.117.76]) by mail.gnome.org (Postfix) with ESMTP id CB94B18856 for ; Mon, 27 Oct 2003 06:31:19 -0500 (EST) Received: from vihsx03a.vih.infineon.com (vih.ifx-mail3.com [172.31.163.97]) by smtp1.infineon.com (8.12.10/8.12.10) with ESMTP id h9RBSmAl003602; Mon, 27 Oct 2003 12:28:48 +0100 (MET) Received: by vihsx03a.vih.infineon.com with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Oct 2003 12:31:48 +0100 Message-ID: <258B0164D480D5118D900800062B38580184042D@vihsx09a.vih.infineon.com> From: Murray.Cumming@Comneon.com To: veillard@redhat.com, cdevienne@alphacent.com Cc: xml@gnome.org, libxmlplusplus-general@lists.sourceforge.net Subject: RE: [xml] xmlReader and _private Date: Mon, 27 Oct 2003 12:31:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: > From: xml-admin@gnome.org [mailto:xml-admin@gnome.org] On > On Sun, Oct 26, 2003 at 12:30:57PM +0100, Christophe de Vienne wrote: > > I see 2 potential solutions to the problem : > > 1) Change libxml xmlreader implementation so it does not use > > _xmlNode._private. > > This wasn't possible before 2.6.0 , I commited the change to CVS Thanks Daniel. That's very cool. Murray Cumming www.murrayc.com murrayc@usa.net From iinmgc00@ucv.udc.es Mon Oct 27 07:47:50 2003 Return-Path: Delivered-To: xml@gnome.org Received: from unica.udc.es (unica.udc.es [193.147.41.3]) by mail.gnome.org (Postfix) with ESMTP id 52EBE180F5 for ; Mon, 27 Oct 2003 07:47:50 -0500 (EST) Received: from unica.udc.es (localhost [127.0.0.1]) by unica.udc.es (8.12.8p1/8.12.3) with ESMTP id h9RFbghS014205 for ; Mon, 27 Oct 2003 14:37:42 -0100 (GMT) Received: from necora.cdf.udc.es (necora.eps.cdf.udc.es [193.147.41.4]) by unica.udc.es (8.12.8p1/8.12.3) with ESMTP id h9RFbfPQ014199 for ; Mon, 27 Oct 2003 14:37:41 -0100 (GMT) Received: from eps213 (eps213.eps.cdf.udc.es [193.144.52.213]) by necora.cdf.udc.es (8.12.8p1/8.11.3) with SMTP id h9RFhMIW003059 for ; Mon, 27 Oct 2003 14:43:23 -0100 (GMT) Message-ID: <00ba01c39c88$b2ee68c0$d53490c1@eps.cdf.udc.es> From: =?iso-8859-1?Q?Manuel_Gonz=E1lez_Castro?= To: References: <258B0164D480D5118D900800062B38580184042D@vihsx09a.vih.infineon.com> Date: Mon, 27 Oct 2003 13:48:57 +0100 Organization: UDC MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [xml] Parse unavailable document Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hello, Using libxml2-2.6.0 on Windows. Suppose that "systemId" contains an = unavalible URL, then=20 inputStream =3D xmlLoadExternalEntity(systemId, NULL, ctxt); will set "ctxt->lastError" to an I/O warning ("failed to load external = entity ..."). However, if I use xmlDocPtr doc =3D xmlCtxtReadFile(ctxt, systemId, NULL, 0); I get a : - NULL doc, - "ctxt->input" is NULL=20 - but "ctxt->lastError->level" is set to "XML_ERR_NONE".=20 1) Why "xmlCtxtReadFile" doesn't raise an I/O warning ? 2) If "xmlCtxtReadFile" returns a NULL doc and I want to check if the = URL is not valid, is enough to check if "ctxt->input" is NULL or should = I call "xmlLoadExternalEntity" and get the I/O warning to be sure that = the problem is that? Best regards, Manuel From cdevienne@alphacent.com Mon Oct 27 08:30:16 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail.alphacent.com (APuteaux-102-2-1-32.w193-251.abo.wanadoo.fr [193.251.91.32]) by mail.gnome.org (Postfix) with ESMTP id D0B1818126 for ; Mon, 27 Oct 2003 08:30:15 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.alphacent.com (Postfix) with ESMTP id 15F7D2DA45; Mon, 27 Oct 2003 14:30:38 +0100 (CET) Received: from immodium.alphacent.com (immodium.alphacent.com [192.168.1.7]) by mail.alphacent.com (Postfix) with ESMTP id D21B82DA29; Mon, 27 Oct 2003 14:30:36 +0100 (CET) Received: from immodium.alphacent.com (localhost [127.0.0.1]) by immodium.alphacent.com (Postfix) with ESMTP id ECFF93C9E7; Mon, 27 Oct 2003 14:30:39 +0100 (CET) Received: from alphacent.com (raoul.alphacent.com [192.168.1.63]) by immodium.alphacent.com (Postfix) with ESMTP id A9F6F3C9D1; Mon, 27 Oct 2003 14:30:34 +0100 (CET) Message-ID: <3F9D1DD0.7040400@alphacent.com> Date: Mon, 27 Oct 2003 14:29:52 +0100 From: Christophe de VIENNE User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031014 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: veillard@redhat.com Cc: Murray.Cumming@Comneon.com, xml@gnome.org, libxmlplusplus-general@lists.sourceforge.net Subject: Re: [xml] xmlReader and _private References: <258B0164D480D5118D900800062B3858018403AF@vihsx09a.vih.infineon.com> <20031027063013.B19928@redhat.com> In-Reply-To: <20031027063013.B19928@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Virus-Scanned: by AMaViS Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Daniel Veillard wrote: > Anyway, fixed in CVS. > > > That's great ! Thanks very much... Regards, Christophe From kbuchcik@4commerce.de Mon Oct 27 08:32:36 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mx01.qsc.de (mx01.qsc.de [213.148.129.14]) by mail.gnome.org (Postfix) with ESMTP id 31CB1181A5 for ; Mon, 27 Oct 2003 08:32:36 -0500 (EST) Received: from port-212-202-229-162.reverse.qsc.de ([212.202.229.162] helo=kisone) by mx01.qsc.de with smtp (Exim 3.35 #1) id 1AE7UL-0006bI-00 for xml@gnome.org; Mon, 27 Oct 2003 14:32:53 +0100 From: Kasimier Buchcik To: X-Priority: 3 Received: from emission [10.254.2.2] by kisone [10.254.2.2] with SMTP eMission ESMTPServer; Mon, 27 Oct 2003 14:26:45 +0100 Received: from 4commerce.de (10.1.72.2 [10.1.72.2]) by kisone.kisnet.de with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VR3AG1Q1; Mon, 27 Oct 2003 14:26:45 +0100 Message-ID: <3F9D1DDB.9050403@4commerce.de> Date: Mon, 27 Oct 2003 14:30:03 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en References: <3F9CE92E.2090207@4commerce.de> <3F9CEBAB.7040301@zlatkovic.com> In-Reply-To: <3F9CEBAB.7040301@zlatkovic.com> X-eMessageService: eMission.SMTPServer Subject: "Re: [xml] unresolved external symbol" Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Igor Zlatkovic wrote: > Kasimier Buchcik wrote: >>I know this was asked many times before, but it seems that I still >>cannot manage the problem; linking libxslt 1.0.33 (from cvs) against=20 >>libxml2 2.6.0 (from cvs), I get the following errors: >> >>numbers.obj : error LNK2001: unresolved external symbol _xmlCharInRange >>pattern.obj : error LNK2001: unresolved external symbol _xmlCharInRange >> >>I added xmlCharInRange to the win32/libxml2.def.src file and recompiled;=20 >>the linker is still unhappy. Any hints about what is still missing? >=20 > This has been fixed, current CVS is okay. >=20 > Besides, the libxml2.def.src file is no longer being used. Symbols now hav= e=20 > declarations which mark them as exportable. I see. Hmm, guess the anonymous cvs lags just a bit... I still get these=20 errors. By the way, xmlCharInRange is declared in chvalid.h as follows: XMLPUBFUN int XMLCALL =09=09xmlCharInRange(unsigned int val, const mlChRangeGroupPtr group); What has to be additionally done to mark it exportable? Thanks, Kasimier From igor@zlatkovic.com Mon Oct 27 08:50:06 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail.zlatkovic.com (spell.zlatkovic.com [62.75.159.112]) by mail.gnome.org (Postfix) with ESMTP id 456A918A4B for ; Mon, 27 Oct 2003 08:50:06 -0500 (EST) Received: from zlatkovic.com (pD951B865.dip.t-dialin.net [217.81.184.101]) (authenticated bits=0) by mail.zlatkovic.com (8.12.8/8.12.8) with ESMTP id h9RDoDfI014956 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 27 Oct 2003 14:50:21 +0100 Message-ID: <3F9D2295.1090701@zlatkovic.com> Date: Mon, 27 Oct 2003 14:50:13 +0100 From: Igor Zlatkovic User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031008 X-Accept-Language: en, de MIME-Version: 1.0 To: Kasimier Buchcik Cc: xml@gnome.org Subject: Re: "Re: [xml] unresolved external symbol" References: <3F9CE92E.2090207@4commerce.de> <3F9CEBAB.7040301@zlatkovic.com> <3F9D1DDB.9050403@4commerce.de> In-Reply-To: <3F9D1DDB.9050403@4commerce.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Kasimier Buchcik wrote: > Igor Zlatkovic wrote: > >>Kasimier Buchcik wrote: >> >>>I know this was asked many times before, but it seems that I still >>>cannot manage the problem; linking libxslt 1.0.33 (from cvs) against >>>libxml2 2.6.0 (from cvs), I get the following errors: >>> >>>numbers.obj : error LNK2001: unresolved external symbol _xmlCharInRange >>>pattern.obj : error LNK2001: unresolved external symbol _xmlCharInRange >>> >>>I added xmlCharInRange to the win32/libxml2.def.src file and recompiled; >>>the linker is still unhappy. Any hints about what is still missing? >> >>This has been fixed, current CVS is okay. >> >>Besides, the libxml2.def.src file is no longer being used. Symbols now have >>declarations which mark them as exportable. > > > I see. Hmm, guess the anonymous cvs lags just a bit... I still get these > errors. > By the way, xmlCharInRange is declared in chvalid.h as follows: > > XMLPUBFUN int XMLCALL > xmlCharInRange(unsigned int val, const > mlChRangeGroupPtr group); > > What has to be additionally done to mark it exportable? It is allready marked as exportable. That XMLPUBFUN thing does the job. I have no idea what you are doing wrong. I compiled libxml, libxslt, xmlsec and xsldbg yesterday with no such error. 1. Check the libxml2.dll with dumpbin and confirm that it exports xmlCharInRange. 2. Check the libxml2.lib with dumpbin and confirm that it mentions xmlCharInRange. 3. Make sure your linker finds the right import library. Perhaps there is another libxml2.lib on your disc which the linker picks up instead of the intended one. Ciao, Igor From veillard@redhat.com Mon Oct 27 09:34:29 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 522BA18862 for ; Mon, 27 Oct 2003 09:34:29 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9REYh209901; Mon, 27 Oct 2003 09:34:43 -0500 Date: Mon, 27 Oct 2003 09:34:43 -0500 From: Daniel Veillard To: =?iso-8859-1?Q?Manuel_Gonz=E1lez_Castro?= Cc: xml@gnome.org Subject: Re: [xml] Parse unavailable document Message-ID: <20031027093443.E19928@redhat.com> Reply-To: veillard@redhat.com References: <258B0164D480D5118D900800062B38580184042D@vihsx09a.vih.infineon.com> <00ba01c39c88$b2ee68c0$d53490c1@eps.cdf.udc.es> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <00ba01c39c88$b2ee68c0$d53490c1@eps.cdf.udc.es>; from iinmgc00@ucv.udc.es on Mon, Oct 27, 2003 at 01:48:57PM +0100 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Mon, Oct 27, 2003 at 01:48:57PM +0100, Manuel González Castro wrote: > I get a : > - NULL doc, > - "ctxt->input" is NULL > - but "ctxt->lastError->level" is set to "XML_ERR_NONE". > > 1) Why "xmlCtxtReadFile" doesn't raise an I/O warning ? Well it's a bug, I got a report about it last week and fixed it in CVS this morning. > 2) If "xmlCtxtReadFile" returns a NULL doc and I want to check if the URL is not valid, is enough to check if "ctxt->input" is NULL or should I call "xmlLoadExternalEntity" and get the I/O warning to be sure that the problem is that? Hum, you should not have to do that kind of tricks, really the fix in 1/ is the proper way to proceed. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From kbuchcik@4commerce.de Mon Oct 27 09:37:23 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mx01.qsc.de (mx01.qsc.de [213.148.129.14]) by mail.gnome.org (Postfix) with ESMTP id 7D08D18A7B for ; Mon, 27 Oct 2003 09:37:23 -0500 (EST) Received: from port-212-202-229-162.reverse.qsc.de ([212.202.229.162] helo=kisone) by mx01.qsc.de with smtp (Exim 3.35 #1) id 1AE8V2-0008Ce-00 for xml@gnome.org; Mon, 27 Oct 2003 15:37:40 +0100 From: Kasimier Buchcik To: X-Priority: 3 Received: from emission [10.254.2.2] by kisone [10.254.2.2] with SMTP eMission ESMTPServer; Mon, 27 Oct 2003 15:34:14 +0100 Received: from 4commerce.de (10.1.72.2 [10.1.72.2]) by kisone.kisnet.de with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VR3AG1QQ; Mon, 27 Oct 2003 15:34:14 +0100 Message-ID: <3F9D2DAC.20007@4commerce.de> Date: Mon, 27 Oct 2003 15:37:32 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en References: <3F9CE92E.2090207@4commerce.de> <3F9CEBAB.7040301@zlatkovic.com> <3F9D1DDB.9050403@4commerce.de> <3F9D2295.1090701@zlatkovic.com> In-Reply-To: <3F9D2295.1090701@zlatkovic.com> X-eMessageService: eMission.SMTPServer Subject: "Re: [xml] unresolved external symbol" Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Igor Zlatkovic wrote: > Kasimier Buchcik wrote: >>Igor Zlatkovic wrote: >>>Kasimier Buchcik wrote: einordnen :-) Jesus, who wrote what? >>>>I know this was asked many times before, but it seems that I still >>>>cannot manage the problem; linking libxslt 1.0.33 (from cvs) against=20 >>>>libxml2 2.6.0 (from cvs), I get the following errors: >>>> >>>>numbers.obj : error LNK2001: unresolved external symbol _xmlCharInRange >>>>pattern.obj : error LNK2001: unresolved external symbol _xmlCharInRange >>>> >>>>I added xmlCharInRange to the win32/libxml2.def.src file and recompiled;= =20 >>>>the linker is still unhappy. Any hints about what is still missing? >>> >>>This has been fixed, current CVS is okay. >>> >>>Besides, the libxml2.def.src file is no longer being used. Symbols now ha= ve=20 >>>declarations which mark them as exportable. >> >> >>I see. Hmm, guess the anonymous cvs lags just a bit... I still get these=20 >>errors. >>By the way, xmlCharInRange is declared in chvalid.h as follows: >> >>XMLPUBFUN int XMLCALL >>=09=09xmlCharInRange(unsigned int val, const >>mlChRangeGroupPtr group); >> >>What has to be additionally done to mark it exportable? >=20 >=20 > It is allready marked as exportable. That XMLPUBFUN thing does the job. >=20 > I have no idea what you are doing wrong. I compiled libxml, libxslt, xmlse= c=20 > and xsldbg yesterday with no such error. >=20 > 1. Check the libxml2.dll with dumpbin and confirm that it exports=20 > xmlCharInRange. > 2. Check the libxml2.lib with dumpbin and confirm that it mentions=20 > xmlCharInRange. > 3. Make sure your linker finds the right import library. Perhaps there is=20 > another libxml2.lib on your disc which the linker picks up instead of the=20 > intended one. >=20 > Ciao, > Igor dumpbin says that the produced libxml2.dll does *not* export=20 xmlCharInRange; neither it is mentioned in libxml2.lib. I checked the compile messages once again and found the following: -------------- chvalid.c ..\chvalid.c(163) : warning C4028: formal parameter 2 different from=20 declaration -------------- in chvalid.c we got: xmlCharInRange (unsigned int val, xmlChRangeGroupPtr rptr) in chvalid.h we got: XMLPUBFUN int XMLCALL =09=09xmlCharInRange(unsigned int val, const xmlChRangeGroupPtr group) Note the different argument names "rptr" & "group" in both functions. Could that be the reason why the function is not exported? Greetings, Kasimier From veillard@redhat.com Mon Oct 27 09:56:24 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id D18C318501 for ; Mon, 27 Oct 2003 09:56:23 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9REudI20224; Mon, 27 Oct 2003 09:56:39 -0500 Date: Mon, 27 Oct 2003 09:56:39 -0500 From: Daniel Veillard To: Kasimier Buchcik Cc: xml@gnome.org Subject: Re: "Re: [xml] unresolved external symbol" Message-ID: <20031027095638.F19928@redhat.com> Reply-To: veillard@redhat.com References: <3F9CE92E.2090207@4commerce.de> <3F9CEBAB.7040301@zlatkovic.com> <3F9D1DDB.9050403@4commerce.de> <3F9D2295.1090701@zlatkovic.com> <3F9D2DAC.20007@4commerce.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3F9D2DAC.20007@4commerce.de>; from kbuchcik@4commerce.de on Mon, Oct 27, 2003 at 03:37:32PM +0100 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Mon, Oct 27, 2003 at 03:37:32PM +0100, Kasimier Buchcik wrote: > > I checked the compile messages once again and found the following: > -------------- > chvalid.c > ..\chvalid.c(163) : warning C4028: formal parameter 2 different from > declaration > -------------- > > in chvalid.c we got: > > xmlCharInRange (unsigned int val, xmlChRangeGroupPtr rptr) > > in chvalid.h we got: > > XMLPUBFUN int XMLCALL > xmlCharInRange(unsigned int val, const xmlChRangeGroupPtr group) yeah, I fixed that in CVS last week I think, > Note the different argument names "rptr" & "group" in both functions. > Could that be the reason why the function is not exported? I rather think it's the missing "const", Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From kbuchcik@4commerce.de Mon Oct 27 10:02:36 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mx01.qsc.de (mx01.qsc.de [213.148.129.14]) by mail.gnome.org (Postfix) with ESMTP id 4B7671825F for ; Mon, 27 Oct 2003 10:02:36 -0500 (EST) Received: from port-212-202-229-162.reverse.qsc.de ([212.202.229.162] helo=kisone) by mx01.qsc.de with smtp (Exim 3.35 #1) id 1AE8tR-0000L5-00 for xml@gnome.org; Mon, 27 Oct 2003 16:02:53 +0100 From: Kasimier Buchcik To: X-Priority: 3 Received: from emission [10.254.2.2] by kisone [10.254.2.2] with SMTP eMission ESMTPServer; Mon, 27 Oct 2003 15:57:50 +0100 Received: from 4commerce.de (10.1.72.2 [10.1.72.2]) by kisone.kisnet.de with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VR3AG1Q6; Mon, 27 Oct 2003 15:57:49 +0100 Message-ID: <3F9D3333.5090202@4commerce.de> Date: Mon, 27 Oct 2003 16:01:07 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en References: <3F9CE92E.2090207@4commerce.de> <3F9CEBAB.7040301@zlatkovic.com> <3F9D1DDB.9050403@4commerce.de> <3F9D2295.1090701@zlatkovic.com> <3F9D2DAC.20007@4commerce.de> <20031027095638.F19928@redhat.com> In-Reply-To: <20031027095638.F19928@redhat.com> X-eMessageService: eMission.SMTPServer Subject: "Re: [xml] unresolved external symbol" Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Daniel Veillard wrote: > On Mon, Oct 27, 2003 at 03:37:32PM +0100, Kasimier Buchcik wrote: >=20 >>I checked the compile messages once again and found the following: >>-------------- >>chvalid.c >>..\chvalid.c(163) : warning C4028: formal parameter 2 different from=20 >>declaration >>-------------- >> >>in chvalid.c we got: >> >>xmlCharInRange (unsigned int val, xmlChRangeGroupPtr rptr) >> >>in chvalid.h we got: >> >>XMLPUBFUN int XMLCALL >>=09=09xmlCharInRange(unsigned int val, const xmlChRangeGroupPtr group) >=20 >=20 > yeah, I fixed that in CVS last week I think, >=20 >=20 >>Note the different argument names "rptr" & "group" in both functions. >>Could that be the reason why the function is not exported? >=20 >=20 > I rather think it's the missing "const", Hmm, I updated the module libxml2 2.6.0 an hour ago... I the cvs lagging=20 that much? Kasimier From kbuchcik@4commerce.de Mon Oct 27 10:02:39 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mx01.qsc.de (mx01.qsc.de [213.148.129.14]) by mail.gnome.org (Postfix) with ESMTP id 1CC691825F for ; Mon, 27 Oct 2003 10:02:39 -0500 (EST) Received: from port-212-202-229-162.reverse.qsc.de ([212.202.229.162] helo=kisone) by mx01.qsc.de with smtp (Exim 3.35 #1) id 1AE8tU-0000LG-00 for xml@gnome.org; Mon, 27 Oct 2003 16:02:56 +0100 From: Kasimier Buchcik To: X-Priority: 3 Received: from emission [10.254.2.2] by kisone [10.254.2.2] with SMTP eMission ESMTPServer; Mon, 27 Oct 2003 15:56:17 +0100 Received: from 4commerce.de (10.1.72.2 [10.1.72.2]) by kisone.kisnet.de with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VR3AG1QX; Mon, 27 Oct 2003 15:56:17 +0100 Message-ID: <3F9D32D7.1040304@4commerce.de> Date: Mon, 27 Oct 2003 15:59:35 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en References: <3F9CE92E.2090207@4commerce.de> <3F9CEBAB.7040301@zlatkovic.com> <3F9D1DDB.9050403@4commerce.de> <3F9D2295.1090701@zlatkovic.com> <3F9D2DAC.20007@4commerce.de> <20031027095638.F19928@redhat.com> In-Reply-To: <20031027095638.F19928@redhat.com> X-eMessageService: eMission.SMTPServer Subject: "Re: [xml] unresolved external symbol" Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Daniel Veillard wrote: > On Mon, Oct 27, 2003 at 03:37:32PM +0100, Kasimier Buchcik wrote: >=20 >>I checked the compile messages once again and found the following: >>-------------- >>chvalid.c >>..\chvalid.c(163) : warning C4028: formal parameter 2 different from=20 >>declaration >>-------------- >> >>in chvalid.c we got: >> >>xmlCharInRange (unsigned int val, xmlChRangeGroupPtr rptr) >> >>in chvalid.h we got: >> >>XMLPUBFUN int XMLCALL >>=09=09xmlCharInRange(unsigned int val, const xmlChRangeGroupPtr group) >=20 >=20 > yeah, I fixed that in CVS last week I think, >=20 >=20 >>Note the different argument names "rptr" & "group" in both functions. >>Could that be the reason why the function is not exported? >=20 >=20 > I rather think it's the missing "const", >=20 > Daniel >=20 From igor@zlatkovic.com Mon Oct 27 10:12:24 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail.zlatkovic.com (spell.zlatkovic.com [62.75.159.112]) by mail.gnome.org (Postfix) with ESMTP id 1CE37181AF for ; Mon, 27 Oct 2003 10:12:24 -0500 (EST) Received: from zlatkovic.com (pD951B865.dip.t-dialin.net [217.81.184.101]) (authenticated bits=0) by mail.zlatkovic.com (8.12.8/8.12.8) with ESMTP id h9RFCcfI018183 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 27 Oct 2003 16:12:39 +0100 Message-ID: <3F9D35E6.2030204@zlatkovic.com> Date: Mon, 27 Oct 2003 16:12:38 +0100 From: Igor Zlatkovic User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031008 X-Accept-Language: en, de MIME-Version: 1.0 To: veillard@redhat.com Cc: Kasimier Buchcik , xml@gnome.org Subject: Re: "Re: [xml] unresolved external symbol" References: <3F9CE92E.2090207@4commerce.de> <3F9CEBAB.7040301@zlatkovic.com> <3F9D1DDB.9050403@4commerce.de> <3F9D2295.1090701@zlatkovic.com> <3F9D2DAC.20007@4commerce.de> <20031027095638.F19928@redhat.com> In-Reply-To: <20031027095638.F19928@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Daniel Veillard wrote: > On Mon, Oct 27, 2003 at 03:37:32PM +0100, Kasimier Buchcik wrote: > >>I checked the compile messages once again and found the following: >>-------------- >>chvalid.c >>..\chvalid.c(163) : warning C4028: formal parameter 2 different from >>declaration >>-------------- >> >>in chvalid.c we got: >> >>xmlCharInRange (unsigned int val, xmlChRangeGroupPtr rptr) >> >>in chvalid.h we got: >> >>XMLPUBFUN int XMLCALL >> xmlCharInRange(unsigned int val, const xmlChRangeGroupPtr group) > > > yeah, I fixed that in CVS last week I think, > > >>Note the different argument names "rptr" & "group" in both functions. >>Could that be the reason why the function is not exported? Parameter names in declaration and implementation don't mean a thing, it is allowed to use different ones. The compiler warning comes from the "const" being in one but not in the other. The warning is harmless. > > I rather think it's the missing "const", That's the reason for the warning, but has nothing to do with exportability. In our case, symbols are exported only by names. Parameter, not parameter or const parameter has no influence here. There are more functions where declaration says const, implementation doesn't and they are still exported. Ciao, Igor From kbuchcik@4commerce.de Mon Oct 27 10:17:36 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mx01.qsc.de (mx01.qsc.de [213.148.129.14]) by mail.gnome.org (Postfix) with ESMTP id 533E7185FA for ; Mon, 27 Oct 2003 10:17:36 -0500 (EST) Received: from port-212-202-229-162.reverse.qsc.de ([212.202.229.162] helo=kisone) by mx01.qsc.de with smtp (Exim 3.35 #1) id 1AE97x-0000fA-00 for xml@gnome.org; Mon, 27 Oct 2003 16:17:53 +0100 From: Kasimier Buchcik To: X-Priority: 3 Received: from emission [10.254.2.2] by kisone [10.254.2.2] with SMTP eMission ESMTPServer; Mon, 27 Oct 2003 16:14:28 +0100 Received: from 4commerce.de (10.1.72.2 [10.1.72.2]) by kisone.kisnet.de with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VR3AG1RG; Mon, 27 Oct 2003 16:14:28 +0100 Message-ID: <3F9D371A.3020904@4commerce.de> Date: Mon, 27 Oct 2003 16:17:46 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en References: <3F9CE92E.2090207@4commerce.de> <3F9CEBAB.7040301@zlatkovic.com> <3F9D1DDB.9050403@4commerce.de> <3F9D2295.1090701@zlatkovic.com> <3F9D2DAC.20007@4commerce.de> <20031027095638.F19928@redhat.com> <3F9D3333.5090202@4commerce.de> In-Reply-To: <3F9D3333.5090202@4commerce.de> X-eMessageService: eMission.SMTPServer Subject: "Re: [xml] unresolved external symbol" Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi, Myomy... I had better look at the cvs graph: I just updated with "cvs=20 -z3 update -r 1.10 chvalid.c" and got the fixed file. Kasimier Buchcik wrote: > Daniel Veillard wrote: >>On Mon, Oct 27, 2003 at 03:37:32PM +0100, Kasimier Buchcik wrote: >>>I checked the compile messages once again and found the following: >>>-------------- >>>chvalid.c >>>..\chvalid.c(163) : warning C4028: formal parameter 2 different from=20 >>>declaration >>>-------------- >>> >>>in chvalid.c we got: >>> >>>xmlCharInRange (unsigned int val, xmlChRangeGroupPtr rptr) >>> >>>in chvalid.h we got: >>> >>>XMLPUBFUN int XMLCALL >>>=09=09xmlCharInRange(unsigned int val, const xmlChRangeGroupPtr group) >> >> >> yeah, I fixed that in CVS last week I think, >> >> >> >>>Note the different argument names "rptr" & "group" in both functions. >>>Could that be the reason why the function is not exported? >> >> >> I rather think it's the missing "const", >=20 >=20 > Hmm, I updated the module libxml2 2.6.0 an hour ago... I the cvs lagging=20 > that much? Thanks, Kasimier Buchcik From veillard@redhat.com Mon Oct 27 10:29:03 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id A5B2E18184 for ; Mon, 27 Oct 2003 10:29:02 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9RFTH004683; Mon, 27 Oct 2003 10:29:17 -0500 Date: Mon, 27 Oct 2003 10:29:17 -0500 From: Daniel Veillard To: Kasimier Buchcik Cc: xml@gnome.org Subject: Re: "Re: [xml] unresolved external symbol" Message-ID: <20031027102917.G19928@redhat.com> Reply-To: veillard@redhat.com References: <3F9CE92E.2090207@4commerce.de> <3F9CEBAB.7040301@zlatkovic.com> <3F9D1DDB.9050403@4commerce.de> <3F9D2295.1090701@zlatkovic.com> <3F9D2DAC.20007@4commerce.de> <20031027095638.F19928@redhat.com> <3F9D3333.5090202@4commerce.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3F9D3333.5090202@4commerce.de>; from kbuchcik@4commerce.de on Mon, Oct 27, 2003 at 04:01:07PM +0100 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Mon, Oct 27, 2003 at 04:01:07PM +0100, Kasimier Buchcik wrote: > > I rather think it's the missing "const", > > Hmm, I updated the module libxml2 2.6.0 an hour ago... I the cvs lagging > that much? Hum, no the 'const' bug is fixed in CVS, and have been for a while. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From jdaily@progeny.com Mon Oct 27 10:50:44 2003 Return-Path: Delivered-To: xml@gnome.org Received: from morimoto.progeny.com (morimoto.progeny.com [216.37.46.163]) by mail.gnome.org (Postfix) with ESMTP id 344E71829D for ; Mon, 27 Oct 2003 10:50:44 -0500 (EST) Received: from pigwidgeon.progeny.com (dhcp-1-203.progeny.com [192.168.1.203]) by morimoto.progeny.com (Postfix) with ESMTP id 8BC8C636AA for ; Mon, 27 Oct 2003 10:51:01 -0500 (EST) To: xml@gnome.org Subject: Re: [xml] Entity output query In-Reply-To: Your message of "Wed, 22 Oct 2003 14:19:02 EST." <20031022192250.E143B636A8@morimoto.progeny.com> References: <20031022192250.E143B636A8@morimoto.progeny.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <11050.1067269606.0@pigwidgeon.progeny.com> X-Mailer: mh-e 6.1; nmh 1.1-RC1; Emacs 21.2 Date: Mon, 27 Oct 2003 10:46:52 -0500 From: John Daily Message-Id: <20031027155101.8BC8C636AA@morimoto.progeny.com> Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11050.1067269606.1@pigwidgeon.progeny.com> I've been unable to infer a meaningful answer from the silence that greeted this question. Shall I just submit this to the bug system? If it helps, I've attached some documents which, when processed with xsltproc, will demonstrate the issue. broken.xsl results in the raw 8-bit character; works.xsl generates the XML entity. -John At (time_t)756596365 "John R. Daily" wrote: > In xmlEncodeEntitiesReentrant() in entities.c, the following > logic appears at line 481 (as of version 2.6.0): > > } else if (*cur >= 0x80) { > if (((doc != NULL) && (doc->encoding != NULL)) || (html)) { > /* Simply copy the character */ > } else { > /* Translate into an entity */ > } > > The decision of whether to copy an 8-bit character or turn it > into an entity seems to be: > > If we have an encoding for the output, or if we are generating > HTML, don't construct an entity. > > Thus the probability of turning an 8-bit character into an entity > would seem to be very low. > > This strikes me as a rather strange way to make the decision; > when I'm converting to HTML, I'd much rather have the entity than > the raw character. In fact, the else clause knows how to > generate HTML entities, but will never do so. > > > I don't know what the "right" logic is; I'm definitely curious > under what circumstances it is desirable to _not_ generate > entities in XML/HTML output. > > -- > John R. Daily jdaily@progeny.com > Director of Technology Progeny Linux Systems > Master of the ephemeral epiphany > _______________________________________________ > xml mailing list, project page http://xmlsoft.org/ > xml@gnome.org > http://mail.gnome.org/mailman/listinfo/xml > ------- =_aaaaaaaaaa0 Content-Type: text/plain; name="small.xml"; charset="us-ascii" Content-ID: <11050.1067269606.2@pigwidgeon.progeny.com> Content-Description: XML content This is a copyright symbol: © ------- =_aaaaaaaaaa0 Content-Type: text/plain; name="broken.xsl"; charset="us-ascii" Content-ID: <11050.1067269606.3@pigwidgeon.progeny.com> Content-Description: Generates 8-bit character ------- =_aaaaaaaaaa0 Content-Type: text/plain; name="works.xsl"; charset="us-ascii" Content-ID: <11050.1067269606.4@pigwidgeon.progeny.com> Content-Description: Generates XML entity ------- =_aaaaaaaaaa0-- From kbuchcik@4commerce.de Mon Oct 27 10:52:36 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mx01.qsc.de (mx01.qsc.de [213.148.129.14]) by mail.gnome.org (Postfix) with ESMTP id 77F6518173 for ; Mon, 27 Oct 2003 10:52:36 -0500 (EST) Received: from port-212-202-229-162.reverse.qsc.de ([212.202.229.162] helo=kisone) by mx01.qsc.de with smtp (Exim 3.35 #1) id 1AE9fp-0001QY-00 for xml@gnome.org; Mon, 27 Oct 2003 16:52:53 +0100 From: Kasimier Buchcik To: X-Priority: 3 Received: from emission [10.254.2.2] by kisone [10.254.2.2] with SMTP eMission ESMTPServer; Mon, 27 Oct 2003 16:48:56 +0100 Received: from 4commerce.de (10.1.72.2 [10.1.72.2]) by kisone.kisnet.de with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VR3AG1R4; Mon, 27 Oct 2003 16:48:56 +0100 Message-ID: <3F9D3F2D.6070801@4commerce.de> Date: Mon, 27 Oct 2003 16:52:13 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en References: <3F9CE92E.2090207@4commerce.de> <3F9CEBAB.7040301@zlatkovic.com> <3F9D1DDB.9050403@4commerce.de> <3F9D2295.1090701@zlatkovic.com> <3F9D2DAC.20007@4commerce.de> <20031027095638.F19928@redhat.com> <3F9D3333.5090202@4commerce.de> <20031027102917.G19928@redhat.com> In-Reply-To: <20031027102917.G19928@redhat.com> X-eMessageService: eMission.SMTPServer Subject: "Re: [xml] unresolved external symbol" Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi, Daniel Veillard wrote: > On Mon, Oct 27, 2003 at 04:01:07PM +0100, Kasimier Buchcik wrote: >=20 >>> I rather think it's the missing "const", >> >>Hmm, I updated the module libxml2 2.6.0 an hour ago... I the cvs lagging=20 >> that much? > Hum, no the 'const' bug is fixed in CVS, and have been for a while. >=20 > Daniel It was my fault, I was to blind to check out the latest revision :-/ Everything is fine now. Thanks anyway, Kasimier Buchcik From veillard@redhat.com Mon Oct 27 12:26:23 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 0C90D187CF for ; Mon, 27 Oct 2003 12:26:23 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9RHQda07859; Mon, 27 Oct 2003 12:26:39 -0500 Date: Mon, 27 Oct 2003 12:26:39 -0500 From: Daniel Veillard To: John Daily Cc: xml@gnome.org Subject: Re: [xml] Entity output query Message-ID: <20031027122639.K19928@redhat.com> Reply-To: veillard@redhat.com References: <20031022192250.E143B636A8@morimoto.progeny.com> <20031027155101.8BC8C636AA@morimoto.progeny.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031027155101.8BC8C636AA@morimoto.progeny.com>; from jdaily@progeny.com on Mon, Oct 27, 2003 at 10:46:52AM -0500 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Mon, Oct 27, 2003 at 10:46:52AM -0500, John Daily wrote: > I've been unable to infer a meaningful answer from the silence > that greeted this question. Shall I just submit this to the bug > system? yes that's the best way to make sure it won't be forgotten. > If it helps, I've attached some documents which, when processed > with xsltproc, will demonstrate the issue. > > broken.xsl results in the raw 8-bit character; works.xsl > generates the XML entity. please attach them to the bugzilla report, thanks ! Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From pajas@ufal.ms.mff.cuni.cz Mon Oct 27 14:22:04 2003 Return-Path: Delivered-To: xml@gnome.org Received: from smtp1.vol.cz (smtp1.vol.cz [195.250.128.73]) by mail.gnome.org (Postfix) with ESMTP id A975F1833A for ; Mon, 27 Oct 2003 14:22:03 -0500 (EST) Received: from ufal.ms.mff.cuni.cz (prahaf-5-51.dialup.vol.cz [62.177.77.183]) by smtp1.vol.cz (8.12.8p2/8.12.8) with ESMTP id h9RJMJdO071627 for ; Mon, 27 Oct 2003 20:22:19 +0100 (CET) (envelope-from pajas@ufal.ms.mff.cuni.cz) Message-ID: <3F9D717F.4070003@ufal.ms.mff.cuni.cz> Date: Mon, 27 Oct 2003 20:26:55 +0100 From: Petr Pajas User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031014 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: xml@gnome.org Content-Type: multipart/mixed; boundary="------------020001030300070700040308" Subject: [xml] xmlReconciliateNs problem Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. --------------020001030300070700040308 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Daniel, All, I'm trying to make XML::LibXML perl module work with 2.6. After examining one of the self tests that broke after upgrade, I suspect that xmlReconciliateNs doesn't do its right job (if at all). The documentation says: "This function checks that all the namespaces declared within the given tree are properly declared. This is needed for example after Copy or Cut and then paste operations. ..." Now, I have a document like this: and try either: a) move one level up, into b) move into another document in both cases, expecting xmlReconciliateNs to create xmlns:x="http://foo.bar" on . This is at least what it used to do with libxml2-2.5.x. The attached file is my lame attempt of rewriting of the test case into C. It demonstrates the problem in the following way: 1) run it without parameters to check for a) 2) run it with 1 parameter (arbitrary) to check for b) 3) run it with 2 parameter (-"-) to check for b), freeing the original document as soon as was moved and namespaces reconciliated. I compile it with: gcc -I /usr/include/libxml2 -L /usr/lib -lxml2 -o testns testns.c with 2.6, I get 1) ./testns (bad: x:b has prefix but no namespace declared) 2) ./testns x (bad) 3) ./testns x x (even worse - maybe because of the new string reusing code?) while with 2.5.3: 1) ./testns 2) ./testns x 3) ./testns x x which all look well. I looked into the corresponding tree.c code. It appears, that xmlReconciliateNs simply does nothing, being fooled by xmlSearchNsByHref which returns node->ns even though it failed to find a corresponding nsDef. If the behavior of 2.6 is intended, is there a workaround? Thanks, -- Petr --------------020001030300070700040308 Content-Type: text/plain; name="testns.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="testns.c" #include #include #define COPY_BETWEEN_DOCUMENTS 1 /* * The document */ static xmlChar buffer[] = "\n\ \n"; int main(int argc, char **argv) { xmlDocPtr doc1 = NULL; xmlDocPtr doc2 = NULL; xmlNodePtr node = NULL; xmlNodePtr foo = NULL; xmlChar *buf = NULL; int len = 0; int copy_between_documents=0; int free_doc1_soon=0; if (argc>1) copy_between_documents = 1; if (argc>2) free_doc1_soon = 1; doc1 = xmlParseDoc(buffer); foo=xmlDocGetRootElement(doc1); /* foo */ node=foo->children->children; /* x:b */ if (copy_between_documents) { /* move x:b to a new document */ doc2 = xmlNewDoc((const xmlChar*) "1.0"); xmlSetTreeDoc(node, doc2); /* doc2 adopts node */ node->doc=doc2; xmlDocSetRootElement( doc2, node ); xmlReconciliateNs(doc2, node); /* fix namespaces */ if (free_doc1_soon) { /* free doc1 now?*/ if (doc1) xmlFreeDoc(doc1); doc1=NULL; } xmlDocDumpMemory(doc2, &buf, &len); } else { /* raise x:b 1 level into foo */ xmlUnlinkNode( node ); xmlAddChild( foo, node ); xmlReconciliateNs(doc1, node); /* fix namespaces */ xmlDocDumpMemory(doc1, &buf, &len); } printf("%s",buf); if (buf) xmlFree(buf); if (doc1) xmlFreeDoc(doc1); if (doc2) xmlFreeDoc(doc2); xmlCleanupParser(); xmlMemoryDump(); return(0); } --------------020001030300070700040308-- From pajas@ufal.ms.mff.cuni.cz Mon Oct 27 14:49:44 2003 Return-Path: Delivered-To: xml@gnome.org Received: from smtp1.vol.cz (smtp1.vol.cz [195.250.128.73]) by mail.gnome.org (Postfix) with ESMTP id 1C2751812C for ; Mon, 27 Oct 2003 14:49:44 -0500 (EST) Received: from ufal.ms.mff.cuni.cz (prahae-3-91.dialup.vol.cz [62.177.75.5]) by smtp1.vol.cz (8.12.8p2/8.12.8) with ESMTP id h9RJnxdO074804 for ; Mon, 27 Oct 2003 20:50:00 +0100 (CET) (envelope-from pajas@ufal.ms.mff.cuni.cz) Message-ID: <3F9D77FC.2030500@ufal.ms.mff.cuni.cz> Date: Mon, 27 Oct 2003 20:54:36 +0100 From: Petr Pajas User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031014 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: libxml2 Content-Type: multipart/mixed; boundary="------------040508030904020500020100" Subject: [xml] xmllint --postvalid sigsegv if no DTD present Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. --------------040508030904020500020100 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Daniel, I'm experiencing this with XML::LibXML too, but this time its reproducible with xmllint (applied on the attached document missing a DTD): $ valgrind xmllint --postvalid example/article_bad.xml ==984== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==984== Copyright (C) 2002, and GNU GPL'd, by Julian Seward. ==984== Using valgrind-1.9.5pre, a program instrumentation system for x86-linux. ==984== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward. ==984== Estimated CPU clock rate is 909 MHz ==984== For more details, rerun with: -v ==984==
Something here 12345 XML.com
Foo
Here's some leading text And here is the rest...
==984== Invalid read of size 4 ==984== at 0x40228D95: __xmlRaiseError (error.c:455) ==984== by 0x40256D15: xmlErrValid (valid.c:125) ==984== by 0x4025F27C: xmlValidateDocument (valid.c:6457) ==984== by 0x804BDDB: parseAndPrintFile (xmllint.c:1174) ==984== Address 0xFBAD20F2 is not stack'd, malloc'd or free'd Segmentation fault If it could be of any help, in the XML::LibXML case (same document), valgrind says: ==1029== Invalid read of size 4 ==1029== at 0x40228D95: __xmlRaiseError (error.c:455) ==1029== by 0x40256E15: xmlErrValidNode (valid.c:171) ==1029== by 0x4025D604: xmlValidateElementContent (valid.c:5138) ==1029== by 0x4025E0BD: xmlValidateOneElement (valid.c:5819) ==1029== Address 0x41401C0C is 0 bytes after a block of size 20 free'd ==1029== at 0x401631DC: free (in /usr/lib/valgrind/valgrind.so) ==1029== by 0x81247FD: Perl_PerlIO_close (in /usr/bin/perl) ==1029== by 0x80766FA: Perl_yylex (in /usr/bin/perl) ==1029== by 0x8088501: Perl_yyparse (in /usr/bin/perl) ==1029== ==1029== Invalid write of size 4 ==1029== at 0x40228CE3: __xmlRaiseError (error.c:515) ==1029== by 0x40256E15: xmlErrValidNode (valid.c:171) ==1029== by 0x4025D604: xmlValidateElementContent (valid.c:5138) ==1029== by 0x4025E0BD: xmlValidateOneElement (valid.c:5819) ==1029== Address 0x41401A94 is 4 bytes after a block of size 40 alloc'd ==1029== at 0x40162F43: malloc (in /usr/lib/valgrind/valgrind.so) ==1029== by 0x80AB505: Perl_safesysmalloc (in /usr/bin/perl) ==1029== by 0x8124248: PerlIO_push (in /usr/bin/perl) ==1029== by 0x812861A: PerlIOBuf_open (in /usr/bin/perl) ==1029== ==1029== Invalid write of size 4 ==1029== at 0x40228CF7: __xmlRaiseError (error.c:517) ==1029== by 0x40256E15: xmlErrValidNode (valid.c:171) ==1029== by 0x4025D604: xmlValidateElementContent (valid.c:5138) ==1029== by 0x4025E0BD: xmlValidateOneElement (valid.c:5819) ==1029== Address 0x41401A98 is 8 bytes after a block of size 40 alloc'd ==1029== at 0x40162F43: malloc (in /usr/lib/valgrind/valgrind.so) ==1029== by 0x80AB505: Perl_safesysmalloc (in /usr/bin/perl) ==1029== by 0x8124248: PerlIO_push (in /usr/bin/perl) ==1029== by 0x812861A: PerlIOBuf_open (in /usr/bin/perl) ==1029== ==1029== Invalid write of size 4 ==1029== at 0x40228D13: __xmlRaiseError (error.c:519) ==1029== by 0x40256E15: xmlErrValidNode (valid.c:171) ==1029== by 0x4025D604: xmlValidateElementContent (valid.c:5138) ==1029== by 0x4025E0BD: xmlValidateOneElement (valid.c:5819) ==1029== Address 0x41401A9C is 12 bytes after a block of size 40 alloc'd ==1029== at 0x40162F43: malloc (in /usr/lib/valgrind/valgrind.so) ==1029== by 0x80AB505: Perl_safesysmalloc (in /usr/bin/perl) ==1029== by 0x8124248: PerlIO_push (in /usr/bin/perl) ==1029== by 0x812861A: PerlIOBuf_open (in /usr/bin/perl) ==1029== ==1029== Invalid write of size 4 ==1029== at 0x40228D2F: __xmlRaiseError (error.c:521) ==1029== by 0x40256E15: xmlErrValidNode (valid.c:171) ==1029== by 0x4025D604: xmlValidateElementContent (valid.c:5138) ==1029== by 0x4025E0BD: xmlValidateOneElement (valid.c:5819) ==1029== Address 0x41401AA0 is not stack'd, malloc'd or free'd ==1029== ==1029== Invalid write of size 4 ==1029== at 0x40228D3B: __xmlRaiseError (error.c:522) ==1029== by 0x40256E15: xmlErrValidNode (valid.c:171) ==1029== by 0x4025D604: xmlValidateElementContent (valid.c:5138) ==1029== by 0x4025E0BD: xmlValidateOneElement (valid.c:5819) ==1029== Address 0x41401AA4 is not stack'd, malloc'd or free'd ==1029== ==1029== Invalid write of size 4 ==1029== at 0x40228D41: __xmlRaiseError (error.c:523) ==1029== by 0x40256E15: xmlErrValidNode (valid.c:171) ==1029== by 0x4025D604: xmlValidateElementContent (valid.c:5138) ==1029== by 0x4025E0BD: xmlValidateOneElement (valid.c:5819) ==1029== Address 0x41401AA8 is not stack'd, malloc'd or free'd ==1029== ==1029== Invalid write of size 4 ==1029== at 0x40228D47: __xmlRaiseError (error.c:524) ==1029== by 0x40256E15: xmlErrValidNode (valid.c:171) ==1029== by 0x4025D604: xmlValidateElementContent (valid.c:5138) ==1029== by 0x4025E0BD: xmlValidateOneElement (valid.c:5819) ==1029== Address 0x41401AB0 is 16 bytes before a block of size 20 alloc'd ==1029== at 0x40162F43: malloc (in /usr/lib/valgrind/valgrind.so) ==1029== by 0x80AB505: Perl_safesysmalloc (in /usr/bin/perl) ==1029== by 0x8124248: PerlIO_push (in /usr/bin/perl) ==1029== by 0x81266EF: PerlIOUnix_open (in /usr/bin/perl) ==1029== ==1029== Invalid write of size 4 ==1029== at 0x40228D52: __xmlRaiseError (error.c:525) ==1029== by 0x40256E15: xmlErrValidNode (valid.c:171) ==1029== by 0x4025D604: xmlValidateElementContent (valid.c:5138) ==1029== by 0x4025E0BD: xmlValidateOneElement (valid.c:5819) ==1029== Address 0x41401AAC is not stack'd, malloc'd or free'd -- Petr --------------040508030904020500020100 Content-Type: text/xml; name="article_bad.xml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="article_bad.xml"
Something here 12345 XML.com
Foo
Here's some leading text And here is the rest...
--------------040508030904020500020100-- From jfleck@inkstain.net Mon Oct 27 21:53:50 2003 Return-Path: Delivered-To: xml@gnome.org Received: from taka.swcp.com (taka.swcp.com [198.59.115.12]) by mail.gnome.org (Postfix) with ESMTP id 023D01812E for ; Mon, 27 Oct 2003 21:53:50 -0500 (EST) Received: from jelloiii (216.184.14.36.unused.swcp.com [216.184.14.36]) by taka.swcp.com (8.12.9/8.12.9) with ESMTP id h9S2s5Gk057449; Mon, 27 Oct 2003 19:54:05 -0700 (MST) Subject: Re: [xml] xmllint --postvalid sigsegv if no DTD present From: John Fleck To: Petr Pajas Cc: libxml2 In-Reply-To: <3F9D77FC.2030500@ufal.ms.mff.cuni.cz> References: <3F9D77FC.2030500@ufal.ms.mff.cuni.cz> Content-Type: text/plain Message-Id: <1067309746.1072.0.camel@jelloiii> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Mon, 27 Oct 2003 19:55:46 -0700 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on kaimen.swcp.com X-Spam-Status: No, hits=0.0 required=10.0 tests=none autolearn=no version=2.60 X-Spam-Level: Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: I can duplicate this with 2.6.0 (not with 2.5.11). Filed a bug so it won't get lost: http://bugzilla.gnome.org/show_bug.cgi?id=125653 Cheers, John On Mon, 2003-10-27 at 12:54, Petr Pajas wrote: > Hi Daniel, > > I'm experiencing this with XML::LibXML too, but this time its > reproducible with xmllint (applied on the attached document missing a DTD): > > $ valgrind xmllint --postvalid example/article_bad.xml > ==984== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. > ==984== Copyright (C) 2002, and GNU GPL'd, by Julian Seward. > ==984== Using valgrind-1.9.5pre, a program instrumentation system for > x86-linux. > ==984== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward. > ==984== Estimated CPU clock rate is 909 MHz > ==984== For more details, rerun with: -v > ==984== > >
> Something here > 12345 > XML.com >
Foo
> Here's some leading text > And here is the rest... >
> ==984== Invalid read of size 4 > ==984== at 0x40228D95: __xmlRaiseError (error.c:455) > ==984== by 0x40256D15: xmlErrValid (valid.c:125) > ==984== by 0x4025F27C: xmlValidateDocument (valid.c:6457) > ==984== by 0x804BDDB: parseAndPrintFile (xmllint.c:1174) > ==984== Address 0xFBAD20F2 is not stack'd, malloc'd or free'd > Segmentation fault > > If it could be of any help, > in the XML::LibXML case (same document), valgrind says: > > ==1029== Invalid read of size 4 > ==1029== at 0x40228D95: __xmlRaiseError (error.c:455) > ==1029== by 0x40256E15: xmlErrValidNode (valid.c:171) > ==1029== by 0x4025D604: xmlValidateElementContent (valid.c:5138) > ==1029== by 0x4025E0BD: xmlValidateOneElement (valid.c:5819) > ==1029== Address 0x41401C0C is 0 bytes after a block of size 20 free'd > ==1029== at 0x401631DC: free (in /usr/lib/valgrind/valgrind.so) > ==1029== by 0x81247FD: Perl_PerlIO_close (in /usr/bin/perl) > ==1029== by 0x80766FA: Perl_yylex (in /usr/bin/perl) > ==1029== by 0x8088501: Perl_yyparse (in /usr/bin/perl) > ==1029== > ==1029== Invalid write of size 4 > ==1029== at 0x40228CE3: __xmlRaiseError (error.c:515) > ==1029== by 0x40256E15: xmlErrValidNode (valid.c:171) > ==1029== by 0x4025D604: xmlValidateElementContent (valid.c:5138) > ==1029== by 0x4025E0BD: xmlValidateOneElement (valid.c:5819) > ==1029== Address 0x41401A94 is 4 bytes after a block of size 40 alloc'd > ==1029== at 0x40162F43: malloc (in /usr/lib/valgrind/valgrind.so) > ==1029== by 0x80AB505: Perl_safesysmalloc (in /usr/bin/perl) > ==1029== by 0x8124248: PerlIO_push (in /usr/bin/perl) > ==1029== by 0x812861A: PerlIOBuf_open (in /usr/bin/perl) > ==1029== > ==1029== Invalid write of size 4 > ==1029== at 0x40228CF7: __xmlRaiseError (error.c:517) > ==1029== by 0x40256E15: xmlErrValidNode (valid.c:171) > ==1029== by 0x4025D604: xmlValidateElementContent (valid.c:5138) > ==1029== by 0x4025E0BD: xmlValidateOneElement (valid.c:5819) > ==1029== Address 0x41401A98 is 8 bytes after a block of size 40 alloc'd > ==1029== at 0x40162F43: malloc (in /usr/lib/valgrind/valgrind.so) > ==1029== by 0x80AB505: Perl_safesysmalloc (in /usr/bin/perl) > ==1029== by 0x8124248: PerlIO_push (in /usr/bin/perl) > ==1029== by 0x812861A: PerlIOBuf_open (in /usr/bin/perl) > ==1029== > ==1029== Invalid write of size 4 > ==1029== at 0x40228D13: __xmlRaiseError (error.c:519) > ==1029== by 0x40256E15: xmlErrValidNode (valid.c:171) > ==1029== by 0x4025D604: xmlValidateElementContent (valid.c:5138) > ==1029== by 0x4025E0BD: xmlValidateOneElement (valid.c:5819) > ==1029== Address 0x41401A9C is 12 bytes after a block of size 40 alloc'd > ==1029== at 0x40162F43: malloc (in /usr/lib/valgrind/valgrind.so) > ==1029== by 0x80AB505: Perl_safesysmalloc (in /usr/bin/perl) > ==1029== by 0x8124248: PerlIO_push (in /usr/bin/perl) > ==1029== by 0x812861A: PerlIOBuf_open (in /usr/bin/perl) > ==1029== > ==1029== Invalid write of size 4 > ==1029== at 0x40228D2F: __xmlRaiseError (error.c:521) > ==1029== by 0x40256E15: xmlErrValidNode (valid.c:171) > ==1029== by 0x4025D604: xmlValidateElementContent (valid.c:5138) > ==1029== by 0x4025E0BD: xmlValidateOneElement (valid.c:5819) > ==1029== Address 0x41401AA0 is not stack'd, malloc'd or free'd > ==1029== > ==1029== Invalid write of size 4 > ==1029== at 0x40228D3B: __xmlRaiseError (error.c:522) > ==1029== by 0x40256E15: xmlErrValidNode (valid.c:171) > ==1029== by 0x4025D604: xmlValidateElementContent (valid.c:5138) > ==1029== by 0x4025E0BD: xmlValidateOneElement (valid.c:5819) > ==1029== Address 0x41401AA4 is not stack'd, malloc'd or free'd > ==1029== > ==1029== Invalid write of size 4 > ==1029== at 0x40228D41: __xmlRaiseError (error.c:523) > ==1029== by 0x40256E15: xmlErrValidNode (valid.c:171) > ==1029== by 0x4025D604: xmlValidateElementContent (valid.c:5138) > ==1029== by 0x4025E0BD: xmlValidateOneElement (valid.c:5819) > ==1029== Address 0x41401AA8 is not stack'd, malloc'd or free'd > ==1029== > ==1029== Invalid write of size 4 > ==1029== at 0x40228D47: __xmlRaiseError (error.c:524) > ==1029== by 0x40256E15: xmlErrValidNode (valid.c:171) > ==1029== by 0x4025D604: xmlValidateElementContent (valid.c:5138) > ==1029== by 0x4025E0BD: xmlValidateOneElement (valid.c:5819) > ==1029== Address 0x41401AB0 is 16 bytes before a block of size 20 alloc'd > ==1029== at 0x40162F43: malloc (in /usr/lib/valgrind/valgrind.so) > ==1029== by 0x80AB505: Perl_safesysmalloc (in /usr/bin/perl) > ==1029== by 0x8124248: PerlIO_push (in /usr/bin/perl) > ==1029== by 0x81266EF: PerlIOUnix_open (in /usr/bin/perl) > ==1029== > ==1029== Invalid write of size 4 > ==1029== at 0x40228D52: __xmlRaiseError (error.c:525) > ==1029== by 0x40256E15: xmlErrValidNode (valid.c:171) > ==1029== by 0x4025D604: xmlValidateElementContent (valid.c:5138) > ==1029== by 0x4025E0BD: xmlValidateOneElement (valid.c:5819) > ==1029== Address 0x41401AAC is not stack'd, malloc'd or free'd > > -- Petr > > ______________________________________________________________________ >
> Something here > 12345 > XML.com >
Foo
> Here's some leading text > And here is the rest... >
-- John Fleck jfleck@inkstain.net (h) http://www.inkstain.net "It makes me mad when someone writes or draws something that I can't get right away!" - Zippy the Pinhead From mh@glandium.org Mon Oct 27 22:25:31 2003 Return-Path: Delivered-To: xml@gnome.org Received: from vaio.glandium.org (unknown [202.215.53.66]) by mail.gnome.org (Postfix) with ESMTP id B7F6F180E7 for ; Mon, 27 Oct 2003 22:25:30 -0500 (EST) Received: from localhost ([127.0.0.1]) by vaio.glandium.org with esmtp (Exim 3.36 #1 (Debian)) id 1AEKUB-0000Gp-00 for ; Tue, 28 Oct 2003 12:25:35 +0900 From: Mike Hommey Organization: glandium To: xml@gnome.org Subject: Re: [xml] New error layer seems to break ABI compatibility... Date: Mon, 27 Oct 2003 22:18:39 +0900 User-Agent: KMail/1.5.4 References: <200310271609.43461.mh@glandium.org> <200310271638.31650.mh@glandium.org> In-Reply-To: <200310271638.31650.mh@glandium.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200310272218.39628.mh@glandium.org> Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Monday October 27 2003 16:38, Mike Hommey wrote: > On Monday October 27 2003 16:09, Mike Hommey wrote: > [...] > > > Which may lead to conclude that there is something incompatible with the > > new error management layer. > > > > I did not have time to investigate further, but if you have paths you > > want me to follow to track this incompatibility bug, I'll be happy to > > give a hand. > > Investigating a bit further shows it is not an API breakage, but only an > ABI breakage : recompiling scrollkeeper against libxml2 2.6.0 make it work > perfectly. Okay, I still don't understand how it happened to work properly at some tim= e,=20 but it appears that the scrollkeeper package compiled against libxml2 2.6.0= =20 doesn't work either. Now, I recompiled bith scrollkeeper and libxml2 with debugging symbols, so= =20 that backtrace is much more verbose : # gdb scrollkeeper-update GNU gdb 5.3-debian Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-linux"... (gdb) run Starting program: /usr/bin/scrollkeeper-update [New Thread 16384 (LWP 17982)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 17982)] 0x40079c53 in __xmlRaiseError (schannel=3D0, channel=3D0x40024450=20 , data=3D0xbfffe69f, ctx=3D0xbfffe69f, nod=3D0x804d918, domain=3D4, code= =3D518,=20 level=3DXML_ERR_ERROR, file=3D0x0, line=3D0, str1=3D0x804d958 "subject", str2=3D0x804d958 "sub= ject",=20 str3=3D0x0, int1=3D-1663232, int2=3D-1663232, msg=3D0x4012a1c0 "Element %s does not= carry=20 attribute %s\n") at error.c:453 453 if ((schannel =3D=3D NULL) && (ctxt !=3D NULL) && (ctxt->sa= x !=3D=20 NULL) && (gdb) bt #0 0x40079c53 in __xmlRaiseError (schannel=3D0, channel=3D0x40024450=20 , data=3D0xbfffe69f, ctx=3D0xbfffe69f, nod=3D0x804d918, domain=3D4, code= =3D518,=20 level=3DXML_ERR_ERROR, file=3D0x0, line=3D0, str1=3D0x804d958 "subject", str2=3D0x804d958 "sub= ject",=20 str3=3D0x0, int1=3D-1663232, int2=3D-1663232, msg=3D0x4012a1c0 "Element %s does not= carry=20 attribute %s\n") at error.c:453 #1 0x400a774b in xmlErrValidNode (ctxt=3D0xffe69f00, node=3D0xffe69f00,=20 error=3D-1663232, msg=3D0xffe69f00
, str1=3D0xbfffe69f = "", str2=3D0xffe69f00
, str3=3D0x0) at=20 valid.c:171 #2 0x400aed6b in xmlValidateOneElement (ctxt=3D0xbfffe6a0, doc=3D0x0,=20 elem=3D0x804d918) at valid.c:5941 #3 0x400af781 in xmlValidateElement (ctxt=3D0xbfffe6a0, doc=3D0x804d618,=20 elem=3D0x804d918) at valid.c:6062 #4 0x400af816 in xmlValidateElement (ctxt=3D0xbfffe6a0, doc=3D0x804d618,=20 elem=3D0x804d770) at valid.c:6073 #5 0x400af816 in xmlValidateElement (ctxt=3D0xbfffe6a0, doc=3D0x804d618,=20 elem=3D0x804d6b8) at valid.c:6073 #6 0x400afce9 in xmlValidateDtd (ctxt=3D0xbfffe6a0, doc=3D0xbfffe69f,=20 dtd=3D0xbfffe69f) at valid.c:6278 #7 0x4002609f in install ( omf_name=3D0x804c3a8 "/usr/share/omf/gnome-applets/gweather_applet-it.o= mf", scrollkeeper_dir=3D0xbffff760 "/var/lib/scrollkeeper", data_dir=3D0xbffff460 "/usr/share/scrollkeeper", outputprefs=3D0 '\0') = at=20 install.c:189 #8 0x08049d2b in main (argc=3D134529736, argv=3D0x0) at update.c:520 The interesting part is that xmllint also segfaults on the same file when=20 trying to run xmllint --dtdvalid /usr/share/xml/scrollkeeper/dtds/ scrollkeeper-omf.dtd /usr/share/omf/gnome-applets/gweather_applet-it.omf Here is the backtrace for that : # gdb xmllint GNU gdb 5.3-debian Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-linux"... (gdb) run --dtdvalid /usr/share/xml/scrollkeeper/dtds/scrollkeeper-omf.dtd / usr/share/omf/gnome-applets/gweather_applet-it.omf Starting program: /usr/bin/xmllint --dtdvalid /usr/share/xml/scrollkeeper/ dtds/scrollkeeper-omf.dtd /usr/share/omf/gnome-applets/gweather_applet-it.o= mf [New Thread 16384 (LWP 18055)] Applet GNOME Weather GNOME|Applets|Utility Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 18055)] 0x40043c53 in __xmlRaiseError (schannel=3D0, channel=3D0x8049f9c ,= =20 data=3D0x402b6ee0, ctx=3D0x402b6ee0, nod=3D0x806db10, domain=3D4, code=3D504, level=3DXML_= ERR_ERROR,=20 file=3D0x0, line=3D0, str1=3D0x80760b8 "resource", str2=3D0x80760b8 "resource", str3=3D0xbfffb810 "(title subject format identifier language )",=20 int1=3D-72540026, int2=3D-72540026, msg=3D0x400f3e60 "Element %s content does not follow the DTD, expecting= %s,=20 got %s\n") at error.c:453 453 if ((schannel =3D=3D NULL) && (ctxt !=3D NULL) && (ctxt->sa= x !=3D=20 NULL) && (gdb) bt #0 0x40043c53 in __xmlRaiseError (schannel=3D0, channel=3D0x8049f9c ,=20 data=3D0x402b6ee0, ctx=3D0x402b6ee0, nod=3D0x806db10, domain=3D4, code=3D504, level=3DXML_= ERR_ERROR,=20 file=3D0x0, line=3D0, str1=3D0x80760b8 "resource", str2=3D0x80760b8 "resource", str3=3D0xbfffb810 "(title subject format identifier language )",=20 int1=3D-72540026, int2=3D-72540026, msg=3D0x400f3e60 "Element %s content does not follow the DTD, expecting= %s,=20 got %s\n") at error.c:453 #1 0x4007174b in xmlErrValidNode (ctxt=3D0xfbad2086, node=3D0xfbad2086,=20 error=3D-72540026, msg=3D0xfbad2086
, str1=3D0x402b6ee0 = "\206=20 ", str2=3D0xfbad2086
, str3=3D0xbfffb810 "(title subject format identifier language )") at=20 valid.c:171 #2 0x40078141 in xmlValidateElementContent (ctxt=3D0x8060cb8, child=3D0x80= 6db50, elemDecl=3D0xbfffb810, warn=3D1, parent=3D0x806db10) at valid.c:5129 #3 0x4007931f in xmlValidateOneElement (ctxt=3D0x8060cb8, doc=3D0xbfffb810= ,=20 elem=3D0x806db10) at valid.c:5819 #4 0x40079781 in xmlValidateElement (ctxt=3D0x8060cb8, doc=3D0x806d9e0,=20 elem=3D0x806db10) at valid.c:6062 #5 0x40079816 in xmlValidateElement (ctxt=3D0x8060cb8, doc=3D0x806d9e0,=20 elem=3D0x806da78) at valid.c:6073 #6 0x40079ce9 in xmlValidateDtd (ctxt=3D0x8060cb8, doc=3D0x402b6ee0,=20 dtd=3D0x402b6ee0) at valid.c:6278 #7 0x0804b62a in parseAndPrintFile ( filename=3D0xbffffb3b "/usr/share/omf/gnome-applets/gweather_applet-it.= omf",=20 rectxt=3D0xbfffb810) at xmllint.c:1142 #8 0x0804ceaa in main (argc=3D4, argv=3D0xbffff9f4) at xmllint.c:1829 After tracking a bit the bug, it appears that there is an API breakage in t= he=20 usage of the userData field of the struct _xmlValidCtxt in the=20 xmlErrValidNode function. This function expects it to be a xmlParserCtxtPtr= ,=20 which is obviously not the case. By the way, there are two "pctxt =3D ctxt->userData" statements at valid.c:= 134=20 and valid.c:135... I suspect something when wrong while editing this file... Note that I didn't check elsewhere if there were any similar API breakage=20 (i.e. change in the usage of the userData field) ; I only focused on the=20 current issue. If you still need additional information about the issue, just ask. Mike =2D-=20 "I have sampled every language, french is my favorite. Fantastic language, especially to curse with. Nom de dieu de putain de bordel de merde de saloperie de connard d'encul=E9 de ta m=E8re. It's like wiping your ass with silk! I love it." -- The Merovingian, in the Matrix Reloaded From malcolm@commsecure.com.au Mon Oct 27 23:20:17 2003 Return-Path: Delivered-To: xml@gnome.org Received: from commsecure.com.au (CommSecureAustPtyLtd.sb1.optus.net.au [203.202.148.106]) by mail.gnome.org (Postfix) with ESMTP id 55F911821F for ; Mon, 27 Oct 2003 23:20:16 -0500 (EST) Received: from sunhill.commsecure.com.au (sunhill.commsecure.com.au [172.16.15.1]) by commsecure.com.au (8.11.6/8.11.6) with ESMTP id h9S4KS725354; Tue, 28 Oct 2003 15:20:28 +1100 Received: from ws14.commsecure.com.au (ws14.commsecure.com.au [172.16.15.14]) by sunhill.commsecure.com.au (8.11.6/8.11.6) with ESMTP id h9S4KWe25512; Tue, 28 Oct 2003 15:20:32 +1100 Received: from ws14.commsecure.com.au (localhost.localdomain [127.0.0.1]) by ws14.commsecure.com.au (8.12.8/8.12.8) with ESMTP id h9S4KWTv019635; Tue, 28 Oct 2003 15:20:32 +1100 Received: (from malcolm@localhost) by ws14.commsecure.com.au (8.12.8/8.12.8/Submit) id h9S4KVp9019633; Tue, 28 Oct 2003 15:20:31 +1100 X-Authentication-Warning: ws14.commsecure.com.au: malcolm set sender to malcolm@commsecure.com.au using -f Subject: Re: [xml] New error layer seems to break ABI compatibility... From: Malcolm Tredinnick To: Mike Hommey Cc: xml@gnome.org In-Reply-To: <200310272218.39628.mh@glandium.org> References: <200310271609.43461.mh@glandium.org> <200310271638.31650.mh@glandium.org> <200310272218.39628.mh@glandium.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1067314830.18848.67.camel@ws14.commsecure.com.au> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 28 Oct 2003 15:20:31 +1100 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Tue, 2003-10-28 at 00:18, Mike Hommey wrote: > On Monday October 27 2003 16:38, Mike Hommey wrote: > > On Monday October 27 2003 16:09, Mike Hommey wrote: > > [...] > > > > > Which may lead to conclude that there is something incompatible with the > > > new error management layer. > > > > > > I did not have time to investigate further, but if you have paths you > > > want me to follow to track this incompatibility bug, I'll be happy to > > > give a hand. > > > > Investigating a bit further shows it is not an API breakage, but only an > > ABI breakage : recompiling scrollkeeper against libxml2 2.6.0 make it work > > perfectly. > > Okay, I still don't understand how it happened to work properly at some time, > but it appears that the scrollkeeper package compiled against libxml2 2.6.0 > doesn't work either. > > Now, I recompiled bith scrollkeeper and libxml2 with debugging symbols, so > that backtrace is much more verbose : This looks like the bug that is being discussed in another thread. John Fleck just filed this bug report: http://bugzilla.gnome.org/show_bug.cgi?id=125653 and your investigations seem to point to the same thing. I should point out that with scrollkeeper it is a bit more tricky identifying the exact problem, since there were a number of memory management problems in scrollkeeper that have been fixed recently. If you are building from the 0.3.12 tarball, then you may be able to trigger some of those (I never could, but they existed in theory). However, in this case, I think you are looking at a libxml bug. Malcolm From mh@glandium.org Tue Oct 28 00:00:32 2003 Return-Path: Delivered-To: xml@gnome.org Received: from vaio.glandium.org (unknown [202.215.53.66]) by mail.gnome.org (Postfix) with ESMTP id E8FC5180DE for ; Tue, 28 Oct 2003 00:00:31 -0500 (EST) Received: from localhost ([127.0.0.1]) by vaio.glandium.org with esmtp (Exim 3.36 #1 (Debian)) id 1AELyB-0000Zg-00 for ; Tue, 28 Oct 2003 14:00:39 +0900 From: Mike Hommey Organization: glandium To: xml@gnome.org Subject: Re: [xml] New error layer seems to break ABI compatibility... Date: Tue, 28 Oct 2003 14:00:37 +0900 User-Agent: KMail/1.5.4 References: <200310271609.43461.mh@glandium.org> <200310272218.39628.mh@glandium.org> <1067314830.18848.67.camel@ws14.commsecure.com.au> In-Reply-To: <1067314830.18848.67.camel@ws14.commsecure.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200310281400.37621.mh@glandium.org> Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Tuesday October 28 2003 13:20, Malcolm Tredinnick wrote: > This looks like the bug that is being discussed in another thread. John > Fleck just filed this bug report: > > http://bugzilla.gnome.org/show_bug.cgi?id=3D125653 > > and your investigations seem to point to the same thing. This is definitely the exact same bug. > I should point out that with scrollkeeper it is a bit more tricky > identifying the exact problem, since there were a number of memory > management problems in scrollkeeper that have been fixed recently. If > you are building from the 0.3.12 tarball, then you may be able to > trigger some of those (I never could, but they existed in theory). > However, in this case, I think you are looking at a libxml bug. Yes, I am building from the 0.3.12 tarball, but from the bits of code I loo= ked=20 into, it seems to me to be the exact same bug as for xmllint, except that t= he=20 used functions for ctx->error and such, and data in ctx->userData are not t= he=20 same. But both break at the same point. Mike =2D-=20 "I have sampled every language, french is my favorite. Fantastic language, especially to curse with. Nom de dieu de putain de bordel de merde de saloperie de connard d'encul=C3=A9 de ta m=C3=A8re. It's like wiping your a= ss with silk! I love it." -- The Merovingian, in the Matrix Reloaded From kbuchcik@4commerce.de Tue Oct 28 07:57:17 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mx01.qsc.de (mx01.qsc.de [213.148.129.14]) by mail.gnome.org (Postfix) with ESMTP id 408E1188D2 for ; Tue, 28 Oct 2003 07:57:17 -0500 (EST) Received: from port-212-202-229-162.reverse.qsc.de ([212.202.229.162] helo=kisone) by mx01.qsc.de with smtp (Exim 3.35 #1) id 1AETPb-0004t1-00; Tue, 28 Oct 2003 13:57:27 +0100 From: Kasimier Buchcik To: Petr Pajas , X-Priority: 3 Received: from emission [10.254.2.2] by kisone [10.254.2.2] with SMTP eMission ESMTPServer; Tue, 28 Oct 2003 13:51:24 +0100 Received: from 4commerce.de (10.1.72.2 [10.1.72.2]) by kisone.kisnet.de with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VR3AG1ZN; Tue, 28 Oct 2003 13:51:24 +0100 Message-ID: <3F9E670C.4080603@4commerce.de> Date: Tue, 28 Oct 2003 13:54:36 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en References: <3F9D717F.4070003@ufal.ms.mff.cuni.cz> In-Reply-To: <3F9D717F.4070003@ufal.ms.mff.cuni.cz> X-eMessageService: eMission.SMTPServer Subject: "Re: [xml] xmlReconciliateNs problem" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="_PART_xs71z98sby4492v8" Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: This is a multipart message in MIME format --_PART_xs71z98sby4492v8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Petr Pajas wrote: > Hi Daniel, All, >=20 > I'm trying to make XML::LibXML perl module work with 2.6. After=20 > examining one of the self tests that broke after upgrade, I suspect that=20 > xmlReconciliateNs doesn't do its right job (if at all). The=20 > documentation says: >=20 > "This function checks that all the namespaces declared within the given > tree are properly declared. This is needed for example after Copy or Cut > and then paste operations. ..." >=20 > Now, I have a document like this: > > >=20 > and try either: > a) move one level up, into > b) move into another document >=20 > in both cases, expecting xmlReconciliateNs to create=20 > xmlns:x=3D"http://foo.bar" on . This is at least what it used to do=20 > with libxml2-2.5.x. >=20 > The attached file is my lame attempt of rewriting of the test case into=20 > C. It demonstrates the problem in the following way: >=20 > 1) run it without parameters to check for a) > 2) run it with 1 parameter (arbitrary) to check for b) > 3) run it with 2 parameter (-"-) to check for b), freeing the original=20 > document as soon as was moved and namespaces reconciliated. >=20 > I compile it with: > gcc -I /usr/include/libxml2 -L /usr/lib -lxml2 -o testns testns.c >=20 > with 2.6, I get > 1) ./testns > > > (bad: x:b has prefix but no namespace declared) >=20 > 2) ./testns x > > > (bad) >=20 > 3) ./testns x x > > > (even worse - maybe because of the new string reusing code?) >=20 > while with 2.5.3: >=20 > 1) ./testns > > > 2) ./testns x > > > 3) ./testns x x > > >=20 > which all look well. >=20 > I looked into the corresponding tree.c code. It appears, that=20 > xmlReconciliateNs simply does nothing, being fooled by xmlSearchNsByHref=20 > which returns node->ns even though it failed to find a corresponding nsDef= . >=20 > If the behavior of 2.6 is intended, is there a workaround? > Thanks, >=20 > -- Petr I attached a patch fixing that issue. The new speedup part of the=20 function did not prevent the specified node's namespace to be compared=20 to the searched one. Greetings, Kasimier --_PART_xs71z98sby4492v8 Content-Type: text/plain; name="tree.diff" Content-Transfer-Encoding: Quoted-Printable Content-Disposition: attachment; filename="tree.diff" Index: tree.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/gnome/libxml2/tree.c,v retrieving revision 1.291 diff -c -r1.291 tree.c *** tree.c=0921 Oct 2003 00:08:42 -0000=091.291 --- tree.c=0928 Oct 2003 12:47:01 -0000 *************** *** 5482,5495 **** } cur =3D cur->next; } ! cur =3D node->ns; ! if (cur !=3D NULL) { ! if ((cur->href !=3D NULL) && (href !=3D NULL) && ! (xmlStrEqual(cur->href, href))) { ! =09=09 if (xmlNsInScope(doc, orig, node, cur->href) =3D=3D 1) ! =09=09=09return (cur); } ! } } node =3D node->parent; } --- 5482,5497 ---- } cur =3D cur->next; } ! if (orig !=3D node) { ! cur =3D node->ns; ! if (cur !=3D NULL) { ! if ((cur->href !=3D NULL) && (href !=3D NULL) && ! (xmlStrEqual(cur->href, href))) { ! =09=09 if (xmlNsInScope(doc, orig, node, cur->href) =3D=3D 1) ! =09=09=09 return (cur); ! } } ! } =20 } node =3D node->parent; } --_PART_xs71z98sby4492v8-- From kbuchcik@4commerce.de Tue Oct 28 08:07:10 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mx01.qsc.de (mx01.qsc.de [213.148.129.14]) by mail.gnome.org (Postfix) with ESMTP id 3B8E5189E2 for ; Tue, 28 Oct 2003 08:07:10 -0500 (EST) Received: from port-212-202-229-162.reverse.qsc.de ([212.202.229.162] helo=kisone) by mx01.qsc.de with smtp (Exim 3.35 #1) id 1AETZH-00056y-00; Tue, 28 Oct 2003 14:07:27 +0100 From: Kasimier Buchcik To: Cc: Petr Pajas X-Priority: 3 Received: from emission [10.254.2.2] by kisone [10.254.2.2] with SMTP eMission ESMTPServer; Tue, 28 Oct 2003 14:00:28 +0100 Received: from 4commerce.de (10.1.72.2 [10.1.72.2]) by kisone.kisnet.de with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VR3AG1Z4; Tue, 28 Oct 2003 14:00:28 +0100 Message-ID: <3F9E692F.7090305@4commerce.de> Date: Tue, 28 Oct 2003 14:03:43 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en References: <3F9D717F.4070003@ufal.ms.mff.cuni.cz> <3F9E670C.4080603@4commerce.de> In-Reply-To: <3F9E670C.4080603@4commerce.de> X-eMessageService: eMission.SMTPServer Subject: "Re: [xml] xmlReconciliateNs problem" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="_PART_kzie81156xfshntk" Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: This is a multipart message in MIME format --_PART_kzie81156xfshntk Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, you may want to use the attached patch, rather than the last one, since=20 the bug occured to xmlSearchNs as well. Kasimier Buchcik wrote: > Hi, >=20 > Petr Pajas wrote: >=20 >>Hi Daniel, All, >> >>I'm trying to make XML::LibXML perl module work with 2.6. After=20 >>examining one of the self tests that broke after upgrade, I suspect that=20 >>xmlReconciliateNs doesn't do its right job (if at all). The=20 >>documentation says: >> >>"This function checks that all the namespaces declared within the given >>tree are properly declared. This is needed for example after Copy or Cut >>and then paste operations. ..." >> >>Now, I have a document like this: >> >> >> >>and try either: >>a) move one level up, into >>b) move into another document >> >>in both cases, expecting xmlReconciliateNs to create=20 >>xmlns:x=3D"http://foo.bar" on . This is at least what it used to do=20 >>with libxml2-2.5.x. >> >>The attached file is my lame attempt of rewriting of the test case into=20 >>C. It demonstrates the problem in the following way: >> >>1) run it without parameters to check for a) >>2) run it with 1 parameter (arbitrary) to check for b) >>3) run it with 2 parameter (-"-) to check for b), freeing the original=20 >>document as soon as was moved and namespaces reconciliated. >> >>I compile it with: >>gcc -I /usr/include/libxml2 -L /usr/lib -lxml2 -o testns testns.c >> >>with 2.6, I get >>1) ./testns >> >> >>(bad: x:b has prefix but no namespace declared) >> >>2) ./testns x >> >> >>(bad) >> >>3) ./testns x x >> >> >>(even worse - maybe because of the new string reusing code?) >> >>while with 2.5.3: >> >>1) ./testns >> >> >>2) ./testns x >> >> >>3) ./testns x x >> >> >> >>which all look well. >> >>I looked into the corresponding tree.c code. It appears, that=20 >>xmlReconciliateNs simply does nothing, being fooled by xmlSearchNsByHref=20 >>which returns node->ns even though it failed to find a corresponding nsDef= . >> >>If the behavior of 2.6 is intended, is there a workaround? >>Thanks, >> >>-- Petr >=20 >=20 > I attached a patch fixing that issue. The new speedup part of the=20 > function did not prevent the specified node's namespace to be compared=20 > to the searched one. Kasimier --_PART_kzie81156xfshntk Content-Type: text/plain; name="tree.diff" Content-Transfer-Encoding: Quoted-Printable Content-Disposition: attachment; filename="tree.diff" Index: tree.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/gnome/libxml2/tree.c,v retrieving revision 1.291 diff -c -r1.291 tree.c *** tree.c=0921 Oct 2003 00:08:42 -0000=091.291 --- tree.c=0928 Oct 2003 13:00:10 -0000 *************** *** 5292,5298 **** --- 5292,5300 ---- */ xmlNsPtr xmlSearchNs(xmlDocPtr doc, xmlNodePtr node, const xmlChar *nameSpace) { + =09 xmlNsPtr cur; + xmlNodePtr orig =3D node; =20 if (node =3D=3D NULL) return(NULL); if ((nameSpace !=3D NULL) && *************** *** 5350,5365 **** =09=09 return(cur); =09=09cur =3D cur->next; =09 } ! =09 cur =3D node->ns; ! =09 if (cur !=3D NULL) { ! =09=09if ((cur->prefix =3D=3D NULL) && (nameSpace =3D=3D NULL) && ! =09=09 (cur->href !=3D NULL)) ! =09=09 return(cur); ! =09=09if ((cur->prefix !=3D NULL) && (nameSpace !=3D NULL) && ! =09=09 (cur->href !=3D NULL) && ! =09=09 (xmlStrEqual(cur->prefix, nameSpace))) ! =09=09 return(cur); ! =09 } =09} =09node =3D node->parent; } --- 5352,5369 ---- =09=09 return(cur); =09=09cur =3D cur->next; =09 } ! =09 if (orig !=3D node) {=20 ! =09 cur =3D node->ns; ! =09 if (cur !=3D NULL) { ! =09=09 if ((cur->prefix =3D=3D NULL) && (nameSpace =3D=3D NULL) && ! =09=09 (cur->href !=3D NULL)) ! =09=09 return(cur); ! =09=09 if ((cur->prefix !=3D NULL) && (nameSpace !=3D NULL) && ! =09=09 (cur->href !=3D NULL) && ! =09=09 (xmlStrEqual(cur->prefix, nameSpace))) ! =09=09 return(cur); ! =09 } ! =09 } =20 =09} =09node =3D node->parent; } *************** *** 5482,5495 **** } cur =3D cur->next; } ! cur =3D node->ns; ! if (cur !=3D NULL) { ! if ((cur->href !=3D NULL) && (href !=3D NULL) && ! (xmlStrEqual(cur->href, href))) { ! =09=09 if (xmlNsInScope(doc, orig, node, cur->href) =3D=3D 1) ! =09=09=09return (cur); } ! } } node =3D node->parent; } --- 5486,5501 ---- } cur =3D cur->next; } ! if (orig !=3D node) { ! cur =3D node->ns; ! if (cur !=3D NULL) { ! if ((cur->href !=3D NULL) && (href !=3D NULL) && ! (xmlStrEqual(cur->href, href))) { ! =09=09 if (xmlNsInScope(doc, orig, node, cur->href) =3D=3D 1) ! =09=09=09 return (cur); ! } } ! } =20 } node =3D node->parent; } --_PART_kzie81156xfshntk-- From veillard@redhat.com Tue Oct 28 09:27:35 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 87BF518B39 for ; Tue, 28 Oct 2003 09:27:35 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9SERoS31001; Tue, 28 Oct 2003 09:27:50 -0500 Date: Tue, 28 Oct 2003 09:27:49 -0500 From: Daniel Veillard To: Kasimier Buchcik Cc: xml@gnome.org, Petr Pajas Subject: Re: "Re: [xml] xmlReconciliateNs problem" Message-ID: <20031028092749.A23901@redhat.com> Reply-To: veillard@redhat.com References: <3F9D717F.4070003@ufal.ms.mff.cuni.cz> <3F9E670C.4080603@4commerce.de> <3F9E692F.7090305@4commerce.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3F9E692F.7090305@4commerce.de>; from kbuchcik@4commerce.de on Tue, Oct 28, 2003 at 02:03:43PM +0100 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Tue, Oct 28, 2003 at 02:03:43PM +0100, Kasimier Buchcik wrote: > Hi, > > you may want to use the attached patch, rather than the last one, since > the bug occured to xmlSearchNs as well. Okay, applied and commited, thanks ! Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From kbuchcik@4commerce.de Tue Oct 28 11:27:11 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mx01.qsc.de (mx01.qsc.de [213.148.129.14]) by mail.gnome.org (Postfix) with ESMTP id 575A8182FE for ; Tue, 28 Oct 2003 11:27:11 -0500 (EST) Received: from port-212-202-229-162.reverse.qsc.de ([212.202.229.162] helo=kisone) by mx01.qsc.de with smtp (Exim 3.35 #1) id 1AEWgq-0001o4-00 for xml@gnome.org; Tue, 28 Oct 2003 17:27:28 +0100 From: Kasimier Buchcik To: X-Priority: 3 Received: from emission [10.254.2.2] by kisone [10.254.2.2] with SMTP eMission ESMTPServer; Tue, 28 Oct 2003 17:21:06 +0100 Received: from 4commerce.de (10.1.72.2 [10.1.72.2]) by kisone.kisnet.de with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VR3AG15Y; Tue, 28 Oct 2003 17:21:05 +0100 Message-ID: <3F9E9833.6010501@4commerce.de> Date: Tue, 28 Oct 2003 17:24:19 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en X-eMessageService: eMission.SMTPServer Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [xml] UTF-16 byte order mark Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi, is it possible to use libxml2's UTF-16 conversion functions and=20 serialization mechanism without a byte order mark? I.e. am I able to=20 define somewhere if byte order marks should be expected and if byte=20 order marks should be returned? regards, Kasimier Buchcik From veillard@redhat.com Tue Oct 28 12:12:31 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 61C861811E for ; Tue, 28 Oct 2003 12:12:31 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9SHCjq22159; Tue, 28 Oct 2003 12:12:45 -0500 Date: Tue, 28 Oct 2003 12:12:45 -0500 From: Daniel Veillard To: Kasimier Buchcik Cc: xml@gnome.org Subject: Re: [xml] UTF-16 byte order mark Message-ID: <20031028121245.C23901@redhat.com> Reply-To: veillard@redhat.com References: <3F9E9833.6010501@4commerce.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3F9E9833.6010501@4commerce.de>; from kbuchcik@4commerce.de on Tue, Oct 28, 2003 at 05:24:19PM +0100 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Tue, Oct 28, 2003 at 05:24:19PM +0100, Kasimier Buchcik wrote: > Hi, > > is it possible to use libxml2's UTF-16 conversion functions and > serialization mechanism without a byte order mark? I.e. am I able to > define somewhere if byte order marks should be expected and if byte > order marks should be returned? No, but you can define your own handler for any given encoding http://xmlsoft.org/encoding.html#extend Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From kbuchcik@4commerce.de Tue Oct 28 13:07:11 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mx01.qsc.de (mx01.qsc.de [213.148.129.14]) by mail.gnome.org (Postfix) with ESMTP id 8B97E18325 for ; Tue, 28 Oct 2003 13:07:11 -0500 (EST) Received: from port-212-202-229-162.reverse.qsc.de ([212.202.229.162] helo=kisone) by mx01.qsc.de with smtp (Exim 3.35 #1) id 1AEYFc-0006i5-00 for xml@gnome.org; Tue, 28 Oct 2003 19:07:29 +0100 From: Kasimier Buchcik To: X-Priority: 3 Received: from emission [10.254.2.2] by kisone [10.254.2.2] with SMTP eMission ESMTPServer; Tue, 28 Oct 2003 19:01:56 +0100 Received: from 4commerce.de (10.1.72.2 [10.1.72.2]) by kisone.kisnet.de with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VR3AG17G; Tue, 28 Oct 2003 19:01:55 +0100 Message-ID: <3F9EAFD6.9050401@4commerce.de> Date: Tue, 28 Oct 2003 19:05:10 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en References: <3F9E9833.6010501@4commerce.de> <20031028121245.C23901@redhat.com> In-Reply-To: <20031028121245.C23901@redhat.com> X-eMessageService: eMission.SMTPServer Subject: "Re: [xml] UTF-16 byte order mark" Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi, Daniel Veillard wrote: > On Tue, Oct 28, 2003 at 05:24:19PM +0100, Kasimier Buchcik wrote: >>Hi, >> >>is it possible to use libxml2's UTF-16 conversion functions and=20 >>serialization mechanism without a byte order mark? I.e. am I able to=20 >>define somewhere if byte order marks should be expected and if byte=20 >>order marks should be returned? >=20 > No, but you can define your own handler for any given encoding > http://xmlsoft.org/encoding.html#extend >=20 > Daniel I see, ok. Thanks, Kasimier Buchcik From veillard@redhat.com Tue Oct 28 16:35:07 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 3E54F18974 for ; Tue, 28 Oct 2003 16:35:07 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9SLZNH16174; Tue, 28 Oct 2003 16:35:23 -0500 Date: Tue, 28 Oct 2003 16:35:23 -0500 From: Daniel Veillard To: Graham Bennett Cc: xml@gnome.org Subject: Re: [xml] context reuse for push parser Message-ID: <20031028163523.I23901@redhat.com> Reply-To: veillard@redhat.com References: <20031021211943.GC12643@lamity.org> <20031021175845.E17879@redhat.com> <20031022070635.GA17027@lamity.org> <20031022204821.GA26585@lamity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031022204821.GA26585@lamity.org>; from graham-libxml@simulcra.org on Wed, Oct 22, 2003 at 09:48:21PM +0100 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, Oct 22, 2003 at 09:48:21PM +0100, Graham Bennett wrote: > I have updated my function: > > static int xmlCtxtInitPushParser(xmlParserCtxtPtr ctxt, const char > *chunk, int size, const char *filename, xmlCharEncoding enc) Okay, I have mostly integrated it but with a few differences: - reformatting - takes a const char * encoding instead of the xmlCharEncoding, since I want to get rid of this enum as much as possible - renamed it as xmlCtxtResetPush and exported it from that should be in CVS. The only unfortunate point is that I didn't wrote code or converted xmllint --push --repeat to use it... Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard@redhat.com Tue Oct 28 18:39:28 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 8196818121 for ; Tue, 28 Oct 2003 18:39:28 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9SNdil04568 for xml@gnome.org; Tue, 28 Oct 2003 18:39:46 -0500 Date: Tue, 28 Oct 2003 18:39:44 -0500 From: Daniel Veillard To: xml@gnome.org Message-ID: <20031028183944.K23901@redhat.com> Reply-To: veillard@redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Subject: [xml] Release of libxml2-2.6.1 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: After the 2.6.0 big release a number of bugs and fixes accumulated in the last week. You can get a cleaned up code base at: ftp://xmlsoft.org/ and GNOME FTP mirrors http://xmlsoft.org/ This is mostly bug fixes: * Unix compilation patches: libxml.m4 (Patrick Welche), warnings cleanup (William Brack) * Windows compilation patches (Joachim Bauch, Stephane Bidoul, Igor Zlatkovic) * xmlWriter bugfix (Alfred Mickautsch) * chvalid.[ch]: couple of fixes from Stephane Bidoul * context reset: error state reset, push parser reset (Graham Bennett) * context reuse: generate errors if file is not readable * defaulted attributes for element coming from internal entities (Stephane Bidoul) * Python: tab and spaces mix (William Brack) * Error handler could crash in DTD validation in 2.6.0 * xmlReader: do not use the document or element _private field * testSAX.c: avoid a problem with some PIs (Massimo Morara) * general bug fixes: mandatory encoding in text decl, serializing Document Fragment nodes, xmlSearchNs 2.6.0 problem (Kasimier Buchcik), XPath errors not reported, slow HTML parsing of large documents. All libxml2 errors reported to bugzilla have been looked at, and except pathological cases they should be fixed. If I missed something which was sent to the list, please register the problem in bugzilla to make sure this is not forgotten under a large pile of junk mail ! Thanks to all who reported bugs and provided fixes, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From mgrushinskiy@comcast.net Tue Oct 28 21:08:38 2003 Return-Path: Delivered-To: xml@gnome.org Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mail.gnome.org (Postfix) with ESMTP id 0A562181B8 for ; Tue, 28 Oct 2003 21:08:38 -0500 (EST) Received: from 204.127.197.117 ([204.127.197.117]) by comcast.net (rwcrmhc12) with SMTP id <2003102902085501400mij67e>; Wed, 29 Oct 2003 02:08:55 +0000 Received: from [68.38.116.126] by 204.127.197.117; Wed, 29 Oct 2003 02:08:52 +0000 From: mgrushinskiy@comcast.net To: xml@gnome.org Date: Wed, 29 Oct 2003 02:08:52 +0000 Message-Id: <102920030208.24123.7517@comcast.net> X-Mailer: AT&T Message Center Version 1 (Oct 14 2003) X-Authenticated-Sender: bWdydXNoaW5za2l5QGNvbWNhc3QubmV0 Subject: [xml] 2.6.1 bug? echo "" | xmllint - Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: It seems in 2.6.1 reading from stdin is not working as it used to be. bash-2.05b$ echo "" | xmllint - -:1: parser error : Document is empty ^ -:1: parser error : Start tag expected, '<' not found ^ I've compiled it on Mandrake 9.2. Not sure if others have same problem on other platforms. --Mikhail From acarrico@memebeam.org Tue Oct 28 22:46:36 2003 Return-Path: Delivered-To: xml@gnome.org Received: from jvb.vm.bytemark.co.uk (ege-inc.org [212.13.199.72]) by mail.gnome.org (Postfix) with ESMTP id C3FF51842D for ; Tue, 28 Oct 2003 22:46:35 -0500 (EST) Received: from sub-d.memebeam.org (user-10mt0kf.cable.mindspring.com [::ffff:65.110.130.143]) (AUTH: LOGIN acarrico@memebeam.org, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by jvb.vm.bytemark.co.uk with esmtp; Tue, 28 Oct 2003 22:46:49 -0500 Received: from acarrico by sub-d.memebeam.org with local (Exim 3.35 #1 (Debian)) id 1AEhFH-00015x-00 for ; Tue, 28 Oct 2003 22:43:43 -0500 Date: Tue, 28 Oct 2003 22:43:43 -0500 From: Anthony Carrico To: libxml Message-ID: <20031029034343.GA4108@memebeam.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline User-Agent: Mutt/1.5.4i Subject: [xml] unregister XPath namespace prefix crash (python bindings) Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: I'm using libxml2 version 2.5.11 (debian packages). I've narrowed my bug down to small a bit of code that registers and removes an xpath namespace prefix. Here is the test code: $ cat test-xmlMalloc #! /usr/bin/env python2.3 import libxml2 buffer = """ """ libxml2.debugMemory(1) doc = libxml2.parseMemory(buffer, len(buffer)) context = doc.xpathNewContext() print context.xpathRegisterNs("dsig", "http://www.w3.org/2000/09/xmldsig#") print context.xpathRegisterNs("dsig", None) context.xpathFreeContext() Here is the output: $ ./test-xmlMalloc 0 0 (nil) : Freed() xmlMallocBreakpoint reached on block 0 Segmentation fault That crash happens in "context.xpathFreeContext()". I looked at the libxml2 source code a little bit. It seems like maybe the code xmlHashUpdateEntry doesn't delete the hashtable entry if the ns_uri is NULL, so I wonder if something like the following patch would be appropriate. I haven't tested this patch yet; I wanted to submit the problem with the wisdom of this list to see if I'm going in the right direction. bash-2.05b$ diff -u xpath.c ../../xpath.c --- xpath.c 2003-07-31 10:47:38.000000000 -0400 +++ ../../xpath.c 2003-10-28 21:40:49.000000000 -0500 @@ -2929,8 +2929,11 @@ ctxt->nsHash = xmlHashCreate(10); if (ctxt->nsHash == NULL) return(-1); - return(xmlHashUpdateEntry(ctxt->nsHash, prefix, (void *) xmlStrdup(ns_uri), - (xmlHashDeallocator)xmlFree)); + if (ns_uri == NULL) + return(xmlHashRemoveEntry(ctxt->nsHash, ns_uri, (xmlHashDeallocator)xmlFree)); + else + return(xmlHashUpdateEntry(ctxt->nsHash, prefix, (void *) xmlStrdup(ns_uri), + (xmlHashDeallocator)xmlFree)); } /** -- Anthony Carrico From aleksey@aleksey.com Tue Oct 28 23:09:53 2003 Return-Path: Delivered-To: xml@gnome.org Received: from shell.aleksey.com (dsl093-129-176.sfo4.dsl.speakeasy.net [66.93.129.176]) by mail.gnome.org (Postfix) with ESMTP id 177BC18A55 for ; Tue, 28 Oct 2003 23:09:53 -0500 (EST) Received: from aleksey.com (unknown [192.168.1.63]) by shell.aleksey.com (Postfix) with ESMTP id AB9ABB5B6 for ; Tue, 28 Oct 2003 20:10:10 -0800 (PST) Message-ID: <3F9F3D99.7060102@aleksey.com> Date: Tue, 28 Oct 2003 20:10:01 -0800 From: Aleksey Sanin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, ru MIME-Version: 1.0 To: xml Content-Type: multipart/mixed; boundary="------------080704050900040307080703" Subject: [xml] [patch] xmlStrVPrintf Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. --------------080704050900040307080703 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Daniel, I found that in addition to xmlStrPrintf I need xmlStrVPrintf function for strings formatting. It's a trivial wrapper around Trio function and I hope that you wouldn't object to add this function to LibXML2 API. Thank you in advance, Aleksey --------------080704050900040307080703 Content-Type: text/plain; name="xmlStrVPrintf.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xmlStrVPrintf.diff" Index: parser.c =================================================================== RCS file: /cvs/gnome/gnome-xml/parser.c,v retrieving revision 1.340 diff -u -r1.340 parser.c --- parser.c 28 Oct 2003 23:06:30 -0000 1.340 +++ parser.c 29 Oct 2003 04:03:56 -0000 @@ -2482,6 +2482,30 @@ return(ret); } +/** + * xmlStrVPrintf: + * @buf: the result buffer. + * @len: the result buffer length. + * @msg: the message with printf formatting. + * @ap: extra parameters for the message. + * + * Formats @msg and places result into @buf. + * + * Returns the number of characters written to @buf or -1 if an error occurs. + */ +int +xmlStrVPrintf(xmlChar *buf, int len, const xmlChar *msg, va_list ap) { + int ret; + + if((buf == NULL) || (msg == NULL)) { + return(-1); + } + + ret = vsnprintf((char *) buf, len, (const char *) msg, ap); + buf[len - 1] = 0; /* be safe ! */ + + return(ret); +} /************************************************************************ * * * Commodity functions, cleanup needed ? * Index: include/libxml/parser.h =================================================================== RCS file: /cvs/gnome/gnome-xml/include/libxml/parser.h,v retrieving revision 1.107 diff -u -r1.107 parser.h --- include/libxml/parser.h 28 Oct 2003 21:31:45 -0000 1.107 +++ include/libxml/parser.h 29 Oct 2003 04:03:58 -0000 @@ -9,6 +9,8 @@ #ifndef __XML_PARSER_H__ #define __XML_PARSER_H__ +#include + #include #include #include @@ -863,6 +865,12 @@ int len, const xmlChar *msg, ...); + +XMLPUBFUN int XMLCALL + xmlStrVPrintf (xmlChar *buf, + int len, + const xmlChar *msg, + va_list ap); /* * Basic parsing Interfaces --------------080704050900040307080703-- From mark@lilback.com Tue Oct 28 23:18:06 2003 Return-Path: Delivered-To: xml@gnome.org Received: from rtlabs.com (unknown [64.21.77.200]) by mail.gnome.org (Postfix) with ESMTP id 6A2EB18A55 for ; Tue, 28 Oct 2003 23:18:03 -0500 (EST) Received: from [24.193.53.5] (account mark HELO [10.0.0.181]) by rtlabs.com (CommuniGate Pro SMTP 4.0.5) with ESMTP id 2114288 for xml@gnome.org; Tue, 28 Oct 2003 23:14:11 -0500 Mime-Version: 1.0 X-Sender: mark@mail.lilback.com Message-Id: Date: Tue, 28 Oct 2003 23:18:08 -0500 To: xml@gnome.org From: "Mark J. Lilback" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [xml] patch for tree.c Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: There are a few locations where libxml2 isn't honoring a TEXT node's name being xmlStringTextNoenc. Here's a patch to fix the problem. It's on a slightly older version of the code, but I haven't had time to update my application to the new code. One other problem I had was with htmlNodeDumpFormatOutput not honoring all the instances of xmlStringTextNoenc. I changed the comparison to use xmlStrEqual instead of a pointer because I'd like to mark some nodes I add (such as for PHP code) to not be encoded when output. A much better solution, I think, would be to add an API to get/set if a text node is to be encoded. *** ../x/libxml2-2.5.11/tree.c Tue Sep 9 06:02:48 2003 --- ./tree.c Thu Oct 9 17:25:00 2003 *************** *** 2869,2875 **** xmlUnlinkNode(elem); ! if ((cur->type == XML_TEXT_NODE) && (elem->type == XML_TEXT_NODE)) { xmlNodeAddContent(cur, elem->content); xmlFreeNode(elem); return(cur); --- 2869,2877 ---- xmlUnlinkNode(elem); ! if ((cur->type == XML_TEXT_NODE) && (elem->type == XML_TEXT_NODE) && ! (cur->name == elem->name)) ! { xmlNodeAddContent(cur, elem->content); xmlFreeNode(elem); return(cur); *************** *** 3009,3014 **** --- 3011,3017 ---- if (cur->type == XML_TEXT_NODE) { if ((parent->type == XML_TEXT_NODE) && (parent->content != NULL) && + (parent->name == cur->name) && (parent != cur)) { xmlNodeAddContent(parent, cur->content); xmlFreeNode(cur); -- __________________________________________________________________________ "They that can give up essential liberty Mark J. Lilback to obtain a little temporary safety deserve neither liberty or safety." http://www.lilback.com/ -- Benjamin Franklin From mh@glandium.org Wed Oct 29 00:40:58 2003 Return-Path: Delivered-To: xml@gnome.org Received: from vaio.glandium.org (i61-195-247-171.us.catvmics.ne.jp [61.195.247.171]) by mail.gnome.org (Postfix) with ESMTP id 0363D1849A for ; Wed, 29 Oct 2003 00:40:57 -0500 (EST) Received: from localhost ([127.0.0.1]) by vaio.glandium.org with esmtp (Exim 3.36 #1 (Debian)) id 1AEj4s-0004si-00 for ; Wed, 29 Oct 2003 14:41:06 +0900 From: Mike Hommey Organization: glandium To: xml@gnome.org Date: Wed, 29 Oct 2003 14:41:05 +0900 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310291441.05066.mh@glandium.org> Subject: [xml] What xmlCleanup* functions are supposed to do ? Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi, It seems to me that (with 2.6.0, at least, not tested with any other version), using xmlCleanupGlobals() or xmlCleanupParser() does absolutely nothing. Valgrind still tells me there is 419 bytes in 16 blocks not freed... Which I guess is the memory taken by the global variables... Am I using the wrong functions or do I assume them to do something they are not supposed to do ? Mike From veillard@redhat.com Wed Oct 29 04:19:09 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id B5CCC180DB for ; Wed, 29 Oct 2003 04:19:09 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9T9JQ811176; Wed, 29 Oct 2003 04:19:26 -0500 Date: Wed, 29 Oct 2003 04:19:26 -0500 From: Daniel Veillard To: mgrushinskiy@comcast.net Cc: xml@gnome.org Subject: Re: [xml] 2.6.1 bug? echo "" | xmllint - Message-ID: <20031029041926.L23901@redhat.com> Reply-To: veillard@redhat.com References: <102920030208.24123.7517@comcast.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <102920030208.24123.7517@comcast.net>; from mgrushinskiy@comcast.net on Wed, Oct 29, 2003 at 02:08:52AM +0000 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, Oct 29, 2003 at 02:08:52AM +0000, mgrushinskiy@comcast.net wrote: > It seems in 2.6.1 reading from stdin is not working as it used to be. > > bash-2.05b$ echo "" | xmllint - > -:1: parser error : Document is empty > > ^ > -:1: parser error : Start tag expected, '<' not found > > ^ > > I've compiled it on Mandrake 9.2. Not sure if others have same problem on > other platforms. Hum, apparently it's the same on 2.6.0, please bugzilla it. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard@redhat.com Wed Oct 29 04:21:31 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 1FC28180DB for ; Wed, 29 Oct 2003 04:21:31 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9T9Lmx12048; Wed, 29 Oct 2003 04:21:48 -0500 Date: Wed, 29 Oct 2003 04:21:48 -0500 From: Daniel Veillard To: Aleksey Sanin Cc: xml Subject: Re: [xml] [patch] xmlStrVPrintf Message-ID: <20031029042148.M23901@redhat.com> Reply-To: veillard@redhat.com References: <3F9F3D99.7060102@aleksey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3F9F3D99.7060102@aleksey.com>; from aleksey@aleksey.com on Tue, Oct 28, 2003 at 08:10:01PM -0800 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Tue, Oct 28, 2003 at 08:10:01PM -0800, Aleksey Sanin wrote: > Daniel, > > I found that in addition to xmlStrPrintf I need xmlStrVPrintf function > for strings formatting. It's a trivial wrapper around Trio function and > I hope > that you wouldn't object to add this function to LibXML2 API. Sure, please commit it ! Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard@redhat.com Wed Oct 29 04:28:07 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id DC8921842B for ; Wed, 29 Oct 2003 04:28:06 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9T9SNQ13888; Wed, 29 Oct 2003 04:28:23 -0500 Date: Wed, 29 Oct 2003 04:28:23 -0500 From: Daniel Veillard To: Mike Hommey Cc: xml@gnome.org Subject: Re: [xml] What xmlCleanup* functions are supposed to do ? Message-ID: <20031029042823.N23901@redhat.com> Reply-To: veillard@redhat.com References: <200310291441.05066.mh@glandium.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200310291441.05066.mh@glandium.org>; from mh@glandium.org on Wed, Oct 29, 2003 at 02:41:05PM +0900 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, Oct 29, 2003 at 02:41:05PM +0900, Mike Hommey wrote: > Hi, > > It seems to me that (with 2.6.0, at least, not tested with any other version), > using xmlCleanupGlobals() or xmlCleanupParser() does absolutely nothing. strange, the code is the same. > Valgrind still tells me there is 419 bytes in 16 blocks not freed... Which I > guess is the memory taken by the global variables... Well if you want to see where there is a leak, follow the mechanism for doing so: http://xmlsoft.org/xmlmem.html#Debugging if you can reproduce the leak with xmllint or some of the programs I provide then give the input used and I will fix it. If not, I assume the problem is in your code, and the pages gives the informations on how to chase them down. > Am I using the wrong functions or do I assume them to do something they are > not supposed to do ? xmllint.c calls xmlCleanupParser(); at the end of the processing and doesn't report any leak on the existing test suite regressions. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From wbrack@mmm.com.hk Wed Oct 29 05:06:58 2003 Return-Path: Delivered-To: xml@gnome.org Received: from delightful.com.hk (adsl-63-204-84-206.dsl.sktn01.pacbell.net [63.204.84.206]) by mail.gnome.org (Postfix) with ESMTP id 53395181EA for ; Wed, 29 Oct 2003 05:06:58 -0500 (EST) Received: from delightful.com.hk (localhost [127.0.0.1]) by delightful.com.hk (8.12.9/8.12.9) with SMTP id h9TA7FVq030041 for ; Wed, 29 Oct 2003 02:07:15 -0800 Received: from 68.185.74.32 (SquirrelMail authenticated user wbrack) by www.delightful.com.hk with HTTP; Wed, 29 Oct 2003 18:07:15 +0800 (HKT) Message-ID: <3615.68.185.74.32.1067422035.squirrel@www.delightful.com.hk> In-Reply-To: <20031029041926.L23901@redhat.com> References: <102920030208.24123.7517@comcast.net> <20031029041926.L23901@redhat.com> Date: Wed, 29 Oct 2003 18:07:15 +0800 (HKT) Subject: Re: [xml] 2.6.1 bug? echo "" | xmllint - From: "William M. Brack" To: xml@gnome.org User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Daniel Veillard said: > On Wed, Oct 29, 2003 at 02:08:52AM +0000, mgrushinskiy@comcast.net > wrote: >> It seems in 2.6.1 reading from stdin is not working as it used to >> be. >> >> bash-2.05b$ echo "" | xmllint - >> -:1: parser error : Document is empty >> >> ^ >> -:1: parser error : Start tag expected, '<' not found >> >> ^ >> >> I've compiled it on Mandrake 9.2. Not sure if others have same >> problem on >> other platforms. > > Hum, apparently it's the same on 2.6.0, please bugzilla it. > > Daniel > > -- > Daniel Veillard | Red Hat Network https://rhn.redhat.com/ > veillard@redhat.com | libxml GNOME XML XSLT toolkit > http://xmlsoft.org/ > http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ > _______________________________________________ > xml mailing list, project page http://xmlsoft.org/ > xml@gnome.org > http://mail.gnome.org/mailman/listinfo/xml > From wbrack@mmm.com.hk Wed Oct 29 05:13:19 2003 Return-Path: Delivered-To: xml@gnome.org Received: from delightful.com.hk (adsl-63-204-84-206.dsl.sktn01.pacbell.net [63.204.84.206]) by mail.gnome.org (Postfix) with ESMTP id 419F3182BB for ; Wed, 29 Oct 2003 05:13:18 -0500 (EST) Received: from delightful.com.hk (localhost [127.0.0.1]) by delightful.com.hk (8.12.9/8.12.9) with SMTP id h9TADaVq030072 for ; Wed, 29 Oct 2003 02:13:36 -0800 Received: from 68.185.74.32 (SquirrelMail authenticated user wbrack) by www.delightful.com.hk with HTTP; Wed, 29 Oct 2003 18:13:36 +0800 (HKT) Message-ID: <3632.68.185.74.32.1067422416.squirrel@www.delightful.com.hk> In-Reply-To: <20031029041926.L23901@redhat.com> References: <102920030208.24123.7517@comcast.net> <20031029041926.L23901@redhat.com> Date: Wed, 29 Oct 2003 18:13:36 +0800 (HKT) Subject: Re: [xml] 2.6.1 bug? echo "" | xmllint - From: "William M. Brack" To: xml@gnome.org User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Daniel Veillard said: > On Wed, Oct 29, 2003 at 02:08:52AM +0000, mgrushinskiy@comcast.net > wrote: >> It seems in 2.6.1 reading from stdin is not working as it used to >> be. >> >> bash-2.05b$ echo "" | xmllint - >> -:1: parser error : Document is empty >> >> ^ >> -:1: parser error : Start tag expected, '<' not found >> >> ^ >> >> I've compiled it on Mandrake 9.2. Not sure if others have same >> problem on >> other platforms. > > Hum, apparently it's the same on 2.6.0, please bugzilla it. > > Daniel *********************** Sorry - first I replied direct to Daniel, then noticed I hadn't copied the list, so sent a message to the list without my response... It's been a long day (just got back to the U.S. from HK, about 18 hours door to door). Here's the missing response:- *********************** Seems this is related to the code attempting to detect a compressed file, i.e. something I put in a little while ago - it involves a "rewind", and with stdin that doesn't work very well ;-(. Once the bugzilla is in, I'll take it. Thanks for the report Bill From veillard@redhat.com Wed Oct 29 06:15:00 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 38C7B18C68 for ; Wed, 29 Oct 2003 06:15:00 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9TBFFj19297; Wed, 29 Oct 2003 06:15:15 -0500 Date: Wed, 29 Oct 2003 06:15:15 -0500 From: Daniel Veillard To: Anthony Carrico Cc: libxml Subject: Re: [xml] unregister XPath namespace prefix crash (python bindings) Message-ID: <20031029061515.B18691@redhat.com> Reply-To: veillard@redhat.com References: <20031029034343.GA4108@memebeam.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031029034343.GA4108@memebeam.org>; from acarrico@memebeam.org on Tue, Oct 28, 2003 at 10:43:43PM -0500 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Tue, Oct 28, 2003 at 10:43:43PM -0500, Anthony Carrico wrote: > That crash happens in "context.xpathFreeContext()". > > I looked at the libxml2 source code a little bit. It seems like maybe > the code xmlHashUpdateEntry doesn't delete the hashtable entry if the > ns_uri is NULL, so I wonder if something like the following patch > would be appropriate. I haven't tested this patch yet; I wanted to > submit the problem with the wisdom of this list to see if I'm going in > the right direction. Yeah, that sounds right. I changed that in CVS. I also tried to add more checks in the hash module to avoid the problem in a more general way. thanks, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From Steve.Ball@zveno.com Wed Oct 29 07:23:48 2003 Return-Path: Delivered-To: xml@gnome.org Received: from waycool.zveno.com (static-ctb0236.webone.com.au [210.9.242.36]) by mail.gnome.org (Postfix) with ESMTP id 7CF0518108 for ; Wed, 29 Oct 2003 07:23:47 -0500 (EST) Received: from zveno.com (pbook [192.168.0.4]) by waycool.zveno.com (8.12.8/8.12.8) with ESMTP id h9TDtpWI008098; Thu, 30 Oct 2003 00:55:53 +1100 Message-ID: <3F9FB1C2.70405@zveno.com> Date: Wed, 29 Oct 2003 23:25:38 +1100 From: Steve Ball Reply-To: Steve.Ball@zveno.com Organization: Zveno Pty Ltd User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: veillard@redhat.com Cc: xml@gnome.org Subject: Re: [xml] RFE: Schema-validation API References: <3F8B3F93.5040500@zveno.com> <20031014034211.N29460@redhat.com> In-Reply-To: <20031014034211.N29460@redhat.com> Content-Type: multipart/mixed; boundary="------------080100010607020302070205" Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. --------------080100010607020302070205 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Daniel, Please find attached a patch to add a new API as discussed below. The API has been tested via my own project, but if you would like an additional patch for testschemas.c let me know. Regards, Steve Ball You wrote: > On Tue, Oct 14, 2003 at 10:13:07AM +1000, Steve Ball wrote: > >>The WXS module in libxml2-2.5.11 provides an interface >>to schema-validate an instance document, given the schema >>document as either a URL or in a memory buffer. >>However, in my project I already have the schema document >>as a xmlDocPtr object (ie. it is already parsed as an XML document). >>At the moment my code serializes the schema document into >>a memory buffer and then passes that buffer to >>xmlSchemaNewMemParserCtxt. This routine then re-parses the >>document. >> >>Accordingly, my RFE is to have a new API that accepts the >>schema document as an xmlDocPtr. Something like: >> >>xmlSchemaParserCtxtPtr xmlSchemaNewDocParserCtxt (xmlDocPtr doc); >> >>The code would be fairly straight-forward, in fact almost >>trivial. I can do the implementation and submit it as a >>patch if desired. > > > Yep, should be trivial to add this entry point, I take patches :) > Still I'm a bit scared that you use the Schemas implementation, I > suppose it all depends on the schemas you actually use, if simple > enough you may not hit any bug. > > Daniel > -- Steve Ball | XSLT Standard Library | Training & Seminars Zveno Pty Ltd | Web Tcl Complete | XML XSL Schemas http://www.zveno.com/ | TclXML TclDOM | Tcl, Web Development Steve.Ball@zveno.com +---------------------------+--------------------- Ph. +61 2 6242 4099 | Mobile (0413) 594 462 | Fax +61 2 6242 4099 --------------080100010607020302070205 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="schema.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="schema.patch" *** /tmp/libxml2-2.6.0/xmlschemas.c Sun Oct 19 08:04:20 2003 --- xmlschemas.c Wed Oct 29 16:59:33 2003 *************** *** 3184,3189 **** --- 3184,3218 ---- } /** + * xmlSchemaNewDocParserCtxt: + * @doc: a preparsed document tree + * + * Create an XML Schemas parse context for that document. + * NB. The document may be modified during the parsing process. + * + * Returns the parser context or NULL in case of error + */ + xmlSchemaParserCtxtPtr + xmlSchemaNewDocParserCtxt(xmlDocPtr doc) + { + xmlSchemaParserCtxtPtr ret; + + if (doc == NULL) + return (NULL); + + ret = (xmlSchemaParserCtxtPtr) xmlMalloc(sizeof(xmlSchemaParserCtxt)); + if (ret == NULL) { + xmlSchemaPErrMemory(NULL, "allocating schema parser context", + NULL); + return (NULL); + } + memset(ret, 0, sizeof(xmlSchemaParserCtxt)); + ret->doc = doc; + + return (ret); + } + + /** * xmlSchemaFreeParserCtxt: * @ctxt: the schema parser context * *************** *** 4224,4229 **** --- 4253,4260 ---- } doc->URL = xmlStrdup(BAD_CAST "in_memory_buffer"); ctxt->URL = xmlStrdup(BAD_CAST "in_memory_buffer"); + } else if (ctxt->doc != NULL) { + doc = ctxt->doc; } else { xmlSchemaPErr(ctxt, NULL, XML_SCHEMAP_NOTHING_TO_PARSE, *** /tmp/libxml2-2.6.0/include/libxml/xmlschemas.h Mon Sep 29 22:14:52 2003 --- include/libxml/xmlschemas.h Mon Oct 27 13:33:12 2003 *************** *** 77,82 **** --- 77,84 ---- XMLPUBFUN xmlSchemaParserCtxtPtr XMLCALL xmlSchemaNewMemParserCtxt (const char *buffer, int size); + XMLPUBFUN xmlSchemaParserCtxtPtr XMLCALL + xmlSchemaNewDocParserCtxt (xmlDocPtr doc); XMLPUBFUN void XMLCALL xmlSchemaFreeParserCtxt (xmlSchemaParserCtxtPtr ctxt); XMLPUBFUN void XMLCALL --------------080100010607020302070205-- From veillard@redhat.com Wed Oct 29 07:57:14 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 080D91864A for ; Wed, 29 Oct 2003 07:57:14 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9TCvVX19120; Wed, 29 Oct 2003 07:57:31 -0500 Date: Wed, 29 Oct 2003 07:57:31 -0500 From: Daniel Veillard To: "Mark J. Lilback" Cc: xml@gnome.org Subject: Re: [xml] patch for tree.c Message-ID: <20031029075731.C18691@redhat.com> Reply-To: veillard@redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from mark@lilback.com on Tue, Oct 28, 2003 at 11:18:08PM -0500 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Tue, Oct 28, 2003 at 11:18:08PM -0500, Mark J. Lilback wrote: > There are a few locations where libxml2 isn't honoring a TEXT node's > name being xmlStringTextNoenc. Here's a patch to fix the problem. > It's on a slightly older version of the code, but I haven't had time > to update my application to the new code. That's fine, this makes sense, applied. > One other problem I had was with htmlNodeDumpFormatOutput not > honoring all the instances of xmlStringTextNoenc. I changed the Hum, where ? > comparison to use xmlStrEqual instead of a pointer because I'd like Hum, no it' really should be pointer compares. > to mark some nodes I add (such as for PHP code) to not be encoded > when output. A much better solution, I think, would be to add an API > to get/set if a text node is to be encoded. Well that was supposed to be restricted to XSLT processing, and even there disable-output-escaping should be limited to a fairly small number of pathological cases, not as a general purpose mechanism. Usually it means something is just not done right from an XML structure point of view, so I feel a bit annoyed about exposing it too widely. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From shard@neoni.net Wed Oct 29 05:54:05 2003 Return-Path: Delivered-To: xml@gnome.org Received: from nicolaus.az.pl (nicolaus.az.pl [217.153.59.68]) by mail.gnome.org (Postfix) with ESMTP id 7760F18C4E for ; Wed, 29 Oct 2003 05:54:04 -0500 (EST) Received: from bepc.home.astercity.net (69-ego-3.acn.waw.pl [62.121.86.69]) by nicolaus.az.pl (8.11.6/8.11.6) with ESMTP id h9TAs7q23648; Wed, 29 Oct 2003 11:54:07 +0100 Cc: xml@gnome.org Date: Wed, 29 Oct 2003 11:54:03 +0100 From: shard@neoni.net Message-Id: <20031029115403.857.3@bepc.home.astercity.net> Mime-Version: 1.0 To: veillard@redhat.com User-Agent: Beam 1.0-rc4 Content-Type: multipart/mixed; boundary="_=_BOUNDARY_1495774274_1_=_" Content-Transfer-Encoding: 7bit Subject: [xml] [PATCH] BeOS threading support. Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. --_=_BOUNDARY_1495774274_1_=_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I've modified threads.c and testThreads to let libxml2 use "mutex" etc.. code on BeOS. There is partly implemented libpthreads for BeOS, but it's very far from usable state :( I also "fixed" nanoftp.c and nanohttp.c - they wouldn't compile with -DSTANDALONE on BeOS because of lack of data casting in few places :( i added testThreadsBeOS.c file, but didn't know how to make configure script, or makefile base files to use it instead of testThreads.c without some hacking in them. so i just removed testThreads.c and put symlink with that name to testThreadsBeOS.c - that's why in attached diff file there are changes in testThreads.c. test runs ok, so i suppose code is ok, but i don't have anything to test it in "real-life" usage. Regards Shard --_=_BOUNDARY_1495774274_1_=_ Content-Type: text/plain; charset="UTF-8"; name="libxml2-2.6.0-BeOS.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="libxml2-2.6.0-BeOS.diff" diff -r -u /boot/home/Unzipped/libxml2-2.6.0/nanoftp.c /boot/home/Unzipped/_libxml2-2.6.0/nanoftp.c --- /boot/home/Unzipped/libxml2-2.6.0/nanoftp.c Fri Oct 10 17:49:38 2003 +++ /boot/home/Unzipped/_libxml2-2.6.0/nanoftp.c Wed Oct 29 11:45:46 2003 @@ -2221,10 +2221,10 @@ void ftpData(void *userData, const char *data, int len) { if (userData == NULL) return; if (len <= 0) { - fclose(userData); + fclose((FILE*)userData); return; } - fwrite(data, len, 1, userData); + fwrite(data, len, 1, (FILE*)userData); } int main(int argc, char **argv) { diff -r -u /boot/home/Unzipped/libxml2-2.6.0/nanohttp.c /boot/home/Unzipped/_libxml2-2.6.0/nanohttp.c --- /boot/home/Unzipped/libxml2-2.6.0/nanohttp.c Sun Oct 19 15:26:37 2003 +++ /boot/home/Unzipped/_libxml2-2.6.0/nanohttp.c Wed Oct 29 11:47:17 2003 @@ -1314,7 +1314,7 @@ if (contentType && *contentType) blen += strlen(*contentType) + 16; blen += strlen(method) + strlen(ctxt->path) + 24; - bp = xmlMallocAtomic(blen); + bp = (char*)xmlMallocAtomic(blen); if ( bp == NULL ) { xmlNanoHTTPFreeCtxt( ctxt ); xmlHTTPErrMemory("allocating header buffer"); @@ -1616,7 +1616,7 @@ */ int xmlNanoHTTPContentLength( void * ctx ) { - xmlNanoHTTPCtxtPtr ctxt = ctx; + xmlNanoHTTPCtxtPtr ctxt = (xmlNanoHTTPCtxtPtr)ctx; return ( ( ctxt == NULL ) ? -1 : ctxt->ContentLength ); } @@ -1631,7 +1631,7 @@ */ const char * xmlNanoHTTPRedir( void * ctx ) { - xmlNanoHTTPCtxtPtr ctxt = ctx; + xmlNanoHTTPCtxtPtr ctxt = (xmlNanoHTTPCtxtPtr)ctx; return ( ( ctxt == NULL ) ? NULL : ctxt->location ); } @@ -1646,7 +1646,7 @@ */ const char * xmlNanoHTTPEncoding( void * ctx ) { - xmlNanoHTTPCtxtPtr ctxt = ctx; + xmlNanoHTTPCtxtPtr ctxt = (xmlNanoHTTPCtxtPtr)ctx; return ( ( ctxt == NULL ) ? NULL : ctxt->encoding ); } @@ -1661,7 +1661,7 @@ */ const char * xmlNanoHTTPMimeType( void * ctx ) { - xmlNanoHTTPCtxtPtr ctxt = ctx; + xmlNanoHTTPCtxtPtr ctxt = (xmlNanoHTTPCtxtPtr)ctx; return ( ( ctxt == NULL ) ? NULL : ctxt->mimeType ); } @@ -1680,7 +1680,7 @@ */ int xmlNanoHTTPFetchContent( void * ctx, char ** ptr, int * len ) { - xmlNanoHTTPCtxtPtr ctxt = ctx; + xmlNanoHTTPCtxtPtr ctxt = (xmlNanoHTTPCtxtPtr)ctx; int rc = 0; int cur_lgth; diff -r -u /boot/home/Unzipped/libxml2-2.6.0/testThreads.c /boot/home/Unzipped/_libxml2-2.6.0/testThreads.c --- /boot/home/Unzipped/libxml2-2.6.0/testThreads.c Thu Aug 7 10:00:59 2003 +++ /boot/home/Unzipped/_libxml2-2.6.0/testThreads.c Tue Oct 28 20:36:25 2003 @@ -7,7 +7,11 @@ #include #include #include +#ifdef HAVE_PTHREAD_H #include +#elif defined HAVE_BEOS_THREADS +#include +#endif #include #if !defined(_MSC_VER) #include @@ -15,7 +19,11 @@ #include #define MAX_ARGC 20 +#ifdef HAVE_PTHREAD_H static pthread_t tid[MAX_ARGC]; +#elif defined HAVE_BEOS_THREADS +static thread_id tid[MAX_ARGC]; +#endif static const char *catalog = "test/threads/complex.xml"; static const char *testfiles[] = { @@ -83,6 +91,7 @@ return ((void *) Okay); } +#ifdef HAVE_PTHREAD_H int main(void) { @@ -125,6 +134,62 @@ xmlMemoryDump(); return (0); } +#elif defined HAVE_BEOS_THREADS +int +main(void) +{ + unsigned int i, repeat; + unsigned int num_threads = sizeof(testfiles) / sizeof(testfiles[0]); + void *results[MAX_ARGC]; + status_t ret; + + xmlInitParser(); + printf("Parser initialized\n"); + for (repeat = 0;repeat < 500;repeat++) { + printf("repeat: %d\n",repeat); + xmlLoadCatalog(catalog); + printf("loaded catalog: %s\n", catalog); + for (i = 0; i < num_threads; i++) { + results[i] = NULL; + tid[i] = (thread_id) -1; + } + printf("cleaned threads\n"); + for (i = 0; i < num_threads; i++) { + tid[i] = spawn_thread(thread_specific_data, "xmlTestThread", B_NORMAL_PRIORITY, (void *) testfiles[i]); + if (tid[i] < B_OK) { + perror("beos_thread_create"); + exit(1); + } + printf("beos_thread_create %d -> %d\n", i, tid[i]); + } + for (i = 0; i < num_threads; i++) { + ret = wait_for_thread(tid[i], &results[i]); + printf("beos_thread_wait %d -> %d\n", i, ret); + if (ret != B_OK) { + perror("beos_thread_wait"); + exit(1); + } + } + + xmlCatalogCleanup(); + ret = B_OK; + for (i = 0; i < num_threads; i++) + if (results[i] != (void *) Okay) { + printf("Thread %d handling %s failed\n", i, testfiles[i]); + ret = B_ERROR; + } + } + xmlCleanupParser(); + xmlMemoryDump(); + + if (ret == B_OK) + printf("testThread : BeOS : SUCCESS!\n"); + else + printf("testThread : BeOS : FAILED!\n"); + + return (0); +} +#endif /* pthreads or BeOS threads */ #else /* !LIBXML_THREADS_ENABLED */ int diff -r -u /boot/home/Unzipped/libxml2-2.6.0/threads.c /boot/home/Unzipped/_libxml2-2.6.0/threads.c --- /boot/home/Unzipped/libxml2-2.6.0/threads.c Sat Oct 11 12:17:30 2003 +++ /boot/home/Unzipped/_libxml2-2.6.0/threads.c Tue Oct 28 19:14:27 2003 @@ -35,6 +35,11 @@ #endif #endif +#ifdef HAVE_BEOS_THREADS +#include +#include +#endif + #if defined(SOLARIS) #include #endif @@ -55,6 +60,8 @@ pthread_mutex_t lock; #elif defined HAVE_WIN32_THREADS HANDLE mutex; +#elif defined HAVE_BEOS_THREADS + sem_id sem; #else int empty; #endif @@ -73,6 +80,10 @@ #elif defined HAVE_WIN32_THREADS CRITICAL_SECTION cs; unsigned int count; +#elif defined HAVE_BEOS_THREADS + xmlMutexPtr lock; + thread_id tid; + int32 count; #else int empty; #endif @@ -96,7 +107,12 @@ #endif /* HAVE_COMPILER_TLS */ static DWORD mainthread; static int run_once_init = 1; -#endif /* HAVE_WIN32_THREADS */ +/* endif HAVE_WIN32_THREADS */ +#elif defined HAVE_BEOS_THREADS +int32 globalkey = 0; +thread_id mainthread = 0; +int32 run_once_init = 0; +#endif static xmlRMutexPtr xmlLibraryLock = NULL; #ifdef LIBXML_THREAD_ENABLED @@ -122,6 +138,11 @@ pthread_mutex_init(&tok->lock, NULL); #elif defined HAVE_WIN32_THREADS tok->mutex = CreateMutex(NULL, FALSE, NULL); +#elif defined HAVE_BEOS_THREADS + if ((tok->sem = create_sem(1, "xmlMutex")) < B_OK) { + free(tok); + return NULL; + } #endif return (tok); } @@ -142,6 +163,8 @@ pthread_mutex_destroy(&tok->lock); #elif defined HAVE_WIN32_THREADS CloseHandle(tok->mutex); +#elif defined HAVE_BEOS_THREADS + delete_sem(tok->sem); #endif free(tok); } @@ -161,6 +184,13 @@ pthread_mutex_lock(&tok->lock); #elif defined HAVE_WIN32_THREADS WaitForSingleObject(tok->mutex, INFINITE); +#elif defined HAVE_BEOS_THREADS + if (acquire_sem(tok->sem) != B_NO_ERROR) { +#ifdef DEBUG_THREADS + xmlGenericError(xmlGenericErrorContext, "xmlMutexLock():BeOS:Couldn't aquire semaphore\n"); + exit(); +#endif + } #endif } @@ -180,6 +210,8 @@ pthread_mutex_unlock(&tok->lock); #elif defined HAVE_WIN32_THREADS ReleaseMutex(tok->mutex); +#elif defined HAVE_BEOS_THREADS + release_sem(tok->sem); #endif } @@ -208,6 +240,13 @@ #elif defined HAVE_WIN32_THREADS InitializeCriticalSection(&tok->cs); tok->count = 0; +#elif defined HAVE_BEOS_THREADS + if ((tok->lock = xmlNewMutex()) == NULL) { + free(tok); + return NULL; + } + tok->count = 0; + tok->tid = 0; #endif return (tok); } @@ -226,6 +265,8 @@ pthread_mutex_destroy(&tok->lock); #elif defined HAVE_WIN32_THREADS DeleteCriticalSection(&tok->cs); +#elif defined HAVE_BEOS_THREADS + xmlFreeMutex(tok->lock); #endif free(tok); } @@ -261,6 +302,15 @@ #elif defined HAVE_WIN32_THREADS EnterCriticalSection(&tok->cs); ++tok->count; +#elif defined HAVE_BEOS_THREADS + if (tok->tid == find_thread(NULL)) { + tok->count++; + return; + } else { + xmlMutexLock(tok->lock); + tok->tid = find_thread(NULL); + tok->count = 1; + } #endif } @@ -287,6 +337,15 @@ #elif defined HAVE_WIN32_THREADS if (!--tok->count) LeaveCriticalSection(&tok->cs); +#elif defined HAVE_BEOS_THREADS + if (tok->tid == find_thread(NULL)) { + tok->count--; + if (tok->count == 0) { + tok->tid = 0; + xmlMutexUnlock(tok->lock); + } + return; + } #endif } @@ -369,6 +428,15 @@ #endif /* HAVE_COMPILER_TLS */ #endif /* HAVE_WIN32_THREADS */ +#if defined HAVE_BEOS_THREADS +void xmlGlobalStateCleanup(void *data) +{ + void *globalval = tls_get(globalkey); + if (globalval != NULL) + xmlFreeGlobalState(globalval); +} +#endif + /** * xmlGetGlobalState: * @@ -438,6 +506,20 @@ } return (globalval); #endif /* HAVE_COMPILER_TLS */ +#elif defined HAVE_BEOS_THREADS + xmlGlobalState *globalval; + + xmlOnceInit(); + + if ((globalval = (xmlGlobalState *) + tls_get(globalkey)) == NULL) { + xmlGlobalState *tsd = xmlNewGlobalState(); + + tls_set(globalkey, tsd); + on_exit_thread(xmlGlobalStateCleanup, NULL); + return (tsd); + } + return (globalval); #else return(NULL); #endif @@ -463,6 +545,8 @@ return((int) pthread_self()); #elif defined HAVE_WIN32_THREADS return GetCurrentThreadId(); +#elif defined HAVE_BEOS_THREADS + return find_thread(NULL); #else return((int) 0); #endif @@ -485,6 +569,8 @@ run_once_init = 0; xmlOnceInit (); } +#elif defined HAVE_BEOS_THREADS + xmlOnceInit(); #endif #ifdef DEBUG_THREADS @@ -494,6 +580,8 @@ return(mainthread == pthread_self()); #elif defined HAVE_WIN32_THREADS return(mainthread == GetCurrentThreadId ()); +#elif defined HAVE_BEOS_THREADS + return(mainthread == find_thread(NULL)); #else return(1); #endif @@ -600,6 +688,15 @@ globalkey = TlsAlloc(); #endif mainthread = GetCurrentThreadId(); +#endif + +#ifdef HAVE_BEOS_THREADS + if (atomic_add(&run_once_init, 1) == 0) { + globalkey = tls_allocate(); + tls_set(globalkey, NULL); + mainthread = find_thread(NULL); + } else + atomic_add(&run_once_init, -1); #endif } #endif --_=_BOUNDARY_1495774274_1_=_-- From veillard@redhat.com Wed Oct 29 08:23:29 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id D2B11183E9 for ; Wed, 29 Oct 2003 08:23:28 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9TDNhC29291; Wed, 29 Oct 2003 08:23:43 -0500 Date: Wed, 29 Oct 2003 08:23:43 -0500 From: Daniel Veillard To: Steve Ball Cc: xml@gnome.org Subject: Re: [xml] RFE: Schema-validation API Message-ID: <20031029082343.E18691@redhat.com> Reply-To: veillard@redhat.com References: <3F8B3F93.5040500@zveno.com> <20031014034211.N29460@redhat.com> <3F9FB1C2.70405@zveno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3F9FB1C2.70405@zveno.com>; from Steve.Ball@zveno.com on Wed, Oct 29, 2003 at 11:25:38PM +1100 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, Oct 29, 2003 at 11:25:38PM +1100, Steve Ball wrote: > Hi Daniel, > > Please find attached a patch to add a new API as discussed > below. The API has been tested via my own project, > but if you would like an additional patch for testschemas.c > let me know. Nahh, this looks simple enough, there is little room for errors, except maybe the allocation strategy. Ideally freeing the context should not free the document since the document was provided by the user. I don't know if this is worth noting or taking care of. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard@redhat.com Wed Oct 29 08:39:04 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 5A76F18154 for ; Wed, 29 Oct 2003 08:39:04 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9TDdI502770; Wed, 29 Oct 2003 08:39:18 -0500 Date: Wed, 29 Oct 2003 08:39:18 -0500 From: Daniel Veillard To: shard@neoni.net Cc: xml@gnome.org Subject: Re: [xml] [PATCH] BeOS threading support. Message-ID: <20031029083918.F18691@redhat.com> Reply-To: veillard@redhat.com References: <20031029115403.857.3@bepc.home.astercity.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031029115403.857.3@bepc.home.astercity.net>; from shard@neoni.net on Wed, Oct 29, 2003 at 11:54:03AM +0100 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, Oct 29, 2003 at 11:54:03AM +0100, shard@neoni.net wrote: > Hi, > > I've modified threads.c and testThreads to let libxml2 use "mutex" etc.. > code on BeOS. > There is partly implemented libpthreads for BeOS, but it's very far from > usable state :( > > I also "fixed" nanoftp.c and nanohttp.c - they wouldn't compile with > -DSTANDALONE on BeOS because of lack of data casting in few places :( > > i added testThreadsBeOS.c file, but didn't know how to make configure > script, or makefile base files to use it instead of testThreads.c without > some hacking in them. so i just removed testThreads.c and put symlink with > that name to testThreadsBeOS.c - that's why in attached diff file there > are changes in testThreads.c. Okay, the patch looks clean, doesn't seems to introduce any regression, so applied and commited to CVS, thanks, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From novak@merlot.ics.muni.cz Wed Oct 29 08:59:59 2003 Return-Path: Delivered-To: xml@gnome.org Received: from merlot.ics.muni.cz (merlot.ics.muni.cz [147.251.18.30]) by mail.gnome.org (Postfix) with ESMTP id 38D94185E3 for ; Wed, 29 Oct 2003 08:59:59 -0500 (EST) Received: (from novak@localhost) by merlot.ics.muni.cz (8.11.7p1+Sun/8.11.6) id h9TE0GF11876 for xml@gnome.org; Wed, 29 Oct 2003 15:00:16 +0100 (MET) Date: Wed, 29 Oct 2003 15:00:16 +0100 From: Petr Novak To: xml@gnome.org Message-ID: <20031029140016.GB11717@merlot.ics.muni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.25i Subject: [xml] validation API question at the second time Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi all, I can ask if it is possible now in libxml2-2.6.1 someway validate XML document against DTD or XML Scheme (or Relax NG in future) and obtain elements or attributes which are not valid. There is used xmlValidityErrorFunc in xmllint.c. But it returns only error text message. I need link to the element. I read that this will be possible in libxml2-2.6.0 but i cannot find nothing in documentation. Cheers -petrn -- Petr Novak, Liberouter Project (www.liberouter.org) E-mail: novak@merlot.ics.muni.cz From shard@neoni.net Wed Oct 29 09:41:28 2003 Return-Path: Delivered-To: xml@gnome.org Received: from nicolaus.az.pl (nicolaus.az.pl [217.153.59.68]) by mail.gnome.org (Postfix) with ESMTP id C76A118CB3 for ; Wed, 29 Oct 2003 09:41:27 -0500 (EST) Received: from bepc.home.astercity.net (69-ego-3.acn.waw.pl [62.121.86.69]) by nicolaus.az.pl (8.11.6/8.11.6) with ESMTP id h9TEfVq09329 for ; Wed, 29 Oct 2003 15:41:31 +0100 Date: Wed, 29 Oct 2003 15:41:26 +0100 From: shard@neoni.net Message-Id: <20031029154126.16085.3@bepc.home.astercity.net> Mime-Version: 1.0 To: xml@gnome.org User-Agent: Beam 1.0-rc4 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [xml] Threads support question Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi, I've made xmlMutex based only on semaphore. That means there is no "prevention" from calling xmlMutex->Unlock() multiple times (ie. more than it was locked). Because of such thing, smaphore will have more than one "free slot", and more than one thread, or the same thread few times, will be able to lock it. Now question: Should i add counter also there, and prevent from unlocking too many times, or leave it to application developers? Regads Shard From acarrico@memebeam.org Wed Oct 29 10:43:52 2003 Return-Path: Delivered-To: xml@gnome.org Received: from jvb.vm.bytemark.co.uk (ege-inc.org [212.13.199.72]) by mail.gnome.org (Postfix) with ESMTP id 5B5E4181AA for ; Wed, 29 Oct 2003 10:43:45 -0500 (EST) Received: from sub-d.memebeam.org (user-10mt0kf.cable.mindspring.com [::ffff:65.110.130.143]) (AUTH: LOGIN acarrico@memebeam.org, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by jvb.vm.bytemark.co.uk with esmtp; Wed, 29 Oct 2003 10:43:57 -0500 Received: from acarrico by sub-d.memebeam.org with local (Exim 3.35 #1 (Debian)) id 1AEsRK-0001JN-00; Wed, 29 Oct 2003 10:40:54 -0500 Date: Wed, 29 Oct 2003 10:40:54 -0500 From: Anthony Carrico To: Daniel Veillard Cc: libxml Subject: Re: [xml] unregister XPath namespace prefix crash (python bindings) Message-ID: <20031029154054.GA4939@memebeam.org> References: <20031029034343.GA4108@memebeam.org> <20031029061515.B18691@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <20031029061515.B18691@redhat.com> User-Agent: Mutt/1.5.4i Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, Oct 29, 2003 at 06:15:15AM -0500, Daniel Veillard wrote: > Yeah, that sounds right. I changed that in CVS. I also tried to > add more checks in the hash module to avoid the problem in a more general > way. Thanks. Oops. You probably caught it, but that little patch should say: return(xmlHashRemoveEntry(ctxt->nsHash, prefix, ... not: return(xmlHashRemoveEntry(ctxt->nsHash, ns_uri, ... Also, I'm guessing there the same bug exists in the other xmlXPathRegister* procedures. -- Anthony Carrico From aleksey@aleksey.com Wed Oct 29 10:52:02 2003 Return-Path: Delivered-To: xml@gnome.org Received: from shell.aleksey.com (dsl093-129-176.sfo4.dsl.speakeasy.net [66.93.129.176]) by mail.gnome.org (Postfix) with ESMTP id 426E818147 for ; Wed, 29 Oct 2003 10:52:02 -0500 (EST) Received: from aleksey.com (unknown [192.168.1.63]) by shell.aleksey.com (Postfix) with ESMTP id CEE84B5B6; Wed, 29 Oct 2003 07:52:19 -0800 (PST) Message-ID: <3F9FE22E.8090209@aleksey.com> Date: Wed, 29 Oct 2003 07:52:14 -0800 From: Aleksey Sanin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, ru MIME-Version: 1.0 To: veillard@redhat.com Cc: xml Subject: Re: [xml] [patch] xmlStrVPrintf References: <3F9F3D99.7060102@aleksey.com> <20031029042148.M23901@redhat.com> In-Reply-To: <20031029042148.M23901@redhat.com> Content-Type: multipart/alternative; boundary="------------070808060502020706020407" Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. --------------070808060502020706020407 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Commited. Thank you very much! Aleksey Checking in include/libxml/parser.h; /cvs/gnome/gnome-xml/include/libxml/parser.h,v <-- parser.h new revision: 1.108; previous revision: 1.107 done Checking in parser.c; /cvs/gnome/gnome-xml/parser.c,v <-- parser.c new revision: 1.341; previous revision: 1.340 done Checking in ChangeLog; /cvs/gnome/gnome-xml/ChangeLog,v <-- ChangeLog new revision: 1.1731; previous revision: 1.1730 done Daniel Veillard wrote: >On Tue, Oct 28, 2003 at 08:10:01PM -0800, Aleksey Sanin wrote: > > >>Daniel, >> >>I found that in addition to xmlStrPrintf I need xmlStrVPrintf function >>for strings formatting. It's a trivial wrapper around Trio function and >>I hope >>that you wouldn't object to add this function to LibXML2 API. >> >> > > Sure, please commit it ! > >Daniel > > > --------------070808060502020706020407 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Commited. Thank you very much!

Aleksey

Checking in include/libxml/parser.h;
/cvs/gnome/gnome-xml/include/libxml/parser.h,v  <--  parser.h
new revision: 1.108; previous revision: 1.107
done
Checking in parser.c;
/cvs/gnome/gnome-xml/parser.c,v  <--  parser.c
new revision: 1.341; previous revision: 1.340
done
Checking in ChangeLog;
/cvs/gnome/gnome-xml/ChangeLog,v  <--  ChangeLog
new revision: 1.1731; previous revision: 1.1730
done



Daniel Veillard wrote:
On Tue, Oct 28, 2003 at 08:10:01PM -0800, Aleksey Sanin wrote:
  
Daniel,

I found that in addition to xmlStrPrintf I need xmlStrVPrintf function
for strings formatting. It's a trivial wrapper around Trio function and 
I hope
that you wouldn't object to add this function to LibXML2 API.
    

  Sure, please commit it !

Daniel
--------------070808060502020706020407-- From veillard@redhat.com Wed Oct 29 11:45:31 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id ED356183B2 for ; Wed, 29 Oct 2003 11:45:30 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9TGjjJ07307; Wed, 29 Oct 2003 11:45:45 -0500 Date: Wed, 29 Oct 2003 11:45:45 -0500 From: Daniel Veillard To: Anthony Carrico Cc: libxml Subject: Re: [xml] unregister XPath namespace prefix crash (python bindings) Message-ID: <20031029114545.E25702@redhat.com> Reply-To: veillard@redhat.com References: <20031029034343.GA4108@memebeam.org> <20031029061515.B18691@redhat.com> <20031029154054.GA4939@memebeam.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031029154054.GA4939@memebeam.org>; from acarrico@memebeam.org on Wed, Oct 29, 2003 at 10:40:54AM -0500 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, Oct 29, 2003 at 10:40:54AM -0500, Anthony Carrico wrote: > On Wed, Oct 29, 2003 at 06:15:15AM -0500, Daniel Veillard wrote: > > Yeah, that sounds right. I changed that in CVS. I also tried to > > add more checks in the hash module to avoid the problem in a more general > > way. > > Thanks. Oops. You probably caught it, but that little patch should > say: > > return(xmlHashRemoveEntry(ctxt->nsHash, prefix, ... > > not: > > return(xmlHashRemoveEntry(ctxt->nsHash, ns_uri, ... oh, that explains the -1 in the python test :-) > Also, I'm guessing there the same bug exists in the other > xmlXPathRegister* procedures. yeah did something similar for variables, and functions, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From Mark_Vakoc@jdedwards.com Wed Oct 29 11:48:00 2003 Return-Path: Delivered-To: xml@gnome.org Received: from ns2.jdedwards.com (ns2.jdedwards.com [199.166.248.75]) by mail.gnome.org (Postfix) with ESMTP id E7E5118313 for ; Wed, 29 Oct 2003 11:47:59 -0500 (EST) Received: from denvscans4.jdedwards.com ([10.0.14.76]) by ns2.jdedwards.com (8.11.6/8.11.6) with SMTP id h9TGmIf09054 for ; Wed, 29 Oct 2003 09:48:18 -0700 Received: from 10.0.14.87 by denvscans4.jdedwards.com (InterScan E-Mail VirusWall NT); Wed, 29 Oct 2003 09:48:17 -0700 Received: from denmails3.jdedwards.com ([10.0.14.80]) by densmtps1.jdedwards.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 29 Oct 2003 09:48:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C39E3C.73E357DD" Date: Wed, 29 Oct 2003 09:48:17 -0700 Message-ID: <09B3671D58690A4193A7F8F15F416B23FF27B3@denmails3.jdedwards.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: missing _cplusplus clause Thread-Index: AcOePHPW/i0ExSXVRHe+fxWATls/Aw== From: "Vakoc, Mark" To: X-OriginalArrivalTime: 29 Oct 2003 16:48:17.0694 (UTC) FILETIME=[73F183E0:01C39E3C] Subject: [xml] missing _cplusplus clause Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------_=_NextPart_001_01C39E3C.73E357DD Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C39E3C.73E357DD" ------_=_NextPart_002_01C39E3C.73E357DD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In relaxng.h =20 =20 ------_=_NextPart_002_01C39E3C.73E357DD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In relaxng.h

 

 

=00 ------_=_NextPart_002_01C39E3C.73E357DD-- ------_=_NextPart_001_01C39E3C.73E357DD Content-Type: application/octet-stream; name="relaxng.diff" Content-Transfer-Encoding: base64 Content-Description: relaxng.diff Content-Disposition: attachment; filename="relaxng.diff" SW5kZXg6IHJlbGF4bmcuaA0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC9jdnMvZ25vbWUvZ25vbWUt eG1sL2luY2x1ZGUvbGlieG1sL3JlbGF4bmcuaCx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMTUN CmRpZmYgLWMgLXIxLjE1IHJlbGF4bmcuaA0KKioqIHJlbGF4bmcuaAkyOSBTZXAgMjAwMyAxMzoy MDoyMiAtMDAwMAkxLjE1DQotLS0gcmVsYXhuZy5oCTI5IE9jdCAyMDAzIDE2OjQ2OjMyIC0wMDAw DQoqKioqKioqKioqKioqKioNCioqKiAxMiwxNyAqKioqDQotLS0gMTIsMjEgLS0tLQ0KICAjaW5j bHVkZSA8bGlieG1sL3htbHZlcnNpb24uaD4NCiAgI2luY2x1ZGUgPGxpYnhtbC9oYXNoLmg+DQog IA0KKyAjaWZkZWYgX19jcGx1c3BsdXMNCisgZXh0ZXJuICJDIiB7DQorICNlbmRpZg0KKyANCiAg dHlwZWRlZiBzdHJ1Y3QgX3htbFJlbGF4TkcgeG1sUmVsYXhORzsNCiAgdHlwZWRlZiB4bWxSZWxh eE5HICp4bWxSZWxheE5HUHRyOw0KICANCioqKioqKioqKioqKioqKg0KKioqIDE1MiwxNTUgKioq Kg0KLS0tIDE1NiwxNjMgLS0tLQ0KICAJCSAgICB4bWxSZWxheE5HVmFsaWRhdGVGdWxsRWxlbWVu dAkoeG1sUmVsYXhOR1ZhbGlkQ3R4dFB0ciBjdHh0LA0KICAJCQkJCSB4bWxEb2NQdHIgZG9jLA0K ICAJCQkJCSB4bWxOb2RlUHRyIGVsZW0pOw0KKyANCisgI2lmZGVmIF9fY3BsdXNwbHVzDQorIH0N CisgI2VuZGlmDQogICNlbmRpZiAvKiBfX1hNTF9SRUxBWF9OR19fICovDQo= ------_=_NextPart_001_01C39E3C.73E357DD-- From Mark_Vakoc@jdedwards.com Wed Oct 29 11:54:55 2003 Return-Path: Delivered-To: xml@gnome.org Received: from ns1.jdedwards.com (ns1.jdedwards.com [199.166.248.147]) by mail.gnome.org (Postfix) with ESMTP id E465D18C27 for ; Wed, 29 Oct 2003 11:54:54 -0500 (EST) Received: from denvscans3.jdedwards.com ([10.0.14.77]) by ns1.jdedwards.com (8.11.6/8.11.6) with SMTP id h9TGtD307479 for ; Wed, 29 Oct 2003 09:55:13 -0700 Received: from 10.0.14.88 by denvscans3.jdedwards.com (InterScan E-Mail VirusWall NT); Wed, 29 Oct 2003 09:55:12 -0700 Received: from denmails3.jdedwards.com ([10.0.14.80]) by densmtps2.jdedwards.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 29 Oct 2003 09:55:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C39E3D.6B2FD812" Date: Wed, 29 Oct 2003 09:55:12 -0700 Message-ID: <09B3671D58690A4193A7F8F15F416B23FF27B4@denmails3.jdedwards.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: xmlIO.c fix Thread-Index: AcOePWsqPmnyj3o8TAKkdouuIQXbYg== From: "Vakoc, Mark" To: X-OriginalArrivalTime: 29 Oct 2003 16:55:12.0523 (UTC) FILETIME=[6B3365B0:01C39E3D] Subject: [xml] xmlIO.c fix Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------_=_NextPart_001_01C39E3D.6B2FD812 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C39E3D.6B2FD812" ------_=_NextPart_002_01C39E3D.6B2FD812 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable When http isn't compiled in =20 =20 ------_=_NextPart_002_01C39E3D.6B2FD812 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

When http isn’t compiled in

 

 

=00 ------_=_NextPart_002_01C39E3D.6B2FD812-- ------_=_NextPart_001_01C39E3D.6B2FD812 Content-Type: application/octet-stream; name="xmlIo.diff" Content-Transfer-Encoding: base64 Content-Description: xmlIo.diff Content-Disposition: attachment; filename="xmlIo.diff" SW5kZXg6IHhtbElPLmMNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0NClJDUyBmaWxlOiAvY3ZzL2dub21lL2dub21lLXht bC94bWxJTy5jLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4xMzINCmRpZmYgLWMgLXIxLjEzMiB4 bWxJTy5jDQoqKiogeG1sSU8uYwkyNyBPY3QgMjAwMyAxMToyNToxMyAtMDAwMAkxLjEzMg0KLS0t IHhtbElPLmMJMjkgT2N0IDIwMDMgMTY6NTQ6NTcgLTAwMDANCioqKioqKioqKioqKioqKg0KKioq IDIxODgsMjE5NiAqKioqDQogICAgICB2b2lkICpjb250ZXh0ID0gTlVMTDsNCiAgICAgIGNoYXIg KnVuZXNjYXBlZDsNCiAgDQotICNpZmRlZiBMSUJYTUxfSFRUUF9FTkFCTEVEDQogICAgICBpbnQg aXNfaHR0cF91cmkgPSAwOwkvKiAgIENhbid0IGNoYW5nZSBpZiBIVFRQIGRpc2FibGVkICAqLw0K LSAjZW5kaWYNCiAgDQogICAgICBpZiAoeG1sT3V0cHV0Q2FsbGJhY2tJbml0aWFsaXplZCA9PSAw KQ0KICAJeG1sUmVnaXN0ZXJEZWZhdWx0T3V0cHV0Q2FsbGJhY2tzKCk7DQotLS0gMjE4OCwyMTk0 IC0tLS0NCg== ------_=_NextPart_001_01C39E3D.6B2FD812-- From veillard@redhat.com Wed Oct 29 12:10:12 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 3112D1837C for ; Wed, 29 Oct 2003 12:10:12 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9THATb20892; Wed, 29 Oct 2003 12:10:29 -0500 Date: Wed, 29 Oct 2003 12:10:29 -0500 From: Daniel Veillard To: "Vakoc, Mark" Cc: xml@gnome.org Subject: Re: [xml] missing _cplusplus clause Message-ID: <20031029121029.F25702@redhat.com> Reply-To: veillard@redhat.com References: <09B3671D58690A4193A7F8F15F416B23FF27B3@denmails3.jdedwards.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <09B3671D58690A4193A7F8F15F416B23FF27B3@denmails3.jdedwards.com>; from Mark_Vakoc@jdedwards.com on Wed, Oct 29, 2003 at 09:48:17AM -0700 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, Oct 29, 2003 at 09:48:17AM -0700, Vakoc, Mark wrote: > In relaxng.h Oops, right ! applied and commited, thanks, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard@redhat.com Wed Oct 29 12:22:53 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 4B2F7184D3 for ; Wed, 29 Oct 2003 12:22:53 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9THNAn28687; Wed, 29 Oct 2003 12:23:10 -0500 Date: Wed, 29 Oct 2003 12:23:09 -0500 From: Daniel Veillard To: "Vakoc, Mark" Cc: xml@gnome.org Subject: Re: [xml] xmlIO.c fix Message-ID: <20031029122309.G25702@redhat.com> Reply-To: veillard@redhat.com References: <09B3671D58690A4193A7F8F15F416B23FF27B4@denmails3.jdedwards.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <09B3671D58690A4193A7F8F15F416B23FF27B4@denmails3.jdedwards.com>; from Mark_Vakoc@jdedwards.com on Wed, Oct 29, 2003 at 09:55:12AM -0700 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, Oct 29, 2003 at 09:55:12AM -0700, Vakoc, Mark wrote: > When http isn't compiled in okay, applied and commited, thanks, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From Steve.Ball@zveno.com Wed Oct 29 15:15:07 2003 Return-Path: Delivered-To: xml@gnome.org Received: from waycool.zveno.com (static-ctb0236.webone.com.au [210.9.242.36]) by mail.gnome.org (Postfix) with ESMTP id B6F3E18EDB for ; Wed, 29 Oct 2003 15:15:06 -0500 (EST) Received: from zveno.com (pbook [192.168.0.4]) by waycool.zveno.com (8.12.8/8.12.8) with ESMTP id h9TLlGWI009901; Thu, 30 Oct 2003 08:47:17 +1100 Message-ID: <3FA0203E.6050407@zveno.com> Date: Thu, 30 Oct 2003 07:17:02 +1100 From: Steve Ball Reply-To: Steve.Ball@zveno.com Organization: Zveno Pty Ltd User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: veillard@redhat.com Cc: xml@gnome.org Subject: Re: [xml] RFE: Schema-validation API References: <3F8B3F93.5040500@zveno.com> <20031014034211.N29460@redhat.com> <3F9FB1C2.70405@zveno.com> <20031029082343.E18691@redhat.com> In-Reply-To: <20031029082343.E18691@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Daniel Veillard wrote: > On Wed, Oct 29, 2003 at 11:25:38PM +1100, Steve Ball wrote: >>Please find attached a patch to add a new API as discussed >>below. The API has been tested via my own project, >>but if you would like an additional patch for testschemas.c >>let me know. > > Nahh, this looks simple enough, there is little room for errors, > except maybe the allocation strategy. Ideally freeing the context > should not free the document since the document was provided by the > user. I don't know if this is worth noting or taking care of. The document may be modified by the schema parser routine (whitespace trimmed), so the application *should* provide a copy (at least, that would be best practise). The doco for the new API includes a note to that effect. I'm happy enough that the schema context assumes ownership of the document that it is given. Cheers, Steve Ball -- Steve Ball | XSLT Standard Library | Training & Seminars Zveno Pty Ltd | Web Tcl Complete | XML XSL Schemas http://www.zveno.com/ | TclXML TclDOM | Tcl, Web Development Steve.Ball@zveno.com +---------------------------+--------------------- Ph. +61 2 6242 4099 | Mobile (0413) 594 462 | Fax +61 2 6242 4099 From veillard@redhat.com Wed Oct 29 17:23:29 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 8932F180DB for ; Wed, 29 Oct 2003 17:23:29 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9TMMl331144; Wed, 29 Oct 2003 17:22:47 -0500 Date: Wed, 29 Oct 2003 17:22:47 -0500 From: Daniel Veillard To: Steve Ball Cc: xml@gnome.org Subject: Re: [xml] RFE: Schema-validation API Message-ID: <20031029172247.J25702@redhat.com> Reply-To: veillard@redhat.com References: <3F8B3F93.5040500@zveno.com> <20031014034211.N29460@redhat.com> <3F9FB1C2.70405@zveno.com> <20031029082343.E18691@redhat.com> <3FA0203E.6050407@zveno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3FA0203E.6050407@zveno.com>; from Steve.Ball@zveno.com on Thu, Oct 30, 2003 at 07:17:02AM +1100 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, Oct 30, 2003 at 07:17:02AM +1100, Steve Ball wrote: > Daniel Veillard wrote: > > On Wed, Oct 29, 2003 at 11:25:38PM +1100, Steve Ball wrote: > >>Please find attached a patch to add a new API as discussed > >>below. The API has been tested via my own project, > >>but if you would like an additional patch for testschemas.c > >>let me know. > > > > Nahh, this looks simple enough, there is little room for errors, > > except maybe the allocation strategy. Ideally freeing the context > > should not free the document since the document was provided by the > > user. I don't know if this is worth noting or taking care of. > > The document may be modified by the schema parser routine > (whitespace trimmed), so the application *should* provide > a copy (at least, that would be best practise). The doco > for the new API includes a note to that effect. Excellent :-) Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From christi@fsmath.zbt.uni-heidelberg.de Wed Oct 29 16:34:16 2003 Return-Path: Delivered-To: xml@gnome.org Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by mail.gnome.org (Postfix) with ESMTP id 093E61812F for ; Wed, 29 Oct 2003 16:34:16 -0500 (EST) Received: from ix.urz.uni-heidelberg.de (mail.urz.uni-heidelberg.de [129.206.119.234]) by relay.uni-heidelberg.de (8.12.10/8.12.10) with ESMTP id h9TLYUaj012592 for ; Wed, 29 Oct 2003 22:34:31 +0100 (MET) Received: from fsmath.zbt.uni-heidelberg.de (mail@fsmath.zbt.uni-heidelberg.de [129.206.91.26]) by ix.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id WAA47622 for ; Wed, 29 Oct 2003 22:34:31 +0100 Received: from christi by fsmath.zbt.uni-heidelberg.de with local (Exim 3.35 #1 (Debian)) id 1AExxX-0003iC-00 for ; Wed, 29 Oct 2003 22:34:31 +0100 Date: Wed, 29 Oct 2003 22:34:31 +0100 From: Christian Engwer To: xml@gnome.org Message-ID: <20031029213431.GA13391@mathphys.fsk.uni-heidelberg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Subject: [xml] xmlIO extensions Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi, I am currently using libxml2.4 for a private project. During this work I was in need for a special xmlIO handler. I wanted to store all needed files inside one archive (like the document structure of openoffice.org). So I wrote an IO handler for zip files. I can now read an write files inside a ziparchive. The work is based on the xmlIO handlers provided with the lib and the zip code is taken from minizip/miniunzip examples provided with zlib. I think this code might be usefull for others as well, so I'd like to publish it. If desired I can adopt it to 2.6 or provide patches to integrate it into the cvs. My biggest Problem right now is the license. I read both licenses (that of libxml and that of zlib/minizip). I think it would be nice to use the same license for everything in libxml. I think both licenses are quite equal, so that the usage of zlib-code would not restrict anything. My code would be published under the term of the MIT License. If anyone would ike to have a look at the software ... you can find it at http://hal.iwr.uni-heidelberg.de/~christi/xmlzipio/ Cheers Christian From veillard@redhat.com Wed Oct 29 17:56:57 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 3E3CA18612 for ; Wed, 29 Oct 2003 17:56:57 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9TMvAK13947; Wed, 29 Oct 2003 17:57:10 -0500 Date: Wed, 29 Oct 2003 17:57:10 -0500 From: Daniel Veillard To: Christian Engwer Cc: xml@gnome.org Subject: Re: [xml] xmlIO extensions Message-ID: <20031029175710.L25702@redhat.com> Reply-To: veillard@redhat.com References: <20031029213431.GA13391@mathphys.fsk.uni-heidelberg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031029213431.GA13391@mathphys.fsk.uni-heidelberg.de>; from christi@fsmath.zbt.uni-heidelberg.de on Wed, Oct 29, 2003 at 10:34:31PM +0100 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Wed, Oct 29, 2003 at 10:34:31PM +0100, Christian Engwer wrote: > Hi, > > I am currently using libxml2.4 for a private project. During this work > I was in need for a special xmlIO handler. > > I wanted to store all needed files inside one archive (like the > document structure of openoffice.org). So I wrote an IO handler for > zip files. I can now read an write files inside a ziparchive. The work > is based on the xmlIO handlers provided with the lib and the zip code > is taken from minizip/miniunzip examples provided with zlib. > > I think this code might be usefull for others as well, so I'd like to > publish it. If desired I can adopt it to 2.6 or provide patches to > integrate it into the cvs. > > My biggest Problem right now is the license. I read both licenses > (that of libxml and that of zlib/minizip). I think it would be nice to > use the same license for everything in libxml. I think both licenses > are quite equal, so that the usage of zlib-code would not restrict > anything. My code would be published under the term of the MIT License. > > If anyone would ike to have a look at the software ... > you can find it at > http://hal.iwr.uni-heidelberg.de/~christi/xmlzipio/ Looked briefly at it, interesting but I think you made an error in the naming scheme. Basically your scheme doesn't seems to be an URI, which mean you loose the automatic naming support. Suppose you have top.xml and chapter.xml in the same zip, that top.xml references chapter.xml for entities or XInclude, you would get something like href="chapter.xml" in top.xml . If your naming scheme was an URI then the libxml2 XInclude processor, given the name for the top.xml resource and the href="chapter.xml" URI-Reference would automatically compute the chapter.xml URI based on the top.xml one and would be able to transparently process the include. I think preserving this property is really important in practice. The problem is that if you take test.zip#zip:top.xml as the base and try to compute the URI-Reference chapter.xml from it you end up with chapter.xml and not test.zip#zip:chapter.xml That's a serious limitation, most of the URI-Reference used for DTD, entities, XInclude, XPointer, etc... won't work out of the box within the zip archive while if the naming was done differently all this could "just work". Something like zip:///path/to/zip/test.zip/top.xml is similar to the file:// scheme, would allow URI-Reference and fragment identifiers. But it would have the same limitations as file:// , namely it's difficult to express addressing relative to the curent directory. Maybe the OpenOffice people have done it right...it's worth checking. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From Mark_Vakoc@jdedwards.com Wed Oct 29 20:00:47 2003 Return-Path: Delivered-To: xml@gnome.org Received: from ns2.jdedwards.com (ns2.jdedwards.com [199.166.248.75]) by mail.gnome.org (Postfix) with ESMTP id 32B16180DB for ; Wed, 29 Oct 2003 20:00:47 -0500 (EST) Received: from denvscans4.jdedwards.com ([10.0.14.76]) by ns2.jdedwards.com (8.11.6/8.11.6) with SMTP id h9U114901598 for ; Wed, 29 Oct 2003 18:01:05 -0700 Received: from 10.0.14.88 by denvscans4.jdedwards.com (InterScan E-Mail VirusWall NT); Wed, 29 Oct 2003 18:01:04 -0700 Received: from denmails3.jdedwards.com ([10.0.14.80]) by densmtps2.jdedwards.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 29 Oct 2003 18:01:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [xml] xmlIO extensions Date: Wed, 29 Oct 2003 18:01:04 -0700 Message-ID: <09B3671D58690A4193A7F8F15F416B23FF27B5@denmails3.jdedwards.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [xml] xmlIO extensions Thread-Index: AcOecA820oe/m0Y+QvyfjfCckImJXgAEOg3w From: "Vakoc, Mark" To: X-OriginalArrivalTime: 30 Oct 2003 01:01:04.0093 (UTC) FILETIME=[4AE3F8D0:01C39E81] Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: I have been using a similar xmlIO extraction for several years with libxml2. It is also based on the zlib/minizip code. The format I have been using is: zip://something.zip/path/to/file/in/zip.xml In my case I know the location of the something.zip file so it doesn't support currently support searching the filesystem for the file. I suppose that could be added using Daniel's suggestion if you require that the zip file end in '.zip'. Anyways it works with XInclude processing and I assume would work with relative URIs though I never use them with the zip:// protocol. =20 I think I at one point had an output handler using the same scheme to store files into the zip file but I think I removed that b/c I no longer use it. If anyone wants to look at my code for comparision I will be more than happy to post it. It isn't very many lines. -----Original Message----- From: Daniel Veillard [mailto:veillard@redhat.com]=20 Sent: Wednesday, October 29, 2003 3:57 PM To: Christian Engwer Cc: xml@gnome.org Subject: Re: [xml] xmlIO extensions On Wed, Oct 29, 2003 at 10:34:31PM +0100, Christian Engwer wrote: > Hi, >=20 > I am currently using libxml2.4 for a private project. During this work > I was in need for a special xmlIO handler. >=20 > I wanted to store all needed files inside one archive (like the > document structure of openoffice.org). So I wrote an IO handler for > zip files. I can now read an write files inside a ziparchive. The work > is based on the xmlIO handlers provided with the lib and the zip code > is taken from minizip/miniunzip examples provided with zlib. >=20 > I think this code might be usefull for others as well, so I'd like to > publish it. If desired I can adopt it to 2.6 or provide patches to > integrate it into the cvs. >=20 > My biggest Problem right now is the license. I read both licenses > (that of libxml and that of zlib/minizip). I think it would be nice to > use the same license for everything in libxml. I think both licenses > are quite equal, so that the usage of zlib-code would not restrict > anything. My code would be published under the term of the MIT License. >=20 > If anyone would ike to have a look at the software ... > you can find it at=20 > http://hal.iwr.uni-heidelberg.de/~christi/xmlzipio/ Looked briefly at it, interesting but I think you made an error in the naming scheme. Basically your scheme doesn't seems to be an URI, which mean you loose the automatic naming support. Suppose you have top.xml and chapter.xml in the same zip, that top.xml references chapter.xml for entities or XInclude, you would get something like href=3D"chapter.xml" in top.xml . If your naming = scheme was an URI then the libxml2 XInclude processor, given the name for the top.xml resource and the href=3D"chapter.xml" URI-Reference would automatically compute the chapter.xml URI based on the top.xml one and would be able to transparently process the include. I think preserving this property is really important in practice. The problem is that if you take test.zip#zip:top.xml as the base and try to compute the URI-Reference chapter.xml from it you end up with=20 chapter.xml and not=20 test.zip#zip:chapter.xml That's a serious limitation, most of the URI-Reference used for DTD, entities, XInclude, XPointer, etc... won't work out of the box within the zip archive while if the naming was done differently all this could "just work". Something like zip:///path/to/zip/test.zip/top.xml is similar to the file:// scheme, would allow URI-Reference and fragment identifiers. But it would have the same limitations as file:// , namely it's difficult to express addressing relative to the curent directory. Maybe the OpenOffice people have done it right...it's worth checking. Daniel --=20 Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ _______________________________________________ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml From christi@fsmath.zbt.uni-heidelberg.de Thu Oct 30 02:51:48 2003 Return-Path: Delivered-To: xml@gnome.org Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by mail.gnome.org (Postfix) with ESMTP id C06CA180F8 for ; Thu, 30 Oct 2003 02:51:47 -0500 (EST) Received: from ix.urz.uni-heidelberg.de (mail.urz.uni-heidelberg.de [129.206.119.234]) by relay.uni-heidelberg.de (8.12.10/8.12.10) with ESMTP id h9U7q3aj009435 for ; Thu, 30 Oct 2003 08:52:04 +0100 (MET) Received: from fsmath.zbt.uni-heidelberg.de (mail@fsmath.zbt.uni-heidelberg.de [129.206.91.26]) by ix.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id IAA29208 for ; Thu, 30 Oct 2003 08:52:04 +0100 Received: from christi by fsmath.zbt.uni-heidelberg.de with local (Exim 3.35 #1 (Debian)) id 1AF7bA-0007XK-00 for ; Thu, 30 Oct 2003 08:52:04 +0100 Date: Thu, 30 Oct 2003 08:52:04 +0100 From: Christian Engwer To: xml@gnome.org Subject: Re: [xml] xmlIO extensions Message-ID: <20031030075204.GC27473@mathphys.fsk.uni-heidelberg.de> References: <20031029213431.GA13391@mathphys.fsk.uni-heidelberg.de> <20031029175710.L25702@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031029175710.L25702@redhat.com> User-Agent: Mutt/1.3.28i Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi, > Looked briefly at it, interesting but I think you made an error in the > naming scheme. Basically your scheme doesn't seems to be an URI, which mean > you loose the automatic naming support. that is right, Inever experienced this problem, because I never used external entities inside the zip archive :-( > Something like zip:///path/to/zip/test.zip/top.xml is similar to the > file:// scheme, would allow URI-Reference and fragment identifiers. > But it would have the same limitations as file:// , namely it's difficult > to express addressing relative to the curent directory. The big disadvatage would be, that all archives would have to be named *.zip. I read through rfc2396 and have an other suggestion: I'd like to keep the syntax . That makes it easier to parse and offers the flexibility to name the archive in any way. I thought zip would be good . While reading through rfc2396 I found 3 chars which are allowed, but very uncommon for filenames: '!' '@' and ':'. So I'd suggest some uri like path/to/zip/test.zip@zip/top.xml This would impose a small limitation on the user... he could not use directories names ending on @zip while using xmlzipio, but I tink this is OK. I test all three chars, all three work fine, although I think @zip would be best readable. What would you think... Christian From veillard@redhat.com Thu Oct 30 03:35:39 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id E1E50180F8 for ; Thu, 30 Oct 2003 03:35:38 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9U8Zpw27959; Thu, 30 Oct 2003 03:35:51 -0500 Date: Thu, 30 Oct 2003 03:35:50 -0500 From: Daniel Veillard To: Christian Engwer Cc: xml@gnome.org Subject: Re: [xml] xmlIO extensions Message-ID: <20031030033550.M25702@redhat.com> Reply-To: veillard@redhat.com References: <20031029213431.GA13391@mathphys.fsk.uni-heidelberg.de> <20031029175710.L25702@redhat.com> <20031030075204.GC27473@mathphys.fsk.uni-heidelberg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031030075204.GC27473@mathphys.fsk.uni-heidelberg.de>; from christi@uni-hd.de on Thu, Oct 30, 2003 at 08:52:04AM +0100 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, Oct 30, 2003 at 08:52:04AM +0100, Christian Engwer wrote: > Hi, > > > Looked briefly at it, interesting but I think you made an error in the > > naming scheme. Basically your scheme doesn't seems to be an URI, which mean > > you loose the automatic naming support. > > that is right, Inever experienced this problem, because I never used > external entities inside the zip archive :-( > > > Something like zip:///path/to/zip/test.zip/top.xml is similar to the > > file:// scheme, would allow URI-Reference and fragment identifiers. > > But it would have the same limitations as file:// , namely it's difficult > > to express addressing relative to the curent directory. > > The big disadvatage would be, that all archives would have to be named > *.zip. I read through rfc2396 and have an other suggestion: > I'd like to keep the syntax . > That makes it easier to parse and offers the flexibility to name the > archive in any way. > I thought zip would be good . While reading > through rfc2396 I found 3 chars which are allowed, but very uncommon > for filenames: '!' '@' and ':'. > So I'd suggest some uri like > path/to/zip/test.zip@zip/top.xml > This would impose a small limitation on the user... he could not use > directories names ending on @zip while using xmlzipio, but I tink this > is OK. > > I test all three chars, all three work fine, although I think @zip > would be best readable. > > What would you think... Why not it seems it would work fine too. But even better, check how the OpenOffice guys did it and reuse it if possible ! Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From morus@tanto-xipolis.de Thu Oct 30 04:01:29 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail.tanto-xipolis.de (mail.xipolis.net [213.61.178.42]) by mail.gnome.org (Postfix) with ESMTP id B6C9A1880F for ; Thu, 30 Oct 2003 04:01:29 -0500 (EST) Received: from tucholsky.office.tanto.de (morus.xipolis.net [10.0.1.4]) by mail.tanto-xipolis.de (Postfix on SuSE Linux 7.3 (i386)) with ESMTP id 33B7419B74B for ; Thu, 30 Oct 2003 10:01:47 +0100 (CET) Received: from tucholsky.office.tanto.de (morus@tucholsky [127.0.0.1]) by tucholsky.office.tanto.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9U92l9t030321 for ; Thu, 30 Oct 2003 10:02:47 +0100 Received: (from morus@localhost) by tucholsky.office.tanto.de (8.12.3/8.12.3/Debian-6.6) id h9U92l93030317; Thu, 30 Oct 2003 10:02:47 +0100 From: Morus Walter MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16288.54198.953085.371046@tanto-xipolis.de> Date: Thu, 30 Oct 2003 10:02:46 +0100 To: xml@gnome.org Subject: Re: [xml] xmlIO extensions In-Reply-To: <20031030033550.M25702@redhat.com> References: <20031029213431.GA13391@mathphys.fsk.uni-heidelberg.de> <20031029175710.L25702@redhat.com> <20031030075204.GC27473@mathphys.fsk.uni-heidelberg.de> <20031030033550.M25702@redhat.com> X-Mailer: VM 7.03 under 21.4 (patch 6) "Common Lisp" XEmacs Lucid Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Daniel Veillard writes: > > Why not it seems it would work fine too. > But even better, check how the OpenOffice guys did it and > reuse it if possible ! > It's not OpenOffice but there's a virtual file system layer for java in the apache jakarta project: http://jakarta.apache.org/commons/sandbox/vfs/ They provide read only access to zip and jar files http://jakarta.apache.org/commons/sandbox/vfs/filesystems.html#Zip%20and%20Jar --- URI Format zip://zip-file-uri[!absolute-path] jar://zip-file-uri[!absolute-path] Where zip-file-uri refers to a file of any supported type, including other zip files. Note that any ! characters in zip-file-uri must be escaped using %21. --- Of course one could restrict this to using local files for the zip-file-uri, but it might be worth considering this syntax. Regarding OpenOffice, I'm not sure, if they are using URL syntax at all. Within the *.sxw there's just a META-INF/manifest.xml file listing the files in the archive just using local names (i.e. ) and (from a user point of view) OpenOffice itself just adresses the archive as a whole. But I didn't look at OOs specs or sources. Morus From chregu@php.net Thu Oct 30 03:37:50 2003 Return-Path: Delivered-To: xml@gnome.org Received: from bambi.bitflux.ch (bambi.bitflux.ch [212.71.97.156]) by mail.gnome.org (Postfix) with ESMTP id D2100180F8 for ; Thu, 30 Oct 2003 03:37:49 -0500 (EST) Received: from localhost (reh [127.0.0.1]) by bambi.bitflux.ch (Postfix) with ESMTP id 6A6D07F88B for ; Thu, 30 Oct 2003 09:38:07 +0100 (CET) Received: from bambi.bitflux.ch ([127.0.0.1]) by localhost (bambi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 03100-08 for ; Thu, 30 Oct 2003 09:38:07 +0100 (CET) Received: from php.net (dclient217-162-237-29.hispeed.ch [217.162.237.29]) by bambi.bitflux.ch (Postfix) with ESMTP id 3EB8C7F501 for ; Thu, 30 Oct 2003 09:38:07 +0100 (CET) Message-ID: <3FA0CDEE.7090207@php.net> Date: Thu, 30 Oct 2003 09:38:06 +0100 From: Christian Stocker User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: xml@gnome.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p3 (Debian) at bitflux.ch X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) Subject: [xml] HTML vs html in DOCTYPE Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi I just realized, that libxml2-2.6.0 outputs with the html outpt, while 2.5.6 did: (HTML vs html) What's the reason for changing this? The lowercase isn't invalid per se but http://www.w3.org/QA/2002/04/valid-dtd-list.html and http://www.w3.org/TR/html401/sgml/dtd.html recommend using the Upper-Case version. Personally, I don't mind which version is used, just one of our test failed due to this issue and I'm wondering now, why this was changed or if it's even a bug ;) chregu From veillard@redhat.com Thu Oct 30 04:18:02 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id C4ED818AF3 for ; Thu, 30 Oct 2003 04:18:01 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9U9II905758; Thu, 30 Oct 2003 04:18:18 -0500 Date: Thu, 30 Oct 2003 04:18:18 -0500 From: Daniel Veillard To: Morus Walter Cc: xml@gnome.org Subject: Re: [xml] xmlIO extensions Message-ID: <20031030041818.N25702@redhat.com> Reply-To: veillard@redhat.com References: <20031029213431.GA13391@mathphys.fsk.uni-heidelberg.de> <20031029175710.L25702@redhat.com> <20031030075204.GC27473@mathphys.fsk.uni-heidelberg.de> <20031030033550.M25702@redhat.com> <16288.54198.953085.371046@tanto-xipolis.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <16288.54198.953085.371046@tanto-xipolis.de>; from morus.walter@tanto-xipolis.de on Thu, Oct 30, 2003 at 10:02:46AM +0100 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, Oct 30, 2003 at 10:02:46AM +0100, Morus Walter wrote: > Daniel Veillard writes: > > > > Why not it seems it would work fine too. > > But even better, check how the OpenOffice guys did it and > > reuse it if possible ! > > > It's not OpenOffice but there's a virtual file system layer for java > in the apache jakarta project: > http://jakarta.apache.org/commons/sandbox/vfs/ > > They provide read only access to zip and jar files > http://jakarta.apache.org/commons/sandbox/vfs/filesystems.html#Zip%20and%20Jar > > --- > URI Format > > zip://zip-file-uri[!absolute-path] > > jar://zip-file-uri[!absolute-path] > > Where zip-file-uri refers to a file of any supported type, including other > zip files. Note that any ! characters in zip-file-uri must be escaped using > %21. > --- > > Of course one could restrict this to using local files for the zip-file-uri, > but it might be worth considering this syntax. Okay, looking at the example, yes this should work. zip:http://somehost/downloads/somefile.zip!/file.xml is interesting, however forcing the paths within the archive to be absolute sounds a bit strange, what happens if the / after ! is missing. Writing back when not using a pure file access is not realistic but could be expressed, that's rather good. > > Regarding OpenOffice, I'm not sure, if they are using URL syntax at all. > Within the *.sxw there's just a META-INF/manifest.xml file listing the > files in the archive just using local names (i.e. > manifest:full-path="content.xml"/>) > and (from a user point of view) OpenOffice itself just adresses the archive > as a whole. > But I didn't look at OOs specs or sources. yeah, that should be asked there. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard@redhat.com Thu Oct 30 04:21:40 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 1B6A7182D0 for ; Thu, 30 Oct 2003 04:21:40 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9U9LwF06918; Thu, 30 Oct 2003 04:21:58 -0500 Date: Thu, 30 Oct 2003 04:21:58 -0500 From: Daniel Veillard To: Christian Stocker Cc: xml@gnome.org Subject: Re: [xml] HTML vs html in DOCTYPE Message-ID: <20031030042158.O25702@redhat.com> Reply-To: veillard@redhat.com References: <3FA0CDEE.7090207@php.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3FA0CDEE.7090207@php.net>; from chregu@php.net on Thu, Oct 30, 2003 at 09:38:06AM +0100 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, Oct 30, 2003 at 09:38:06AM +0100, Christian Stocker wrote: > Hi > > I just realized, that libxml2-2.6.0 outputs > > "http://www.w3.org/TR/REC-html40/loose.dtd"> > > with the html outpt, while 2.5.6 did: > > "http://www.w3.org/TR/REC-html40/loose.dtd"> > > (HTML vs html) > > What's the reason for changing this? The lowercase isn't invalid per se > but http://www.w3.org/QA/2002/04/valid-dtd-list.html and > http://www.w3.org/TR/html401/sgml/dtd.html recommend using the > Upper-Case version. > > Personally, I don't mind which version is used, just one of our test > failed due to this issue and I'm wondering now, why this was changed or > if it's even a bug ;) it was changed on-purpose. XHTML syntax is lowercase, basically this lowers the barrier when switching from SGML HTML to XHTML, and you have more chances of generating valid HTML in modern frameworks by using the lowercase version than when using the uppercase version. The world is slowly moving toward XHTML and this just reflects that tendancy :-) Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From chregu@php.net Thu Oct 30 05:01:54 2003 Return-Path: Delivered-To: xml@gnome.org Received: from bambi.bitflux.ch (bambi.bitflux.ch [212.71.97.156]) by mail.gnome.org (Postfix) with ESMTP id D878818384 for ; Thu, 30 Oct 2003 05:01:53 -0500 (EST) Received: from localhost (reh [127.0.0.1]) by bambi.bitflux.ch (Postfix) with ESMTP id 86B9E7F89B; Thu, 30 Oct 2003 11:02:11 +0100 (CET) Received: from bambi.bitflux.ch ([127.0.0.1]) by localhost (bambi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 13004-02; Thu, 30 Oct 2003 11:02:11 +0100 (CET) Received: from php.net (bx-109.bitflux.ch [212.71.98.109]) by bambi.bitflux.ch (Postfix) with ESMTP id 571987F898; Thu, 30 Oct 2003 11:02:11 +0100 (CET) Message-ID: <3FA0E1A3.2010706@php.net> Date: Thu, 30 Oct 2003 11:02:11 +0100 From: Christian Stocker User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: veillard@redhat.com Cc: xml@gnome.org Subject: Re: [xml] HTML vs html in DOCTYPE References: <3FA0CDEE.7090207@php.net> <20031030042158.O25702@redhat.com> In-Reply-To: <20031030042158.O25702@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p3 (Debian) at bitflux.ch X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi thanks for the answer, I will adjust our tests accordingly chregu On 10/30/03 10:21 AM, Daniel Veillard wrote: > On Thu, Oct 30, 2003 at 09:38:06AM +0100, Christian Stocker wrote: > >>Hi >> >>I just realized, that libxml2-2.6.0 outputs >> >>>"http://www.w3.org/TR/REC-html40/loose.dtd"> >> >>with the html outpt, while 2.5.6 did: >> >>>"http://www.w3.org/TR/REC-html40/loose.dtd"> >> >>(HTML vs html) >> >>What's the reason for changing this? The lowercase isn't invalid per se >>but http://www.w3.org/QA/2002/04/valid-dtd-list.html and >>http://www.w3.org/TR/html401/sgml/dtd.html recommend using the >>Upper-Case version. >> >>Personally, I don't mind which version is used, just one of our test >>failed due to this issue and I'm wondering now, why this was changed or >>if it's even a bug ;) > > > it was changed on-purpose. XHTML syntax is lowercase, basically this lowers > the barrier when switching from SGML HTML to XHTML, and you have more chances > of generating valid HTML in modern frameworks by using the lowercase version > than when using the uppercase version. The world is slowly moving toward > XHTML and this just reflects that tendancy :-) > > Daniel > From rsalz@datapower.com Thu Oct 30 07:07:04 2003 Return-Path: Delivered-To: xml@gnome.org Received: from smtp.datapower.com (ip67-93-141-188.z141-93-67.customer.algx.net [67.93.141.188]) by mail.gnome.org (Postfix) with ESMTP id 115511814D for ; Thu, 30 Oct 2003 07:07:04 -0500 (EST) Received: (qmail 1647 invoked by uid 529); 30 Oct 2003 12:07:22 -0000 Date: Thu, 30 Oct 2003 07:07:22 -0500 (EST) From: Rich Salz To: Daniel Veillard Cc: Christian Engwer , "xml@gnome.org" Subject: Re: [xml] xmlIO extensions In-Reply-To: <20031030033550.M25702@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: how about something like "http.zip:" and "file.zip" as the url type? /r$ From christi@fsmath.zbt.uni-heidelberg.de Thu Oct 30 07:54:02 2003 Return-Path: Delivered-To: xml@gnome.org Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by mail.gnome.org (Postfix) with ESMTP id 09DFC1887B for ; Thu, 30 Oct 2003 07:54:02 -0500 (EST) Received: from ix.urz.uni-heidelberg.de (mail.urz.uni-heidelberg.de [129.206.119.234]) by relay.uni-heidelberg.de (8.12.10/8.12.10) with ESMTP id h9UCsIaj024329 for ; Thu, 30 Oct 2003 13:54:18 +0100 (MET) Received: from fsmath.zbt.uni-heidelberg.de (mail@fsmath.zbt.uni-heidelberg.de [129.206.91.26]) by ix.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id NAA27388 for ; Thu, 30 Oct 2003 13:54:18 +0100 Received: from christi by fsmath.zbt.uni-heidelberg.de with local (Exim 3.35 #1 (Debian)) id 1AFCJe-0000jP-00 for ; Thu, 30 Oct 2003 13:54:18 +0100 Date: Thu, 30 Oct 2003 13:54:18 +0100 From: Christian Engwer To: "xml@gnome.org" Subject: Re: [xml] xmlIO extensions Message-ID: <20031030125418.GD427@mathphys.fsk.uni-heidelberg.de> References: <20031030033550.M25702@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, Oct 30, 2003 at 07:07:22AM -0500, Rich Salz wrote: > how about something like "http.zip:" and "file.zip" as the url > type? > /r$ Perhaps I should have explained, that my code currently only reads and writes local files. I am currently waiting for the openoffice download to finish, in order to have a look at their zip code. CU Christian From veillard@redhat.com Thu Oct 30 07:59:36 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id DCE0F18104 for ; Thu, 30 Oct 2003 07:59:35 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9UCxDe05964; Thu, 30 Oct 2003 07:59:13 -0500 Date: Thu, 30 Oct 2003 07:59:13 -0500 From: Daniel Veillard To: Rich Salz Cc: Christian Engwer , "xml@gnome.org" Subject: Re: [xml] xmlIO extensions Message-ID: <20031030075913.Q25702@redhat.com> Reply-To: veillard@redhat.com References: <20031030033550.M25702@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from rsalz@datapower.com on Thu, Oct 30, 2003 at 07:07:22AM -0500 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, Oct 30, 2003 at 07:07:22AM -0500, Rich Salz wrote: > how about something like "http.zip:" and "file.zip" as the url > type? You mean the protocol part ? Well the Java existing URI naming sounds just fine to me. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From christi@fsmath.zbt.uni-heidelberg.de Thu Oct 30 08:55:53 2003 Return-Path: Delivered-To: xml@gnome.org Received: from relay2.uni-heidelberg.de (relay2.uni-heidelberg.de [129.206.210.211]) by mail.gnome.org (Postfix) with ESMTP id 6873E188A2 for ; Thu, 30 Oct 2003 08:55:53 -0500 (EST) Received: from ix.urz.uni-heidelberg.de (mail.urz.uni-heidelberg.de [129.206.119.234]) by relay2.uni-heidelberg.de (8.12.10/8.12.10) with ESMTP id h9UDuAED010945 for ; Thu, 30 Oct 2003 14:56:10 +0100 (MET) Received: from fsmath.zbt.uni-heidelberg.de (mail@fsmath.zbt.uni-heidelberg.de [129.206.91.26]) by ix.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id OAA19930 for ; Thu, 30 Oct 2003 14:56:09 +0100 Received: from christi by fsmath.zbt.uni-heidelberg.de with local (Exim 3.35 #1 (Debian)) id 1AFDHV-000161-00 for ; Thu, 30 Oct 2003 14:56:09 +0100 Date: Thu, 30 Oct 2003 14:56:09 +0100 From: Christian Engwer To: xml@gnome.org Subject: Re: [xml] xmlIO extensions Message-ID: <20031030135609.GA3650@mathphys.fsk.uni-heidelberg.de> References: <20031029213431.GA13391@mathphys.fsk.uni-heidelberg.de> <20031029175710.L25702@redhat.com> <20031030075204.GC27473@mathphys.fsk.uni-heidelberg.de> <20031030033550.M25702@redhat.com> <16288.54198.953085.371046@tanto-xipolis.de> <20031030041818.N25702@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031030041818.N25702@redhat.com> User-Agent: Mutt/1.3.28i Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi, I had a quick glance at the OOo code. It realy seems like they don't use any uri scheme pointing at files inside an archive. The zip interface uses 2 filename (zip-srchive and the file inside). > Okay, looking at the example, yes this should work. > zip:http://somehost/downloads/somefile.zip!/file.xml > is interesting, however forcing the paths within the archive to be > absolute sounds a bit strange, what happens if the / after ! is missing. > Writing back when not using a pure file access is not realistic but could > be expressed, that's rather good. For me the jakarta naming scheme would be ok. I could easily integrate it for local files like zip:../dir/somefile.zip!/file.xml and file uris like zip:file:///home/user/dir/somefile.zip!/file.xml For non local files it woould be much more work and for now I don't see to much use in it. I think the absolute path for the structure inside the archive is nessesary, because the uri-translation will fail otherwise. Imagine this: You have an archive with two files: archive.zip | +-> content.xml +-> content.dtd If you open zip:/dir/archive.zip!/content.xml and content.xml referes to an external entity "content.dtd" libxml will realise that this is a relative request and will build a new path as followed: oldpath: zip:/dir/archive.zip!/content.xml ->basepath: zip:/dir/archive.zip!/ ->newpath: zip:/dir/archive.zip!/content.dtd If you would open the xml file as zip:/dir/archive.zip!content.xml it would look like this: oldpath: zip:/dir/archive.zip!content.xml ->basepath: zip:/dir/ ->newpath: zip:/dir/content.dtd You get a wrong directory for the new path. I would suggest, that I change my naming convention to that from jakarta, but I will not support the http stuff, because I wuould have to change the unzip zip stuff and want to finish my project first. bye Christian From bruce.miller@nist.gov Thu Oct 30 09:15:21 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mta1.adelphia.net (mta1.adelphia.net [68.168.78.175]) by mail.gnome.org (Postfix) with ESMTP id 5534818D06 for ; Thu, 30 Oct 2003 09:15:21 -0500 (EST) Received: from nist.gov ([67.21.63.3]) by mta1.adelphia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20031030141751.HPBX16569.mta1.adelphia.net@nist.gov> for ; Thu, 30 Oct 2003 09:17:51 -0500 Message-ID: <3FA11D0A.9070900@nist.gov> Date: Thu, 30 Oct 2003 09:15:38 -0500 From: Bruce Miller Organization: NIST User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: xml@gnome.org Subject: Re: [xml] xmlIO extensions References: <20031029213431.GA13391@mathphys.fsk.uni-heidelberg.de> <20031029175710.L25702@redhat.com> <20031030075204.GC27473@mathphys.fsk.uni-heidelberg.de> <20031030033550.M25702@redhat.com> <16288.54198.953085.371046@tanto-xipolis.de> <20031030041818.N25702@redhat.com> <20031030135609.GA3650@mathphys.fsk.uni-heidelberg.de> In-Reply-To: <20031030135609.GA3650@mathphys.fsk.uni-heidelberg.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Christian Engwer wrote: > If you open > zip:/dir/archive.zip!/content.xml > and content.xml referes to an external entity "content.dtd" > libxml will realise that this is a relative request and will build a > new path as followed: > oldpath: zip:/dir/archive.zip!/content.xml > ->basepath: zip:/dir/archive.zip!/ > ->newpath: zip:/dir/archive.zip!/content.dtd I've been watching from the sidelines, and may be missing something significant, but why do you need the marker (!) at all? _If_ you're willing to make the module act a bit like a `zip server' (analogous to http server), and have it traverse the directory components from the top: when it encounters a zip file instead of a directory, then it knows (analogous to finding a cgi somewhere within the url). OTOH, this would _not_ extend well to the case of getting the zip from http, ftp, whatever! So forget this suggestion if you're going that direction!! :> -- bruce.miller@nist.gov http://math.nist.gov/~BMiller/ From veillard@redhat.com Thu Oct 30 09:22:05 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id B82E118259 for ; Thu, 30 Oct 2003 09:22:03 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9UEMCS04700; Thu, 30 Oct 2003 09:22:12 -0500 Date: Thu, 30 Oct 2003 09:22:12 -0500 From: Daniel Veillard To: Christian Engwer Cc: xml@gnome.org Subject: Re: [xml] xmlIO extensions Message-ID: <20031030092212.R25702@redhat.com> Reply-To: veillard@redhat.com References: <20031029213431.GA13391@mathphys.fsk.uni-heidelberg.de> <20031029175710.L25702@redhat.com> <20031030075204.GC27473@mathphys.fsk.uni-heidelberg.de> <20031030033550.M25702@redhat.com> <16288.54198.953085.371046@tanto-xipolis.de> <20031030041818.N25702@redhat.com> <20031030135609.GA3650@mathphys.fsk.uni-heidelberg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031030135609.GA3650@mathphys.fsk.uni-heidelberg.de>; from christi@uni-hd.de on Thu, Oct 30, 2003 at 02:56:09PM +0100 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, Oct 30, 2003 at 02:56:09PM +0100, Christian Engwer wrote: > For me the jakarta naming scheme would be ok. I could easily integrate > it for local files like > zip:../dir/somefile.zip!/file.xml > and file uris like > zip:file:///home/user/dir/somefile.zip!/file.xml okay, > For non local files it woould be much more work and for now I don't > see to much use in it. okay, > I think the absolute path for the structure inside the archive is > nessesary, because the uri-translation will fail otherwise. hum, right, oversight from my part ! > I would suggest, that I change my naming convention to that from > jakarta, but I will not support the http stuff, because I wuould have > to change the unzip zip stuff and want to finish my project first. Sure, no problem. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard@redhat.com Thu Oct 30 09:32:18 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 214E518111 for ; Thu, 30 Oct 2003 09:32:18 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9UEWZh09418; Thu, 30 Oct 2003 09:32:35 -0500 Date: Thu, 30 Oct 2003 09:32:35 -0500 From: Daniel Veillard To: Bruce Miller Cc: xml@gnome.org Subject: Re: [xml] xmlIO extensions Message-ID: <20031030093235.S25702@redhat.com> Reply-To: veillard@redhat.com References: <20031029213431.GA13391@mathphys.fsk.uni-heidelberg.de> <20031029175710.L25702@redhat.com> <20031030075204.GC27473@mathphys.fsk.uni-heidelberg.de> <20031030033550.M25702@redhat.com> <16288.54198.953085.371046@tanto-xipolis.de> <20031030041818.N25702@redhat.com> <20031030135609.GA3650@mathphys.fsk.uni-heidelberg.de> <3FA11D0A.9070900@nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3FA11D0A.9070900@nist.gov>; from bruce.miller@nist.gov on Thu, Oct 30, 2003 at 09:15:38AM -0500 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, Oct 30, 2003 at 09:15:38AM -0500, Bruce Miller wrote: > Christian Engwer wrote: > > If you open > > zip:/dir/archive.zip!/content.xml > > and content.xml referes to an external entity "content.dtd" > > libxml will realise that this is a relative request and will build a > > new path as followed: > > oldpath: zip:/dir/archive.zip!/content.xml > > ->basepath: zip:/dir/archive.zip!/ > > ->newpath: zip:/dir/archive.zip!/content.dtd > > I've been watching from the sidelines, and may be missing something > significant, but why do you need the marker (!) at all? to disambiguate zip:///dir/archive!/subdir/content.xml from zip:///dir/archive/subdir!/content.xml and not rely on a .zip suffix either (open office files do not have a .zip suffix !), you could avoid taht by walking he full set of possible paths to check if they are zip can be a bit expensive. > _If_ you're willing to make the module act a bit like a `zip server' > (analogous to http server), and have it traverse the directory components > from the top: when it encounters a zip file instead of a directory, > then it knows (analogous to finding a cgi somewhere within the url). Hum, the problem is that the ! marker allows to know precisely what resource to look for and then pass it to the zip layer. You're right to some extend, but I think having the exclamation mark makes things simpler, and more general. > OTOH, this would _not_ extend well to the case of getting the zip from > http, ftp, whatever! So forget this suggestion if you're going that > direction!! :> yes keeping that feature is nice, and wouldn't be too hard from a libxml2 standpoint since there is already the code needed for http and ftp. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From albie@alfarrabio.di.uminho.pt Thu Oct 30 09:52:02 2003 Return-Path: Delivered-To: xml@gnome.org Received: from alfarrabio.di.uminho.pt (alfarrabio.di.uminho.pt [193.136.20.210]) by mail.gnome.org (Postfix) with SMTP id 4C72B18243 for ; Thu, 30 Oct 2003 09:52:00 -0500 (EST) Received: (qmail 19662 invoked by uid 0); 30 Oct 2003 15:52:15 -0000 Received: from unknown (HELO eremita.di.uminho.pt) (193.136.20.208) by 0 with SMTP; 30 Oct 2003 15:52:15 -0000 From: Alberto Manuel =?ISO-8859-1?Q?Brand=E3o_Sim=F5es?= Reply-To: albie@alfarrabio.di.uminho.pt To: xml@gnome.org Content-Type: text/plain Organization: Departamento de Informática - Universidade do Minho Message-Id: <1067525981.8921.152.camel@eremita.di.uminho.pt> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 30 Oct 2003 14:59:42 +0000 Content-Transfer-Encoding: 7bit Subject: [xml] xmllint and HTML Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi! Although I may seem complaining, do not see it like that. Maybe it is my bad English :) 1. I was used to use xmllint --html to process HTML or generic HTML files with some special (mine) tags. Now, xmllint complains (ok, I can ignore the complains :D but it would be nice to have a generic pseudo-html processor) 2. The second problem is that an empty tag (again with xmllint --html) gives complains: for example _.xml:2: error: Unexpected end tag : hr
^ Thank for all ideas :D best regards, Alberto From jsp@PKC.com Thu Oct 30 10:33:53 2003 Return-Path: Delivered-To: xml@gnome.org Received: from pkc.com (unknown [216.75.143.162]) by mail.gnome.org (Postfix) with ESMTP id 31A70181DE for ; Thu, 30 Oct 2003 10:33:52 -0500 (EST) Message-ID: <9ac7e692d321c766a2b88a2b20d3e1753fa12f03@pkc.com> From: Jesse Pelton To: "'albie@alfarrabio.di.uminho.pt'" , xml@gnome.org Subject: RE: [xml] xmllint and HTML Date: Thu, 30 Oct 2003 10:34:06 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On the second point, at least, xmllint is correct. According to http://www.w3.org/TR/1998/REC-html40-19980424/present/graphics.html#edef= -HR, an end tag for
is forbidden in HTML. (It's a different story in = XHTML, of course, but XHTML should be treated as XML, not HTML.) > -----Original Message----- > From: Alberto Manuel Brand=E3o Sim=F5es=20 > [mailto:albie@alfarrabio.di.uminho.pt]=20 > Sent: Thursday, October 30, 2003 10:00 AM > To: xml@gnome.org > Subject: [xml] xmllint and HTML >=20 >=20 > Hi! >=20 > Although I may seem complaining, do not see it like that.=20 > Maybe it is my > bad English :) >=20 > 1. I was used to use xmllint --html to process HTML or generic HTML > files with some special (mine) tags. Now, xmllint complains (ok, I = can > ignore the complains :D but it would be nice to have a generic > pseudo-html processor) >=20 > 2. The second problem is that an empty tag (again with xmllint = --html) > gives complains: for example > _.xml:2: error: Unexpected end tag : hr >
> ^ > Thank for all ideas :D > best regards, > Alberto >=20 >=20 >=20 > _______________________________________________ > xml mailing list, project page http://xmlsoft.org/ > xml@gnome.org > http://mail.gnome.org/mailman/listinfo/xml >=20 From veillard@redhat.com Thu Oct 30 10:36:10 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 747D1181DE for ; Thu, 30 Oct 2003 10:36:10 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9UFaRp09383; Thu, 30 Oct 2003 10:36:27 -0500 Date: Thu, 30 Oct 2003 10:36:27 -0500 From: Daniel Veillard To: =?iso-8859-1?Q?Alberto_Manuel_Brand=E3o_Sim=F5es?= Cc: xml@gnome.org Subject: Re: [xml] xmllint and HTML Message-ID: <20031030103627.T25702@redhat.com> Reply-To: veillard@redhat.com References: <1067525981.8921.152.camel@eremita.di.uminho.pt> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <1067525981.8921.152.camel@eremita.di.uminho.pt>; from albie@alfarrabio.di.uminho.pt on Thu, Oct 30, 2003 at 02:59:42PM +0000 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, Oct 30, 2003 at 02:59:42PM +0000, Alberto Manuel Brandão Simões wrote: > Hi! > > Although I may seem complaining, do not see it like that. Maybe it is my > bad English :) > > 1. I was used to use xmllint --html to process HTML or generic HTML > files with some special (mine) tags. Now, xmllint complains (ok, I can > ignore the complains :D but it would be nice to have a generic > pseudo-html processor) That's a BAD idea !!! Suppose the libxml2 HTML parser sees

Does closes

? is itself expected to be closed ? If you want to extend the base syntax *use XML* ! It was designed precisely to overcome the limitation that an SGML HTML parser has. So "switch to XHTML" is the only acceptable answer at this point, any other design decision is just broken, sorry ! > 2. The second problem is that an empty tag (again with xmllint --html) > gives complains: for example > _.xml:2: error: Unexpected end tag : hr >

> ^ Hum, that's a valid point, please bugzilla it, so it will get fixed. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From albie@alfarrabio.di.uminho.pt Thu Oct 30 10:40:54 2003 Return-Path: Delivered-To: xml@gnome.org Received: from alfarrabio.di.uminho.pt (alfarrabio.di.uminho.pt [193.136.20.210]) by mail.gnome.org (Postfix) with SMTP id D2447188D0 for ; Thu, 30 Oct 2003 10:40:53 -0500 (EST) Received: (qmail 20048 invoked by uid 0); 30 Oct 2003 16:41:03 -0000 Received: from unknown (HELO eremita.di.uminho.pt) (193.136.20.208) by 0 with SMTP; 30 Oct 2003 16:41:03 -0000 Subject: RE: [xml] xmllint and HTML From: Alberto Manuel =?ISO-8859-1?Q?Brand=E3o_Sim=F5es?= Reply-To: albie@alfarrabio.di.uminho.pt To: Jesse Pelton , veillard@redhat.com Cc: xml@gnome.org In-Reply-To: <9ac7e692d321c766a2b88a2b20d3e1753fa12f03@pkc.com> References: <9ac7e692d321c766a2b88a2b20d3e1753fa12f03@pkc.com> Content-Type: text/plain; charset=ISO-8859-15 Organization: Departamento de Informática - Universidade do Minho Message-Id: <1067528866.8924.155.camel@eremita.di.uminho.pt> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 30 Oct 2003 15:47:47 +0000 Content-Transfer-Encoding: 8bit Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, 2003-10-30 at 15:34, Jesse Pelton wrote: > On the second point, at least, xmllint is correct. According to > http://www.w3.org/TR/1998/REC-html40-19980424/present/graphics.html#edef-HR, > an end tag for
is forbidden in HTML. (It's a different story in XHTML, > of course, but XHTML should be treated as XML, not HTML.) OK, then should I bugzilla it, or not? By the way, it would be nice if --html do not complain if you send him a xml file (looking to the header we could change to XML parser without the user need to look at the file to see if it is xhtml). Bests Alberto > > > -----Original Message----- > > From: Alberto Manuel Brandão Simões > > [mailto:albie@alfarrabio.di.uminho.pt] > > Sent: Thursday, October 30, 2003 10:00 AM > > To: xml@gnome.org > > Subject: [xml] xmllint and HTML > > > > > > Hi! > > > > Although I may seem complaining, do not see it like that. > > Maybe it is my > > bad English :) > > > > 1. I was used to use xmllint --html to process HTML or generic HTML > > files with some special (mine) tags. Now, xmllint complains (ok, I can > > ignore the complains :D but it would be nice to have a generic > > pseudo-html processor) > > > > 2. The second problem is that an empty tag (again with xmllint --html) > > gives complains: for example > > _.xml:2: error: Unexpected end tag : hr > >
> > ^ > > Thank for all ideas :D > > best regards, > > Alberto > > > > > > > > _______________________________________________ > > xml mailing list, project page http://xmlsoft.org/ > > xml@gnome.org > > http://mail.gnome.org/mailman/listinfo/xml > > > _______________________________________________ > xml mailing list, project page http://xmlsoft.org/ > xml@gnome.org > http://mail.gnome.org/mailman/listinfo/xml From veillard@redhat.com Thu Oct 30 10:51:04 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 4432D1830A for ; Thu, 30 Oct 2003 10:51:04 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9UFpJD16439; Thu, 30 Oct 2003 10:51:19 -0500 Date: Thu, 30 Oct 2003 10:51:19 -0500 From: Daniel Veillard To: =?iso-8859-1?Q?Alberto_Manuel_Brand=E3o_Sim=F5es?= Cc: Jesse Pelton , xml@gnome.org Subject: Re: [xml] xmllint and HTML Message-ID: <20031030105119.V25702@redhat.com> Reply-To: veillard@redhat.com References: <9ac7e692d321c766a2b88a2b20d3e1753fa12f03@pkc.com> <1067528866.8924.155.camel@eremita.di.uminho.pt> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <1067528866.8924.155.camel@eremita.di.uminho.pt>; from albie@alfarrabio.di.uminho.pt on Thu, Oct 30, 2003 at 03:47:47PM +0000 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, Oct 30, 2003 at 03:47:47PM +0000, Alberto Manuel Brandão Simões wrote: > On Thu, 2003-10-30 at 15:34, Jesse Pelton wrote: > > On the second point, at least, xmllint is correct. According to > > http://www.w3.org/TR/1998/REC-html40-19980424/present/graphics.html#edef-HR, > > an end tag for
is forbidden in HTML. (It's a different story in XHTML, > > of course, but XHTML should be treated as XML, not HTML.) > > OK, then should I bugzilla it, or not? Hum, then no. Clearly it's not a bug: Start tag: required, End tag: forbidden > By the way, it would be nice if --html do not complain if you send him a > xml file (looking to the header we could change to XML parser without > the user need to look at the file to see if it is xhtml). Hum, if people use xmllint to check SGML HTML, then they are checking for the vocabulary used too, and switching transparently to an XML parser which would just check well formedness doesn't sound right. If a simple XML file ends up in the middle of your set of HTML files, then with the behaviour you suggest xmllint would not raise any error about it. No that doesn't sound a good idea to me. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From albie@alfarrabio.di.uminho.pt Thu Oct 30 11:00:12 2003 Return-Path: Delivered-To: xml@gnome.org Received: from alfarrabio.di.uminho.pt (alfarrabio.di.uminho.pt [193.136.20.210]) by mail.gnome.org (Postfix) with SMTP id 2BB4518172 for ; Thu, 30 Oct 2003 11:00:11 -0500 (EST) Received: (qmail 20250 invoked by uid 0); 30 Oct 2003 17:00:22 -0000 Received: from unknown (HELO eremita.di.uminho.pt) (193.136.20.208) by 0 with SMTP; 30 Oct 2003 17:00:22 -0000 Subject: Re: [xml] xmllint and HTML From: Alberto Manuel =?ISO-8859-1?Q?Brand=E3o_Sim=F5es?= Reply-To: albie@alfarrabio.di.uminho.pt To: veillard@redhat.com Cc: Jesse Pelton , xml@gnome.org In-Reply-To: <20031030105119.V25702@redhat.com> References: <9ac7e692d321c766a2b88a2b20d3e1753fa12f03@pkc.com> <1067528866.8924.155.camel@eremita.di.uminho.pt> <20031030105119.V25702@redhat.com> Content-Type: text/plain Organization: Departamento de Informática - Universidade do Minho Message-Id: <1067530026.8925.159.camel@eremita.di.uminho.pt> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 30 Oct 2003 16:07:07 +0000 Content-Transfer-Encoding: 7bit Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: > > By the way, it would be nice if --html do not complain if you send him a > > xml file (looking to the header we could change to XML parser without > > the user need to look at the file to see if it is xhtml). > > Hum, if people use xmllint to check SGML HTML, then they are > checking for the vocabulary used too, and switching transparently > to an XML parser which would just check well formedness doesn't > sound right. If a simple XML file > > > > ends up in the middle of your set of HTML files, then with the > behaviour you suggest xmllint would not raise any error about it. > No that doesn't sound a good idea to me. OK. It is a good point. only one more thing: xhtml is not valid html? I mean, the following behaviour is expected? [albie@natura albie]$ xmllint --html index.html > _.xhtml [albie@natura albie]$ xmllint --html _.xhtml > /dev/null _.xhtml:1: error: htmlParseStartTag: invalid element name ^ _.xhtml:2: error: Misplaced DOCTYPE declaration > Daniel From christi@fsmath.zbt.uni-heidelberg.de Thu Oct 30 11:46:08 2003 Return-Path: Delivered-To: xml@gnome.org Received: from relay2.uni-heidelberg.de (relay2.uni-heidelberg.de [129.206.210.211]) by mail.gnome.org (Postfix) with ESMTP id 0FE93188A0 for ; Thu, 30 Oct 2003 11:46:08 -0500 (EST) Received: from ix.urz.uni-heidelberg.de (mail.urz.uni-heidelberg.de [129.206.119.234]) by relay2.uni-heidelberg.de (8.12.10/8.12.10) with ESMTP id h9UGkOED020275 for ; Thu, 30 Oct 2003 17:46:25 +0100 (MET) Received: from fsmath.zbt.uni-heidelberg.de (mail@fsmath.zbt.uni-heidelberg.de [129.206.91.26]) by ix.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id RAA30858 for ; Thu, 30 Oct 2003 17:46:24 +0100 Received: from christi by fsmath.zbt.uni-heidelberg.de with local (Exim 3.35 #1 (Debian)) id 1AFFwG-0001t6-00 for ; Thu, 30 Oct 2003 17:46:24 +0100 Date: Thu, 30 Oct 2003 17:46:23 +0100 From: Christian Engwer To: xml@gnome.org Subject: Re: [xml] xmlIO extensions Message-ID: <20031030164623.GA6783@mathphys.fsk.uni-heidelberg.de> References: <20031029213431.GA13391@mathphys.fsk.uni-heidelberg.de> <20031029175710.L25702@redhat.com> <20031030075204.GC27473@mathphys.fsk.uni-heidelberg.de> <20031030033550.M25702@redhat.com> <16288.54198.953085.371046@tanto-xipolis.de> <20031030041818.N25702@redhat.com> <20031030135609.GA3650@mathphys.fsk.uni-heidelberg.de> <20031030092212.R25702@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031030092212.R25702@redhat.com> User-Agent: Mutt/1.3.28i Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi, I have adopted the naming scheme from jakarta... URI Format zip://zip-file-uri[!absolute-path] jar://zip-file-uri[!absolute-path] Where zip-file-uri refers to a file of any supported type, including other zip files. Note that any ! characters in zip-file-uri must be escaped using %21. There are two difference: 1) I only support local paths and file uris for zip-file-uri. 2) I search for the last "!/" sequence to split zip-path and internal-file-path, I don't need to escape "!" to %21. I am not shure whether this has any down sides, but ... works for me ... The new version can be found on the homepage http://hal.iwr.uni-heidelberg.de/~christi/xmlzipio/ I want to make again some valgrind tests, but I would be surprised to find new bugs, because these were really small changes... but who knows ;-) Bye Christian From veillard@redhat.com Thu Oct 30 11:47:37 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 002B0188AD for ; Thu, 30 Oct 2003 11:47:36 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9UGlgS12606; Thu, 30 Oct 2003 11:47:42 -0500 Date: Thu, 30 Oct 2003 11:47:42 -0500 From: Daniel Veillard To: =?iso-8859-1?Q?Alberto_Manuel_Brand=E3o_Sim=F5es?= Cc: Jesse Pelton , xml@gnome.org Subject: Re: [xml] xmllint and HTML Message-ID: <20031030114742.X25702@redhat.com> Reply-To: veillard@redhat.com References: <9ac7e692d321c766a2b88a2b20d3e1753fa12f03@pkc.com> <1067528866.8924.155.camel@eremita.di.uminho.pt> <20031030105119.V25702@redhat.com> <1067530026.8925.159.camel@eremita.di.uminho.pt> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <1067530026.8925.159.camel@eremita.di.uminho.pt>; from albie@alfarrabio.di.uminho.pt on Thu, Oct 30, 2003 at 04:07:07PM +0000 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, Oct 30, 2003 at 04:07:07PM +0000, Alberto Manuel Brandão Simões wrote: > OK. It is a good point. > only one more thing: xhtml is not valid html? > I mean, the following behaviour is expected? > > [albie@natura albie]$ xmllint --html index.html > _.xhtml I would expect _.xhtml to be SGML HTML there > [albie@natura albie]$ xmllint --html _.xhtml > /dev/null > _.xhtml:1: error: htmlParseStartTag: invalid element name > Apparently it's not the case, sounds like a bug > ^ > _.xhtml:2: error: Misplaced DOCTYPE declaration > "http://www.w3.org^ Considering your question it doesn't make much sense. xhtml is XML. This is not SGML. XHTML and SGML HTML do not have similar validity rules. "valid" has a very strict meaning in XML. I don't know what meaning you're trying to give to it in your question. And xmllint --html index.html is not supposed to generate XHTML . Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard@redhat.com Thu Oct 30 11:54:27 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id F2BC1180F2 for ; Thu, 30 Oct 2003 11:54:26 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9UGscc16351; Thu, 30 Oct 2003 11:54:38 -0500 Date: Thu, 30 Oct 2003 11:54:38 -0500 From: Daniel Veillard To: Christian Engwer Cc: xml@gnome.org Subject: Re: [xml] xmlIO extensions Message-ID: <20031030115438.Y25702@redhat.com> Reply-To: veillard@redhat.com References: <20031029213431.GA13391@mathphys.fsk.uni-heidelberg.de> <20031029175710.L25702@redhat.com> <20031030075204.GC27473@mathphys.fsk.uni-heidelberg.de> <20031030033550.M25702@redhat.com> <16288.54198.953085.371046@tanto-xipolis.de> <20031030041818.N25702@redhat.com> <20031030135609.GA3650@mathphys.fsk.uni-heidelberg.de> <20031030092212.R25702@redhat.com> <20031030164623.GA6783@mathphys.fsk.uni-heidelberg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031030164623.GA6783@mathphys.fsk.uni-heidelberg.de>; from christi@uni-hd.de on Thu, Oct 30, 2003 at 05:46:23PM +0100 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, Oct 30, 2003 at 05:46:23PM +0100, Christian Engwer wrote: > Hi, > > I have adopted the naming scheme from jakarta... > > > URI Format > zip://zip-file-uri[!absolute-path] > jar://zip-file-uri[!absolute-path] > Where zip-file-uri refers to a file of any supported type, including > other zip files. Note that any ! characters in zip-file-uri must be > escaped using %21. > > > There are two difference: > > 1) I only support local paths and file uris for zip-file-uri. > 2) I search for the last "!/" sequence to split zip-path and > internal-file-path, I don't need to escape "!" to %21. I am not > shure whether this has any down sides, but ... works for me ... > > The new version can be found on the homepage > http://hal.iwr.uni-heidelberg.de/~christi/xmlzipio/ > > I want to make again some valgrind tests, but I would be surprised to > find new bugs, because these were really small changes... but who > knows ;-) Sounds cool, if the code is small it could be integrated. I have one question though: what happen if one use zip://zip-file-uri without !absolute-path. I would expect some kind of autogenerated XML indicating the content of the archive but I don't know what the jakarta code does by default, if they do something like that it might be nice to have the same behaviour. For an OpenOffice file or a Jar I would expect the manifest to be parsed. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From rsalz@datapower.com Thu Oct 30 12:02:52 2003 Return-Path: Delivered-To: xml@gnome.org Received: from smtp.datapower.com (ip67-93-141-188.z141-93-67.customer.algx.net [67.93.141.188]) by mail.gnome.org (Postfix) with ESMTP id 8C6FE18CF1 for ; Thu, 30 Oct 2003 12:02:52 -0500 (EST) Received: (qmail 3773 invoked by uid 505); 30 Oct 2003 17:03:11 -0000 Received: from rsalz@datapower.com by smtp.datapower.com by uid 502 with qmail-scanner-1.14 (clamscan: 0.51. spamassassin: 2.42. Clear:. Processed in 0.329823 secs); 30 Oct 2003 17:03:11 -0000 Received: from ip67-93-141-189.z141-93-67.customer.algx.net (HELO datapower.com) (67.93.141.189) by ip67-93-141-188.z141-93-67.customer.algx.net with SMTP; 30 Oct 2003 17:03:10 -0000 Message-ID: <3FA14504.8070806@datapower.com> Date: Thu, 30 Oct 2003 12:06:12 -0500 From: Rich Salz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Engwer Cc: xml@gnome.org Subject: Re: [xml] xmlIO extensions References: <20031029213431.GA13391@mathphys.fsk.uni-heidelberg.de> <20031029175710.L25702@redhat.com> <20031030075204.GC27473@mathphys.fsk.uni-heidelberg.de> <20031030033550.M25702@redhat.com> <16288.54198.953085.371046@tanto-xipolis.de> <20031030041818.N25702@redhat.com> <20031030135609.GA3650@mathphys.fsk.uni-heidelberg.de> <20031030092212.R25702@redhat.com> <20031030164623.GA6783@mathphys.fsk.uni-heidelberg.de> In-Reply-To: <20031030164623.GA6783@mathphys.fsk.uni-heidelberg.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: > zip://zip-file-uri[!absolute-path] URL monikers (that is, MSFT DCOM) lives. :) Neat hack, tho. I suppose you could use "!!1" to mean "the first file", and so on, if you wanted os-independant naming.... /r$ -- Rich Salz, Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html From christi@fsmath.zbt.uni-heidelberg.de Thu Oct 30 14:33:43 2003 Return-Path: Delivered-To: xml@gnome.org Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by mail.gnome.org (Postfix) with ESMTP id 6035B182AC for ; Thu, 30 Oct 2003 14:33:43 -0500 (EST) Received: from ix.urz.uni-heidelberg.de (mail.urz.uni-heidelberg.de [129.206.119.234]) by relay.uni-heidelberg.de (8.12.10/8.12.10) with ESMTP id h9UJXxaj027119 for ; Thu, 30 Oct 2003 20:34:00 +0100 (MET) Received: from fsmath.zbt.uni-heidelberg.de (mail@fsmath.zbt.uni-heidelberg.de [129.206.91.26]) by ix.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id UAA37244 for ; Thu, 30 Oct 2003 20:34:00 +0100 Received: from christi by fsmath.zbt.uni-heidelberg.de with local (Exim 3.35 #1 (Debian)) id 1AFIYS-00030x-00 for ; Thu, 30 Oct 2003 20:34:00 +0100 Date: Thu, 30 Oct 2003 20:34:00 +0100 From: Christian Engwer To: xml@gnome.org Subject: Re: [xml] xmlIO extensions Message-ID: <20031030193400.GA11125@mathphys.fsk.uni-heidelberg.de> References: <20031029213431.GA13391@mathphys.fsk.uni-heidelberg.de> <20031029175710.L25702@redhat.com> <20031030075204.GC27473@mathphys.fsk.uni-heidelberg.de> <20031030033550.M25702@redhat.com> <16288.54198.953085.371046@tanto-xipolis.de> <20031030041818.N25702@redhat.com> <20031030135609.GA3650@mathphys.fsk.uni-heidelberg.de> <20031030092212.R25702@redhat.com> <20031030164623.GA6783@mathphys.fsk.uni-heidelberg.de> <20031030115438.Y25702@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031030115438.Y25702@redhat.com> User-Agent: Mutt/1.3.28i Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi, > Sounds cool, if the code is small it could be integrated. It's not to big: * zip.h zip.c unzip.h unzip.c from minizip * xmlzipio.h xmlzipio.c with my code What would you prefere? The files themself or patches (And against which version 2.4 and cvs or only cvs?)? > I have one question though: > what happen if one use zip://zip-file-uri without !absolute-path. Right now the xmlZipMatch returns false, because the namesplit for zip-file-uri and absolute-path fails. > I would expect some kind of autogenerated XML indicating the content of the > archive Sounds good, but I think this is something for the next release :-) There are some more things to improve: 1) change zip.c/unzip.c to use xmlIO instead of libc for fileio 2) change the xmlZipWrite to write directly into the file without copying all data to a temporary file. (It's quick enough right now, but I don't use very big files right now) > but I don't know what the jakarta code does by default, if they > do something like that it might be nice to have the same behaviour. I don't know either... has anyone experience with jakarta? > For an OpenOffice file or a Jar I would expect the manifest to be parsed. As far as I know jar files don't contain an xml Manifest. I read on openoffice.org, that they use zip files with an xml manifest, instead of the normal jar manifest. Bye Christian From graham-libxml@simulcra.org Thu Oct 30 17:50:02 2003 Return-Path: Delivered-To: xml@gnome.org Received: from lamity.org (lamity.org [212.13.197.69]) by mail.gnome.org (Postfix) with SMTP id 4D2BB18762 for ; Thu, 30 Oct 2003 17:50:02 -0500 (EST) Received: (qmail 31308 invoked by uid 1001); 30 Oct 2003 22:50:19 -0000 Date: Thu, 30 Oct 2003 22:50:19 +0000 From: Graham Bennett To: xml@gnome.org Message-ID: <20031030225019.GA23829@lamity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Subject: [xml] stopping parsing Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi all, What's the best way of stopping the parser from the SAX interface? My situation is this: I'm doing 'partial' parsing of a document which involves stopping when a certain element is reached and not doing any more processing. My initial solution was to NULL out all of my callbacks in the SAX handler so that the parser runs through to the end without my code receiving any more events. This seems to work, but it would be nice to be able to stop the parser in its tracks rather than letting it finish the document. I looked at xmlStopParser, but I will tend to call this when I hit a start element, and the parser will give me errors back saying that it hit the end of the data before seeing the end element. Thanks in advance, Graham. -- Graham Bennett From veillard@redhat.com Thu Oct 30 18:00:52 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 51AAE1827D for ; Thu, 30 Oct 2003 18:00:52 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9UN19e11520; Thu, 30 Oct 2003 18:01:09 -0500 Date: Thu, 30 Oct 2003 18:01:09 -0500 From: Daniel Veillard To: Graham Bennett Cc: xml@gnome.org Subject: Re: [xml] stopping parsing Message-ID: <20031030180109.B25702@redhat.com> Reply-To: veillard@redhat.com References: <20031030225019.GA23829@lamity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031030225019.GA23829@lamity.org>; from graham-libxml@simulcra.org on Thu, Oct 30, 2003 at 10:50:19PM +0000 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, Oct 30, 2003 at 10:50:19PM +0000, Graham Bennett wrote: > Hi all, > > What's the best way of stopping the parser from the SAX interface? > > My situation is this: I'm doing 'partial' parsing of a document which > involves stopping when a certain element is reached and not doing any > more processing. My initial solution was to NULL out all of my > callbacks in the SAX handler so that the parser runs through to the end > without my code receiving any more events. This seems to work, but it > would be nice to be able to stop the parser in its tracks rather than > letting it finish the document. > > I looked at xmlStopParser, but I will tend to call this when I hit a > start element, and the parser will give me errors back saying that it > hit the end of the data before seeing the end element. Hum, the problem is that the parser drives the data consumption. And unless adding check for the condition set by xmlStopParser() in a lot of places it's hard to make an instantaneous stop. Still bugzilla it, it should be relatively simple to find at least a few crucial spots where this condition could be tested to exit faster. Resetting all the callbacks is a bit extreme that can probably be avoided (especially now that parsing contexts can be reused). Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From malcolm@commsecure.com.au Thu Oct 30 18:08:59 2003 Return-Path: Delivered-To: xml@gnome.org Received: from commsecure.com.au (CommSecureAustPtyLtd.sb1.optus.net.au [203.202.148.106]) by mail.gnome.org (Postfix) with ESMTP id 193461827D for ; Thu, 30 Oct 2003 18:08:58 -0500 (EST) Received: from sunhill.commsecure.com.au (sunhill.commsecure.com.au [172.16.15.1]) by commsecure.com.au (8.11.6/8.11.6) with ESMTP id h9UN9A732752 for ; Fri, 31 Oct 2003 10:09:10 +1100 Received: from ws14.commsecure.com.au (ws14.commsecure.com.au [172.16.15.14]) by sunhill.commsecure.com.au (8.11.6/8.11.6) with ESMTP id h9UN9De07787 for ; Fri, 31 Oct 2003 10:09:13 +1100 Received: from ws14.commsecure.com.au (localhost.localdomain [127.0.0.1]) by ws14.commsecure.com.au (8.12.8/8.12.8) with ESMTP id h9UN9DTv008846 for ; Fri, 31 Oct 2003 10:09:13 +1100 Received: (from malcolm@localhost) by ws14.commsecure.com.au (8.12.8/8.12.8/Submit) id h9UN9DTj008844 for xml@gnome.org; Fri, 31 Oct 2003 10:09:13 +1100 X-Authentication-Warning: ws14.commsecure.com.au: malcolm set sender to malcolm@commsecure.com.au using -f Subject: Re: [xml] stopping parsing From: Malcolm Tredinnick To: xml@gnome.org In-Reply-To: <20031030225019.GA23829@lamity.org> References: <20031030225019.GA23829@lamity.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1067555352.8512.9.camel@ws14.commsecure.com.au> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 31 Oct 2003 10:09:13 +1100 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Fri, 2003-10-31 at 09:50, Graham Bennett wrote: > Hi all, > > What's the best way of stopping the parser from the SAX interface? > > My situation is this: I'm doing 'partial' parsing of a document which > involves stopping when a certain element is reached and not doing any > more processing. My initial solution was to NULL out all of my > callbacks in the SAX handler so that the parser runs through to the end > without my code receiving any more events. This seems to work, but it > would be nice to be able to stop the parser in its tracks rather than > letting it finish the document. > > I looked at xmlStopParser, but I will tend to call this when I hit a > start element, and the parser will give me errors back saying that it > hit the end of the data before seeing the end element. Notwithstanding Daniel's offer to include some extract code in libxml to help with this, my current solution to this problem is to set a variable within my data structure to indicate "I am shutting down". I set this just prior to calling xmlStopParser(). Then my error handler checks this and if it is in "shutting down" mode, does not process/report the error. I guess this may not be appropriate for you, depending on how your data structures are arranged. My general method have something hanging onto the _private element of the ParserCtxt that I can add a "shutting_down" field to, so I can let libxml haul the data pointer around for me. It's is a bit (very?) hacky, but it seems to do the trick. Cheers, Malcolm From nick@webthing.com Thu Oct 30 19:49:36 2003 Return-Path: Delivered-To: xml@gnome.org Received: from jarl.webthing.com (81-174-213-164.pth-as6.dial.plus.net [81.174.213.164]) by mail.gnome.org (Postfix) with ESMTP id 5EA741888D for ; Thu, 30 Oct 2003 19:49:35 -0500 (EST) Received: from fenris.webthing.com (fenris.webthing.com [192.168.10.5]) by jarl.webthing.com (Postfix) with ESMTP id 6721D61BD; Fri, 31 Oct 2003 00:49:48 +0000 (GMT) Received: by fenris.webthing.com (Postfix, from userid 1000) id BB8F5113; Fri, 31 Oct 2003 00:49:47 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by fenris.webthing.com (Postfix) with ESMTP id 31EE9B9; Fri, 31 Oct 2003 00:49:47 +0000 (GMT) Date: Fri, 31 Oct 2003 00:49:46 +0000 (GMT) From: Nick Kew To: Graham Bennett Cc: Subject: Re: [xml] stopping parsing In-Reply-To: <20031030225019.GA23829@lamity.org> Message-ID: <20031031004413.M1012-100000@fenris.webthing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, 30 Oct 2003, Graham Bennett wrote: > What's the best way of stopping the parser from the SAX interface? > > My situation is this: I'm doing 'partial' parsing of a document which > involves stopping when a certain element is reached and not doing any > more processing. I do that with a somewhat-inelegant hack that uses chunked parsing, and simply stops stops feeding chunks to the parser when it's found what I'm looking for. That means only a small amount of extra parsing will happen. > My initial solution was to NULL out all of my > callbacks in the SAX handler so that the parser runs through to the end > without my code receiving any more events. Yep, that's also useful. Though the effect is fairly negligible, unless your callbacks do some heavyweight processing. > I looked at xmlStopParser, but I will tend to call this when I hit a > start element, and the parser will give me errors back saying that it > hit the end of the data before seeing the end element. That's something I hadn't seen. Is it a newish call? Is it available in the htmlParser? -- Nick Kew > From nick@webthing.com Thu Oct 30 20:00:25 2003 Return-Path: Delivered-To: xml@gnome.org Received: from jarl.webthing.com (81-174-213-164.pth-as6.dial.plus.net [81.174.213.164]) by mail.gnome.org (Postfix) with ESMTP id A3694181BA for ; Thu, 30 Oct 2003 20:00:24 -0500 (EST) Received: from fenris.webthing.com (fenris.webthing.com [192.168.10.5]) by jarl.webthing.com (Postfix) with ESMTP id 5937161BD; Fri, 31 Oct 2003 01:00:42 +0000 (GMT) Received: by fenris.webthing.com (Postfix, from userid 1000) id EB3AE113; Fri, 31 Oct 2003 01:00:41 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by fenris.webthing.com (Postfix) with ESMTP id CFA60B9; Fri, 31 Oct 2003 01:00:41 +0000 (GMT) Date: Fri, 31 Oct 2003 01:00:41 +0000 (GMT) From: Nick Kew To: Daniel Veillard Cc: =?iso-8859-1?Q?Alberto_Manuel_Brand=E3o_Sim=F5es?= , Subject: Re: [xml] xmllint and HTML In-Reply-To: <20031030103627.T25702@redhat.com> Message-ID: <20031031005007.J1012-100000@fenris.webthing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Thu, 30 Oct 2003, Daniel Veillard wrote: > On Thu, Oct 30, 2003 at 02:59:42PM +0000, Alberto Manuel Brand=E3o Sim=F5= es wrote: > > Hi! > > > > Although I may seem complaining, do not see it like that. Maybe it is m= y > > bad English :) > > > > 1. I was used to use xmllint --html to process HTML or generic HTML > > files with some special (mine) tags. Now, xmllint complains (ok, I can > > ignore the complains :D but it would be nice to have a generic > > pseudo-html processor) > > That's a BAD idea !!! Suppose the libxml2 HTML parser sees > >

> > > Does closes

? is itself expected to be closed ? That would be defined by DTD. Or it could be built in to the processor, as HTML4 is in libxml's htmlParser. It's entirely possible to use with htmlParser and get meaningful behaviour. The parser will, by default, generate the SAX events as-if it were XML. > If you want to extend the base syntax *use XML* ! It was designed > precisely to overcome the limitation that an SGML HTML parser has. On the contrary, an SGML parser has fewer limitations, due to the far greater flexibility and expressiveness of the language. For serious HTML work - and especially for nonstandard DTDs, the answer is to use a true SGML parser. OpenSP is the obvious recommendation, though if it's just HTML with a few nonstandard elements then a heuristic parser (libxml2/htmlParser or Tidy) may serve. > So "switch to XHTML" is the only acceptable answer at this point, > any other design decision is just broken, sorry ! Only if the design constrains you to use an XML-based processor. Which is fair enough in the context of this list, but not so much in the wider world. > > 2. The second problem is that an empty tag (again with xmllint --html) > > gives complains: for example > > _.xml:2: error: Unexpected end tag : hr > >

Is that in your markup, or is xmllint inserting a spurious ? --=20 Nick Kew From morus@tanto-xipolis.de Fri Oct 31 02:51:13 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mail.tanto-xipolis.de (mail.xipolis.net [213.61.178.42]) by mail.gnome.org (Postfix) with ESMTP id 936A7180E2 for ; Fri, 31 Oct 2003 02:51:12 -0500 (EST) Received: from tucholsky.office.tanto.de (morus.xipolis.net [10.0.1.4]) by mail.tanto-xipolis.de (Postfix on SuSE Linux 7.3 (i386)) with ESMTP id F08E619B719 for ; Fri, 31 Oct 2003 08:51:28 +0100 (CET) Received: from tucholsky.office.tanto.de (morus@tucholsky [127.0.0.1]) by tucholsky.office.tanto.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9V7qZ9t006282 for ; Fri, 31 Oct 2003 08:52:35 +0100 Received: (from morus@localhost) by tucholsky.office.tanto.de (8.12.3/8.12.3/Debian-6.6) id h9V7qYx7006278; Fri, 31 Oct 2003 08:52:34 +0100 From: Morus Walter MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16290.5314.448520.278325@tanto-xipolis.de> Date: Fri, 31 Oct 2003 08:52:34 +0100 To: xml@gnome.org Subject: Re: [xml] xmlIO extensions In-Reply-To: <20031030193400.GA11125@mathphys.fsk.uni-heidelberg.de> References: <20031029213431.GA13391@mathphys.fsk.uni-heidelberg.de> <20031029175710.L25702@redhat.com> <20031030075204.GC27473@mathphys.fsk.uni-heidelberg.de> <20031030033550.M25702@redhat.com> <16288.54198.953085.371046@tanto-xipolis.de> <20031030041818.N25702@redhat.com> <20031030135609.GA3650@mathphys.fsk.uni-heidelberg.de> <20031030092212.R25702@redhat.com> <20031030164623.GA6783@mathphys.fsk.uni-heidelberg.de> <20031030115438.Y25702@redhat.com> <20031030193400.GA11125@mathphys.fsk.uni-heidelberg.de> X-Mailer: VM 7.03 under 21.4 (patch 6) "Common Lisp" XEmacs Lucid Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Christian Engwer writes: > > > but I don't know what the jakarta code does by default, if they > > do something like that it might be nice to have the same behaviour. > I don't know either... has anyone experience with jakarta? > The jakarta classes provide a file access API. They don't have anything to do with xml. I didn't use them beyond some testing yet, but if you create a FileObject with an url pointing to the zip file, I'd expect you get one of type directory. Morus From veillard@redhat.com Fri Oct 31 04:12:00 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id B666218417 for ; Fri, 31 Oct 2003 04:11:57 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9V9CDH26397; Fri, 31 Oct 2003 04:12:13 -0500 Date: Fri, 31 Oct 2003 04:12:13 -0500 From: Daniel Veillard To: Nick Kew Cc: =?iso-8859-1?Q?Alberto_Manuel_Brand=E3o_Sim=F5es?= , xml@gnome.org Subject: Re: [xml] xmllint and HTML Message-ID: <20031031041213.D25702@redhat.com> Reply-To: veillard@redhat.com References: <20031030103627.T25702@redhat.com> <20031031005007.J1012-100000@fenris.webthing.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031031005007.J1012-100000@fenris.webthing.com>; from nick@webthing.com on Fri, Oct 31, 2003 at 01:00:41AM +0000 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Fri, Oct 31, 2003 at 01:00:41AM +0000, Nick Kew wrote: > On Thu, 30 Oct 2003, Daniel Veillard wrote: > > That's a BAD idea !!! Suppose the libxml2 HTML parser sees > > > >

> > > > > > Does closes

? is itself expected to be closed ? > > That would be defined by DTD. SGML DTDs are too complext to be supported by libxml2, so this won't work. > Or it could be built in to the processor, > as HTML4 is in libxml's htmlParser. I don't think augmenting the HTML parser with random vocabularies makes any sense either. XML was defined to do this precisely because it was to hard within the HTML SGML framework. > It's entirely possible to use with htmlParser and get meaningful > behaviour. The parser will, by default, generate the SAX events as-if > it were XML. No sorry, there is still the undertainty of the autoclosure, do you get startElement(p) endElement(p) startElement(foo) or startElement(p) startElement(foo) it is not meaningful to act on SAX strem without processing endElement() > > If you want to extend the base syntax *use XML* ! It was designed > > precisely to overcome the limitation that an SGML HTML parser has. > > On the contrary, an SGML parser has fewer limitations, due to the > far greater flexibility and expressiveness of the language. For and there are 2 parser conformant in the world, the DoD one and James Clark. Use SGML if you want, but it's not a libxml2 topic ! Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From breese@mail1.stofanet.dk Fri Oct 31 04:31:30 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mx04.stofanet.dk (mx04.stofanet.dk [212.10.30.234]) by mail.gnome.org (Postfix) with ESMTP id CF24A185BB for ; Fri, 31 Oct 2003 04:31:29 -0500 (EST) Received: from 3e6b273a.rev.stofanet.dk ([62.107.39.58]) by mx04.stofanet.dk with esmtp (Exim 4.22) id 1AFVdD-0002A0-2C for xml@gnome.org; Fri, 31 Oct 2003 10:31:47 +0100 Subject: Re: [xml] stopping parsing From: Bjorn Reese To: xml@gnome.org In-Reply-To: <20031030180109.B25702@redhat.com> References: <20031030225019.GA23829@lamity.org> <20031030180109.B25702@redhat.com> Content-Type: text/plain Organization: Hyperspace Academy Message-Id: <1067592934.2086.2.camel@stellifer> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 31 Oct 2003 10:35:35 +0100 Content-Transfer-Encoding: 7bit Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Fri, 2003-10-31 at 00:01, Daniel Veillard wrote: > Hum, the problem is that the parser drives the data consumption. > And unless adding check for the condition set by xmlStopParser() in > a lot of places it's hard to make an instantaneous stop. Would longjmp in the SAX callbacks do the trick, or would that leave the parser in an inconsistant state (risking memory leaks and worse)? From veillard@redhat.com Fri Oct 31 04:33:02 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id A1B031820E for ; Fri, 31 Oct 2003 04:33:02 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9V9XGU00925; Fri, 31 Oct 2003 04:33:16 -0500 Date: Fri, 31 Oct 2003 04:33:16 -0500 From: Daniel Veillard To: Malcolm Tredinnick Cc: xml@gnome.org Subject: Re: [xml] stopping parsing Message-ID: <20031031043316.E25702@redhat.com> Reply-To: veillard@redhat.com References: <20031030225019.GA23829@lamity.org> <1067555352.8512.9.camel@ws14.commsecure.com.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="1yeeQ81UyVL57Vl7" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1067555352.8512.9.camel@ws14.commsecure.com.au>; from malcolm@commsecure.com.au on Fri, Oct 31, 2003 at 10:09:13AM +1100 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Oct 31, 2003 at 10:09:13AM +1100, Malcolm Tredinnick wrote: > On Fri, 2003-10-31 at 09:50, Graham Bennett wrote: > > Hi all, > > > > What's the best way of stopping the parser from the SAX interface? > > > > My situation is this: I'm doing 'partial' parsing of a document which > > involves stopping when a certain element is reached and not doing any > > more processing. My initial solution was to NULL out all of my > > callbacks in the SAX handler so that the parser runs through to the end > > without my code receiving any more events. This seems to work, but it > > would be nice to be able to stop the parser in its tracks rather than > > letting it finish the document. > > > > I looked at xmlStopParser, but I will tend to call this when I hit a > > start element, and the parser will give me errors back saying that it > > hit the end of the data before seeing the end element. > > Notwithstanding Daniel's offer to include some extract code in libxml to > help with this, my current solution to this problem is to set a variable > within my data structure to indicate "I am shutting down". I set this the parser context has a ctxt->disableSAX field used to block further callbacks, it's not set set in xmlStopParser and is a trivial way of doing so. To shutdown errors too, the very same variable could simply be checked in the error routines. So there are simple ways to do this without change in the client code. The enclosed patch implements this, I will commit this as soon as I can check there is no negative side-effect. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="stop.patch" Index: parser.c =================================================================== RCS file: /cvs/gnome/gnome-xml/parser.c,v retrieving revision 1.342 diff -u -r1.342 parser.c --- parser.c 30 Oct 2003 22:13:02 -0000 1.342 +++ parser.c 31 Oct 2003 09:22:23 -0000 @@ -141,6 +141,9 @@ xmlErrAttributeDup(xmlParserCtxtPtr ctxt, const xmlChar * prefix, const xmlChar * localname) { + if ((ctxt != NULL) && (ctxt->disableSAX != 0) && + (ctxt->instate == XML_PARSER_EOF)) + return; ctxt->errNo = XML_ERR_ATTRIBUTE_REDEFINED; if (prefix == NULL) __xmlRaiseError(NULL, NULL, NULL, ctxt, NULL, XML_FROM_PARSER, @@ -171,6 +174,9 @@ { const char *errmsg; + if ((ctxt != NULL) && (ctxt->disableSAX != 0) && + (ctxt->instate == XML_PARSER_EOF)) + return; switch (error) { case XML_ERR_INVALID_HEX_CHARREF: errmsg = "CharRef: invalid hexadecimal value\n"; @@ -371,6 +377,9 @@ xmlFatalErrMsg(xmlParserCtxtPtr ctxt, xmlParserErrors error, const char *msg) { + if ((ctxt != NULL) && (ctxt->disableSAX != 0) && + (ctxt->instate == XML_PARSER_EOF)) + return; ctxt->errNo = error; __xmlRaiseError(NULL, NULL, NULL, ctxt, NULL, XML_FROM_PARSER, error, XML_ERR_FATAL, NULL, 0, NULL, NULL, NULL, 0, 0, msg); @@ -395,6 +404,9 @@ { xmlStructuredErrorFunc schannel = NULL; + if ((ctxt != NULL) && (ctxt->disableSAX != 0) && + (ctxt->instate == XML_PARSER_EOF)) + return; ctxt->errNo = error; if ((ctxt->sax != NULL) && (ctxt->sax->initialized == XML_SAX2_MAGIC)) schannel = ctxt->sax->serror; @@ -421,6 +433,10 @@ const char *msg, const xmlChar *str1) { xmlStructuredErrorFunc schannel = NULL; + + if ((ctxt != NULL) && (ctxt->disableSAX != 0) && + (ctxt->instate == XML_PARSER_EOF)) + return; ctxt->errNo = error; if ((ctxt->sax != NULL) && (ctxt->sax->initialized == XML_SAX2_MAGIC)) schannel = ctxt->sax->serror; @@ -446,6 +462,9 @@ xmlFatalErrMsgInt(xmlParserCtxtPtr ctxt, xmlParserErrors error, const char *msg, int val) { + if ((ctxt != NULL) && (ctxt->disableSAX != 0) && + (ctxt->instate == XML_PARSER_EOF)) + return; ctxt->errNo = error; __xmlRaiseError(NULL, NULL, NULL, ctxt, NULL, XML_FROM_PARSER, error, XML_ERR_FATAL, @@ -471,6 +490,9 @@ const char *msg, const xmlChar *str1, int val, const xmlChar *str2) { + if ((ctxt != NULL) && (ctxt->disableSAX != 0) && + (ctxt->instate == XML_PARSER_EOF)) + return; ctxt->errNo = error; __xmlRaiseError(NULL, NULL, NULL, ctxt, NULL, XML_FROM_PARSER, error, XML_ERR_FATAL, @@ -494,6 +516,9 @@ xmlFatalErrMsgStr(xmlParserCtxtPtr ctxt, xmlParserErrors error, const char *msg, const xmlChar * val) { + if ((ctxt != NULL) && (ctxt->disableSAX != 0) && + (ctxt->instate == XML_PARSER_EOF)) + return; ctxt->errNo = error; __xmlRaiseError(NULL, NULL, NULL, ctxt, NULL, XML_FROM_PARSER, error, XML_ERR_FATAL, @@ -517,6 +542,9 @@ xmlErrMsgStr(xmlParserCtxtPtr ctxt, xmlParserErrors error, const char *msg, const xmlChar * val) { + if ((ctxt != NULL) && (ctxt->disableSAX != 0) && + (ctxt->instate == XML_PARSER_EOF)) + return; ctxt->errNo = error; __xmlRaiseError(NULL, NULL, NULL, ctxt, NULL, XML_FROM_PARSER, error, XML_ERR_ERROR, @@ -540,6 +568,9 @@ const xmlChar * info1, const xmlChar * info2, const xmlChar * info3) { + if ((ctxt != NULL) && (ctxt->disableSAX != 0) && + (ctxt->instate == XML_PARSER_EOF)) + return; ctxt->errNo = error; __xmlRaiseError(NULL, NULL, NULL, ctxt, NULL, XML_FROM_NAMESPACE, error, XML_ERR_ERROR, NULL, 0, (const char *) info1, @@ -10126,7 +10157,10 @@ */ void xmlStopParser(xmlParserCtxtPtr ctxt) { + if (ctxt == NULL) + return; ctxt->instate = XML_PARSER_EOF; + ctxt->disableSAX = 1; if (ctxt->input != NULL) ctxt->input->cur = BAD_CAST""; } Index: parserInternals.c =================================================================== RCS file: /cvs/gnome/gnome-xml/parserInternals.c,v retrieving revision 1.100 diff -u -r1.100 parserInternals.c --- parserInternals.c 27 Oct 2003 11:25:13 -0000 1.100 +++ parserInternals.c 31 Oct 2003 09:22:23 -0000 @@ -105,6 +105,9 @@ void xmlErrMemory(xmlParserCtxtPtr ctxt, const char *extra) { + if ((ctxt != NULL) && (ctxt->disableSAX != 0) && + (ctxt->instate == XML_PARSER_EOF)) + return; if (ctxt != NULL) { ctxt->errNo = XML_ERR_NO_MEMORY; ctxt->instate = XML_PARSER_EOF; @@ -135,6 +138,9 @@ __xmlErrEncoding(xmlParserCtxtPtr ctxt, xmlParserErrors error, const char *msg, const xmlChar * str1, const xmlChar * str2) { + if ((ctxt != NULL) && (ctxt->disableSAX != 0) && + (ctxt->instate == XML_PARSER_EOF)) + return; if (ctxt != NULL) ctxt->errNo = error; __xmlRaiseError(NULL, NULL, NULL, @@ -159,6 +165,9 @@ static void xmlErrInternal(xmlParserCtxtPtr ctxt, const char *msg, const xmlChar * str) { + if ((ctxt != NULL) && (ctxt->disableSAX != 0) && + (ctxt->instate == XML_PARSER_EOF)) + return; if (ctxt != NULL) ctxt->errNo = XML_ERR_INTERNAL_ERROR; __xmlRaiseError(NULL, NULL, NULL, @@ -185,6 +194,9 @@ xmlErrEncodingInt(xmlParserCtxtPtr ctxt, xmlParserErrors error, const char *msg, int val) { + if ((ctxt != NULL) && (ctxt->disableSAX != 0) && + (ctxt->instate == XML_PARSER_EOF)) + return; if (ctxt != NULL) ctxt->errNo = error; __xmlRaiseError(NULL, NULL, NULL, Index: xmlIO.c =================================================================== RCS file: /cvs/gnome/gnome-xml/xmlIO.c,v retrieving revision 1.134 diff -u -r1.134 xmlIO.c --- xmlIO.c 29 Oct 2003 22:15:13 -0000 1.134 +++ xmlIO.c 31 Oct 2003 09:22:24 -0000 @@ -409,6 +409,9 @@ void *data = NULL; xmlErrorLevel level = XML_ERR_ERROR; + if ((ctxt != NULL) && (ctxt->disableSAX != 0) && + (ctxt->instate == XML_PARSER_EOF)) + return; if ((ctxt != NULL) && (ctxt->sax != NULL)) { if (ctxt->validate) { channel = ctxt->sax->error; --1yeeQ81UyVL57Vl7-- From veillard@redhat.com Fri Oct 31 04:41:19 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id BE6561820E for ; Fri, 31 Oct 2003 04:41:19 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9V9fZj03468; Fri, 31 Oct 2003 04:41:35 -0500 Date: Fri, 31 Oct 2003 04:41:35 -0500 From: Daniel Veillard To: Bjorn Reese Cc: xml@gnome.org Subject: Re: [xml] stopping parsing Message-ID: <20031031044135.F25702@redhat.com> Reply-To: veillard@redhat.com References: <20031030225019.GA23829@lamity.org> <20031030180109.B25702@redhat.com> <1067592934.2086.2.camel@stellifer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1067592934.2086.2.camel@stellifer>; from breese@mail1.stofanet.dk on Fri, Oct 31, 2003 at 10:35:35AM +0100 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Fri, Oct 31, 2003 at 10:35:35AM +0100, Bjorn Reese wrote: > On Fri, 2003-10-31 at 00:01, Daniel Veillard wrote: > > > Hum, the problem is that the parser drives the data consumption. > > And unless adding check for the condition set by xmlStopParser() in > > a lot of places it's hard to make an instantaneous stop. > > Would longjmp in the SAX callbacks do the trick, or would that > leave the parser in an inconsistant state (risking memory leaks > and worse)? Hard to tell without testing. I love setjmp/longjmp for historical reasons, but I'm not sure I want to rely on them for the parser. In the pre-2.6.x area memory leaks would be nearly garanteed with this approach. Now that we use a dictionnary attached to the parser context it is less obvious, but still I think there are serious risks for example sometimes attribute values need to be duplicated as new strings, if the client code does a longjmp to a state started in xmlParseDocument() from the startElement() callback, then yes I'm afraid this could leak. Similary when element content is passed down and needed to be copied, longjump'ing from the character() callback might leak too. Really, I think staying in the structured processing is really safer. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard@redhat.com Fri Oct 31 04:43:43 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 941F51820E for ; Fri, 31 Oct 2003 04:43:43 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9V9hxq04774; Fri, 31 Oct 2003 04:43:59 -0500 Date: Fri, 31 Oct 2003 04:43:59 -0500 From: Daniel Veillard To: Nick Kew Cc: Graham Bennett , xml@gnome.org Subject: Re: [xml] stopping parsing Message-ID: <20031031044359.G25702@redhat.com> Reply-To: veillard@redhat.com References: <20031030225019.GA23829@lamity.org> <20031031004413.M1012-100000@fenris.webthing.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031031004413.M1012-100000@fenris.webthing.com>; from nick@webthing.com on Fri, Oct 31, 2003 at 12:49:46AM +0000 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Fri, Oct 31, 2003 at 12:49:46AM +0000, Nick Kew wrote: > On Thu, 30 Oct 2003, Graham Bennett wrote: > > I looked at xmlStopParser, but I will tend to call this when I hit a > > start element, and the parser will give me errors back saying that it > > hit the end of the data before seeing the end element. > > That's something I hadn't seen. Is it a newish call? Is it available > in the htmlParser? yes that should work with HTML too, same limitations apply though. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From novak@merlot.ics.muni.cz Fri Oct 31 07:00:43 2003 Return-Path: Delivered-To: xml@gnome.org Received: from merlot.ics.muni.cz (merlot.ics.muni.cz [147.251.18.30]) by mail.gnome.org (Postfix) with ESMTP id 842F0181AD for ; Fri, 31 Oct 2003 07:00:41 -0500 (EST) Received: (from novak@localhost) by merlot.ics.muni.cz (8.11.7p1+Sun/8.11.6) id h9VC0xa27819 for xml@gnome.org; Fri, 31 Oct 2003 13:00:59 +0100 (MET) Date: Fri, 31 Oct 2003 13:00:59 +0100 From: Petr Novak To: xml@gnome.org Message-ID: <20031031120059.GA27791@merlot.ics.muni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.25i Subject: [xml] xmlTextReader and XML schema Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hallo, is any way how to validate document against XML schema by the xmlTextReader? (in tutorial is described only DTD and Relax NG and I found nothing in xmlreader.h) Cheers, -petrn -- Petr Novak, Liberouter Project (www.liberouter.org) E-mail: novak@merlot.ics.muni.cz From veillard@redhat.com Fri Oct 31 07:06:26 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 2A6F5181A8 for ; Fri, 31 Oct 2003 07:06:26 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9VC6hB20235; Fri, 31 Oct 2003 07:06:43 -0500 Date: Fri, 31 Oct 2003 07:06:43 -0500 From: Daniel Veillard To: Petr Novak Cc: xml@gnome.org Subject: Re: [xml] xmlTextReader and XML schema Message-ID: <20031031070643.J25702@redhat.com> Reply-To: veillard@redhat.com References: <20031031120059.GA27791@merlot.ics.muni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031031120059.GA27791@merlot.ics.muni.cz>; from novak@merlot.ics.muni.cz on Fri, Oct 31, 2003 at 01:00:59PM +0100 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Fri, Oct 31, 2003 at 01:00:59PM +0100, Petr Novak wrote: > Hallo, > is any way how to validate document against XML schema by the xmlTextReader? > (in tutorial is described only DTD and Relax NG and I found nothing in > xmlreader.h) Not possible yet. Considering the current state of XML schema in libxml2 there is more urgent work to be done first before hooking XML schema to the new APIs. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From luigi.ballabio@riskmap.it Fri Oct 31 10:48:22 2003 Return-Path: Delivered-To: xml@gnome.org Received: from bgph-226.opennet.it (bgph-226.opennet.it [213.212.129.226]) by mail.gnome.org (Postfix) with ESMTP id AFA0718B9E for ; Fri, 31 Oct 2003 10:48:21 -0500 (EST) Received: from ballabl03.riskmap.it ([213.212.148.34]) by bgph-226.opennet.it (8.11.6/8.11.6) with ESMTP id h9VFlmp11533 for ; Fri, 31 Oct 2003 16:47:53 +0100 Message-Id: <6.0.0.22.0.20031031163318.01b15c80@mail.riskmap.net> X-Sender: X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 31 Oct 2003 16:48:42 +0100 To: xml@gnome.org From: Luigi Ballabio In-Reply-To: <20031031152901.31874.5428.Mailman@moniker.gnome.org> References: <20031031152901.31874.5428.Mailman@moniker.gnome.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [xml] Inspecting a RelaxNG schema Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: Hi all, apologies if I missed any relevant FAQ or documentation entries. I'm using the Python bindings (specifically, the RelaxNG module API) to parse a RelaxNG schema. What I'm doing is: >>> from libxmlmods import libxml2mod >>> ctxt = libxml2mod.xmlRelaxNGNewParserCtxt('foo.rng') >>> schema = libxml2mod.xmlRelaxNGParse(ctxt) which, I guess, is a fairly direct translation of the corresponding C code. By the end of the last instruction, the RelaxNG module has made most of the work I'm interested in at the time. In particular, and if I'm not mistaken, it descended into any documents referenced by nodes in order to build the full schema (well, it wanted the referenced files to be there, so I assumed it did read them.) The problem is, the resulting xmlRelaxNGPtr is returned to Python as a very much opaque PyCObject pointer. My question is, is there any exported function in the module which will allow me to inspect the created schema? Can it be converted to some less opaque structure? Or should I resort to coding in C ? Thanks in advance, Luigi From nanning@guest.lunatech.com Fri Oct 31 10:58:24 2003 Return-Path: Delivered-To: xml@gnome.org Received: from mx1.lunatech.com (fw1.lunatech.com [62.58.71.3]) by mail.gnome.org (Postfix) with ESMTP id CC2BD18B9E for ; Fri, 31 Oct 2003 10:58:23 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mx1.lunatech.com (Lunatech MTA) with ESMTP id 52D212DDF2 for ; Fri, 31 Oct 2003 16:58:39 +0100 (CET) Received: from mx1.lunatech.com ([127.0.0.1]) by localhost (yin [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14147-06 for ; Fri, 31 Oct 2003 16:58:39 +0100 (CET) Received: from guest.lunatech.com (guest.lunatech.com [192.168.8.11]) by mx1.lunatech.com (Lunatech MTA) with ESMTP id 0F8442DDBF for ; Fri, 31 Oct 2003 16:58:39 +0100 (CET) Received: by guest.lunatech.com (Postfix, from userid 1009) id D7CD78345D; Fri, 31 Oct 2003 16:58:38 +0100 (CET) Date: Fri, 31 Oct 2003 16:58:38 +0100 From: Nanning Buitenhuis To: xml@gnome.org Message-ID: <20031031155838.GB6878@guest.lunatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Virus-Scanned: by amavisd-new-20030616-p5 (Debian) at lunatech.com Subject: [xml] How to extend the Reader interface with a dup() function Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: I want to extend the Reader interface with a dup() function. That is, make a new reader with the same state as the current reader, so a trial run over the data is possible. Possible, impossible, or pointers? Regards, NaN. From veillard@redhat.com Fri Oct 31 11:01:37 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id B888C18B9E for ; Fri, 31 Oct 2003 11:01:36 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9VG1nS22409; Fri, 31 Oct 2003 11:01:49 -0500 Date: Fri, 31 Oct 2003 11:01:49 -0500 From: Daniel Veillard To: Luigi Ballabio Cc: xml@gnome.org Subject: Re: [xml] Inspecting a RelaxNG schema Message-ID: <20031031110149.L25702@redhat.com> Reply-To: veillard@redhat.com References: <20031031152901.31874.5428.Mailman@moniker.gnome.org> <6.0.0.22.0.20031031163318.01b15c80@mail.riskmap.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <6.0.0.22.0.20031031163318.01b15c80@mail.riskmap.net>; from luigi.ballabio@riskmap.it on Fri, Oct 31, 2003 at 04:48:42PM +0100 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Fri, Oct 31, 2003 at 04:48:42PM +0100, Luigi Ballabio wrote: > > Hi all, > apologies if I missed any relevant FAQ or documentation entries. I'm using > the Python bindings (specifically, the RelaxNG module API) to parse a > RelaxNG schema. What I'm doing is: > > >>> from libxmlmods import libxml2mod > >>> ctxt = libxml2mod.xmlRelaxNGNewParserCtxt('foo.rng') > >>> schema = libxml2mod.xmlRelaxNGParse(ctxt) > > which, I guess, is a fairly direct translation of the corresponding C code. > > By the end of the last instruction, the RelaxNG module has made most of the > work I'm interested in at the time. In particular, and if I'm not mistaken, > it descended into any documents referenced by nodes in order to > build the full schema (well, it wanted the referenced files to be there, so > I assumed it did read them.) yes, > The problem is, the resulting xmlRelaxNGPtr is > returned to Python as a very much opaque PyCObject pointer. yes, > My question is, is there any exported function in the module which will > allow me to inspect the created schema? Can it be converted to some less > opaque structure? Or should I resort to coding in C ? It's opaque even at the C level, the structures are defined in the C module not in the header and not exported. What do you need to know from those data structure ? Then an API might be designed and added. Considering the level of complexity of the Relax-NG structure, exposing the internals directly won't help you anyway ! Read the relaxng.c module, see it in action under a debugger and you will see what I mean, then you might be in a better position to sugest an API. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard@redhat.com Fri Oct 31 11:04:09 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 5CCEB18B9E for ; Fri, 31 Oct 2003 11:04:09 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9VG4N523536; Fri, 31 Oct 2003 11:04:23 -0500 Date: Fri, 31 Oct 2003 11:04:23 -0500 From: Daniel Veillard To: Nanning Buitenhuis Cc: xml@gnome.org Subject: Re: [xml] How to extend the Reader interface with a dup() function Message-ID: <20031031110423.M25702@redhat.com> Reply-To: veillard@redhat.com References: <20031031155838.GB6878@guest.lunatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031031155838.GB6878@guest.lunatech.com>; from nanning@elvenkind.com on Fri, Oct 31, 2003 at 04:58:38PM +0100 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Fri, Oct 31, 2003 at 04:58:38PM +0100, Nanning Buitenhuis wrote: > I want to extend the Reader interface with a dup() function. > That is, make a new reader with the same state as the current > reader, so a trial run over the data is possible. > > Possible, impossible, or pointers? Would require special code in the xmlreader.c . Seems really hard anyway for example if you feed the data from a socket. So In general it sounds like too hard to make reliable and it't better to reuse the Reader for the same stream again. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From luigi.ballabio@riskmap.it Fri Oct 31 11:30:23 2003 Return-Path: Delivered-To: xml@gnome.org Received: from bgph-226.opennet.it (bgph-226.opennet.it [213.212.129.226]) by mail.gnome.org (Postfix) with ESMTP id 0B636182EB for ; Fri, 31 Oct 2003 11:30:23 -0500 (EST) Received: from ballabl03.riskmap.it ([213.212.148.34]) by bgph-226.opennet.it (8.11.6/8.11.6) with ESMTP id h9VGTip06798; Fri, 31 Oct 2003 17:29:50 +0100 Message-Id: <6.0.0.22.0.20031031172715.01b1c5f8@mail.riskmap.net> X-Sender: X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 31 Oct 2003 17:30:37 +0100 To: veillard@redhat.com From: Luigi Ballabio Subject: Re: [xml] Inspecting a RelaxNG schema Cc: xml@gnome.org In-Reply-To: <20031031110149.L25702@redhat.com> References: <20031031152901.31874.5428.Mailman@moniker.gnome.org> <6.0.0.22.0.20031031163318.01b15c80@mail.riskmap.net> <20031031110149.L25702@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: At 17:01 31/10/2003, Daniel Veillard wrote: >On Fri, Oct 31, 2003 at 04:48:42PM +0100, Luigi Ballabio wrote: > > > > ...(snipping my own ramblings on the opaqueness of xmlRelaxNGPtr) > > > My question is, is there any exported function in the module which will > > allow me to inspect the created schema? Can it be converted to some less > > opaque structure? Or should I resort to coding in C ? > > It's opaque even at the C level, the structures are defined in the C module >not in the header and not exported. > What do you need to know from those data structure ? Then an API might >be designed and added. Considering the level of complexity of the Relax-NG >structure, exposing the internals directly won't help you anyway ! Read >the relaxng.c module, see it in action under a debugger and you will see what >I mean, then you might be in a better position to sugest an API. Daniel, thanks---that was prompt. I'll do some homework on relaxrg.c and come back (I hope.) Later, Luigi From shard@neoni.net Fri Oct 31 16:24:27 2003 Return-Path: Delivered-To: xml@gnome.org Received: from nicolaus.az.pl (nicolaus.az.pl [217.153.59.68]) by mail.gnome.org (Postfix) with ESMTP id 35EA91892D for ; Fri, 31 Oct 2003 16:24:26 -0500 (EST) Received: from bepc.home.astercity.net (69-ego-3.acn.waw.pl [62.121.86.69]) by nicolaus.az.pl (8.11.6/8.11.6) with ESMTP id h9VLOGH23074 for ; Fri, 31 Oct 2003 22:24:17 +0100 Date: Fri, 31 Oct 2003 22:24:12 +0100 From: shard@neoni.net Message-Id: <20031031222412.92269.1@bepc.home.astercity.net> Mime-Version: 1.0 To: xml@gnome.org User-Agent: Beam 1.0-rc4 Content-Type: multipart/mixed; boundary="_=_BOUNDARY_12239314257_1_=_" Content-Transfer-Encoding: 7bit Subject: [xml] [PATCH] libxml2-2.6.1 for BeOS Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. --_=_BOUNDARY_12239314257_1_=_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I know some changes were already added to CVS but i wanted to make "clean" diff. If it's much trouble i can try make patch for current CVS. No one answered my question about it, I modified xmlMutex implementation so now only thread who locked mutex can unlock it. Since i used thread_id for it, i could remove the same tid from xmlRMutex. Trying to lock from the same thread will make deadlock - didn't change that because i've read in pthread docs that default pthread_mutex type makes the same (and i wanted to keep it funtion the more or less the same way as on other platforms). I also patched nanohttp code for making nonblocking socket on BeOS (didn't work before). Now i can download whole html from url, not only first x bytes ;D Regards Shard --_=_BOUNDARY_12239314257_1_=_ Content-Type: text/plain; charset="UTF-8"; name="libxml2-2.6.1-BeOS.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="libxml2-2.6.1-BeOS.diff" diff -u /boot/home/Unzipped/libxml2-2.6.1/nanoftp.c /BeStorage/Sources/Apps/My/LibPak/src_current/libxml2-2.6.1/nanoftp.c --- /boot/home/Unzipped/libxml2-2.6.1/nanoftp.c Fri Oct 10 17:49:38 2003 +++ /BeStorage/Sources/Apps/My/LibPak/src_current/libxml2-2.6.1/nanoftp.c Fri Oct 31 19:43:22 2003 @@ -2221,10 +2221,10 @@ void ftpData(void *userData, const char *data, int len) { if (userData == NULL) return; if (len <= 0) { - fclose(userData); + fclose((FILE*)userData); return; } - fwrite(data, len, 1, userData); + fwrite(data, len, 1, (FILE*)userData); } int main(int argc, char **argv) { diff -u /boot/home/Unzipped/libxml2-2.6.1/nanohttp.c /BeStorage/Sources/Apps/My/LibPak/src_current/libxml2-2.6.1/nanohttp.c --- /boot/home/Unzipped/libxml2-2.6.1/nanohttp.c Sun Oct 19 15:26:37 2003 +++ /BeStorage/Sources/Apps/My/LibPak/src_current/libxml2-2.6.1/nanohttp.c Fri Oct 31 19:45:01 2003 @@ -909,6 +909,12 @@ status = ioctl(s, FIONBIO, &enable); } #else /* VMS */ +#if defined(__BEOS__) + { + bool noblock = true; + status = setsockopt(s, SOL_SOCKET, SO_NONBLOCK, &noblock, sizeof(noblock)); + } +#else /* __BEOS__ */ if ((status = fcntl(s, F_GETFL, 0)) != -1) { #ifdef O_NONBLOCK status |= O_NONBLOCK; @@ -927,6 +933,7 @@ closesocket(s); return(-1); } +#endif /* !__BEOS__ */ #endif /* !VMS */ #endif /* !_WINSOCKAPI_ */ @@ -1314,7 +1321,7 @@ if (contentType && *contentType) blen += strlen(*contentType) + 16; blen += strlen(method) + strlen(ctxt->path) + 24; - bp = xmlMallocAtomic(blen); + bp = (char*)xmlMallocAtomic(blen); if ( bp == NULL ) { xmlNanoHTTPFreeCtxt( ctxt ); xmlHTTPErrMemory("allocating header buffer"); @@ -1616,7 +1623,7 @@ */ int xmlNanoHTTPContentLength( void * ctx ) { - xmlNanoHTTPCtxtPtr ctxt = ctx; + xmlNanoHTTPCtxtPtr ctxt = (xmlNanoHTTPCtxtPtr)ctx; return ( ( ctxt == NULL ) ? -1 : ctxt->ContentLength ); } @@ -1631,7 +1638,7 @@ */ const char * xmlNanoHTTPRedir( void * ctx ) { - xmlNanoHTTPCtxtPtr ctxt = ctx; + xmlNanoHTTPCtxtPtr ctxt = (xmlNanoHTTPCtxtPtr)ctx; return ( ( ctxt == NULL ) ? NULL : ctxt->location ); } @@ -1646,7 +1653,7 @@ */ const char * xmlNanoHTTPEncoding( void * ctx ) { - xmlNanoHTTPCtxtPtr ctxt = ctx; + xmlNanoHTTPCtxtPtr ctxt = (xmlNanoHTTPCtxtPtr)ctx; return ( ( ctxt == NULL ) ? NULL : ctxt->encoding ); } @@ -1661,7 +1668,7 @@ */ const char * xmlNanoHTTPMimeType( void * ctx ) { - xmlNanoHTTPCtxtPtr ctxt = ctx; + xmlNanoHTTPCtxtPtr ctxt = (xmlNanoHTTPCtxtPtr)ctx; return ( ( ctxt == NULL ) ? NULL : ctxt->mimeType ); } @@ -1680,7 +1687,7 @@ */ int xmlNanoHTTPFetchContent( void * ctx, char ** ptr, int * len ) { - xmlNanoHTTPCtxtPtr ctxt = ctx; + xmlNanoHTTPCtxtPtr ctxt = (xmlNanoHTTPCtxtPtr)ctx; int rc = 0; int cur_lgth; diff -u /boot/home/Unzipped/libxml2-2.6.1/testThreads.c /BeStorage/Sources/Apps/My/LibPak/src_current/libxml2-2.6.1/testThreads.c --- /boot/home/Unzipped/libxml2-2.6.1/testThreads.c Thu Aug 7 10:00:59 2003 +++ /BeStorage/Sources/Apps/My/LibPak/src_current/libxml2-2.6.1/testThreads.c Tue Oct 28 20:36:25 2003 @@ -7,7 +7,11 @@ #include #include #include +#ifdef HAVE_PTHREAD_H #include +#elif defined HAVE_BEOS_THREADS +#include +#endif #include #if !defined(_MSC_VER) #include @@ -15,7 +19,11 @@ #include #define MAX_ARGC 20 +#ifdef HAVE_PTHREAD_H static pthread_t tid[MAX_ARGC]; +#elif defined HAVE_BEOS_THREADS +static thread_id tid[MAX_ARGC]; +#endif static const char *catalog = "test/threads/complex.xml"; static const char *testfiles[] = { @@ -83,6 +91,7 @@ return ((void *) Okay); } +#ifdef HAVE_PTHREAD_H int main(void) { @@ -125,6 +134,62 @@ xmlMemoryDump(); return (0); } +#elif defined HAVE_BEOS_THREADS +int +main(void) +{ + unsigned int i, repeat; + unsigned int num_threads = sizeof(testfiles) / sizeof(testfiles[0]); + void *results[MAX_ARGC]; + status_t ret; + + xmlInitParser(); + printf("Parser initialized\n"); + for (repeat = 0;repeat < 500;repeat++) { + printf("repeat: %d\n",repeat); + xmlLoadCatalog(catalog); + printf("loaded catalog: %s\n", catalog); + for (i = 0; i < num_threads; i++) { + results[i] = NULL; + tid[i] = (thread_id) -1; + } + printf("cleaned threads\n"); + for (i = 0; i < num_threads; i++) { + tid[i] = spawn_thread(thread_specific_data, "xmlTestThread", B_NORMAL_PRIORITY, (void *) testfiles[i]); + if (tid[i] < B_OK) { + perror("beos_thread_create"); + exit(1); + } + printf("beos_thread_create %d -> %d\n", i, tid[i]); + } + for (i = 0; i < num_threads; i++) { + ret = wait_for_thread(tid[i], &results[i]); + printf("beos_thread_wait %d -> %d\n", i, ret); + if (ret != B_OK) { + perror("beos_thread_wait"); + exit(1); + } + } + + xmlCatalogCleanup(); + ret = B_OK; + for (i = 0; i < num_threads; i++) + if (results[i] != (void *) Okay) { + printf("Thread %d handling %s failed\n", i, testfiles[i]); + ret = B_ERROR; + } + } + xmlCleanupParser(); + xmlMemoryDump(); + + if (ret == B_OK) + printf("testThread : BeOS : SUCCESS!\n"); + else + printf("testThread : BeOS : FAILED!\n"); + + return (0); +} +#endif /* pthreads or BeOS threads */ #else /* !LIBXML_THREADS_ENABLED */ int diff -u /boot/home/Unzipped/libxml2-2.6.1/threads.c /BeStorage/Sources/Apps/My/LibPak/src_current/libxml2-2.6.1/threads.c --- /boot/home/Unzipped/libxml2-2.6.1/threads.c Sat Oct 11 12:17:30 2003 +++ /BeStorage/Sources/Apps/My/LibPak/src_current/libxml2-2.6.1/threads.c Fri Oct 31 22:08:16 2003 @@ -35,6 +35,11 @@ #endif #endif +#ifdef HAVE_BEOS_THREADS +#include +#include +#endif + #if defined(SOLARIS) #include #endif @@ -55,6 +60,9 @@ pthread_mutex_t lock; #elif defined HAVE_WIN32_THREADS HANDLE mutex; +#elif defined HAVE_BEOS_THREADS + sem_id sem; + thread_id tid; #else int empty; #endif @@ -73,6 +81,10 @@ #elif defined HAVE_WIN32_THREADS CRITICAL_SECTION cs; unsigned int count; +#elif defined HAVE_BEOS_THREADS + xmlMutexPtr lock; + thread_id tid; + int32 count; #else int empty; #endif @@ -96,7 +108,11 @@ #endif /* HAVE_COMPILER_TLS */ static DWORD mainthread; static int run_once_init = 1; -#endif /* HAVE_WIN32_THREADS */ +#elif defined(HAVE_BEOS_THREADS) +int32 globalkey = 0; +thread_id mainthread = 0; +int32 run_once_init = 0; +#endif static xmlRMutexPtr xmlLibraryLock = NULL; #ifdef LIBXML_THREAD_ENABLED @@ -122,6 +138,12 @@ pthread_mutex_init(&tok->lock, NULL); #elif defined HAVE_WIN32_THREADS tok->mutex = CreateMutex(NULL, FALSE, NULL); +#elif defined HAVE_BEOS_THREADS + if ((tok->sem = create_sem(1, "xmlMutex")) < B_OK) { + free(tok); + return NULL; + } + tok->tid = -1; #endif return (tok); } @@ -142,6 +164,8 @@ pthread_mutex_destroy(&tok->lock); #elif defined HAVE_WIN32_THREADS CloseHandle(tok->mutex); +#elif defined HAVE_BEOS_THREADS + delete_sem(tok->sem); #endif free(tok); } @@ -161,6 +185,14 @@ pthread_mutex_lock(&tok->lock); #elif defined HAVE_WIN32_THREADS WaitForSingleObject(tok->mutex, INFINITE); +#elif defined HAVE_BEOS_THREADS + if (acquire_sem(tok->sem) != B_NO_ERROR) { +#ifdef DEBUG_THREADS + xmlGenericError(xmlGenericErrorContext, "xmlMutexLock():BeOS:Couldn't aquire semaphore\n"); + exit(); +#endif + } + tok->tid = find_thread(NULL); #endif } @@ -180,6 +212,11 @@ pthread_mutex_unlock(&tok->lock); #elif defined HAVE_WIN32_THREADS ReleaseMutex(tok->mutex); +#elif defined HAVE_BEOS_THREADS + if (tok->tid == find_thread(NULL)) { + tok->tid = -1; + release_sem(tok->sem); + } #endif } @@ -208,6 +245,12 @@ #elif defined HAVE_WIN32_THREADS InitializeCriticalSection(&tok->cs); tok->count = 0; +#elif defined HAVE_BEOS_THREADS + if ((tok->lock = xmlNewMutex()) == NULL) { + free(tok); + return NULL; + } + tok->count = 0; #endif return (tok); } @@ -226,6 +269,8 @@ pthread_mutex_destroy(&tok->lock); #elif defined HAVE_WIN32_THREADS DeleteCriticalSection(&tok->cs); +#elif defined HAVE_BEOS_THREADS + xmlFreeMutex(tok->lock); #endif free(tok); } @@ -261,6 +306,14 @@ #elif defined HAVE_WIN32_THREADS EnterCriticalSection(&tok->cs); ++tok->count; +#elif defined HAVE_BEOS_THREADS + if (tok->lock->tid == find_thread(NULL)) { + tok->count++; + return; + } else { + xmlMutexLock(tok->lock); + tok->count = 1; + } #endif } @@ -287,6 +340,14 @@ #elif defined HAVE_WIN32_THREADS if (!--tok->count) LeaveCriticalSection(&tok->cs); +#elif defined HAVE_BEOS_THREADS + if (tok->lock->tid == find_thread(NULL)) { + tok->count--; + if (tok->count == 0) { + xmlMutexUnlock(tok->lock); + } + return; + } #endif } @@ -369,6 +430,15 @@ #endif /* HAVE_COMPILER_TLS */ #endif /* HAVE_WIN32_THREADS */ +#if defined HAVE_BEOS_THREADS +void xmlGlobalStateCleanup(void *data) +{ + void *globalval = tls_get(globalkey); + if (globalval != NULL) + xmlFreeGlobalState(globalval); +} +#endif + /** * xmlGetGlobalState: * @@ -438,6 +508,20 @@ } return (globalval); #endif /* HAVE_COMPILER_TLS */ +#elif defined HAVE_BEOS_THREADS + xmlGlobalState *globalval; + + xmlOnceInit(); + + if ((globalval = (xmlGlobalState *) + tls_get(globalkey)) == NULL) { + xmlGlobalState *tsd = xmlNewGlobalState(); + + tls_set(globalkey, tsd); + on_exit_thread(xmlGlobalStateCleanup, NULL); + return (tsd); + } + return (globalval); #else return(NULL); #endif @@ -463,6 +547,8 @@ return((int) pthread_self()); #elif defined HAVE_WIN32_THREADS return GetCurrentThreadId(); +#elif defined HAVE_BEOS_THREADS + return find_thread(NULL); #else return((int) 0); #endif @@ -485,6 +571,8 @@ run_once_init = 0; xmlOnceInit (); } +#elif defined HAVE_BEOS_THREADS + xmlOnceInit(); #endif #ifdef DEBUG_THREADS @@ -494,6 +582,8 @@ return(mainthread == pthread_self()); #elif defined HAVE_WIN32_THREADS return(mainthread == GetCurrentThreadId ()); +#elif defined HAVE_BEOS_THREADS + return(mainthread == find_thread(NULL)); #else return(1); #endif @@ -600,6 +690,15 @@ globalkey = TlsAlloc(); #endif mainthread = GetCurrentThreadId(); +#endif + +#ifdef HAVE_BEOS_THREADS + if (atomic_add(&run_once_init, 1) == 0) { + globalkey = tls_allocate(); + tls_set(globalkey, NULL); + mainthread = find_thread(NULL); + } else + atomic_add(&run_once_init, -1); #endif } #endif --_=_BOUNDARY_12239314257_1_=_-- From veillard@redhat.com Fri Oct 31 17:53:35 2003 Return-Path: Delivered-To: xml@gnome.org Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 28EDD181AE for ; Fri, 31 Oct 2003 17:53:35 -0500 (EST) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h9VMrp029954; Fri, 31 Oct 2003 17:53:51 -0500 Date: Fri, 31 Oct 2003 17:53:51 -0500 From: Daniel Veillard To: shard@neoni.net Cc: xml@gnome.org Subject: Re: [xml] [PATCH] libxml2-2.6.1 for BeOS Message-ID: <20031031175351.A1428@redhat.com> Reply-To: veillard@redhat.com References: <20031031222412.92269.1@bepc.home.astercity.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031031222412.92269.1@bepc.home.astercity.net>; from shard@neoni.net on Fri, Oct 31, 2003 at 10:24:12PM +0100 Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: On Fri, Oct 31, 2003 at 10:24:12PM +0100, shard@neoni.net wrote: > Hi, > > I know some changes were already added to CVS but i wanted to make "clean" > diff. If it's much trouble i can try make patch for current CVS. Yeah, could you do that ? I always feel unsafe if I need to edit patches because only part of it only can apply. > No one answered my question about it, I modified xmlMutex implementation > so now only thread who locked mutex can unlock it. Since i used thread_id > for it, i could remove the same tid from xmlRMutex. Trying to lock from > the same thread will make deadlock - didn't change that because i've read > in pthread docs that default pthread_mutex type makes the same (and i > wanted to keep it funtion the more or less the same way as on other > platforms). I think libxml2 usage of threads is relatively basic, while those different semantic are really important of generic thread APIs for the limited use within libxml2 this should not have side effects. > I also patched nanohttp code for making nonblocking socket on BeOS (didn't > work before). Now i can download whole html from url, not only first x > bytes ;D Okay :-) if you can make new patches that would be great, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From shard@neoni.net Fri Oct 31 18:44:47 2003 Return-Path: Delivered-To: xml@gnome.org Received: from nicolaus.az.pl (nicolaus.az.pl [217.153.59.68]) by mail.gnome.org (Postfix) with ESMTP id DB45F1810F for ; Fri, 31 Oct 2003 18:44:46 -0500 (EST) Received: from bepc.home.astercity.net (69-ego-3.acn.waw.pl [62.121.86.69]) by nicolaus.az.pl (8.11.6/8.11.6) with ESMTP id h9VNiUH15313; Sat, 1 Nov 2003 00:44:30 +0100 Cc: xml@gnome.org Date: Sat, 01 Nov 2003 00:44:39 +0100 From: shard@neoni.net In-Reply-To: <20031031175351.A1428@redhat.com> Message-Id: <20031101004439.2115.2@bepc.home.astercity.net> Mime-Version: 1.0 References: <20031031222412.92269.1@bepc.home.astercity.net> <20031031175351.A1428@redhat.com> Subject: Re: [xml] [PATCH] libxml2-2.6.1 for BeOS To: veillard@redhat.com User-Agent: Beam 1.0-rc4 Content-Type: multipart/mixed; boundary="_=_BOUNDARY_3221849333_2_=_" Content-Transfer-Encoding: 7bit Content-Disposition: attachment Sender: xml-admin@gnome.org Errors-To: xml-admin@gnome.org X-BeenThere: xml@gnome.org X-Loop: xml@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XML library mailing-list List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. --_=_BOUNDARY_3221849333_2_=_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline > Yeah, could you do that ? I always feel unsafe if I need to edit > patches > because only part of it only can apply. here it is. > I think libxml2 usage of threads is relatively basic, while those > different > semantic are really important of generic thread APIs for the limited use > within libxml2 this should not have side effects. good :) > Okay :-) if you can make new patches that would be great, done :) Could someone change configure script and/or makefile so it will add "#define HAVE_BEOS_THREADS" to config.h? also there is no libm on BeOS (math is in "default" system libs, no need to link additional things) - that's not a big problem since library links ok, but still it would be "cleaner" if it wouldn't add -lm on BeOS. also it would be great if there was configure switch to chose threads type (for example here i have libpthread, but it's buggy and not usable for libxml2, so i use BeOS native sepmaphore and TLC). I don't know how to do that :( i know configure scripts often use uname to recognize OS so here it is: $ uname --help Usage: /bin/uname [OPTION]... Print certain system information. With no OPTION, same as -s. -a, --all print all information -m, --machine print the machine (hardware) type -n, --nodename print the machine's network node hostname -r, --release print the operating system release -s, --sysname print the operating system name -p, --processor print the host processor type -v print the operating system version --help display this help and exit --version output version information and exit Report bugs to . $ uname BeOS $ uname -a BeOS trantor 5.0 1000009 BePC unknown $ uname -m BePC $ uname -n trantor $ uname -r 5.0 $ uname -s BeOS $ uname -p unknown $ uname -v 1000009 THX in advance Regards Shard --_=_BOUNDARY_3221849333_2_=_ Content-Type: text/plain; charset="UTF-8"; name="libxml2-2.6.1-BeOS.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="libxml2-2.6.1-BeOS.diff" diff -u /boot/home/Unzipped/libxml2/nanohttp.c /BeStorage/Sources/Apps/My/LibPak/src_current/libxml2-2.6.1/nanohttp.c --- /boot/home/Unzipped/libxml2/nanohttp.c Wed Oct 29 14:39:15 2003 +++ /BeStorage/Sources/Apps/My/LibPak/src_current/libxml2-2.6.1/nanohttp.c Fri Oct 31 19:45:01 2003 @@ -909,6 +909,12 @@ status = ioctl(s, FIONBIO, &enable); } #else /* VMS */ +#if defined(__BEOS__) + { + bool noblock = true; + status = setsockopt(s, SOL_SOCKET, SO_NONBLOCK, &noblock, sizeof(noblock)); + } +#else /* __BEOS__ */ if ((status = fcntl(s, F_GETFL, 0)) != -1) { #ifdef O_NONBLOCK status |= O_NONBLOCK; @@ -927,6 +933,7 @@ closesocket(s); return(-1); } +#endif /* !__BEOS__ */ #endif /* !VMS */ #endif /* !_WINSOCKAPI_ */ diff -u /boot/home/Unzipped/libxml2/threads.c /BeStorage/Sources/Apps/My/LibPak/src_current/libxml2-2.6.1/threads.c --- /boot/home/Unzipped/libxml2/threads.c Wed Oct 29 14:39:15 2003 +++ /BeStorage/Sources/Apps/My/LibPak/src_current/libxml2-2.6.1/threads.c Sat Nov 1 00:27:20 2003 @@ -62,6 +62,7 @@ HANDLE mutex; #elif defined HAVE_BEOS_THREADS sem_id sem; + thread_id tid; #else int empty; #endif @@ -143,6 +144,7 @@ free(tok); return NULL; } + tok->tid = -1; #endif return (tok); } @@ -191,6 +193,7 @@ exit(); #endif } + tok->tid = find_thread(NULL); #endif } @@ -211,7 +214,10 @@ #elif defined HAVE_WIN32_THREADS ReleaseMutex(tok->mutex); #elif defined HAVE_BEOS_THREADS - release_sem(tok->sem); + if (tok->tid == find_thread(NULL)) { + tok->tid = -1; + release_sem(tok->sem); + } #endif } @@ -246,7 +252,6 @@ return NULL; } tok->count = 0; - tok->tid = 0; #endif return (tok); } @@ -303,12 +308,11 @@ EnterCriticalSection(&tok->cs); ++tok->count; #elif defined HAVE_BEOS_THREADS - if (tok->tid == find_thread(NULL)) { + if (tok->lock->tid == find_thread(NULL)) { tok->count++; return; } else { xmlMutexLock(tok->lock); - tok->tid = find_thread(NULL); tok->count = 1; } #endif @@ -338,10 +342,9 @@ if (!--tok->count) LeaveCriticalSection(&tok->cs); #elif defined HAVE_BEOS_THREADS - if (tok->tid == find_thread(NULL)) { + if (tok->lock->tid == find_thread(NULL)) { tok->count--; if (tok->count == 0) { - tok->tid = 0; xmlMutexUnlock(tok->lock); } return; --_=_BOUNDARY_3221849333_2_=_--