libxmlplusplus-general — Open discusions about libXML++

Re: [libxml++] program crashes when parsing XML with accent

[Murray C. <mu...@mu...>]

On Tue, 2004-05-04 at 19:11 +0200, Christophe de VIENNE wrote:
> Indeed (cf my other message).
> However I think we should signal this to the glibmm dev team, so they at 
> least document it since it does not have the behavior we naturaly though 
> it had.

I have just signalled myself.

Re: [libxml++] program crashes when parsing XML with accent

[Christophe de V. <cde...@al...>]

Hi again,

Here is a little program that makes thing more clear :

#include <iostream>
#include <glibmm/ustring.h>

int main()
{
        try {
                Glib::ustring test("égal", 4);
                std::cout << "Success" << std::endl;
        } catch (...) {
                std::cout << "Failure" << std::endl;
        }
        try {
                Glib::ustring test("égal", 5);
                std::cout << "Success" << std::endl;
        } catch (...) {
                std::cout << "Failure" << std::endl;
        }
};


The output of it is:

Success
Failure


So, we have two possible conclusions :

1) Glib::ustring::ustring(const char *, ustring::size_type) does not 
have the good behavior.
2) We do no use correctly Glib::ustring::ustring(const char *, 
ustring::size_type)

I'd say that the constructor from a const char * should wait for the 
length in byte, and not in characters, since if I'm manipulating a char 
*, I have few chances to know the length in characters easily, so my 
personal conclusion is more 1) than 2).

Anyway I guess that Glibmm being stable, the behavior will not change. 
So we should probably use the Glib::ustring::ustring(const char *) 
constructor instead.
For that we have to be sure that libxml2 will always gives us strings 
with a trailing '\0'. Daniel could you confirm ? Thanks.


Regards

Christophe

Re: [libxml++] program crashes when parsing XML with accent

[Murray C. <mu...@mu...>]

On Tue, 2004-05-04 at 18:40 +0200, Christophe de VIENNE wrote:
> Hi,
> 
> 
> I could reproduce the problem with the saxparser example and the xml sample file from the bugzilla ticket.
> I obtain this bt:
> 
> #0  0x403b91b1 in kill () from /lib/libc.so.6
> #1  0x4014a9c1 in pthread_kill () from /lib/libpthread.so.0
> #2  0x4014accb in raise () from /lib/libpthread.so.0
> #3  0x403b8df4 in raise () from /lib/libc.so.6
> #4  0x403ba5a8 in abort () from /lib/libc.so.6
> #5  0x402bca74 in __cxa_call_unexpected () from /usr/lib/./libstdc++.so.5
> #6  0x402bcab1 in std::terminate () from /usr/lib/./libstdc++.so.5
> #7  0x402bcc21 in __cxa_throw () from /usr/lib/./libstdc++.so.5
> #8  0x40276a5c in std::__throw_length_error () from /usr/lib/./libstdc++.so.5
> #9  0x402af83f in std::string::_Rep::_S_create () from /usr/lib/./libstdc++.so.5
> #10 0x402b03a4 in std::string::_M_replace_safe<char const*> () from /usr/lib/./libstdc++.so.5
> #11 0x402ad23a in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string () from /usr/lib/./libstdc++.so.5
> #12 0x401d28b4 in Glib::ustring::ustring () from /usr/lib/./libglibmm-2.3.so.2
> #13 0x40024924 in xmlpp::SaxParserCallback::characters (context=0x0, ch=0xbffff0a0 "égal", len=5) at saxparser.cc:390
> #14 0x4005dd0d in xmlParseCharDataComplex () from /usr/lib/./libxml2.so.2
> #15 0x4005d7d2 in xmlParseCharData () from /usr/lib/./libxml2.so.2
> #16 0x40066bf1 in xmlParseContent () from /usr/lib/./libxml2.so.2
> #17 0x40066fa9 in xmlParseElement () from /usr/lib/./libxml2.so.2
> #18 0x400682e3 in xmlParseDocument () from /usr/lib/./libxml2.so.2
> #19 0x4002383d in xmlpp::SaxParser::parse (this=0xbffff560) at saxparser.cc:152
> #20 0x4002398a in xmlpp::SaxParser::parse_file (this=0xbffff560, filename=@0xbffff590) at saxparser.cc:173
> #21 0x08049adc in main (argc=2, argv=0x0) at main.cc:45
> 
> We see at line #13 that the callback gives the string utf-8 encoded and it's length in characters. This is with no doubt correct, and those values are given to ustring constructor directly.
> 
> Going throught ustring sources I see that the constructor we use do this:
>     269 ustring::ustring(const char* src, ustring::size_type n)
>     270 :
>     271   string_ (src, utf8_byte_offset(src, n))
>     272 {}
> 
> knowing that std::__throw_length_error () is supposed to be raised if size is greater than max_size, I presume utf8_byte_offset returned std::string::npos.
> 
> My probably stupid question is the following:
> Murray, in ustring::ustring(const char* src, ustring::size_type n), is "n" supposed to be the length in utf-8 characters, or in bytes ?

