From noreply at sourceforge.net Thu Jun 1 22:33:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Jun 2006 13:33:18 -0700 Subject: [Expat-bugs] [ expat-Bugs-1490371 ] additional conig for INSTALL_ROOT Message-ID: Bugs item #1490371, was opened at 2006-05-17 09:36 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1490371&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: www.libexpat.org Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: additional conig for INSTALL_ROOT Initial Comment: When I install expat 2.0.0, it shows me the following error always. but expat 1.9.5 is fine. camelot# make install make: Fatal error in reader: Makefile, line 48: Unexpected end of line seen the line 48 is as following: 47:ifndef INSTALL_ROOT 48:INSTALL_ROOT=$(DESTDIR) 49:if ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-06-01 13:33 Message: Logged In: NO I'm having the same problem building in a Solaris 10 on Sparc environment. I'm using 2.0.0 from a .gz tarball. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-05-17 10:19 Message: Logged In: YES user_id=290026 In which environment do you try to build expat? Is this a checkout from CVD or did you download the .gz archive? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1490371&group_id=10127 From noreply at sourceforge.net Thu Jun 1 23:01:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Jun 2006 14:01:54 -0700 Subject: [Expat-bugs] [ expat-Bugs-1490371 ] additional conig for INSTALL_ROOT Message-ID: Bugs item #1490371, was opened at 2006-05-17 12:36 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1490371&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: www.libexpat.org Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: additional conig for INSTALL_ROOT Initial Comment: When I install expat 2.0.0, it shows me the following error always. but expat 1.9.5 is fine. camelot# make install make: Fatal error in reader: Makefile, line 48: Unexpected end of line seen the line 48 is as following: 47:ifndef INSTALL_ROOT 48:INSTALL_ROOT=$(DESTDIR) 49:if ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-06-01 17:01 Message: Logged In: YES user_id=290026 Could you please try a checkout from CVS. If you still have a problem, then maybe "make" on your system is too old, or otherwise different. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-06-01 16:33 Message: Logged In: NO I'm having the same problem building in a Solaris 10 on Sparc environment. I'm using 2.0.0 from a .gz tarball. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-05-17 13:19 Message: Logged In: YES user_id=290026 In which environment do you try to build expat? Is this a checkout from CVD or did you download the .gz archive? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1490371&group_id=10127 From noreply at sourceforge.net Thu Jun 1 23:04:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Jun 2006 14:04:04 -0700 Subject: [Expat-bugs] [ expat-Bugs-1476160 ] __cdecl shouldn't be selected by use of MS extensions Message-ID: Bugs item #1476160, was opened at 2006-04-25 10:17 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1476160&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: Platform Specific Status: Open Resolution: Accepted Priority: 5 Submitted By: Mighty Toenail (mighty_toenail) Assigned to: Karl Waclawek (kwaclaw) Summary: __cdecl shouldn't be selected by use of MS extensions Initial Comment: Expat 2.0.0 I find that in my builds _MSC_EXTENSIONS is not defined, probably because I build with Microsoft extensions switched off. The result of this is that XMLCALL does not get defined to __cdecl, so when I try to link to a __fastcall project I can't resolve the symbols. My workaround has been to change expat_external.h as follows: #if defined(XML_USE_MSC_EXTENSIONS) #define XMLCALL __cdecl becomes #if defined(XML_USE_MSC_EXTENSIONS) || defined (_WIN32) || defined (_WIN64) #define XMLCALL __cdecl which is easy to apply and good enough for my purposes. I am not a Windows expert, so there may be better ways, e.g. a symbol that encompases both _WIN32 and _WIN64. However, I think that you should be specifying the Windows calling convention based on whether you are building on Windows, not on whether you are building with Microsoft extensions. XML_USE_MSC_EXTENSIONS is used in other places in your code, but perhaps in these other places it really is appropriate to make the decision based on whether MS extensions are switched on (again, I'm not a Windows expert so I'm not sure). ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-06-01 17:04 Message: Logged In: YES user_id=290026 If you have no objections I'll commit the fix I described in my last message. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-05-26 12:11 Message: Logged In: YES user_id=290026 Does it work for you to use #if defined(_MSC_VER) instead of #if defined(XML_USE_MSC_EXTENSIONS) ? Looking at the other instances of #if defined(XML_USE_MSC_EXTENSIONS) I think they might be OK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1476160&group_id=10127 From noreply at sourceforge.net Thu Jun 1 23:06:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Jun 2006 14:06:56 -0700 Subject: [Expat-bugs] [ expat-Bugs-1463666 ] expat-1.95.8 linking fails on aix Message-ID: Bugs item #1463666, was opened at 2006-04-03 12:34 Message generated for change (Settings changed) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1463666&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open >Resolution: Rejected Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Greg Stein (gstein) Summary: expat-1.95.8 linking fails on aix Initial Comment: *** expat-1.95.8/Makefile.in Mon Apr 3 11:21:48 2006 --- expat-1.95.8/Makefile.in Mon Apr 3 11:22:19 2006 *************** *** 103,109 **** LIBTOOL = @LIBTOOL@ INCLUDES = -I$(srcdir)/lib -I. ! LDFLAGS = @LDFLAGS@ CPPFLAGS = @CPPFLAGS@ CFLAGS = @CFLAGS@ -DHAVE_EXPAT_CONFIG_H VSNFLAG = -version-info @LIBCURRENT@:@LIBREVISION@:@LIBAGE@ --- 103,109 ---- LIBTOOL = @LIBTOOL@ INCLUDES = -I$(srcdir)/lib -I. ! LDFLAGS = @LDFLAGS@ -static CPPFLAGS = @CPPFLAGS@ CFLAGS = @CFLAGS@ -DHAVE_EXPAT_CONFIG_H VSNFLAG = -version-info @LIBCURRENT@:@LIBREVISION@:@LIBAGE@ ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-06-01 17:06 Message: Logged In: YES user_id=290026 Greg, can you clear this up? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-04-03 19:05 Message: Logged In: YES user_id=290026 I am not the Unix build expert here, and don't know what effect this has on builds for other platforms. AFAIK, Expat should build and link OK on AIX. You should contact Greg Stein about it. Have you tried Expat 2.0 yet? Does the problem still exist? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-04-03 18:24 Message: Logged In: NO It fixes Makefile.in so that the resultant expat library can be linked into applications on aix. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-04-03 15:45 Message: Logged In: YES user_id=290026 I don't understand. What does the diff above describe? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1463666&group_id=10127 From noreply at sourceforge.net Fri Jun 2 11:23:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Jun 2006 02:23:22 -0700 Subject: [Expat-bugs] [ expat-Bugs-1476160 ] __cdecl shouldn't be selected by use of MS extensions Message-ID: Bugs item #1476160, was opened at 2006-04-25 14:17 Message generated for change (Comment added) made by mighty_toenail You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1476160&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: Platform Specific Status: Open Resolution: Accepted Priority: 5 Submitted By: Mighty Toenail (mighty_toenail) Assigned to: Karl Waclawek (kwaclaw) Summary: __cdecl shouldn't be selected by use of MS extensions Initial Comment: Expat 2.0.0 I find that in my builds _MSC_EXTENSIONS is not defined, probably because I build with Microsoft extensions switched off. The result of this is that XMLCALL does not get defined to __cdecl, so when I try to link to a __fastcall project I can't resolve the symbols. My workaround has been to change expat_external.h as follows: #if defined(XML_USE_MSC_EXTENSIONS) #define XMLCALL __cdecl becomes #if defined(XML_USE_MSC_EXTENSIONS) || defined (_WIN32) || defined (_WIN64) #define XMLCALL __cdecl which is easy to apply and good enough for my purposes. I am not a Windows expert, so there may be better ways, e.g. a symbol that encompases both _WIN32 and _WIN64. However, I think that you should be specifying the Windows calling convention based on whether you are building on Windows, not on whether you are building with Microsoft extensions. XML_USE_MSC_EXTENSIONS is used in other places in your code, but perhaps in these other places it really is appropriate to make the decision based on whether MS extensions are switched on (again, I'm not a Windows expert so I'm not sure). ---------------------------------------------------------------------- >Comment By: Mighty Toenail (mighty_toenail) Date: 2006-06-02 09:23 Message: Logged In: YES user_id=1509690 Sounds good to me - I'm pretty sure I've seen _MSC_VER used in just this manner in other code, so it's likely a sensible thing to do. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-06-01 21:04 Message: Logged In: YES user_id=290026 If you have no objections I'll commit the fix I described in my last message. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-05-26 16:11 Message: Logged In: YES user_id=290026 Does it work for you to use #if defined(_MSC_VER) instead of #if defined(XML_USE_MSC_EXTENSIONS) ? Looking at the other instances of #if defined(XML_USE_MSC_EXTENSIONS) I think they might be OK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1476160&group_id=10127 From noreply at sourceforge.net Fri Jun 2 14:21:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Jun 2006 05:21:59 -0700 Subject: [Expat-bugs] [ expat-Bugs-1476160 ] __cdecl shouldn't be selected by use of MS extensions Message-ID: Bugs item #1476160, was opened at 2006-04-25 10:17 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1476160&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: Platform Specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mighty Toenail (mighty_toenail) Assigned to: Karl Waclawek (kwaclaw) Summary: __cdecl shouldn't be selected by use of MS extensions Initial Comment: Expat 2.0.0 I find that in my builds _MSC_EXTENSIONS is not defined, probably because I build with Microsoft extensions switched off. The result of this is that XMLCALL does not get defined to __cdecl, so when I try to link to a __fastcall project I can't resolve the symbols. My workaround has been to change expat_external.h as follows: #if defined(XML_USE_MSC_EXTENSIONS) #define XMLCALL __cdecl becomes #if defined(XML_USE_MSC_EXTENSIONS) || defined (_WIN32) || defined (_WIN64) #define XMLCALL __cdecl which is easy to apply and good enough for my purposes. I am not a Windows expert, so there may be better ways, e.g. a symbol that encompases both _WIN32 and _WIN64. However, I think that you should be specifying the Windows calling convention based on whether you are building on Windows, not on whether you are building with Microsoft extensions. XML_USE_MSC_EXTENSIONS is used in other places in your code, but perhaps in these other places it really is appropriate to make the decision based on whether MS extensions are switched on (again, I'm not a Windows expert so I'm not sure). ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-06-02 08:21 Message: Logged In: YES user_id=290026 Yes, this is MS compiler rather than platform specific. Other compilers on Windows might define _WIN32 but still not understand __cdecl. Fixed in expat_external.h rev. 1.8. Closing this issue. ---------------------------------------------------------------------- Comment By: Mighty Toenail (mighty_toenail) Date: 2006-06-02 05:23 Message: Logged In: YES user_id=1509690 Sounds good to me - I'm pretty sure I've seen _MSC_VER used in just this manner in other code, so it's likely a sensible thing to do. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-06-01 17:04 Message: Logged In: YES user_id=290026 If you have no objections I'll commit the fix I described in my last message. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-05-26 12:11 Message: Logged In: YES user_id=290026 Does it work for you to use #if defined(_MSC_VER) instead of #if defined(XML_USE_MSC_EXTENSIONS) ? Looking at the other instances of #if defined(XML_USE_MSC_EXTENSIONS) I think they might be OK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1476160&group_id=10127 From noreply at sourceforge.net Thu Jun 8 16:31:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Jun 2006 07:31:00 -0700 Subject: [Expat-bugs] [ expat-Bugs-787387 ] xmlwf -n on file which uses a ':' as attribute name Message-ID: Bugs item #787387, was opened at 2003-08-12 05:57 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=787387&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: xmlwf -n on file which uses a ':' as attribute name Initial Comment: xmwf -n on file <!DOCTYPE doc [ <!ELEMENT doc (#PCDATA)> <!ATTLIST doc : CDATA #IMPLIED> ]> <doc :="v1"></doc> reports valid/sa/012.xml:3:14: syntax error as it does not like ':' as an attribute name. I'm not quite sure whether this is a bug or not - cf. http://www.w3.org/TR/REC-xml-names/ [4] NCName ::= (Letter | '_') (NCNameChar)* [5] NCNameChar ::= Letter | Digit | '.' | '-' | '_' | CombiningChar | Extender [6] QName ::= (Prefix ':')? LocalPart [7] Prefix ::= NCName [8] LocalPart ::= NCName and http://www.w3.org/TR/REC-xml#attdecls [52] AttlistDecl ::= '<!ATTLIST' S Name AttDef* S? '>' [53] AttDef ::= S Name S AttType S DefaultDecl [4] NameChar ::= Letter | Digit | '.' | '-' | '_' | ':' | CombiningChar | Extender [5] Name ::= (Letter | '_' | ':') (NameChar)* tcrhak at suse.cz ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-06-08 07:30 Message: Logged In: NO Just for letting you guys know, NCN stands for "non- colonized" Names, you can check http://www.w3.org/TR/2004/REC-xmlschema-2- 20041028/datatypes.html#NCName for NCName full description. lucas.massuh at gmail.com ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-08-12 20:29 Message: Logged In: YES user_id=3066 Closing as not-a-bug, for the reason explained by Rolf. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2003-08-12 18:00 Message: Logged In: YES user_id=13222 Not a bug. expat is right. You've quoted even the right productions, to decide this. (4) says, that a NCName must have at least one char and a colon isn't allowed. (By the way: I always thought, that NCName stands for non colon name, but could not found a source for that, at the moment). Prefix (7) and Localpart (8) are both NCNames. A colon in the QName is therefor only possible, if the QName has a prefix. Since the prefix must have at least one char, the att name in your example hasn't a prefix. Note, that your document is a wellformed XML document - and xmlwf (without -n) confirms this. It's only not a wellformed namespaced XML document. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=787387&group_id=10127 From noreply at sourceforge.net Tue Jun 13 08:44:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Jun 2006 23:44:18 -0700 Subject: [Expat-bugs] [ expat-Bugs-1505207 ] Problem in Parsing using expat on Windows Message-ID: Bugs item #1505207, was opened at 2006-06-12 23:44 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=1505207&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: www.libexpat.org Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Problem in Parsing using expat on Windows Initial Comment: Hi, I am using expat to parse xml file. The parsing works fine in Unix but in windows I am facing problems. The start tag in case of Windows is only returning the first character. e.g. if the tag is like in the Handler for start tag, only the first character p from "property" is returned. I am linking with static library libexpatwMT.lib and have also defined XML_STATIC. Please let me know if i am doing anything wrong. Expat Version: 1.95.8 Thanks in advance, Asif Iqbal ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1505207&group_id=10127 From asifiqbal.desai at gmail.com Tue Jun 13 07:27:24 2006 From: asifiqbal.desai at gmail.com (Asif Iqbal Desai) Date: Tue, 13 Jun 2006 10:57:24 +0530 Subject: [Expat-bugs] Facing Problem in Parsing using expat on Windows Message-ID: <929225b30606122227q13dfec8dg5ae7c519024368a6@mail.gmail.com> Hi, I am using expat to parse xml file. The parsing works fine in Unix but in windows I am facing problems. The start tag in case of Windows is only returning the first character. e.g. if the tag is like in the Handler for start tag, only the first character p from "property" is returned. We are linking with static library libexpatwMT.lib and have also defined XML_STATIC. Please let me know if i am doing anything wrong. Thanks in advance, Asif Iqbal Desai -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.libexpat.org/pipermail/expat-bugs/attachments/20060613/798181e9/attachment.htm From noreply at sourceforge.net Tue Jun 13 15:11:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Jun 2006 06:11:51 -0700 Subject: [Expat-bugs] [ expat-Bugs-1505207 ] Problem in Parsing using expat on Windows Message-ID: Bugs item #1505207, was opened at 2006-06-13 02:44 Message generated for change (Settings changed) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1505207&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: www.libexpat.org Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Karl Waclawek (kwaclaw) Summary: Problem in Parsing using expat on Windows Initial Comment: Hi, I am using expat to parse xml file. The parsing works fine in Unix but in windows I am facing problems. The start tag in case of Windows is only returning the first character. e.g. if the tag is like in the Handler for start tag, only the first character p from "property" is returned. I am linking with static library libexpatwMT.lib and have also defined XML_STATIC. Please let me know if i am doing anything wrong. Expat Version: 1.95.8 Thanks in advance, Asif Iqbal ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-06-13 09:11 Message: Logged In: YES user_id=290026 On Windows, libexpatw... returns characters in UTF-16 encoding, libexpat... returns them in UTF-8 encoding. On Unix, UTF-8 is the standard encoding, on Windows it is UTF-16. Just treat the text as UTF-16, and you should be fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1505207&group_id=10127 From noreply at sourceforge.net Thu Jun 15 22:08:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Jun 2006 13:08:20 -0700 Subject: [Expat-bugs] [ expat-Bugs-1506891 ] XML_SetCharacterDataHandler callback function not parsing Message-ID: Bugs item #1506891, was opened at 2006-06-15 13:08 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=1506891&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Test Required Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: XML_SetCharacterDataHandler callback function not parsing Initial Comment: Hello, I have a XML_SetCharacterDataHandler callback function that uses the text to build a directory path. I have noticed that at times the 1st node or last node will result in a partial capture of the text. example. my-57/actual image/ will return with "my-57/actual" only. I've attached my callback functions, startelement, endelement and dataelement. Thank you, Satyajit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1506891&group_id=10127 From noreply at sourceforge.net Thu Jun 15 22:10:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Jun 2006 13:10:12 -0700 Subject: [Expat-bugs] [ expat-Bugs-1506892 ] I forgot to all the files, sorry Message-ID: Bugs item #1506892, was opened at 2006-06-15 13:10 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=1506892&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: I forgot to all the files, sorry Initial Comment: Hello, I have a XML_SetCharacterDataHandler callback function that uses the text to build a directory path. I have noticed that at times the 1st node or last node will result in a partial capture of the text. example. my-57/actual image/ will return with "my-57/actual" only. I've attached my callback functions, startelement, endelement and dataelement. Thank you, Satyajit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1506892&group_id=10127 From noreply at sourceforge.net Thu Jun 15 23:52:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Jun 2006 14:52:40 -0700 Subject: [Expat-bugs] [ expat-Bugs-1506891 ] XML_SetCharacterDataHandler callback function not parsing Message-ID: Bugs item #1506891, was opened at 2006-06-15 16:08 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1506891&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Test Required Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: XML_SetCharacterDataHandler callback function not parsing Initial Comment: Hello, I have a XML_SetCharacterDataHandler callback function that uses the text to build a directory path. I have noticed that at times the 1st node or last node will result in a partial capture of the text. example. my-57/actual image/ will return with "my-57/actual" only. I've attached my callback functions, startelement, endelement and dataelement. Thank you, Satyajit ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-06-15 17:52 Message: Logged In: YES user_id=290026 Do not expect Expat to return all character data within an element in one call-back. You have to accumulate the text in a buffer until the end-tag is reported. Are you doing this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1506891&group_id=10127 From noreply at sourceforge.net Fri Jun 16 00:42:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Jun 2006 15:42:52 -0700 Subject: [Expat-bugs] [ expat-Bugs-1506891 ] XML_SetCharacterDataHandler callback function not parsing Message-ID: Bugs item #1506891, was opened at 2006-06-15 15:08 Message generated for change (Comment added) made by sketkar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1506891&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Test Required Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: XML_SetCharacterDataHandler callback function not parsing Initial Comment: Hello, I have a XML_SetCharacterDataHandler callback function that uses the text to build a directory path. I have noticed that at times the 1st node or last node will result in a partial capture of the text. example. my-57/actual image/ will return with "my-57/actual" only. I've attached my callback functions, startelement, endelement and dataelement. Thank you, Satyajit ---------------------------------------------------------------------- Comment By: sssketkar man! (sketkar) Date: 2006-06-15 17:42 Message: Logged In: YES user_id=944435 Thank you very much. I was expecting that the CharacterHandler was collecting all non-XML data in 1-shot. I wasn't using the EndElement as a check. I'll try that. Satyajit ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-06-15 16:52 Message: Logged In: YES user_id=290026 Do not expect Expat to return all character data within an element in one call-back. You have to accumulate the text in a buffer until the end-tag is reported. Are you doing this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1506891&group_id=10127 From noreply at sourceforge.net Fri Jun 16 20:07:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Jun 2006 11:07:22 -0700 Subject: [Expat-bugs] [ expat-Bugs-1506891 ] XML_SetCharacterDataHandler callback function not parsing Message-ID: Bugs item #1506891, was opened at 2006-06-15 15:08 Message generated for change (Comment added) made by sketkar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1506891&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Test Required Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: XML_SetCharacterDataHandler callback function not parsing Initial Comment: Hello, I have a XML_SetCharacterDataHandler callback function that uses the text to build a directory path. I have noticed that at times the 1st node or last node will result in a partial capture of the text. example. my-57/actual image/ will return with "my-57/actual" only. I've attached my callback functions, startelement, endelement and dataelement. Thank you, Satyajit ---------------------------------------------------------------------- Comment By: sssketkar man! (sketkar) Date: 2006-06-16 13:07 Message: Logged In: YES user_id=944435 Okay, I changed my approach, so that the StartElementHandler sets a flag that is used by the CharacterHandler to collect user text until the EndElementHandlers is called at which point the buffered text is retreived. This approach seems to work expect for the last "iteration", i.e if there are 5 nodes, the first 4 are parsed properly. The last one is still not getting buffered all the way or correctly. Here is a debug output from each Handler... START: tool START: tooladdress END: tooladdress START: imageid END: imageid START: directory END: directory XXY-WER/Actual Image/ <-- correct END: tool START: tool START: tooladdress END: tooladdress START: imageid END: imageid START: directory END: directory XYZ-W3/Actualage//e/ <-- not so correct END: tool As you can see the last tool node directory is incorrect, it should have been XYZ-W3/Actual Image/ Thank you, Satyajit ---------------------------------------------------------------------- Comment By: sssketkar man! (sketkar) Date: 2006-06-15 17:42 Message: Logged In: YES user_id=944435 Thank you very much. I was expecting that the CharacterHandler was collecting all non-XML data in 1-shot. I wasn't using the EndElement as a check. I'll try that. Satyajit ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-06-15 16:52 Message: Logged In: YES user_id=290026 Do not expect Expat to return all character data within an element in one call-back. You have to accumulate the text in a buffer until the end-tag is reported. Are you doing this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1506891&group_id=10127 From noreply at sourceforge.net Fri Jun 16 20:09:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Jun 2006 11:09:49 -0700 Subject: [Expat-bugs] [ expat-Bugs-1506891 ] XML_SetCharacterDataHandler callback function not parsing Message-ID: Bugs item #1506891, was opened at 2006-06-15 15:08 Message generated for change (Comment added) made by sketkar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1506891&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Test Required Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: XML_SetCharacterDataHandler callback function not parsing Initial Comment: Hello, I have a XML_SetCharacterDataHandler callback function that uses the text to build a directory path. I have noticed that at times the 1st node or last node will result in a partial capture of the text. example. my-57/actual image/ will return with "my-57/actual" only. I've attached my callback functions, startelement, endelement and dataelement. Thank you, Satyajit ---------------------------------------------------------------------- Comment By: sssketkar man! (sketkar) Date: 2006-06-16 13:09 Message: Logged In: YES user_id=944435 Also, out of curiousity, is the CharacterHandler called on a timed basis, ie time-sliced? Many the last node directory isn't getting buffered correctly because of timing issue between the StartElementHandler and EndElementHandler. Satyajit ---------------------------------------------------------------------- Comment By: sssketkar man! (sketkar) Date: 2006-06-16 13:07 Message: Logged In: YES user_id=944435 Okay, I changed my approach, so that the StartElementHandler sets a flag that is used by the CharacterHandler to collect user text until the EndElementHandlers is called at which point the buffered text is retreived. This approach seems to work expect for the last "iteration", i.e if there are 5 nodes, the first 4 are parsed properly. The last one is still not getting buffered all the way or correctly. Here is a debug output from each Handler... START: tool START: tooladdress END: tooladdress START: imageid END: imageid START: directory END: directory XXY-WER/Actual Image/ <-- correct END: tool START: tool START: tooladdress END: tooladdress START: imageid END: imageid START: directory END: directory XYZ-W3/Actualage//e/ <-- not so correct END: tool As you can see the last tool node directory is incorrect, it should have been XYZ-W3/Actual Image/ Thank you, Satyajit ---------------------------------------------------------------------- Comment By: sssketkar man! (sketkar) Date: 2006-06-15 17:42 Message: Logged In: YES user_id=944435 Thank you very much. I was expecting that the CharacterHandler was collecting all non-XML data in 1-shot. I wasn't using the EndElement as a check. I'll try that. Satyajit ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-06-15 16:52 Message: Logged In: YES user_id=290026 Do not expect Expat to return all character data within an element in one call-back. You have to accumulate the text in a buffer until the end-tag is reported. Are you doing this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1506891&group_id=10127 From noreply at sourceforge.net Fri Jun 16 20:17:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Jun 2006 11:17:27 -0700 Subject: [Expat-bugs] [ expat-Bugs-1506891 ] XML_SetCharacterDataHandler callback function not parsing Message-ID: Bugs item #1506891, was opened at 2006-06-15 15:08 Message generated for change (Comment added) made by sketkar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1506891&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Test Required Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: XML_SetCharacterDataHandler callback function not parsing Initial Comment: Hello, I have a XML_SetCharacterDataHandler callback function that uses the text to build a directory path. I have noticed that at times the 1st node or last node will result in a partial capture of the text. example. my-57/actual image/ will return with "my-57/actual" only. I've attached my callback functions, startelement, endelement and dataelement. Thank you, Satyajit ---------------------------------------------------------------------- Comment By: sssketkar man! (sketkar) Date: 2006-06-16 13:17 Message: Logged In: YES user_id=944435 Thought it might be useful, here is the XML file. test500115021118813-Jun-06 15:06:2810A/Actual Image/70L/Actual Image/71D/Acoustic Image/10R-5/Actual Image/70F/Actual Image/60P/Actual Image/80P-F/Actual Image/110P-M/Actual Image/ ---------------------------------------------------------------------- Comment By: sssketkar man! (sketkar) Date: 2006-06-16 13:09 Message: Logged In: YES user_id=944435 Also, out of curiousity, is the CharacterHandler called on a timed basis, ie time-sliced? Many the last node directory isn't getting buffered correctly because of timing issue between the StartElementHandler and EndElementHandler. Satyajit ---------------------------------------------------------------------- Comment By: sssketkar man! (sketkar) Date: 2006-06-16 13:07 Message: Logged In: YES user_id=944435 Okay, I changed my approach, so that the StartElementHandler sets a flag that is used by the CharacterHandler to collect user text until the EndElementHandlers is called at which point the buffered text is retreived. This approach seems to work expect for the last "iteration", i.e if there are 5 nodes, the first 4 are parsed properly. The last one is still not getting buffered all the way or correctly. Here is a debug output from each Handler... START: tool START: tooladdress END: tooladdress START: imageid END: imageid START: directory END: directory XXY-WER/Actual Image/ <-- correct END: tool START: tool START: tooladdress END: tooladdress START: imageid END: imageid START: directory END: directory XYZ-W3/Actualage//e/ <-- not so correct END: tool As you can see the last tool node directory is incorrect, it should have been XYZ-W3/Actual Image/ Thank you, Satyajit ---------------------------------------------------------------------- Comment By: sssketkar man! (sketkar) Date: 2006-06-15 17:42 Message: Logged In: YES user_id=944435 Thank you very much. I was expecting that the CharacterHandler was collecting all non-XML data in 1-shot. I wasn't using the EndElement as a check. I'll try that. Satyajit ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-06-15 16:52 Message: Logged In: YES user_id=290026 Do not expect Expat to return all character data within an element in one call-back. You have to accumulate the text in a buffer until the end-tag is reported. Are you doing this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1506891&group_id=10127 From noreply at sourceforge.net Fri Jun 16 20:25:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Jun 2006 11:25:13 -0700 Subject: [Expat-bugs] [ expat-Bugs-1506891 ] XML_SetCharacterDataHandler callback function not parsing Message-ID: Bugs item #1506891, was opened at 2006-06-15 16:08 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1506891&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Test Required Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: XML_SetCharacterDataHandler callback function not parsing Initial Comment: Hello, I have a XML_SetCharacterDataHandler callback function that uses the text to build a directory path. I have noticed that at times the 1st node or last node will result in a partial capture of the text. example. my-57/actual image/ will return with "my-57/actual" only. I've attached my callback functions, startelement, endelement and dataelement. Thank you, Satyajit ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-06-16 14:25 Message: Logged In: YES user_id=290026 I have no problem with your file. Maybe your parsing loop treats the last buffer incorrectly? ---------------------------------------------------------------------- Comment By: sssketkar man! (sketkar) Date: 2006-06-16 14:17 Message: Logged In: YES user_id=944435 Thought it might be useful, here is the XML file. test500115021118813-Jun-06 15:06:2810A/Actual Image/70L/Actual Image/71D/Acoustic Image/10R-5/Actual Image/70F/Actual Image/60P/Actual Image/80P-F/Actual Image/110P-M/Actual Image/ ---------------------------------------------------------------------- Comment By: sssketkar man! (sketkar) Date: 2006-06-16 14:09 Message: Logged In: YES user_id=944435 Also, out of curiousity, is the CharacterHandler called on a timed basis, ie time-sliced? Many the last node directory isn't getting buffered correctly because of timing issue between the StartElementHandler and EndElementHandler. Satyajit ---------------------------------------------------------------------- Comment By: sssketkar man! (sketkar) Date: 2006-06-16 14:07 Message: Logged In: YES user_id=944435 Okay, I changed my approach, so that the StartElementHandler sets a flag that is used by the CharacterHandler to collect user text until the EndElementHandlers is called at which point the buffered text is retreived. This approach seems to work expect for the last "iteration", i.e if there are 5 nodes, the first 4 are parsed properly. The last one is still not getting buffered all the way or correctly. Here is a debug output from each Handler... START: tool START: tooladdress END: tooladdress START: imageid END: imageid START: directory END: directory XXY-WER/Actual Image/ <-- correct END: tool START: tool START: tooladdress END: tooladdress START: imageid END: imageid START: directory END: directory XYZ-W3/Actualage//e/ <-- not so correct END: tool As you can see the last tool node directory is incorrect, it should have been XYZ-W3/Actual Image/ Thank you, Satyajit ---------------------------------------------------------------------- Comment By: sssketkar man! (sketkar) Date: 2006-06-15 18:42 Message: Logged In: YES user_id=944435 Thank you very much. I was expecting that the CharacterHandler was collecting all non-XML data in 1-shot. I wasn't using the EndElement as a check. I'll try that. Satyajit ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-06-15 17:52 Message: Logged In: YES user_id=290026 Do not expect Expat to return all character data within an element in one call-back. You have to accumulate the text in a buffer until the end-tag is reported. Are you doing this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1506891&group_id=10127 From noreply at sourceforge.net Fri Jun 16 20:28:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Jun 2006 11:28:56 -0700 Subject: [Expat-bugs] [ expat-Bugs-1506891 ] XML_SetCharacterDataHandler callback function not parsing Message-ID: Bugs item #1506891, was opened at 2006-06-15 15:08 Message generated for change (Comment added) made by sketkar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1506891&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Test Required Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: XML_SetCharacterDataHandler callback function not parsing Initial Comment: Hello, I have a XML_SetCharacterDataHandler callback function that uses the text to build a directory path. I have noticed that at times the 1st node or last node will result in a partial capture of the text. example. my-57/actual image/ will return with "my-57/actual" only. I've attached my callback functions, startelement, endelement and dataelement. Thank you, Satyajit ---------------------------------------------------------------------- Comment By: sssketkar man! (sketkar) Date: 2006-06-16 13:28 Message: Logged In: YES user_id=944435 Could you point me to an example I can look at to compare. I'm probably missing something obvious. Thanks for all your help. Satyajit. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-06-16 13:25 Message: Logged In: YES user_id=290026 I have no problem with your file. Maybe your parsing loop treats the last buffer incorrectly? ---------------------------------------------------------------------- Comment By: sssketkar man! (sketkar) Date: 2006-06-16 13:17 Message: Logged In: YES user_id=944435 Thought it might be useful, here is the XML file. test500115021118813-Jun-06 15:06:2810A/Actual Image/70L/Actual Image/71D/Acoustic Image/10R-5/Actual Image/70F/Actual Image/60P/Actual Image/80P-F/Actual Image/110P-M/Actual Image/ ---------------------------------------------------------------------- Comment By: sssketkar man! (sketkar) Date: 2006-06-16 13:09 Message: Logged In: YES user_id=944435 Also, out of curiousity, is the CharacterHandler called on a timed basis, ie time-sliced? Many the last node directory isn't getting buffered correctly because of timing issue between the StartElementHandler and EndElementHandler. Satyajit ---------------------------------------------------------------------- Comment By: sssketkar man! (sketkar) Date: 2006-06-16 13:07 Message: Logged In: YES user_id=944435 Okay, I changed my approach, so that the StartElementHandler sets a flag that is used by the CharacterHandler to collect user text until the EndElementHandlers is called at which point the buffered text is retreived. This approach seems to work expect for the last "iteration", i.e if there are 5 nodes, the first 4 are parsed properly. The last one is still not getting buffered all the way or correctly. Here is a debug output from each Handler... START: tool START: tooladdress END: tooladdress START: imageid END: imageid START: directory END: directory XXY-WER/Actual Image/ <-- correct END: tool START: tool START: tooladdress END: tooladdress START: imageid END: imageid START: directory END: directory XYZ-W3/Actualage//e/ <-- not so correct END: tool As you can see the last tool node directory is incorrect, it should have been XYZ-W3/Actual Image/ Thank you, Satyajit ---------------------------------------------------------------------- Comment By: sssketkar man! (sketkar) Date: 2006-06-15 17:42 Message: Logged In: YES user_id=944435 Thank you very much. I was expecting that the CharacterHandler was collecting all non-XML data in 1-shot. I wasn't using the EndElement as a check. I'll try that. Satyajit ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-06-15 16:52 Message: Logged In: YES user_id=290026 Do not expect Expat to return all character data within an element in one call-back. You have to accumulate the text in a buffer until the end-tag is reported. Are you doing this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1506891&group_id=10127 From noreply at sourceforge.net Fri Jun 16 20:42:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Jun 2006 11:42:59 -0700 Subject: [Expat-bugs] [ expat-Bugs-1506891 ] XML_SetCharacterDataHandler callback function not parsing Message-ID: Bugs item #1506891, was opened at 2006-06-15 16:08 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1506891&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Test Required Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: XML_SetCharacterDataHandler callback function not parsing Initial Comment: Hello, I have a XML_SetCharacterDataHandler callback function that uses the text to build a directory path. I have noticed that at times the 1st node or last node will result in a partial capture of the text. example. my-57/actual image/ will return with "my-57/actual" only. I've attached my callback functions, startelement, endelement and dataelement. Thank you, Satyajit ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-06-16 14:42 Message: Logged In: YES user_id=290026 Expat comes with a few demo apps, just look at them. This is taken from the "elements" demo: main(int argc, char *argv[]) { char buf[BUFSIZ]; XML_Parser parser = XML_ParserCreate(NULL); int done; int depth = 0; XML_SetUserData(parser, &depth); XML_SetElementHandler(parser, startElement, endElement); do { int len = (int)fread(buf, 1, sizeof(buf), stdin); done = len < sizeof(buf); if (XML_Parse(parser, buf, len, done) == XML_STATUS_ERROR) { fprintf(stderr, "%s at line %" XML_FMT_INT_MOD "u\n", XML_ErrorString(XML_GetErrorCode(parser)), XML_GetCurrentLineNumber(parser)); return 1; } } while (!done); XML_ParserFree(parser); return 0; } ---------------------------------------------------------------------- Comment By: sssketkar man! (sketkar) Date: 2006-06-16 14:28 Message: Logged In: YES user_id=944435 Could you point me to an example I can look at to compare. I'm probably missing something obvious. Thanks for all your help. Satyajit. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-06-16 14:25 Message: Logged In: YES user_id=290026 I have no problem with your file. Maybe your parsing loop treats the last buffer incorrectly? ---------------------------------------------------------------------- Comment By: sssketkar man! (sketkar) Date: 2006-06-16 14:17 Message: Logged In: YES user_id=944435 Thought it might be useful, here is the XML file. test500115021118813-Jun-06 15:06:2810A/Actual Image/70L/Actual Image/71D/Acoustic Image/10R-5/Actual Image/70F/Actual Image/60P/Actual Image/80P-F/Actual Image/110P-M/Actual Image/ ---------------------------------------------------------------------- Comment By: sssketkar man! (sketkar) Date: 2006-06-16 14:09 Message: Logged In: YES user_id=944435 Also, out of curiousity, is the CharacterHandler called on a timed basis, ie time-sliced? Many the last node directory isn't getting buffered correctly because of timing issue between the StartElementHandler and EndElementHandler. Satyajit ---------------------------------------------------------------------- Comment By: sssketkar man! (sketkar) Date: 2006-06-16 14:07 Message: Logged In: YES user_id=944435 Okay, I changed my approach, so that the StartElementHandler sets a flag that is used by the CharacterHandler to collect user text until the EndElementHandlers is called at which point the buffered text is retreived. This approach seems to work expect for the last "iteration", i.e if there are 5 nodes, the first 4 are parsed properly. The last one is still not getting buffered all the way or correctly. Here is a debug output from each Handler... START: tool START: tooladdress END: tooladdress START: imageid END: imageid START: directory END: directory XXY-WER/Actual Image/ <-- correct END: tool START: tool START: tooladdress END: tooladdress START: imageid END: imageid START: directory END: directory XYZ-W3/Actualage//e/ <-- not so correct END: tool As you can see the last tool node directory is incorrect, it should have been XYZ-W3/Actual Image/ Thank you, Satyajit ---------------------------------------------------------------------- Comment By: sssketkar man! (sketkar) Date: 2006-06-15 18:42 Message: Logged In: YES user_id=944435 Thank you very much. I was expecting that the CharacterHandler was collecting all non-XML data in 1-shot. I wasn't using the EndElement as a check. I'll try that. Satyajit ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-06-15 17:52 Message: Logged In: YES user_id=290026 Do not expect Expat to return all character data within an element in one call-back. You have to accumulate the text in a buffer until the end-tag is reported. Are you doing this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1506891&group_id=10127 From noreply at sourceforge.net Tue Jun 27 11:21:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Jun 2006 02:21:31 -0700 Subject: [Expat-bugs] [ expat-Bugs-1513208 ] memory leak Message-ID: Bugs item #1513208, was opened at 2006-06-27 02:21 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=1513208&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: memory leak Initial Comment: version: 1.95.8 two bufferes, one is "GL-002- 0012", another is "GL- 002-0012", the latter leak 80 bytes every time. the difference of both bufferes is whether the PROLOG exists. the tested function: XML_Parse. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1513208&group_id=10127 From noreply at sourceforge.net Tue Jun 27 22:16:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Jun 2006 13:16:54 -0700 Subject: [Expat-bugs] [ expat-Bugs-1513566 ] readfilemap fails with file size 0 Message-ID: Bugs item #1513566, was opened at 2006-06-27 16:16 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=1513566&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: www.libexpat.org Group: None Status: Open Resolution: None Priority: 5 Submitted By: MikeG (greenemk) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: readfilemap fails with file size 0 Initial Comment: xmlwf compiled with readfilemap.c will fail with an "out of memory" error on file size zero when executing malloc( ) . The attached patch handles 0 size files in the same manner as in win32filemap.c. The patch also includes a close( ) of the open file if malloc( ) fails. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1513566&group_id=10127 From noreply at sourceforge.net Fri Jun 30 20:40:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Jun 2006 11:40:06 -0700 Subject: [Expat-bugs] [ expat-Bugs-1515266 ] missing check of stopped parser in doContext() 'for' loop Message-ID: Bugs item #1515266, was opened at 2006-06-30 14:04 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1515266&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None >Priority: 6 Submitted By: Brett Cannon (bcannon) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: missing check of stopped parser in doContext() 'for' loop Initial Comment: In Expat 2.0.0, in expat.c:doConvert() there is a 'for' loop for the XML_TOK_DATA_CHARS case. There is unfortunately no check in that loop whether the parser was stopped during that call because of an error. This was discovered in Python (Lib/test/crashers/xml_parsers.py) because pyexpat, upon error where there is no error return code like with characterDataHandlers, sets all handlers to 0, sets parsingStatus to XML_FINISHED, and sets errorCode. This leads to a segfault if the 'for' loop goes around again because parser->m_characterDataHandler is set to 0. A simple check if the parser is stopped fixes the problem. I have attached a simple patch that just breaks out of the loop and lets execution fall through to the bottom of the 'switch' statement. I don't know if returning errorCode directly would be better or if checking for XML_SUSPENDED is also desirable. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-06-30 14:40 Message: Logged In: YES user_id=3066 The Python folks need this dealt with before Python 2.5, so I'll try and take a look at it this weekend if no one beats me to it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1515266&group_id=10127