From noreply at sourceforge.net Wed Jun 4 11:32:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 4 13:32:09 2003 Subject: [Expat-bugs] [ expat-Bugs-749026 ] Won't compile with C++ Message-ID: Bugs item #749026, was opened at 2003-06-04 10:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=749026&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Won't compile with C++ Initial Comment: expat-1.95.6.tar.gz SunOS 5.8 Generic_108528-18 sun4u sparc CC: Sun WorkShop 6 update 2 C++ 5.3 Patch 111685- 09 2002/07/17 Compilation flags: -xO4 expat fails to compile due to a forward reference to enum XML_Status in expat.h. Please see attached patch expat.h.patch Thanks, David Robinson drtr @dial.pipex.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=749026&group_id=10127 From noreply at sourceforge.net Wed Jun 4 11:35:43 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 4 13:35:47 2003 Subject: [Expat-bugs] [ expat-Bugs-749026 ] Won't compile with C++ Message-ID: Bugs item #749026, was opened at 2003-06-04 10:32 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=749026&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Won't compile with C++ Initial Comment: expat-1.95.6.tar.gz SunOS 5.8 Generic_108528-18 sun4u sparc CC: Sun WorkShop 6 update 2 C++ 5.3 Patch 111685- 09 2002/07/17 Compilation flags: -xO4 expat fails to compile due to a forward reference to enum XML_Status in expat.h. Please see attached patch expat.h.patch Thanks, David Robinson drtr @dial.pipex.com ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-06-04 10:35 Message: Logged In: NO Apologies, I meant to say that a C++ application, using expat.h compiled with Sun's C++ compiler failed to compile. Expat itself was compiled sucessfully using Sun's C compiler. David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=749026&group_id=10127 From noreply at sourceforge.net Wed Jun 4 12:00:57 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 4 14:01:00 2003 Subject: [Expat-bugs] [ expat-Bugs-749026 ] Won't compile with C++ Message-ID: Bugs item #749026, was opened at 2003-06-04 13:32 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=749026&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Won't compile with C++ Initial Comment: expat-1.95.6.tar.gz SunOS 5.8 Generic_108528-18 sun4u sparc CC: Sun WorkShop 6 update 2 C++ 5.3 Patch 111685- 09 2002/07/17 Compilation flags: -xO4 expat fails to compile due to a forward reference to enum XML_Status in expat.h. Please see attached patch expat.h.patch Thanks, David Robinson drtr @dial.pipex.com ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-06-04 14:00 Message: Logged In: YES user_id=290026 This is a duplicate of bug #676844. Closed. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-06-04 13:35 Message: Logged In: NO Apologies, I meant to say that a C++ application, using expat.h compiled with Sun's C++ compiler failed to compile. Expat itself was compiled sucessfully using Sun's C compiler. David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=749026&group_id=10127 From noreply at sourceforge.net Tue Jun 10 14:03:32 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 10 16:03:36 2003 Subject: [Expat-bugs] [ expat-Bugs-752139 ] < error Message-ID: Bugs item #752139, was opened at 2003-06-10 13:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=752139&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: < error Initial Comment: <OK> For the test case above, I assume the result in void characterDataHandler(void *userData, const XML_Char *s, int len) { } *s should be "<OK>" but the result I got was "<" Is it a bug or by design? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=752139&group_id=10127 From noreply at sourceforge.net Tue Jun 10 14:25:12 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 10 16:25:16 2003 Subject: [Expat-bugs] [ expat-Bugs-752139 ] < error Message-ID: Bugs item #752139, was opened at 2003-06-10 16:03 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=752139&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: < error Initial Comment: <OK> For the test case above, I assume the result in void characterDataHandler(void *userData, const XML_Char *s, int len) { } *s should be "<OK>" but the result I got was "<" Is it a bug or by design? Thanks. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-06-10 16:25 Message: Logged In: YES user_id=290026 According to section 4.4 in the XML specs (XML Processor Treatment of Entities and References) the behaviour of Expat appears to be correct. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=752139&group_id=10127 From noreply at sourceforge.net Wed Jun 11 05:30:41 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 11 07:30:46 2003 Subject: [Expat-bugs] [ expat-Bugs-752139 ] < error Message-ID: Bugs item #752139, was opened at 2003-06-10 13:03 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=752139&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: < error Initial Comment: <OK> For the test case above, I assume the result in void characterDataHandler(void *userData, const XML_Char *s, int len) { } *s should be "<OK>" but the result I got was "<" Is it a bug or by design? Thanks. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-06-11 04:30 Message: Logged In: NO And what you got was probably "" (if my guessing for 60 and 62 chars is correct), but in wide (16b, 2-bytes), not old, one-byte characters. So "<" 0 "O" 0 "K" 0 ">" 0 and trailing duble-0 for end-of-string-zero-char. Latter may be my faulty memory, for callback have probably just block and its width, not wide-character C-string :) ). Hoping it wasn't to messy. d.n.hotch ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-06-10 13:25 Message: Logged In: YES user_id=290026 According to section 4.4 in the XML specs (XML Processor Treatment of Entities and References) the behaviour of Expat appears to be correct. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=752139&group_id=10127 From noreply at sourceforge.net Wed Jun 11 05:39:10 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 11 07:39:14 2003 Subject: [Expat-bugs] [ expat-Bugs-752139 ] < error Message-ID: Bugs item #752139, was opened at 2003-06-10 13:03 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=752139&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: < error Initial Comment: <OK> For the test case above, I assume the result in void characterDataHandler(void *userData, const XML_Char *s, int len) { } *s should be "<OK>" but the result I got was "<" Is it a bug or by design? Thanks. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-06-11 04:39 Message: Logged In: NO Yes, it was not my faulty memory, but my faulty eyes, too. const XML_Char* s, int len means, that you get block of XML_Chars in "s", in which first "len" XML_Chars have meaning. I don't know, what XML_Char means in your expat. It could be char, or wchar_t, so one problem is that you treat string "s" as char string when it is wide-char string (and all you see is first "<\0" sequence), or you shouldn't use *s (which means "XML_Char at zero index", hence you get a '<' char), and use s instead (remembering "len" stuff) d.n.hotch ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-06-11 04:30 Message: Logged In: NO And what you got was probably "" (if my guessing for 60 and 62 chars is correct), but in wide (16b, 2-bytes), not old, one-byte characters. So "<" 0 "O" 0 "K" 0 ">" 0 and trailing duble-0 for end-of-string-zero-char. Latter may be my faulty memory, for callback have probably just block and its width, not wide-character C-string :) ). Hoping it wasn't to messy. d.n.hotch ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-06-10 13:25 Message: Logged In: YES user_id=290026 According to section 4.4 in the XML specs (XML Processor Treatment of Entities and References) the behaviour of Expat appears to be correct. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=752139&group_id=10127 From noreply at sourceforge.net Wed Jun 11 07:41:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 11 09:41:18 2003 Subject: [Expat-bugs] [ expat-Bugs-752139 ] < error Message-ID: Bugs item #752139, was opened at 2003-06-10 16:03 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=752139&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: < error Initial Comment: <OK> For the test case above, I assume the result in void characterDataHandler(void *userData, const XML_Char *s, int len) { } *s should be "<OK>" but the result I got was "<" Is it a bug or by design? Thanks. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-06-11 09:41 Message: Logged In: YES user_id=290026 The definition of XML_Char in Expat depend on how Expat is compiled: - XML_UNICODE defined: XML_Char = ushort - XML_UNICODE and XML_UNICODE_WCHAR_T: XML_Char = wchar_t - otherwise: XML_Char = char ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-06-11 07:39 Message: Logged In: NO Yes, it was not my faulty memory, but my faulty eyes, too. const XML_Char* s, int len means, that you get block of XML_Chars in "s", in which first "len" XML_Chars have meaning. I don't know, what XML_Char means in your expat. It could be char, or wchar_t, so one problem is that you treat string "s" as char string when it is wide-char string (and all you see is first "<\0" sequence), or you shouldn't use *s (which means "XML_Char at zero index", hence you get a '<' char), and use s instead (remembering "len" stuff) d.n.hotch ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-06-11 07:30 Message: Logged In: NO And what you got was probably "" (if my guessing for 60 and 62 chars is correct), but in wide (16b, 2-bytes), not old, one-byte characters. So "<" 0 "O" 0 "K" 0 ">" 0 and trailing duble-0 for end-of-string-zero-char. Latter may be my faulty memory, for callback have probably just block and its width, not wide-character C-string :) ). Hoping it wasn't to messy. d.n.hotch ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-06-10 16:25 Message: Logged In: YES user_id=290026 According to section 4.4 in the XML specs (XML Processor Treatment of Entities and References) the behaviour of Expat appears to be correct. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=752139&group_id=10127 From noreply at sourceforge.net Wed Jun 11 10:06:10 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 11 12:06:16 2003 Subject: [Expat-bugs] [ expat-Bugs-752139 ] < error Message-ID: Bugs item #752139, was opened at 2003-06-10 13:03 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=752139&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: < error Initial Comment: <OK> For the test case above, I assume the result in void characterDataHandler(void *userData, const XML_Char *s, int len) { } *s should be "<OK>" but the result I got was "<" Is it a bug or by design? Thanks. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-06-11 09:06 Message: Logged In: NO I don't think it's a bug. I'll change my code to follow the standard. :-) Please close it. Thanks. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-06-11 06:41 Message: Logged In: YES user_id=290026 The definition of XML_Char in Expat depend on how Expat is compiled: - XML_UNICODE defined: XML_Char = ushort - XML_UNICODE and XML_UNICODE_WCHAR_T: XML_Char = wchar_t - otherwise: XML_Char = char ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-06-11 04:39 Message: Logged In: NO Yes, it was not my faulty memory, but my faulty eyes, too. const XML_Char* s, int len means, that you get block of XML_Chars in "s", in which first "len" XML_Chars have meaning. I don't know, what XML_Char means in your expat. It could be char, or wchar_t, so one problem is that you treat string "s" as char string when it is wide-char string (and all you see is first "<\0" sequence), or you shouldn't use *s (which means "XML_Char at zero index", hence you get a '<' char), and use s instead (remembering "len" stuff) d.n.hotch ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-06-11 04:30 Message: Logged In: NO And what you got was probably "" (if my guessing for 60 and 62 chars is correct), but in wide (16b, 2-bytes), not old, one-byte characters. So "<" 0 "O" 0 "K" 0 ">" 0 and trailing duble-0 for end-of-string-zero-char. Latter may be my faulty memory, for callback have probably just block and its width, not wide-character C-string :) ). Hoping it wasn't to messy. d.n.hotch ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-06-10 13:25 Message: Logged In: YES user_id=290026 According to section 4.4 in the XML specs (XML Processor Treatment of Entities and References) the behaviour of Expat appears to be correct. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=752139&group_id=10127 From noreply at sourceforge.net Wed Jun 11 10:47:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 11 12:47:48 2003 Subject: [Expat-bugs] [ expat-Bugs-752139 ] < error Message-ID: Bugs item #752139, was opened at 2003-06-10 16:03 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=752139&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: < error Initial Comment: <OK> For the test case above, I assume the result in void characterDataHandler(void *userData, const XML_Char *s, int len) { } *s should be "<OK>" but the result I got was "<" Is it a bug or by design? Thanks. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-06-11 12:47 Message: Logged In: YES user_id=290026 Closed - not a bug. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-06-11 12:06 Message: Logged In: NO I don't think it's a bug. I'll change my code to follow the standard. :-) Please close it. Thanks. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-06-11 09:41 Message: Logged In: YES user_id=290026 The definition of XML_Char in Expat depend on how Expat is compiled: - XML_UNICODE defined: XML_Char = ushort - XML_UNICODE and XML_UNICODE_WCHAR_T: XML_Char = wchar_t - otherwise: XML_Char = char ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-06-11 07:39 Message: Logged In: NO Yes, it was not my faulty memory, but my faulty eyes, too. const XML_Char* s, int len means, that you get block of XML_Chars in "s", in which first "len" XML_Chars have meaning. I don't know, what XML_Char means in your expat. It could be char, or wchar_t, so one problem is that you treat string "s" as char string when it is wide-char string (and all you see is first "<\0" sequence), or you shouldn't use *s (which means "XML_Char at zero index", hence you get a '<' char), and use s instead (remembering "len" stuff) d.n.hotch ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-06-11 07:30 Message: Logged In: NO And what you got was probably "" (if my guessing for 60 and 62 chars is correct), but in wide (16b, 2-bytes), not old, one-byte characters. So "<" 0 "O" 0 "K" 0 ">" 0 and trailing duble-0 for end-of-string-zero-char. Latter may be my faulty memory, for callback have probably just block and its width, not wide-character C-string :) ). Hoping it wasn't to messy. d.n.hotch ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-06-10 16:25 Message: Logged In: YES user_id=290026 According to section 4.4 in the XML specs (XML Processor Treatment of Entities and References) the behaviour of Expat appears to be correct. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=752139&group_id=10127 From noreply at sourceforge.net Thu Jun 12 09:50:52 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jun 12 11:50:56 2003 Subject: [Expat-bugs] [ expat-Bugs-753375 ] infinite parsing Message-ID: Bugs item #753375, was opened at 2003-06-12 15:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=753375&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregor SIegert (mastercaster) Assigned to: Nobody/Anonymous (nobody) Summary: infinite parsing Initial Comment: Hello all, I am receiving a SOAP response with content length > 2000 bytes, containing an array of 2 strings (2nd one very long). I traced the packets and found out that the response is split into 2 TCP packets, with the second one starting not well formed (in the middle of the second string) I would assume TCP binds them correctly together, but something goes wrong. I furthermore see that I receive a infinite parsing (using easysoap, newest version, expat 1.95.6) Smaller responses with all the same params are ok. Can someone help me out with this? I struggle here for days. Maybe a hint what I could do? Regards, Gregor ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=753375&group_id=10127 From noreply at sourceforge.net Thu Jun 12 09:56:11 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jun 12 11:56:15 2003 Subject: [Expat-bugs] [ expat-Bugs-753375 ] infinite parsing Message-ID: Bugs item #753375, was opened at 2003-06-12 11:50 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=753375&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregor SIegert (mastercaster) Assigned to: Nobody/Anonymous (nobody) Summary: infinite parsing Initial Comment: Hello all, I am receiving a SOAP response with content length > 2000 bytes, containing an array of 2 strings (2nd one very long). I traced the packets and found out that the response is split into 2 TCP packets, with the second one starting not well formed (in the middle of the second string) I would assume TCP binds them correctly together, but something goes wrong. I furthermore see that I receive a infinite parsing (using easysoap, newest version, expat 1.95.6) Smaller responses with all the same params are ok. Can someone help me out with this? I struggle here for days. Maybe a hint what I could do? Regards, Gregor ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-06-12 11:56 Message: Logged In: YES user_id=290026 You need to be more specific. From what you tell it is impossible to make any conclusions as to what goes wrong. Does Expat parse correctly if you collect the complete response in a buffer before submitting it to Expat? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=753375&group_id=10127 From noreply at sourceforge.net Thu Jun 12 10:40:58 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jun 12 12:41:01 2003 Subject: [Expat-bugs] [ expat-Bugs-753375 ] infinite parsing Message-ID: Bugs item #753375, was opened at 2003-06-12 15:50 Message generated for change (Comment added) made by mastercaster You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=753375&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregor SIegert (mastercaster) Assigned to: Nobody/Anonymous (nobody) Summary: infinite parsing Initial Comment: Hello all, I am receiving a SOAP response with content length > 2000 bytes, containing an array of 2 strings (2nd one very long). I traced the packets and found out that the response is split into 2 TCP packets, with the second one starting not well formed (in the middle of the second string) I would assume TCP binds them correctly together, but something goes wrong. I furthermore see that I receive a infinite parsing (using easysoap, newest version, expat 1.95.6) Smaller responses with all the same params are ok. Can someone help me out with this? I struggle here for days. Maybe a hint what I could do? Regards, Gregor ---------------------------------------------------------------------- >Comment By: Gregor SIegert (mastercaster) Date: 2003-06-12 16:40 Message: Logged In: YES user_id=764177 You could be right, I did some more digging, easysoap tries to read 1024 Bytes from the HTTP payload and sends this to the expat parser (while(1) loop). So they might be responsible for the mess, because they are responsible to collect the buffer initially. Is this error message significant for this problem? : Error while parsing SOAP XML payload: u ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-06-12 15:56 Message: Logged In: YES user_id=290026 You need to be more specific. From what you tell it is impossible to make any conclusions as to what goes wrong. Does Expat parse correctly if you collect the complete response in a buffer before submitting it to Expat? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=753375&group_id=10127 From noreply at sourceforge.net Thu Jun 12 10:49:05 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jun 12 13:27:39 2003 Subject: [Expat-bugs] [ expat-Bugs-753375 ] infinite parsing Message-ID: Bugs item #753375, was opened at 2003-06-12 11:50 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=753375&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregor SIegert (mastercaster) Assigned to: Nobody/Anonymous (nobody) Summary: infinite parsing Initial Comment: Hello all, I am receiving a SOAP response with content length > 2000 bytes, containing an array of 2 strings (2nd one very long). I traced the packets and found out that the response is split into 2 TCP packets, with the second one starting not well formed (in the middle of the second string) I would assume TCP binds them correctly together, but something goes wrong. I furthermore see that I receive a infinite parsing (using easysoap, newest version, expat 1.95.6) Smaller responses with all the same params are ok. Can someone help me out with this? I struggle here for days. Maybe a hint what I could do? Regards, Gregor ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-06-12 12:49 Message: Logged In: YES user_id=290026 I suggest you also submit a report to the EasySoap team. Lets' see what they have to say. It seems part of your error message is missing. ---------------------------------------------------------------------- Comment By: Gregor SIegert (mastercaster) Date: 2003-06-12 12:40 Message: Logged In: YES user_id=764177 You could be right, I did some more digging, easysoap tries to read 1024 Bytes from the HTTP payload and sends this to the expat parser (while(1) loop). So they might be responsible for the mess, because they are responsible to collect the buffer initially. Is this error message significant for this problem? : Error while parsing SOAP XML payload: u ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-06-12 11:56 Message: Logged In: YES user_id=290026 You need to be more specific. From what you tell it is impossible to make any conclusions as to what goes wrong. Does Expat parse correctly if you collect the complete response in a buffer before submitting it to Expat? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=753375&group_id=10127 From noreply at sourceforge.net Fri Jun 13 14:56:44 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jun 13 16:56:46 2003 Subject: [Expat-bugs] [ expat-Bugs-754228 ] Error running in multiprocesor machines Message-ID: Bugs item #754228, was opened at 2003-06-13 13:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=754228&group_id=10127 Category: None Group: Test Required Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Error running in multiprocesor machines Initial Comment: I have errors running in multiprocessor machines (and intenssive usage) that dissaperars when the parse operation is serialized. The errors even occurs if i do nothing in the handlers (only returning the control in each handler to the parser) Version 1.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=754228&group_id=10127 From noreply at sourceforge.net Fri Jun 13 15:12:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jun 13 17:12:24 2003 Subject: [Expat-bugs] [ expat-Bugs-754228 ] Error running in multiprocesor machines Message-ID: Bugs item #754228, was opened at 2003-06-13 16:56 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=754228&group_id=10127 Category: None Group: Test Required Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Error running in multiprocesor machines Initial Comment: I have errors running in multiprocessor machines (and intenssive usage) that dissaperars when the parse operation is serialized. The errors even occurs if i do nothing in the handlers (only returning the control in each handler to the parser) Version 1.2 ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-06-13 17:12 Message: Logged In: YES user_id=290026 Try with a later version. If that works, then use this version, as we do not branch older versions for bug fixes - or in other words: the fix for an older version is the newer one. Consequently, if this bug cannot be confirmed for the current version, then this report will be closed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=754228&group_id=10127 From noreply at sourceforge.net Mon Jun 16 05:22:53 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jun 16 07:22:58 2003 Subject: [Expat-bugs] [ expat-Bugs-753375 ] infinite parsing Message-ID: Bugs item #753375, was opened at 2003-06-12 15:50 Message generated for change (Comment added) made by mastercaster You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=753375&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregor SIegert (mastercaster) Assigned to: Nobody/Anonymous (nobody) Summary: infinite parsing Initial Comment: Hello all, I am receiving a SOAP response with content length > 2000 bytes, containing an array of 2 strings (2nd one very long). I traced the packets and found out that the response is split into 2 TCP packets, with the second one starting not well formed (in the middle of the second string) I would assume TCP binds them correctly together, but something goes wrong. I furthermore see that I receive a infinite parsing (using easysoap, newest version, expat 1.95.6) Smaller responses with all the same params are ok. Can someone help me out with this? I struggle here for days. Maybe a hint what I could do? Regards, Gregor ---------------------------------------------------------------------- >Comment By: Gregor SIegert (mastercaster) Date: 2003-06-16 11:22 Message: Logged In: YES user_id=764177 (closed) I found the problem, tx for the effort. I used #define XML_Unicode. Therefore the encoding was not recognized. (unknown encoding) ... tx for the effort ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-06-12 16:49 Message: Logged In: YES user_id=290026 I suggest you also submit a report to the EasySoap team. Lets' see what they have to say. It seems part of your error message is missing. ---------------------------------------------------------------------- Comment By: Gregor SIegert (mastercaster) Date: 2003-06-12 16:40 Message: Logged In: YES user_id=764177 You could be right, I did some more digging, easysoap tries to read 1024 Bytes from the HTTP payload and sends this to the expat parser (while(1) loop). So they might be responsible for the mess, because they are responsible to collect the buffer initially. Is this error message significant for this problem? : Error while parsing SOAP XML payload: u ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-06-12 15:56 Message: Logged In: YES user_id=290026 You need to be more specific. From what you tell it is impossible to make any conclusions as to what goes wrong. Does Expat parse correctly if you collect the complete response in a buffer before submitting it to Expat? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=753375&group_id=10127 From noreply at sourceforge.net Mon Jun 16 07:19:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jun 16 09:19:45 2003 Subject: [Expat-bugs] [ expat-Bugs-753375 ] infinite parsing Message-ID: Bugs item #753375, was opened at 2003-06-12 11:50 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=753375&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Gregor SIegert (mastercaster) Assigned to: Nobody/Anonymous (nobody) Summary: infinite parsing Initial Comment: Hello all, I am receiving a SOAP response with content length > 2000 bytes, containing an array of 2 strings (2nd one very long). I traced the packets and found out that the response is split into 2 TCP packets, with the second one starting not well formed (in the middle of the second string) I would assume TCP binds them correctly together, but something goes wrong. I furthermore see that I receive a infinite parsing (using easysoap, newest version, expat 1.95.6) Smaller responses with all the same params are ok. Can someone help me out with this? I struggle here for days. Maybe a hint what I could do? Regards, Gregor ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-06-16 09:19 Message: Logged In: YES user_id=290026 Does not seem to be a bug. Closed. ---------------------------------------------------------------------- Comment By: Gregor SIegert (mastercaster) Date: 2003-06-16 07:22 Message: Logged In: YES user_id=764177 (closed) I found the problem, tx for the effort. I used #define XML_Unicode. Therefore the encoding was not recognized. (unknown encoding) ... tx for the effort ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-06-12 12:49 Message: Logged In: YES user_id=290026 I suggest you also submit a report to the EasySoap team. Lets' see what they have to say. It seems part of your error message is missing. ---------------------------------------------------------------------- Comment By: Gregor SIegert (mastercaster) Date: 2003-06-12 12:40 Message: Logged In: YES user_id=764177 You could be right, I did some more digging, easysoap tries to read 1024 Bytes from the HTTP payload and sends this to the expat parser (while(1) loop). So they might be responsible for the mess, because they are responsible to collect the buffer initially. Is this error message significant for this problem? : Error while parsing SOAP XML payload: u ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-06-12 11:56 Message: Logged In: YES user_id=290026 You need to be more specific. From what you tell it is impossible to make any conclusions as to what goes wrong. Does Expat parse correctly if you collect the complete response in a buffer before submitting it to Expat? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=753375&group_id=10127 From noreply at sourceforge.net Thu Jun 19 09:36:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jun 19 11:37:17 2003 Subject: [Expat-bugs] [ expat-Bugs-676844 ] expat.h compile error: enum XML_Status Message-ID: Bugs item #676844, was opened at 2003-01-29 07:37 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=676844&group_id=10127 Category: Build control Group: None Status: Open Resolution: Fixed Priority: 9 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: expat.h compile error: enum XML_Status Initial Comment: c++ -DHAVE_CONFIG_H -I. -I. -I../../autocfg -g -O2 -c context.cpp -fPIC -DPIC -o .libs/context.lo In file included from parser.h:45, from guard.h:143, from context.cpp:45: /usr/include/expat.h:657: use of enum `XML_Status' without previous declaration /usr/include/expat.h:736: multiple definition of `enum XML_Status' when building sablotron. Hand editing the file to place the def of enum XML_Status before any references to it fixes the problem. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-06-19 08:36 Message: Logged In: NO in configure..:: checking XML::Parser perl module... no: documentation requires XML::Parser module and will not be built. checking whether to build under GPL... no checking whether to build the debugger... no checking where to find xml parser... expat (new) checking expat.h usability... no checking expat.h presence... yes configure: WARNING: expat.h: present but cannot be compiled configure: WARNING: expat.h: check for missing prerequisite headers? configure: WARNING: expat.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug-autoconf@gnu.org. ## configure: WARNING: ## ------------------------------------ ## checking for expat.h... yes checking whether expat.h is broken... yes configure: error: You probably have expat version 1.95.6. Please refer to: http://sourceforge.net/tracker/index.php?func=detail&aid=676844&group_id=10127&atid=110127 for a description of the problem. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-05-30 13:47 Message: Logged In: YES user_id=290026 Yes, the file to fix is expat.h. Two things you can do: 1) get the latest expat.h from CVS, or 2) use your editor to search expat.h for the first location where XML_STATUS is used and then move the definition of XML_STATUS to some location before that point. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-05-30 13:26 Message: Logged In: NO I have the same problem has other senders, but the fix is unclear as you did not indicate which file needs fixing (I assume expat.h) or line number to place the def of enum XML_Status. Please assume people are stupid.. checking expat.h usability... no checking expat.h presence... yes configure: WARNING: expat.h: present but cannot be compiled configure: WARNING: expat.h: check for missing prerequisite headers? configure: WARNING: expat.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug-autoconf@gnu.org. ## configure: WARNING: ## ------------------------------------ ## checking for expat.h... yes checking whether expat.h is broken... yes configure: error: You probably have expat version 1.95.6. Please refer to: http://sourceforge.net/tracker/index.php?func=detail&aid=676844&group_id=10127&atid=110127 for a description of the problem. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-05-08 06:18 Message: Logged In: YES user_id=290026 See above - original submission: Hand editing the file to place the def of enum XML_Status before any references to it fixes the problem. ---------------------------------------------------------------------- Comment By: Donche, Pieter (pdon) Date: 2003-05-08 00:20 Message: Logged In: YES user_id=774177 SUN Sparc Enterprise 2170 Solaris 2.8 gcc 3.2 Downloaded expat-1.95.6.tar.gz ./configure, make, make install OK Downloaded Sablot-0.98.tar.gz (Sablotron package, from www.gingerall.com) ./configure says: ... checking expat.h presence... yes expat.h: present but cannot be compiled expat.h: check for missing prerequisite headers? expat.h: proceeding with the preprocessor's result ##-------------------------------------------------## ## Report this to bug-autoconf@gnu.org ## ##-------------------------------------------------## checking for expat.h... yes checking wether expat.h is broken... yes error: You probably have expat version 1.95.6. Please refer to http://sourceforge.net/tracker/index.php? func=detail&aid=676844&group_id=10127&atid=110127 for a description of the problem -- Looked at that web-page. Don't see a solution there. Wath is the solution ? Pieter.Donche@ua.ac.be ---------------------------------------------------------------------- Comment By: Donche, Pieter (pdon) Date: 2003-05-08 00:20 Message: Logged In: YES user_id=774177 SUN Sparc Enterprise 2170 Solaris 2.8 gcc 3.2 Downloaded expat-1.95.6.tar.gz ./configure, make, make install OK Downloaded Sablot-0.98.tar.gz (Sablotron package, from www.gingerall.com) ./configure says: ... checking expat.h presence... yes expat.h: present but cannot be compiled expat.h: check for missing prerequisite headers? expat.h: proceeding with the preprocessor's result ##-------------------------------------------------## ## Report this to bug-autoconf@gnu.org ## ##-------------------------------------------------## checking for expat.h... yes checking wether expat.h is broken... yes error: You probably have expat version 1.95.6. Please refer to http://sourceforge.net/tracker/index.php? func=detail&aid=676844&group_id=10127&atid=110127 for a description of the problem -- Looked at that web-page. Don't see a solution there. Wath is the solution ? Pieter.Donche@ua.ac.be ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-04-16 06:59 Message: Logged In: YES user_id=290026 Changed priority to highest to make it more visible, so that double reporting incidents occur less frequently. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-03-27 02:42 Message: Logged In: NO Same problem and the same fix under Linux and gcc 2.95.2. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-03-07 03:20 Message: Logged In: NO same problem, same fix when building 1.95.6 on vms (just downloaded .tar.gz & processed - got the rpm, but don't know what to do with it - not an archive type I know how to handle on vms, or windows either) - chris.sharman@ccagroup.co.uk ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-28 18:03 Message: Logged In: YES user_id=290026 Strange - I had no problems with MS VC++ 6.0. Which service pack level have you applied? ---------------------------------------------------------------------- Comment By: Jacob Levy (jyljyljyl) Date: 2003-02-28 17:35 Message: Logged In: YES user_id=63723 This makes Expat 1.95.6 unusable for people who create libraries that depend on Expat but don't include their own copy of Expat. Sure, I can edit expat.h and fix it, but my users should not be expected to do that. For that reason I'm staying with Expat 1.95.5 until this problem is fixed. It'd be really nice if you could make Expat 1.95.7 soon.. In my case GCC 2.95.2 and VC++ 6.0 are complaining. ---------------------------------------------------------------------- Comment By: Melvyn Sopacua (nyvlem) Date: 2003-02-13 23:56 Message: Logged In: YES user_id=212431 Yes, that works. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-06 12:47 Message: Logged In: YES user_id=290026 But current CVS works for you, right? ---------------------------------------------------------------------- Comment By: Melvyn Sopacua (nyvlem) Date: 2003-02-06 12:17 Message: Logged In: YES user_id=212431 > So far only gcc3.2 has complained. Nope: /usr/local/include/expat.h:657: use of enum `XML_Status' without previous declaration /usr/local/include/expat.h:736: multiple definition of `enum XML_Status' gmake[2]: *** [context.lo] Error 1 gmake[2]: Leaving directory `/home/mdev/cvs/sablot/src/engine' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/mdev/cvs/sablot/src' gmake: *** [all-recursive] Error 1 $ gcc --version 2.95.3 ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-01-31 06:43 Message: Logged In: YES user_id=290026 It *is* fixed in CVS. Are you sure you checked out the right version, which is expat.h 1.51? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-01-31 02:34 Message: Logged In: NO I just got the same error, already fixed it. But don't understand why it isn't fixed in CVS ? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-01-29 10:44 Message: Logged In: YES user_id=3066 I've not checked the C89 standard yet, but Expat 1.95.6 is certainly dodgy in this case. ;-( The first draft of the C spec I found online certainly seemed to imply that any use of an incomplete enum is not allowed; I'm not likely to go out and buy a copy of the final spec to check further. ;-) As noted, this has been fixed in CVS. Fixed the summary to better indicate what this report is about, and lowered the priority to get it out of the way for maintainers. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-01-29 07:51 Message: Logged In: YES user_id=290026 So far only gcc3.2 has complained. Not sure if this is a bug, since most compilers accept it, but it has been fixed in CVS already anyway. Set resolution status to fixed, but leave open. There may be other users who would report this as a bug and I want them to see the open report instead of having duplicates created. Assigned to Fred - since he may know more about whether this truly is a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=676844&group_id=10127 From waynech at uclink.berkeley.edu Thu Jun 19 16:36:34 2003 From: waynech at uclink.berkeley.edu (Wayne Christopher) Date: Thu Jun 19 21:56:24 2003 Subject: [Expat-bugs] xml_status enum bug Message-ID: <3EF23AF2.4020706@uclink.berkeley.edu> I was including expat.h (expat-1.95.6) into a C++ file and compiling with gcc version 3.1. It complained because: In file included from readxml.C:9: ../expat-1.95.6/lib/expat.h:657: use of enum `XML_Status' without previous declaration ../expat-1.95.6/lib/expat.h:735: multiple definition of `enum XML_Status' ../expat-1.95.6/lib/expat.h:657: previous definition here I had to move a few declarations that used XML_Status down below the enum to make it work. The file is attached. Regards, Wayne -------------- next part -------------- /* Copyright (c) 1998, 1999, 2000 Thai Open Source Software Center Ltd See the file COPYING for copying permission. */ #ifndef XmlParse_INCLUDED #define XmlParse_INCLUDED 1 #ifdef __VMS /* 0 1 2 3 0 1 2 3 1234567890123456789012345678901 1234567890123456789012345678901 */ #define XML_SetProcessingInstructionHandler XML_SetProcessingInstrHandler #define XML_SetUnparsedEntityDeclHandler XML_SetUnparsedEntDeclHandler #define XML_SetStartNamespaceDeclHandler XML_SetStartNamespcDeclHandler #define XML_SetExternalEntityRefHandlerArg XML_SetExternalEntRefHandlerArg #endif #include #ifndef XMLPARSEAPI #if defined(_MSC_EXTENSIONS) && !defined(__BEOS__) && !defined(__CYGWIN__) #ifdef XML_STATIC #define XMLPARSEAPI(type) type __cdecl #else #define XMLPARSEAPI(type) __declspec(dllimport) type __cdecl #endif #else #define XMLPARSEAPI(type) type #endif #endif /* not defined XMLPARSEAPI */ #ifdef __cplusplus extern "C" { #endif #ifdef XML_UNICODE_WCHAR_T #define XML_UNICODE #endif struct XML_ParserStruct; typedef struct XML_ParserStruct *XML_Parser; #ifdef XML_UNICODE /* Information is UTF-16 encoded. */ #ifdef XML_UNICODE_WCHAR_T typedef wchar_t XML_Char; typedef wchar_t XML_LChar; #else typedef unsigned short XML_Char; typedef char XML_LChar; #endif /* XML_UNICODE_WCHAR_T */ #else /* Information is UTF-8 encoded. */ typedef char XML_Char; typedef char XML_LChar; #endif /* XML_UNICODE */ /* Should this be defined using stdbool.h when C99 is available? */ typedef unsigned char XML_Bool; #define XML_TRUE ((XML_Bool) 1) #define XML_FALSE ((XML_Bool) 0) enum XML_Error { XML_ERROR_NONE, XML_ERROR_NO_MEMORY, XML_ERROR_SYNTAX, XML_ERROR_NO_ELEMENTS, XML_ERROR_INVALID_TOKEN, XML_ERROR_UNCLOSED_TOKEN, XML_ERROR_PARTIAL_CHAR, XML_ERROR_TAG_MISMATCH, XML_ERROR_DUPLICATE_ATTRIBUTE, XML_ERROR_JUNK_AFTER_DOC_ELEMENT, XML_ERROR_PARAM_ENTITY_REF, XML_ERROR_UNDEFINED_ENTITY, XML_ERROR_RECURSIVE_ENTITY_REF, XML_ERROR_ASYNC_ENTITY, XML_ERROR_BAD_CHAR_REF, XML_ERROR_BINARY_ENTITY_REF, XML_ERROR_ATTRIBUTE_EXTERNAL_ENTITY_REF, XML_ERROR_MISPLACED_XML_PI, XML_ERROR_UNKNOWN_ENCODING, XML_ERROR_INCORRECT_ENCODING, XML_ERROR_UNCLOSED_CDATA_SECTION, XML_ERROR_EXTERNAL_ENTITY_HANDLING, XML_ERROR_NOT_STANDALONE, XML_ERROR_UNEXPECTED_STATE, XML_ERROR_ENTITY_DECLARED_IN_PE, XML_ERROR_FEATURE_REQUIRES_XML_DTD, XML_ERROR_CANT_CHANGE_FEATURE_ONCE_PARSING }; enum XML_Content_Type { XML_CTYPE_EMPTY = 1, XML_CTYPE_ANY, XML_CTYPE_MIXED, XML_CTYPE_NAME, XML_CTYPE_CHOICE, XML_CTYPE_SEQ }; enum XML_Content_Quant { XML_CQUANT_NONE, XML_CQUANT_OPT, XML_CQUANT_REP, XML_CQUANT_PLUS }; /* If type == XML_CTYPE_EMPTY or XML_CTYPE_ANY, then quant will be XML_CQUANT_NONE, and the other fields will be zero or NULL. If type == XML_CTYPE_MIXED, then quant will be NONE or REP and numchildren will contain number of elements that may be mixed in and children point to an array of XML_Content cells that will be all of XML_CTYPE_NAME type with no quantification. If type == XML_CTYPE_NAME, then the name points to the name, and the numchildren field will be zero and children will be NULL. The quant fields indicates any quantifiers placed on the name. CHOICE and SEQ will have name NULL, the number of children in numchildren and children will point, recursively, to an array of XML_Content cells. The EMPTY, ANY, and MIXED types will only occur at top level. */ typedef struct XML_cp XML_Content; struct XML_cp { enum XML_Content_Type type; enum XML_Content_Quant quant; XML_Char * name; unsigned int numchildren; XML_Content * children; }; /* This is called for an element declaration. See above for description of the model argument. It's the caller's responsibility to free model when finished with it. */ typedef void (*XML_ElementDeclHandler) (void *userData, const XML_Char *name, XML_Content *model); XMLPARSEAPI(void) XML_SetElementDeclHandler(XML_Parser parser, XML_ElementDeclHandler eldecl); /* The Attlist declaration handler is called for *each* attribute. So a single Attlist declaration with multiple attributes declared will generate multiple calls to this handler. The "default" parameter may be NULL in the case of the "#IMPLIED" or "#REQUIRED" keyword. The "isrequired" parameter will be true and the default value will be NULL in the case of "#REQUIRED". If "isrequired" is true and default is non-NULL, then this is a "#FIXED" default. */ typedef void (*XML_AttlistDeclHandler) (void *userData, const XML_Char *elname, const XML_Char *attname, const XML_Char *att_type, const XML_Char *dflt, int isrequired); XMLPARSEAPI(void) XML_SetAttlistDeclHandler(XML_Parser parser, XML_AttlistDeclHandler attdecl); /* The XML declaration handler is called for *both* XML declarations and text declarations. The way to distinguish is that the version parameter will be NULL for text declarations. The encoding parameter may be NULL for XML declarations. The standalone parameter will be -1, 0, or 1 indicating respectively that there was no standalone parameter in the declaration, that it was given as no, or that it was given as yes. */ typedef void (*XML_XmlDeclHandler) (void *userData, const XML_Char *version, const XML_Char *encoding, int standalone); XMLPARSEAPI(void) XML_SetXmlDeclHandler(XML_Parser parser, XML_XmlDeclHandler xmldecl); typedef struct { void *(*malloc_fcn)(size_t size); void *(*realloc_fcn)(void *ptr, size_t size); void (*free_fcn)(void *ptr); } XML_Memory_Handling_Suite; /* Constructs a new parser; encoding is the encoding specified by the external protocol or NULL if there is none specified. */ XMLPARSEAPI(XML_Parser) XML_ParserCreate(const XML_Char *encoding); /* Constructs a new parser and namespace processor. Element type names and attribute names that belong to a namespace will be expanded; unprefixed attribute names are never expanded; unprefixed element type names are expanded only if there is a default namespace. The expanded name is the concatenation of the namespace URI, the namespace separator character, and the local part of the name. If the namespace separator is '\0' then the namespace URI and the local part will be concatenated without any separator. When a namespace is not declared, the name and prefix will be passed through without expansion. */ XMLPARSEAPI(XML_Parser) XML_ParserCreateNS(const XML_Char *encoding, XML_Char namespaceSeparator); /* Constructs a new parser using the memory management suite referred to by memsuite. If memsuite is NULL, then use the standard library memory suite. If namespaceSeparator is non-NULL it creates a parser with namespace processing as described above. The character pointed at will serve as the namespace separator. All further memory operations used for the created parser will come from the given suite. */ XMLPARSEAPI(XML_Parser) XML_ParserCreate_MM(const XML_Char *encoding, const XML_Memory_Handling_Suite *memsuite, const XML_Char *namespaceSeparator); /* Prepare a parser object to be re-used. This is particularly valuable when memory allocation overhead is disproportionatly high, such as when a large number of small documnents need to be parsed. All handlers are cleared from the parser, except for the unknownEncodingHandler. The parser's external state is re-initialized except for the values of ns and ns_triplets. Added in Expat 1.95.3. */ XMLPARSEAPI(XML_Bool) XML_ParserReset(XML_Parser parser, const XML_Char *encoding); /* atts is array of name/value pairs, terminated by 0; names and values are 0 terminated. */ typedef void (*XML_StartElementHandler)(void *userData, const XML_Char *name, const XML_Char **atts); typedef void (*XML_EndElementHandler)(void *userData, const XML_Char *name); /* s is not 0 terminated. */ typedef void (*XML_CharacterDataHandler)(void *userData, const XML_Char *s, int len); /* target and data are 0 terminated */ typedef void (*XML_ProcessingInstructionHandler)(void *userData, const XML_Char *target, const XML_Char *data); /* data is 0 terminated */ typedef void (*XML_CommentHandler)(void *userData, const XML_Char *data); typedef void (*XML_StartCdataSectionHandler)(void *userData); typedef void (*XML_EndCdataSectionHandler)(void *userData); /* This is called for any characters in the XML document for which there is no applicable handler. This includes both characters that are part of markup which is of a kind that is not reported (comments, markup declarations), or characters that are part of a construct which could be reported but for which no handler has been supplied. The characters are passed exactly as they were in the XML document except that they will be encoded in UTF-8 or UTF-16. Line boundaries are not normalized. Note that a byte order mark character is not passed to the default handler. There are no guarantees about how characters are divided between calls to the default handler: for example, a comment might be split between multiple calls. */ typedef void (*XML_DefaultHandler)(void *userData, const XML_Char *s, int len); /* This is called for the start of the DOCTYPE declaration, before any DTD or internal subset is parsed. */ typedef void (*XML_StartDoctypeDeclHandler)(void *userData, const XML_Char *doctypeName, const XML_Char *sysid, const XML_Char *pubid, int has_internal_subset); /* This is called for the start of the DOCTYPE declaration when the closing > is encountered, but after processing any external subset. */ typedef void (*XML_EndDoctypeDeclHandler)(void *userData); /* This is called for entity declarations. The is_parameter_entity argument will be non-zero if the entity is a parameter entity, zero otherwise. For internal entities (), value will be non-NULL and systemId, publicID, and notationName will be NULL. The value string is NOT nul-terminated; the length is provided in the value_length argument. Since it is legal to have zero-length values, do not use this argument to test for internal entities. For external entities, value will be NULL and systemId will be non-NULL. The publicId argument will be NULL unless a public identifier was provided. The notationName argument will have a non-NULL value only for unparsed entity declarations. Note that is_parameter_entity can't be changed to XML_Bool, since that would break binary compatibility. */ typedef void (*XML_EntityDeclHandler) (void *userData, const XML_Char *entityName, int is_parameter_entity, const XML_Char *value, int value_length, const XML_Char *base, const XML_Char *systemId, const XML_Char *publicId, const XML_Char *notationName); XMLPARSEAPI(void) XML_SetEntityDeclHandler(XML_Parser parser, XML_EntityDeclHandler handler); /* OBSOLETE -- OBSOLETE -- OBSOLETE This handler has been superceded by the EntityDeclHandler above. It is provided here for backward compatibility. This is called for a declaration of an unparsed (NDATA) entity. The base argument is whatever was set by XML_SetBase. The entityName, systemId and notationName arguments will never be NULL. The other arguments may be. */ typedef void (*XML_UnparsedEntityDeclHandler)(void *userData, const XML_Char *entityName, const XML_Char *base, const XML_Char *systemId, const XML_Char *publicId, const XML_Char *notationName); /* This is called for a declaration of notation. The base argument is whatever was set by XML_SetBase. The notationName will never be NULL. The other arguments can be. */ typedef void (*XML_NotationDeclHandler)(void *userData, const XML_Char *notationName, const XML_Char *base, const XML_Char *systemId, const XML_Char *publicId); /* When namespace processing is enabled, these are called once for each namespace declaration. The call to the start and end element handlers occur between the calls to the start and end namespace declaration handlers. For an xmlns attribute, prefix will be NULL. For an xmlns="" attribute, uri will be NULL. */ typedef void (*XML_StartNamespaceDeclHandler)(void *userData, const XML_Char *prefix, const XML_Char *uri); typedef void (*XML_EndNamespaceDeclHandler)(void *userData, const XML_Char *prefix); /* This is called if the document is not standalone, that is, it has an external subset or a reference to a parameter entity, but does not have standalone="yes". If this handler returns XML_STATUS_ERROR, then processing will not continue, and the parser will return a XML_ERROR_NOT_STANDALONE error. If parameter entity parsing is enabled, then in addition to the conditions above this handler will only be called if the referenced entity was actually read. */ typedef int (*XML_NotStandaloneHandler)(void *userData); /* This is called for a reference to an external parsed general entity. The referenced entity is not automatically parsed. The application can parse it immediately or later using XML_ExternalEntityParserCreate. The parser argument is the parser parsing the entity containing the reference; it can be passed as the parser argument to XML_ExternalEntityParserCreate. The systemId argument is the system identifier as specified in the entity declaration; it will not be NULL. The base argument is the system identifier that should be used as the base for resolving systemId if systemId was relative; this is set by XML_SetBase; it may be NULL. The publicId argument is the public identifier as specified in the entity declaration, or NULL if none was specified; the whitespace in the public identifier will have been normalized as required by the XML spec. The context argument specifies the parsing context in the format expected by the context argument to XML_ExternalEntityParserCreate; context is valid only until the handler returns, so if the referenced entity is to be parsed later, it must be copied. context is NULL only when the entity is a parameter entity. The handler should return XML_STATUS_ERROR if processing should not continue because of a fatal error in the handling of the external entity. In this case the calling parser will return an XML_ERROR_EXTERNAL_ENTITY_HANDLING error. Note that unlike other handlers the first argument is the parser, not userData. */ typedef int (*XML_ExternalEntityRefHandler)(XML_Parser parser, const XML_Char *context, const XML_Char *base, const XML_Char *systemId, const XML_Char *publicId); /* This is called in two situations: 1) An entity reference is encountered for which no declaration has been read *and* this is not an error. 2) An internal entity reference is read, but not expanded, because XML_SetDefaultHandler has been called. Note: skipped parameter entities in declarations and skipped general entities in attribute values cannot be reported, because the event would be out of sync with the reporting of the declarations or attribute values */ typedef void (*XML_SkippedEntityHandler)(void *userData, const XML_Char *entityName, int is_parameter_entity); /* This structure is filled in by the XML_UnknownEncodingHandler to provide information to the parser about encodings that are unknown to the parser. The map[b] member gives information about byte sequences whose first byte is b. If map[b] is c where c is >= 0, then b by itself encodes the Unicode scalar value c. If map[b] is -1, then the byte sequence is malformed. If map[b] is -n, where n >= 2, then b is the first byte of an n-byte sequence that encodes a single Unicode scalar value. The data member will be passed as the first argument to the convert function. The convert function is used to convert multibyte sequences; s will point to a n-byte sequence where map[(unsigned char)*s] == -n. The convert function must return the Unicode scalar value represented by this byte sequence or -1 if the byte sequence is malformed. The convert function may be NULL if the encoding is a single-byte encoding, that is if map[b] >= -1 for all bytes b. When the parser is finished with the encoding, then if release is not NULL, it will call release passing it the data member; once release has been called, the convert function will not be called again. Expat places certain restrictions on the encodings that are supported using this mechanism. 1. Every ASCII character that can appear in a well-formed XML document, other than the characters $@\^`{}~ must be represented by a single byte, and that byte must be the same byte that represents that character in ASCII. 2. No character may require more than 4 bytes to encode. 3. All characters encoded must have Unicode scalar values <= 0xFFFF, (i.e., characters that would be encoded by surrogates in UTF-16 are not allowed). Note that this restriction doesn't apply to the built-in support for UTF-8 and UTF-16. 4. No Unicode character may be encoded by more than one distinct sequence of bytes. */ typedef struct { int map[256]; void *data; int (*convert)(void *data, const char *s); void (*release)(void *data); } XML_Encoding; /* This is called for an encoding that is unknown to the parser. The encodingHandlerData argument is that which was passed as the second argument to XML_SetUnknownEncodingHandler. The name argument gives the name of the encoding as specified in the encoding declaration. If the callback can provide information about the encoding, it must fill in the XML_Encoding structure, and return XML_STATUS_OK. Otherwise it must return XML_STATUS_ERROR. If info does not describe a suitable encoding, then the parser will return an XML_UNKNOWN_ENCODING error. */ typedef int (*XML_UnknownEncodingHandler)(void *encodingHandlerData, const XML_Char *name, XML_Encoding *info); XMLPARSEAPI(void) XML_SetElementHandler(XML_Parser parser, XML_StartElementHandler start, XML_EndElementHandler end); XMLPARSEAPI(void) XML_SetStartElementHandler(XML_Parser, XML_StartElementHandler); XMLPARSEAPI(void) XML_SetEndElementHandler(XML_Parser, XML_EndElementHandler); XMLPARSEAPI(void) XML_SetCharacterDataHandler(XML_Parser parser, XML_CharacterDataHandler handler); XMLPARSEAPI(void) XML_SetProcessingInstructionHandler(XML_Parser parser, XML_ProcessingInstructionHandler handler); XMLPARSEAPI(void) XML_SetCommentHandler(XML_Parser parser, XML_CommentHandler handler); XMLPARSEAPI(void) XML_SetCdataSectionHandler(XML_Parser parser, XML_StartCdataSectionHandler start, XML_EndCdataSectionHandler end); XMLPARSEAPI(void) XML_SetStartCdataSectionHandler(XML_Parser parser, XML_StartCdataSectionHandler start); XMLPARSEAPI(void) XML_SetEndCdataSectionHandler(XML_Parser parser, XML_EndCdataSectionHandler end); /* This sets the default handler and also inhibits expansion of internal entities. These entity references will be passed to the default handler, or to the skipped entity handler, if one is set. */ XMLPARSEAPI(void) XML_SetDefaultHandler(XML_Parser parser, XML_DefaultHandler handler); /* This sets the default handler but does not inhibit expansion of internal entities. The entity reference will not be passed to the default handler. */ XMLPARSEAPI(void) XML_SetDefaultHandlerExpand(XML_Parser parser, XML_DefaultHandler handler); XMLPARSEAPI(void) XML_SetDoctypeDeclHandler(XML_Parser parser, XML_StartDoctypeDeclHandler start, XML_EndDoctypeDeclHandler end); XMLPARSEAPI(void) XML_SetStartDoctypeDeclHandler(XML_Parser parser, XML_StartDoctypeDeclHandler start); XMLPARSEAPI(void) XML_SetEndDoctypeDeclHandler(XML_Parser parser, XML_EndDoctypeDeclHandler end); XMLPARSEAPI(void) XML_SetUnparsedEntityDeclHandler(XML_Parser parser, XML_UnparsedEntityDeclHandler handler); XMLPARSEAPI(void) XML_SetNotationDeclHandler(XML_Parser parser, XML_NotationDeclHandler handler); XMLPARSEAPI(void) XML_SetNamespaceDeclHandler(XML_Parser parser, XML_StartNamespaceDeclHandler start, XML_EndNamespaceDeclHandler end); XMLPARSEAPI(void) XML_SetStartNamespaceDeclHandler(XML_Parser parser, XML_StartNamespaceDeclHandler start); XMLPARSEAPI(void) XML_SetEndNamespaceDeclHandler(XML_Parser parser, XML_EndNamespaceDeclHandler end); XMLPARSEAPI(void) XML_SetNotStandaloneHandler(XML_Parser parser, XML_NotStandaloneHandler handler); XMLPARSEAPI(void) XML_SetExternalEntityRefHandler(XML_Parser parser, XML_ExternalEntityRefHandler handler); /* If a non-NULL value for arg is specified here, then it will be passed as the first argument to the external entity ref handler instead of the parser object. */ XMLPARSEAPI(void) XML_SetExternalEntityRefHandlerArg(XML_Parser, void *arg); XMLPARSEAPI(void) XML_SetSkippedEntityHandler(XML_Parser parser, XML_SkippedEntityHandler handler); XMLPARSEAPI(void) XML_SetUnknownEncodingHandler(XML_Parser parser, XML_UnknownEncodingHandler handler, void *encodingHandlerData); /* This can be called within a handler for a start element, end element, processing instruction or character data. It causes the corresponding markup to be passed to the default handler. */ XMLPARSEAPI(void) XML_DefaultCurrent(XML_Parser parser); /* If do_nst is non-zero, and namespace processing is in effect, and a name has a prefix (i.e. an explicit namespace qualifier) then that name is returned as a triplet in a single string separated by the separator character specified when the parser was created: URI + sep + local_name + sep + prefix. If do_nst is zero, then namespace information is returned in the default manner (URI + sep + local_name) whether or not the name has a prefix. Note: Calling XML_SetReturnNSTriplet after XML_Parse or XML_ParseBuffer has no effect. */ XMLPARSEAPI(void) XML_SetReturnNSTriplet(XML_Parser parser, int do_nst); /* This value is passed as the userData argument to callbacks. */ XMLPARSEAPI(void) XML_SetUserData(XML_Parser parser, void *userData); /* Returns the last value set by XML_SetUserData or NULL. */ #define XML_GetUserData(parser) (*(void **)(parser)) /* If this function is called, then the parser will be passed as the first argument to callbacks instead of userData. The userData will still be accessible using XML_GetUserData. */ XMLPARSEAPI(void) XML_UseParserAsHandlerArg(XML_Parser parser); /* If useDTD == XML_TRUE is passed to this function, then the parser will assume that there is an external subset, even if none is specified in the document. In such a case the parser will call the externalEntityRefHandler with a value of NULL for the systemId argument (the publicId and context arguments will be NULL as well). Note: If this function is called, then this must be done before the first call to XML_Parse or XML_ParseBuffer, since it will have no effect after that. Returns XML_ERROR_CANT_CHANGE_FEATURE_ONCE_PARSING. Note: If the document does not have a DOCTYPE declaration at all, then startDoctypeDeclHandler and endDoctypeDeclHandler will not be called, despite an external subset being parsed. Note: If XML_DTD is not defined when Expat is compiled, returns XML_ERROR_FEATURE_REQUIRES_XML_DTD. */ XMLPARSEAPI(enum XML_Error) XML_UseForeignDTD(XML_Parser parser, XML_Bool useDTD); XMLPARSEAPI(const XML_Char *) XML_GetBase(XML_Parser parser); /* Returns the number of the attribute/value pairs passed in last call to the XML_StartElementHandler that were specified in the start-tag rather than defaulted. Each attribute/value pair counts as 2; thus this correspondds to an index into the atts array passed to the XML_StartElementHandler. */ XMLPARSEAPI(int) XML_GetSpecifiedAttributeCount(XML_Parser parser); /* Returns the index of the ID attribute passed in the last call to XML_StartElementHandler, or -1 if there is no ID attribute. Each attribute/value pair counts as 2; thus this correspondds to an index into the atts array passed to the XML_StartElementHandler. */ XMLPARSEAPI(int) XML_GetIdAttributeIndex(XML_Parser parser); /* Parses some input. Returns XML_STATUS_ERROR if a fatal error is detected. The last call to XML_Parse must have isFinal true; len may be zero for this call (or any other). The XML_Status enum gives the possible return values for the XML_Parse and XML_ParseBuffer functions. Though the return values for these functions has always been described as a Boolean value, the implementation, at least for the 1.95.x series, has always returned exactly one of these values. The preprocessor #defines are included so this stanza can be added to code that still needs to support older versions of Expat 1.95.x: #ifndef XML_STATUS_OK #define XML_STATUS_OK 1 #define XML_STATUS_ERROR 0 #endif Otherwise, the #define hackery is quite ugly and would have been dropped. */ enum XML_Status { XML_STATUS_ERROR = 0, #define XML_STATUS_ERROR XML_STATUS_ERROR XML_STATUS_OK = 1 #define XML_STATUS_OK XML_STATUS_OK }; XMLPARSEAPI(enum XML_Status) XML_Parse(XML_Parser parser, const char *s, int len, int isFinal); XMLPARSEAPI(void *) XML_GetBuffer(XML_Parser parser, int len); XMLPARSEAPI(enum XML_Status) XML_ParseBuffer(XML_Parser parser, int len, int isFinal); /* Creates an XML_Parser object that can parse an external general entity; context is a '\0'-terminated string specifying the parse context; encoding is a '\0'-terminated string giving the name of the externally specified encoding, or NULL if there is no externally specified encoding. The context string consists of a sequence of tokens separated by formfeeds (\f); a token consisting of a name specifies that the general entity of the name is open; a token of the form prefix=uri specifies the namespace for a particular prefix; a token of the form =uri specifies the default namespace. This can be called at any point after the first call to an ExternalEntityRefHandler so longer as the parser has not yet been freed. The new parser is completely independent and may safely be used in a separate thread. The handlers and userData are initialized from the parser argument. Returns NULL if out of memory. Otherwise returns a new XML_Parser object. */ XMLPARSEAPI(XML_Parser) XML_ExternalEntityParserCreate(XML_Parser parser, const XML_Char *context, const XML_Char *encoding); enum XML_ParamEntityParsing { XML_PARAM_ENTITY_PARSING_NEVER, XML_PARAM_ENTITY_PARSING_UNLESS_STANDALONE, XML_PARAM_ENTITY_PARSING_ALWAYS }; /* This is equivalent to supplying an encoding argument to XML_ParserCreate. On success XML_SetEncoding returns non-zero, zero otherwise. Note: Calling XML_SetEncoding after XML_Parse or XML_ParseBuffer has no effect and returns XML_STATUS_ERROR. */ XMLPARSEAPI(enum XML_Status) XML_SetEncoding(XML_Parser parser, const XML_Char *encoding); /* Sets the base to be used for resolving relative URIs in system identifiers in declarations. Resolving relative identifiers is left to the application: this value will be passed through as the base argument to the XML_ExternalEntityRefHandler, XML_NotationDeclHandler and XML_UnparsedEntityDeclHandler. The base argument will be copied. Returns XML_STATUS_ERROR if out of memory, XML_STATUS_OK otherwise. */ XMLPARSEAPI(enum XML_Status) XML_SetBase(XML_Parser parser, const XML_Char *base); /* Controls parsing of parameter entities (including the external DTD subset). If parsing of parameter entities is enabled, then references to external parameter entities (including the external DTD subset) will be passed to the handler set with XML_SetExternalEntityRefHandler. The context passed will be 0. Unlike external general entities, external parameter entities can only be parsed synchronously. If the external parameter entity is to be parsed, it must be parsed during the call to the external entity ref handler: the complete sequence of XML_ExternalEntityParserCreate, XML_Parse/XML_ParseBuffer and XML_ParserFree calls must be made during this call. After XML_ExternalEntityParserCreate has been called to create the parser for the external parameter entity (context must be 0 for this call), it is illegal to make any calls on the old parser until XML_ParserFree has been called on the newly created parser. If the library has been compiled without support for parameter entity parsing (ie without XML_DTD being defined), then XML_SetParamEntityParsing will return 0 if parsing of parameter entities is requested; otherwise it will return non-zero. Note: If XML_SetParamEntityParsing is called after XML_Parse or XML_ParseBuffer, then it has no effect and will always return 0. */ XMLPARSEAPI(int) XML_SetParamEntityParsing(XML_Parser parser, enum XML_ParamEntityParsing parsing); /* If XML_Parse or XML_ParseBuffer have returned XML_STATUS_ERROR, then XML_GetErrorCode returns information about the error. */ XMLPARSEAPI(enum XML_Error) XML_GetErrorCode(XML_Parser parser); /* These functions return information about the current parse location. They may be called from any callback called to report some parse event; in this case the location is the location of the first of the sequence of characters that generated the event. They may also be called after returning from a call to XML_Parse or XML_ParseBuffer. If the return value is XML_STATUS_ERROR then the location is the location of the character at which the error was detected; otherwise the location is the location of the last parse event, as described above. */ XMLPARSEAPI(int) XML_GetCurrentLineNumber(XML_Parser parser); XMLPARSEAPI(int) XML_GetCurrentColumnNumber(XML_Parser parser); XMLPARSEAPI(long) XML_GetCurrentByteIndex(XML_Parser parser); /* Return the number of bytes in the current event. Returns 0 if the event is in an internal entity. */ XMLPARSEAPI(int) XML_GetCurrentByteCount(XML_Parser parser); /* If XML_CONTEXT_BYTES is defined, returns the input buffer, sets the integer pointed to by offset to the offset within this buffer of the current parse position, and sets the integer pointed to by size to the size of this buffer (the number of input bytes). Otherwise returns a NULL pointer. Also returns a NULL pointer if a parse isn't active. NOTE: The character pointer returned should not be used outside the handler that makes the call. */ XMLPARSEAPI(const char *) XML_GetInputContext(XML_Parser parser, int *offset, int *size); /* For backwards compatibility with previous versions. */ #define XML_GetErrorLineNumber XML_GetCurrentLineNumber #define XML_GetErrorColumnNumber XML_GetCurrentColumnNumber #define XML_GetErrorByteIndex XML_GetCurrentByteIndex /* Frees the content model passed to the element declaration handler */ XMLPARSEAPI(void) XML_FreeContentModel(XML_Parser parser, XML_Content *model); /* Exposing the memory handling functions used in Expat */ XMLPARSEAPI(void *) XML_MemMalloc(XML_Parser parser, size_t size); XMLPARSEAPI(void *) XML_MemRealloc(XML_Parser parser, void *ptr, size_t size); XMLPARSEAPI(void) XML_MemFree(XML_Parser parser, void *ptr); /* Frees memory used by the parser. */ XMLPARSEAPI(void) XML_ParserFree(XML_Parser parser); /* Returns a string describing the error. */ XMLPARSEAPI(const XML_LChar *) XML_ErrorString(enum XML_Error code); /* Return a string containing the version number of this expat */ XMLPARSEAPI(const XML_LChar *) XML_ExpatVersion(void); typedef struct { int major; int minor; int micro; } XML_Expat_Version; /* Return an XML_Expat_Version structure containing numeric version number information for this version of expat. */ XMLPARSEAPI(XML_Expat_Version) XML_ExpatVersionInfo(void); /* Added in Expat 1.95.5. */ enum XML_FeatureEnum { XML_FEATURE_END = 0, XML_FEATURE_UNICODE, XML_FEATURE_UNICODE_WCHAR_T, XML_FEATURE_DTD, XML_FEATURE_CONTEXT_BYTES, XML_FEATURE_MIN_SIZE, XML_FEATURE_SIZEOF_XML_CHAR, XML_FEATURE_SIZEOF_XML_LCHAR /* Additional features must be added to the end of this enum. */ }; typedef struct { enum XML_FeatureEnum feature; const XML_LChar *name; long int value; } XML_Feature; XMLPARSEAPI(const XML_Feature *) XML_GetFeatureList(void); /* Expat follows the GNU/Linux convention of odd number minor version for beta/development releases and even number minor version for stable releases. Micro is bumped with each release, and set to 0 with each change to major or minor version. */ #define XML_MAJOR_VERSION 1 #define XML_MINOR_VERSION 95 #define XML_MICRO_VERSION 6 #ifdef __cplusplus } #endif #endif /* not XmlParse_INCLUDED */ From karl at waclawek.net Thu Jun 19 23:19:29 2003 From: karl at waclawek.net (Karl Waclawek) Date: Thu Jun 19 22:17:04 2003 Subject: [Expat-bugs] xml_status enum bug References: <3EF23AF2.4020706@uclink.berkeley.edu> Message-ID: <002a01c336d2$611230c0$0207a8c0@karl> > I was including expat.h (expat-1.95.6) into a C++ file and compiling > with gcc version 3.1. It complained because: > > In file included from readxml.C:9: > ../expat-1.95.6/lib/expat.h:657: use of enum `XML_Status' without previous > declaration > ../expat-1.95.6/lib/expat.h:735: multiple definition of `enum XML_Status' > ../expat-1.95.6/lib/expat.h:657: previous definition here > > I had to move a few declarations that used XML_Status down below the > enum to make it work. The file is attached. > This "bug" has long been fixed in CVS. Not all compilers have a problem with it. Karl