I think it's meant to be the number of characters. That's not what I'd
expect, but I guess it makes sense in terms of translating std::string
to Glib::ustring.

Actually, in my debugger, the ch paramater to
SaxParserCallback::characters() seems to be 0, which is a more likely
cause for the crash. I guess we should check for 0.

Re: [libxml++] program crashes when parsing XML with accent

[Christophe de V. <cde...@al...>]

Hi,


I could reproduce the problem with the saxparser example and the xml sample file from the bugzilla ticket.
I obtain this bt:

#0  0x403b91b1 in kill () from /lib/libc.so.6
#1  0x4014a9c1 in pthread_kill () from /lib/libpthread.so.0
#2  0x4014accb in raise () from /lib/libpthread.so.0
#3  0x403b8df4 in raise () from /lib/libc.so.6
#4  0x403ba5a8 in abort () from /lib/libc.so.6
#5  0x402bca74 in __cxa_call_unexpected () from /usr/lib/./libstdc++.so.5
#6  0x402bcab1 in std::terminate () from /usr/lib/./libstdc++.so.5
#7  0x402bcc21 in __cxa_throw () from /usr/lib/./libstdc++.so.5
#8  0x40276a5c in std::__throw_length_error () from /usr/lib/./libstdc++.so.5
#9  0x402af83f in std::string::_Rep::_S_create () from /usr/lib/./libstdc++.so.5
#10 0x402b03a4 in std::string::_M_replace_safe<char const*> () from /usr/lib/./libstdc++.so.5
#11 0x402ad23a in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string () from /usr/lib/./libstdc++.so.5
#12 0x401d28b4 in Glib::ustring::ustring () from /usr/lib/./libglibmm-2.3.so.2
#13 0x40024924 in xmlpp::SaxParserCallback::characters (context=0x0, ch=0xbffff0a0 "égal", len=5) at saxparser.cc:390
#14 0x4005dd0d in xmlParseCharDataComplex () from /usr/lib/./libxml2.so.2
#15 0x4005d7d2 in xmlParseCharData () from /usr/lib/./libxml2.so.2
#16 0x40066bf1 in xmlParseContent () from /usr/lib/./libxml2.so.2
#17 0x40066fa9 in xmlParseElement () from /usr/lib/./libxml2.so.2
#18 0x400682e3 in xmlParseDocument () from /usr/lib/./libxml2.so.2
#19 0x4002383d in xmlpp::SaxParser::parse (this=0xbffff560) at saxparser.cc:152
#20 0x4002398a in xmlpp::SaxParser::parse_file (this=0xbffff560, filename=@0xbffff590) at saxparser.cc:173
#21 0x08049adc in main (argc=2, argv=0x0) at main.cc:45

We see at line #13 that the callback gives the string utf-8 encoded and it's length in characters. This is with no doubt correct, and those values are given to ustring constructor directly.

Going throught ustring sources I see that the constructor we use do this:
    269 ustring::ustring(const char* src, ustring::size_type n)
    270 :
    271   string_ (src, utf8_byte_offset(src, n))
    272 {}

knowing that std::__throw_length_error () is supposed to be raised if size is greater than max_size, I presume utf8_byte_offset returned std::string::npos.

My probably stupid question is the following:
Murray, in ustring::ustring(const char* src, ustring::size_type n), is "n" supposed to be the length in utf-8 characters, or in bytes ?


Regards,

Christophe

Re: [libxml++] program crashes when parsing XML with accent

[Jonathan W. <co...@co...>]

On Tue, May 04, 2004 at 05:21:11PM +0100, Jonathan Wakely wrote:

> Your XML document (as attached to the bug report) has no encoding.

oops, yes it does - my mistake ... sorry!

jon

Re: [libxml++] program crashes when parsing XML with accent

[Jonathan W. <co...@co...>]

On Tue, May 04, 2004 at 05:05:18PM +0200, Frederik Himpe wrote:

> Another thing I do not understand: libxml++-1.0 uses std::string, but it seems 
> these std::strings contained UTF-8. Is that possible?

Yes, UTF-8 is a string of bytes, so it can be contained in std::string.
std::string::length() will return the number of bytes, not the number of
characters (since UTF-8 can use multiple bytes per character) but nothing
stops std::string from holding the bytes.

jon

-- 
To conquer oneself is a greater task than conquering others.
	- Buddha 

Re: [libxml++] program crashes when parsing XML with accent

[Daniel V. <vei...@re...>]

On Tue, May 04, 2004 at 04:13:49PM +0200, Frederik Himpe wrote:
> I have an XML document in ISO-8859-1 character set. When using libxml++=
-2.6,=20
> the sax pasers crashes when it encounters a character with an accent (=E9=
) in=20
> the on_characters method. I'm using the Glib::ustring class.
>=20
> With libxml++-1.0 on the same document, it did not crash, but the chara=
cter=20
> was transformed in two (strange) characters.=20

  At the libxml2 SAX level, the document is first converted to UTF8,
so all character() callbacks should only see UTF8 and yes the =E9 will
be converted into 2 bytes in that encoding.
  I cannot explain why this would crash though, this sounds a serious
breakage.

Daniel

--=20
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
vei...@re...  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

[libxml++] program crashes when parsing XML with accent

[Frederik H. <fre...@ar...>]

I have an XML document in ISO-8859-1 character set. When using libxml++-2.6=
,=20
the sax pasers crashes when it encounters a character with an accent (=E9) =
in=20
the on_characters method. I'm using the Glib::ustring class.

With libxml++-1.0 on the same document, it did not crash, but the character=
=20
was transformed in two (strange) characters.=20

With libxml++-2.6 I have this back trace:

#0  0xffffe410 in ?? ()
#1  0xbfffeb6c in ?? ()
#2  0x00000006 in ?? ()
#3  0x00005550 in ?? ()
#4  0x40397640 in raise () from /lib/tls/libc.so.6
#5  0x40399149 in abort () from /lib/tls/libc.so.6
#6  0x403190f5 in __cxa_call_unexpected () from /usr/lib/libstdc++.so.5
#7  0x40319132 in std::terminate() () from /usr/lib/libstdc++.so.5
#8  0x403192b2 in __cxa_throw () from /usr/lib/libstdc++.so.5
#9  0x402ca4aa in std::__throw_length_error(char const*) ()=20
from /usr/lib/libstdc++.so.5
#10 0x4030a7b0 in std::string::_Rep::_S_create(unsigned, std::allocator<cha=
r>=20
const&) () from /usr/lib/libstdc++.so.5
#11 0x4030b8ff in std::string& std::string::_M_replace_safe<char=20
const*>(__gnu_cxx::__normal_iterator<char*, std::string>,=20
__gnu_cxx::__normal_iterator<char*, std::string>, char const*, char const*)=
=20
() from /usr/lib/libstdc++.so.5
#12 0x40307a6c in std::string::string(char const*, unsigned,=20
std::allocator<char> const&) () from /usr/lib/libstdc++.so.5
#13 0x401a8022 in Glib::ustring::ustring(char const*, unsigned) ()=20
from /usr/lib/libglibmm-2.4.so.1
#14 0x400415e8 in xmlpp::SaxParserCallback::characters(void*, unsigned char=
=20
const*, int) () from /usr/lib/libxml++-2.6.so.1
#15 0x4010b374 in xmlParseCharDataComplex () from /usr/lib/libxml2.so.2
#16 0xbfffeec0 in ?? ()
#17 0x00000002 in ?? ()

What could be the reason for this problem?

=2D-=20
=46rederik Himpe

Re: [libxml++] problem with SAX_parser on_character fonction

[LARRODE X. (DR&T) <xav...@sn...>]

OK, a stack will be good so
Thank you daniel.

On Fri, 2004-04-30 at 15:05, Daniel Veillard wrote:
> On Fri, Apr 30, 2004 at 11:38:33AM +0200, LARRODE Xavier (DR&T) wrote:
> > Hi,
> > 
> > Is it normal that sometimes, for the same Element, the on_character
> > function is called 2 times?
> > Can i force the parser to call it explicitly one time?
> 
>   No. One of the goal of SAX is to be able to operate on bounded memory.
> One of the side effect is that very large sections of character data
> may be reported as sequences of characters() callbacks.
> 
> Daniel

Re: [libxml++] problem with SAX_parser on_character fonction

[Daniel V. <vei...@re...>]

On Fri, Apr 30, 2004 at 11:38:33AM +0200, LARRODE Xavier (DR&T) wrote:
> Hi,
> 
> Is it normal that sometimes, for the same Element, the on_character
> function is called 2 times?
> Can i force the parser to call it explicitly one time?

  No. One of the goal of SAX is to be able to operate on bounded memory.
One of the side effect is that very large sections of character data
may be reported as sequences of characters() callbacks.

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
vei...@re...  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

[libxml++] problem with SAX_parser on_character fonction

[LARRODE X. (DR&T) <xav...@sn...>]

Hi,

Is it normal that sometimes, for the same Element, the on_character
function is called 2 times?
Can i force the parser to call it explicitly one time?

here is my example:
<Vertices>
0.4520942e-01 0.4817451e-01 0.6783868e-01 0.5085975e-01 0.2164471e-01
0.9257241e-01 0.4046732e-01 0.1100695e-01 0.6399040e-01 0.3133999e-01
0.4832361e-01 0.7099523e-01 0.3604524e-01 0.3439208e-01 0.5807805e-01
0.5294021e-01 0.1207079e-01 0.8131917e-01 0.2920624e-01 0.3555536e-01
0.7677209e-01 0.4149553e-01 0.4934437e-01 0.6682675e-01 0.5279884e-01
0.3759574e-01 0.7619313e-01 0.4712154e-01 0.1050351e-01 0.7192019e-01
0.4427849e-01 0.2089362e-01 0.8175253e-01 0.3187400e-01 0.3766751e-01
0.6053719e-01 0.5544884e-01 0.2190038e-01 0.8695550e-01 0.5280745e-01
0.1236461e-01 0.8171037e-01 0.4865450e-01 0.3311216e-01 0.6721804e-01
0.3998979e-01 0.1614658e-01 0.5746185e-01 </Vertices>

and the first time i got  this: 
0.4520942e-01 0.4817451e-01 0.6783868e-01 0.5085975e-01 0.2164471e-01
0.9257241e-01 0.4046732e-01 0.1100695e-01 0.6399040e-01 0.3133999e-01
0.4832361e-01 0.7099523e-01 0.3604524e-01 0.3439208e-01 0.5807805e-01
0.5294021e-01 0.1207079e-01 0.8131917e-01 0.2920624e-01 0.3555536e-01
0.7677209e-01 0.4149553e-01 0.4934437e-01 0.6682675e-01 0.5279884e-01
0.3759574e-01 0.7619313e-01 0.4712154e-01 0.1050351e-01 0.7192019e-01
0.4427849e-01 0.2089362e-01 0.8175253e-01 0.3187400e-01 0.3766751e-01
0.60537

and after 
19e-01 0.5544884e-01 0.2190038e-01 0.8695550e-01 0.5280745e-01
0.1236461e-01 0.8171037e-01 0.4865450e-01 0.3311216e-01 0.6721804e-01
0.3998979e-01 0.1614658e-01 0.5746185e-01 

Of course i have a big xml file with this code on, and 80% of the time
it's allright ...

Thank you 
Xavier 

Re: [libxml++] Makefile for sax_parser_build_dom

[LARRODE X. (DR&T) <xav...@sn...>]

OK, it wasn't on my (copy) directory , sorry for that and thank you 
Xavier

On Mon, 2004-04-26 at 14:27, Christophe de VIENNE wrote:
> Hi,
> 
> LARRODE Xavier (DR&T) wrote:
> 
> >Hello, 
> >i have made some (simple) makefile for the example with the SAX API like
> >sax_parser, and now i would like to make one for the
> >sax_parser_build_dom and i have a strange error:
> >  
> >
> [snip]
> 
> >//here is my error : 
> >g++  -o test -Wall -fno-inline --debug \
> >main.o svgelement.o svgdocument.o -L/usr/lib -L/usr/local/lib -lpthread
> >-lz -lm -lxml++-1.0 
> >  
> >
> Here svgparser.o is missing.
> 
> 
> 
> Christophe
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> For a limited time only, get FREE Ground shipping on all orders of $35
> or more. Hurry up and shop folks, this offer expires April 30th!
> http://www.thinkgeek.com/freeshipping/?cpg=12297
> _______________________________________________
> Libxmlplusplus-general mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libxmlplusplus-general

Re: [libxml++] Makefile for sax_parser_build_dom

[Christophe de V. <cde...@al...>]

Hi,

LARRODE Xavier (DR&T) wrote:

>Hello, 
>i have made some (simple) makefile for the example with the SAX API like
>sax_parser, and now i would like to make one for the
>sax_parser_build_dom and i have a strange error:
>  
>
[snip]

>//here is my error : 
>g++  -o test -Wall -fno-inline --debug \
>main.o svgelement.o svgdocument.o -L/usr/lib -L/usr/local/lib -lpthread
>-lz -lm -lxml++-1.0 
>  
>
Here svgparser.o is missing.



Christophe

[libxml++] Makefile for sax_parser_build_dom

[LARRODE X. (DR&T) <xav...@sn...>]

Hello, 
i have made some (simple) makefile for the example with the SAX API like
sax_parser, and now i would like to make one for the
sax_parser_build_dom and i have a strange error:
//here is my Makefile : 

CC = g++
NAME = test
LIBS	= -L/usr/lib -L/usr/local/lib -lpthread -lz -lm -lxml++-1.0 
OUTPUT   = ./
CFLAGS = -Wall -fno-inline --debug

INCLUDE = -I/usr/include/ -I/usr/include/libxml2  -I/.
-I/usr/include/libxml++-1.0/ -I./ -I/usr/X11R6/include 

OBJS := $(patsubst %.cc,%.o,$(wildcard *.cc))
H_OBJS := $(wildcard *.h)


$(NAME): main.o svgdocument.o svgelement.o
	$(CC)  -o $@ $(CFLAGS) \
	main.o svgelement.o svgdocument.o $(LIBS)

.cc.o:
$(OBJS): %.o : %.cc
	$(CC) $(INCLUDE) $(CFLAGS)  -c -o  $@ $<

# svgdocument.o: svgdocument.cc svgdocument.h 
# 	$(CC) $(CFLAGS) $(INCLUDE)   -c svgdocument.cc
# svgelement.o: svgelement.cc svgelement.h
# 	$(CC) $(CFLAGS) $(INCLUDE)   -c svgelement.cc

# main.o: main.cc svgparser.h svgdocument.h svgelement.h svgpath.h
svggroup.h
# 	$(CC) $(CFLAGS) $(INCLUDE) -c main.cc 

clean:
	rm *.o

//here is my error : 
g++  -o test -Wall -fno-inline --debug \
main.o svgelement.o svgdocument.o -L/usr/lib -L/usr/local/lib -lpthread
-lz -lm -lxml++-1.0 
main.o(.text+0x6b): In function `main':
/home/xavier/libxml/exLibxml++/sax_parser_build_dom/main.cc:49:
undefined reference to
`SVG::Parser::Parser[in-charge](xmlpp::Document&)'
main.o(.text+0x4a8):/home/xavier/libxml/exLibxml++/sax_parser_build_dom/main.cc:64: undefined reference to `SVG::Parser::~Parser [in-charge]()'
main.o(.text+0x4c1):/home/xavier/libxml/exLibxml++/sax_parser_build_dom/main.cc:64: undefined reference to `SVG::Parser::~Parser [in-charge]()'
collect2: ld returned 1 exit status
make: *** [test] Error 1

Compilation exited abnormally with code 2 at Mon Apr 26 14:04:00

Any idea ?
thank you 
Xavier

Re: [libxml++] (no subject)

[Christophe de V. <cde...@al...>]

Hi,

You're right, the backend function used is not the good one.
The problem is also present in v2.6.

I'll fix it in the CVS.

In the next API, we could add a "add_content" function.

Thanks,

Christophe


mar...@ti... wrote:

>Hi All!
>I am newbye in xml and probably what I say is incorrect.
>
>In the method ContentNode::set_content there is a xmlNodeAddContent(cobj(),
>(xmlChar*)content.c_str());
>but I think it should be xmlNodeSetContent(cobj(), (xmlChar*)content.c_str());
>
>I view this line in libxml++-1.0.2, and also in libxml++0.26.0.
>I modify this line with the modification suggested and it works fine for
>me (before this change I saw a result of such an append operation, not a
>'set').
>
>Regards,
> Marcello
>
>__________________________________________________________________
>Social price: l'ADSL diventa per tutti
>Tiscali ADSL Senza Canone 640Kbps: GRATIS fino al 3 maggio costo
>di adesione, attivazione e il modem per tutto il 2004. E per i primi 3 mesi,
>con il Tiscali social price, navighi a 1,5 euro l'ora! Affrettati!
>http://point.tiscali.it/adsl/prodotti/640Kbps/
>
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
>For a limited time only, get FREE Ground shipping on all orders of $35
>or more. Hurry up and shop folks, this offer expires April 30th!
>http://www.thinkgeek.com/freeshipping/?cpg297
>_______________________________________________
>Libxmlplusplus-general mailing list
>Lib...@li...
>https://lists.sourceforge.net/lists/listinfo/libxmlplusplus-general
>
>
>  
>

[libxml++] (no subject)

[<mar...@ti...>]

Hi All!
I am newbye in xml and probably what I say is incorrect.

In the method ContentNode::set_content there is a xmlNodeAddContent(cobj(=
),
(xmlChar*)content.c_str());
but I think it should be xmlNodeSetContent(cobj(), (xmlChar*)content.c_st=
r());

I view this line in libxml++-1.0.2, and also in libxml++0.26.0.
I modify this line with the modification suggested and it works fine for
me (before this change I saw a result of such an append operation, not a
'set').

Regards,
 Marcello

__________________________________________________________________
Social price: l'ADSL diventa per tutti
Tiscali ADSL Senza Canone 640Kbps: GRATIS fino al 3 maggio costo
di adesione, attivazione e il modem per tutto il 2004. E per i primi 3 me=
si,
con il Tiscali social price, navighi a 1,5 euro l'ora! Affrettati!
http://point.tiscali.it/adsl/prodotti/640Kbps/

Re: [libxml++] Stuck sax parse never returns

[Paul R. <rst...@ya...>]

My document is a single line like this:
<a><b/></a>
 
with no new line on the end
 
xmllint seems to have no problem with this.
 
Could it be my library lineup?  I am using the very latest of libsigc++ (1.9.16), glib (2.4.0), glibmm (2.3.7) , and libxml2.  Are there any library incompatibilities?
 
Thanks for all you help.  It is most likely in my code somewhere.....  :)
 
 

Re: [libxml++] Stuck sax parse never returns

[Daniel V. <vei...@re...>]

On Fri, Apr 09, 2004 at 09:51:03AM +0200, Christophe de VIENNE wrote:
> Paul Robinson wrote:
> 
> >I am calling parse_memory on an XML++ sax parser and
> >passing it a std::string.  Sometimes it works and
> >sometimes it gets part way through the xml document
> >and then stops after an end_element call, never
> >completing the document.
> > 
> >
> 
> Never seen such a behavior.
> 
> >My document is very short - only a single line of well
> >formed xml.
> >
> >Any tips on what I might be doing to cause this?
> > 
> >
> 
> No. Could you post a sample which reproduce the problem ?

  and to make sure this is not a libxml2 bug, save said sample
to  a file , and try xmllint --memory test.xml
if this blocks then it's a libxml2 bug [1], if not either it's libxml++
or it's your code :-)

Daniel

[1] in which case then please follow the guidelines at
    http://xmlsoft.org/bugs.html , thanks !

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
vei...@re...  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

Re: [libxml++] Stuck sax parse never returns

[Christophe de V. <cde...@al...>]

Paul Robinson wrote:

>I am calling parse_memory on an XML++ sax parser and
>passing it a std::string.  Sometimes it works and
>sometimes it gets part way through the xml document
>and then stops after an end_element call, never
>completing the document.
>  
>

Never seen such a behavior.

>My document is very short - only a single line of well
>formed xml.
>
>Any tips on what I might be doing to cause this?
>  
>

No. Could you post a sample which reproduce the problem ?



Christophe

[libxml++] Stuck sax parse never returns

[Paul R. <rst...@ya...>]

I am calling parse_memory on an XML++ sax parser and
passing it a std::string.  Sometimes it works and
sometimes it gets part way through the xml document
and then stops after an end_element call, never
completing the document.

My document is very short - only a single line of well
formed xml.

Any tips on what I might be doing to cause this?

Thanks!

Re: [libxml++] questions regarding parse_chunk

[Christophe de V. <cde...@al...>]

Hi,


Shannon S. Harvey wrote:

>Hello all,
>
>Just a quick question regarding your api for sax parsing of network-based xml 
>communications.  I wish to use the parse_chunk method to parse chunks of data 
>as it is received over a socket connection.  However, there may be multiple 
>xml "messages" received back-to-back.  I'm a bit confused as to when to call 
>finish_chunk_parsing when I'm relying on a separate class entity to perform 
>my parsing (one class handles network connectivity, the other class handles 
>the parsing of the xml "messages").
>Any suggestions or comments you might have would be appreciated.
>
>  
>

The finish_chunk_parsing has to be called at the end of the xml document.
If your connection is providing you a separated xml document for each 
'message', then you need to call it after each 'message'.
Theoraticaly you should be able to use the same SaxParser instance for 
several documents, although I did not tested that. If you do please 
report if it works well.

Regards

Christophe

[libxml++] Re: noncopyable class

[Christophe de V. <cde...@ne...>]

Brad Mells wrote:

> Hi Christophe:
>
> Perhaps you can help me to better understand this noncopyable class in 
> libxml++. If it were implemented I believe I would never need be 
> concerned about the document integrity. But since it is not 
> implemented I assume that I need to worry about handling asynchronous 
> events in my program. I hope you understand that it is quite difficult 
> for me to try to find the answer by studying the libxml2 source.


The non copyable class has nothing to do with asynchronous events. It's 
here only to ensure that the copy constructor of a descendant of this 
class cannot be called, and this verification is made at compilation 
because the copy constructor is private.
So the implementation of noncopyable is useless because it's only the 
private character of the copy constructor which ensure that a descendant 
of noncopyable will *never* be copied by it's copy constructor.

>
> Let's say that my cgi program parses an xml document from a file, 
> updates the required elements and then rewrites the file. My concern 
> is that if two events occur that execute this program simultaneously 
> under two processes, it is possible for the second process to undo the 
> updates written by the first (or vice versa depending on when things 
> happen). Do I need to make system level calls in my program to ensure 
> that this kind of thing can't happen?


If I understand correctly your problem, the only thing you need is to 
synchronise the accesses to your xml file. This cannot be done within 
libxml++, but rather by system calls. You should probably use either 
file locking or semaphores.

> Your help is greatly appreciated. I know you are busy but you are the 
> undeniable expert in this matter.
>

Please use the mailing-list of libxml++ 
(lib...@li...) for further discussions.

> Many thanks,
>
> Brad
>


Cheers

Christophe

[libxml++] questions regarding parse_chunk

[Shannon S. H. <cur...@ya...>]

Hello all,

Just a quick question regarding your api for sax parsing of network-based xml 
communications.  I wish to use the parse_chunk method to parse chunks of data 
as it is received over a socket connection.  However, there may be multiple 
xml "messages" received back-to-back.  I'm a bit confused as to when to call 
finish_chunk_parsing when I'm relying on a separate class entity to perform 
my parsing (one class handles network connectivity, the other class handles 
the parsing of the xml "messages").
Any suggestions or comments you might have would be appreciated.

Shannon Harvey
Software Engineer
cur...@ya...

Re: [libxml++] [Fwd: DTD validation for libxml++]

[Jonathan W. <co...@co...>]

On Wed, Mar 31, 2004 at 05:16:12PM +0200, Christophe de VIENNE wrote:

> Date: Wed, 31 Mar 2004 16:33:06 +0200
> From: "Guillaume Arreckx" <bil...@ac...>
> To: cde...@us...
> Subject: DTD validation for libxml++

[snip]

> To valide an xml document, all the user has to do is :
> 
> try
> {
>    xmlpp::DtdValidator validator( dtdFileName );
>    xmlpp::Document *pDoc = ...
>    validator.validate( pDoc );
> }
> catch( const xmlpp::parse_error& )

Nice.

Should DtdValidator.validate() throw something other than parse_error ?

A new xmlpp::validation_error type maybe ?

Otherwise distinguishing between not well-formed and not valid requires
something like:

    try
    {
       xmlpp::DtdValidator validator( dtdFileName );
       xmlpp::Document *pDoc = ...
    }
    catch( const xmlpp::parse_error& )
    {
       // DTD or document is not well-formed
    }
    try
    {
       validator.validate( pDoc );
    }
    catch( const xmlpp:parse_error& )
    {
       // document is not valid
    }

as opposed to:

    try
    {
       xmlpp::DtdValidator validator( dtdFileName );
       xmlpp::Document *pDoc = ...
       validator.validate( pDoc );
    }
    catch( const xmlpp::parse_error& )
    {
       // DTD or document is not well-formed
    }
    catch ( const xmlpp::validation_error& )
    {
       // document is not valid
    }

The exception handling in the first example reduces readibility, rather
than moving error-handling away from the business logic.

Just a thought,

jon


-- 
"A scientific theory should be as simple as possible, but no simpler."
	- Albert Einstein

[libxml++] [Fwd: DTD validation for libxml++]

[Christophe de V. <cde...@al...>]