From noreply at sourceforge.net Tue Sep 5 20:24:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 11:24:13 -0700 Subject: [Expat-bugs] [ expat-Bugs-1543233 ] bug in examples/outline.c Message-ID: Bugs item #1543233, was opened at 2006-08-19 22:58 Message generated for change (Comment added) made by hartwork You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1543233&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: Imran (imranghory) Assigned to: Nobody/Anonymous (nobody) Summary: bug in examples/outline.c Initial Comment: In examples/outline.c XML_ParserFree() isn't called to free the parser, hence causing a memory leak. ---------------------------------------------------------------------- Comment By: Sebastian Pipping (hartwork) Date: 2006-09-05 20:24 Message: Logged In: YES user_id=1022691 It's not a memleak but I second that really should not be missing. Sebastian ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1543233&group_id=10127 From noreply at sourceforge.net Tue Sep 5 22:08:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 13:08:30 -0700 Subject: [Expat-bugs] [ expat-Bugs-1543233 ] bug in examples/outline.c Message-ID: Bugs item #1543233, was opened at 2006-08-19 16:58 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1543233&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: Fixed Priority: 5 Submitted By: Imran (imranghory) Assigned to: Nobody/Anonymous (nobody) Summary: bug in examples/outline.c Initial Comment: In examples/outline.c XML_ParserFree() isn't called to free the parser, hence causing a memory leak. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-09-05 16:08 Message: Logged In: YES user_id=290026 I agree. Fixed in outline.c rev. 1.9. ---------------------------------------------------------------------- Comment By: Sebastian Pipping (hartwork) Date: 2006-09-05 14:24 Message: Logged In: YES user_id=1022691 It's not a memleak but I second that really should not be missing. Sebastian ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1543233&group_id=10127 From noreply at sourceforge.net Fri Sep 8 11:15:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Sep 2006 02:15:09 -0700 Subject: [Expat-bugs] [ expat-Bugs-1554618 ] outdated config.sub/config.guess Message-ID: Bugs item #1554618, was opened at 2006-09-08 02:15 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=1554618&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: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: outdated config.sub/config.guess Initial Comment: Please, could you update config.sub/config.guess in conftools subdir. They are over 4 years old, the fail to recognise some platforms. Up-to-date version are available from: http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/config/config.guess http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/config/config.sub Petr ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1554618&group_id=10127 From noreply at sourceforge.net Sat Sep 9 12:07:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Sep 2006 03:07:14 -0700 Subject: [Expat-bugs] [ expat-Bugs-1284386 ] Byte count in large XML files fails Message-ID: Bugs item #1284386, was opened at 2005-09-07 18:01 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1284386&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: Closed Resolution: Fixed Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Karl Waclawek (kwaclaw) Summary: Byte count in large XML files fails Initial Comment: XML_GetCurrentByteIndex(XML_Parser parser) returns a long, which is at least on the most 32 bit Systems 32 bit long. That means, for XML input larger than 2 GByte file size, XML_GetCurrentByteIndex() returns does not return the right number. Sure, such big XML files will be parsed in chunks, so it is possbile, to keep track about the nr of overflows by self, but come on. It's surely a limbo dance by its own to introcude long long in a source, so portable as expat, but that would be it. If you switch to long long if avaliable for this, please consider also XML_GetCurrentLineNumber() and XML_GetCurrentColumnNumber(). They return an int, which is on most 32-byte systems 2 Gig. Though, I'm not stumbled over this two limits in real life, as I in fact did with XML_GetCurrentByteIndex(). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-09-09 03:07 Message: Logged In: NO Maybe you have a look what apache does for apr_size_t. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-03-06 06:44 Message: Logged In: YES user_id=290026 Closing this issue - no complaints received. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-01-12 16:18 Message: Logged In: YES user_id=290026 Rolf, I think I can close that now. Do you agree, or is there something you are still missing? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-12-22 13:06 Message: Logged In: YES user_id=290026 Rolf, I think I go for the simple solution: use long long, and if a compiler doesn't support it, too bad, the programmer will have to use 32 bit integers: #ifdef XML_LARGE_SIZE typedef long long XML_Index; typedef unsigned long long XML_Size; #else typedef long XML_Index; typedef unsigned long XML_Size; #endif Even if undefined, the above declarations will change the return values of XML_GetCurrentLine/ColumnNumber from int to unsigned long. Hope that is not a problem (in theory, long >= int). Anyway, I'll apply the attached patch (LargeInt2.diff) sometime soon and create a pre-release for download. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-12-11 20:35 Message: Logged In: YES user_id=290026 Rolf, you are right about XML_GetCurrentLineNumber() and XML_GetCurrentColumnNumber(). The backwards compatibility is an issue for others, as far as I can tell, so I think I have it off by default. Attached is a patch I quickly put together today. Basic points: The switch is called "XML_LARGE_SIZE". I modified the type names to XML_Index (for signed large ints) and XML_Size (for unsigned large ints). If you have better names, let me know. Would you apply the patch and see how it works for you? (I assume long long works everywhere except Windows). Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2005-12-04 15:40 Message: Logged In: YES user_id=13222 Karl, I followed it. I must confess, I've no clear opinion about the backward compatibilty problem. For me, that is not a problem. I distribute the expat sources with my software and link it statically (so no problem even for binary distribution). One note: I don't think, that XML_GetCurrentLineNumber() and XML_GetCurrentColumnNumber() are seldom used calls. Any resonable XML processing software should be able to deal with the case, that it get feeded with not well-formed XML input. I'd guess, most programmers use that two calls to provide a usefull error msg to their users. I'm happy with any solution. I feel, it may be to much bloat (as you said) to have all that functions twice with different return type. So, I'd favour a build flag. (With the default 32 bit changed to 64 bit right after the 2.0 release). But I'm not really sure. Yes, I still have to provide some bits to check for a long long on unix plattforms, I now. rolf ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-11-30 06:31 Message: Logged In: YES user_id=290026 Rolf, I opened a discussion about this on the discussion list. The main issue - IMO - is backwards compatibility. I don't know how many apps on Linux, for instance, rely on the Expat API staying binary compatible. Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2005-11-27 18:01 Message: Logged In: YES user_id=13222 XML_GetCurrentByteIndex() could return -1: Of course! You're right. And it makes sense. A freshly created or reseted parser without the first XML_Parse() call returns -1 on XML_GetCurrentByteIndex(), to signal this fact: it is not right at the start of the document, but there isn't any parsing started yet. Nice detail. I should have looked at the implementation, before replying. Note: That detail isn't mentioned in the documentation. I'm fine with a signed long long. 2^63 should be big enough, for the next few weeks ;-). Re the defines: Basically yes. It's just, that I'm pretty sure, we need one round more: some configure check for long long and depending on that result defining XML_?Int64 as long long or just long. I'll look something up (but being on deadline catching, may need a bit time). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-11-27 17:00 Message: Logged In: YES user_id=290026 On a 32bit CPU, 64bit integer operations are considerably slower than 32 bit operations. On the other hand XMLUpdatePosition isn't called that often - mostly when you actually request the line/column number. So, I agree - no configuration necessary. For the other point: If you look at the XML_GetCurrentByteIndex() code, it can return -1, and it is calculated using a subtraction. So in practice and theory, it must be a signed integer. XML_GetCurrentByteCount is derived from a subtraction as well, but we know it will be positive because eventEndPtr should always be larger than eventPtr. So we could risk using an unsigned integer. Just playing around, I added this to expat_external.h: #ifdef XML_USE_MSC_EXTENSIONS typedef __int64 XML_Int64; typedef unsigned __int64 XML_UInt64; #else typedef long long XML_Int64; typedef unsigned long long XML_UInt64; #endif What do you think? Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2005-11-27 16:33 Message: Logged In: YES user_id=13222 Configurable: No There is nearly no overhead: just a few variables (at max) 8 bytes long instead of 4 bytes. Also speedwise: not mesuarable. long long acceptable everywhere: Probably no Some very old or limited embedded system may not have a long long (or equivalent). Therefor we probably need defines. Byte index could be negative: don't think so. How could that happen? Byte index starts at 0 and grows. Or do I miss something.? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-11-27 15:21 Message: Logged In: YES user_id=290026 Just some notes, so that I don't forget - should it be configurable? some may not want the overhead of a 64bit integer, especially for line number and column number. - is long long acceptable everywhere else (other than VC++)? - the byte index could be negative, but not line/column number and byte count, right? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-11-27 12:31 Message: Logged In: YES user_id=290026 You are right, Rolf, it should be 64 bits even on a 32bit platform. I guess I should make a note in the docs that Expat supports > 2GB files, as long as each chunk passed to the XML_Parse routines is smaller than 2GB. There are also issues around compiling Expat on a 64bit platform, but at least for VC++, someone has provided a patch (bug # 1105135) which looks it should work on other platforms as well (just a bunch of type casts). One issue I have already seen is that VC++ 6.0 does not know about long long. Thanks for having a look at the cross-platform issue. I am trying to get Expat 2.0 released despite Fred not being active on Expat anymore. Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2005-11-27 12:22 Message: Logged In: YES user_id=13222 Karl, Most reasonable 32bit platforms have support for file sizes > 2 GB these days even on 32. It was in fact a 32bit platform, at which I stumbled over the problem. That for your easy question. Much harder is how to slove this in a portable way. I'm afraid that may need platform depending #defines (with fallback to long). I'll go out digging what other portable software does in this case and will come back with a more concrete proposal. rolf ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-11-27 11:22 Message: Logged In: YES user_id=290026 Rolf, should the type be 64 bit integer on all platforms, or 32bit on 32bit platforms and 64bit on 64bit platforms? I think we are talking about m_parseEndByteIndex, POSITION.lineNumber and POSITION.columnNumber. Options could be size_t, ptrdiff_t. MS VC++ 6.0 does not know about long long, but it knows about __int64. Is there an ANSI definition for 64 bit ints? What do you suggest that works on all platforms? Karl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1284386&group_id=10127 From noreply at sourceforge.net Wed Sep 13 07:48:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Sep 2006 22:48:24 -0700 Subject: [Expat-bugs] [ expat-Bugs-1557638 ] "make check" needs "-I${prefix}/include" Message-ID: Bugs item #1557638, was opened at 2006-09-13 05:48 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=1557638&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: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Jarc (prjsf) Assigned to: Greg Stein (gstein) Summary: "make check" needs "-I${prefix}/include" Initial Comment: "make check" can't compile its C++ test files if the headers are not in the compiler's default include search path. runtestspp.cpp appears to be compiled with make's default rule, not $(CXXCOMPILE), so it doesn't use $(INCLUDES). It does use $(CPPFLAGS), so including $(INCLUDES) and $(DEFS) in $(CPPFLAGS) instead of in $(COMPILE) and $(CXXCOMPILE) should work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1557638&group_id=10127 From noreply at sourceforge.net Wed Sep 13 07:49:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Sep 2006 22:49:31 -0700 Subject: [Expat-bugs] [ expat-Bugs-1557638 ] "make check" needs "-I${prefix}/include" Message-ID: Bugs item #1557638, was opened at 2006-09-13 05:48 Message generated for change (Comment added) made by prjsf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1557638&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: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Jarc (prjsf) Assigned to: Greg Stein (gstein) Summary: "make check" needs "-I${prefix}/include" Initial Comment: "make check" can't compile its C++ test files if the headers are not in the compiler's default include search path. runtestspp.cpp appears to be compiled with make's default rule, not $(CXXCOMPILE), so it doesn't use $(INCLUDES). It does use $(CPPFLAGS), so including $(INCLUDES) and $(DEFS) in $(CPPFLAGS) instead of in $(COMPILE) and $(CXXCOMPILE) should work. ---------------------------------------------------------------------- >Comment By: Paul Jarc (prjsf) Date: 2006-09-13 05:49 Message: Logged In: YES user_id=412110 Sorry, I forgot to mention this applies to expat 2.0.0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1557638&group_id=10127 From noreply at sourceforge.net Fri Sep 22 15:25:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Sep 2006 06:25:32 -0700 Subject: [Expat-bugs] [ expat-Bugs-1535603 ] Error testing expat 2.0.0 Message-ID: Bugs item #1535603, was opened at 2006-08-07 02:02 Message generated for change (Comment added) made by uamike You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1535603&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: Pierre (pierre42) Assigned to: Nobody/Anonymous (nobody) Summary: Error testing expat 2.0.0 Initial Comment: # make check gcc -I./lib -I. -s -O3 -march=i686 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o tests/runtests.o -c tests/runtests.c gcc -I./lib -I. -s -O3 -march=i686 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o tests/chardata.o -c tests/chardata.c gcc -I./lib -I. -s -O3 -march=i686 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o tests/minicheck.o -c tests/minicheck.c /bin/sh ./libtool --silent --mode=link gcc -I./lib -I. -s -O3 -march=i686 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o tests/runtests tests/runtests.o tests/chardata.o tests/minicheck.o libexpat.la g++ -s -O3 -march=i686 -c -o tests/runtestspp.o tests/runtestspp.cpp In file included from tests/runtestspp.cpp:6: tests/runtests.c: In function `void test_line_number_after_parse()': tests/runtests.c:410: error: `XML_Size' undeclared (first use this function) tests/runtests.c:410: error: (Each undeclared identifier is reported only once for each function it appears in.) tests/runtests.c:410: error: expected `;' before "lineno" tests/runtests.c:414: error: `lineno' undeclared (first use this function) tests/runtests.c: In function `void test_column_number_after_parse()': tests/runtests.c:428: error: `XML_Size' undeclared (first use this function) tests/runtests.c:428: error: expected `;' before "colno" tests/runtests.c:432: error: `colno' undeclared (first use this function) tests/runtests.c: In function `void test_line_number_after_error()': tests/runtests.c:514: error: `XML_Size' undeclared (first use this function) tests/runtests.c:514: error: expected `;' before "lineno" tests/runtests.c:518: error: `lineno' undeclared (first use this function) tests/runtests.c: In function `void test_column_number_after_error()': tests/runtests.c:534: error: `XML_Size' undeclared (first use this function) tests/runtests.c:534: error: expected `;' before "colno" tests/runtests.c:538: error: `colno' undeclared (first use this function) tests/runtests.c: In function `void test_ns_prefix_with_empty_uri_1()': tests/runtests.c:1230: error: `XML_ERROR_UNDECLARING_PREFIX' undeclared (first use this function) tests/runtests.c: In function `void test_ns_prefix_with_empty_uri_2()': tests/runtests.c:1244: error: `XML_ERROR_UNDECLARING_PREFIX' undeclared (first use this function) tests/runtests.c: In function `void test_ns_prefix_with_empty_uri_3()': tests/runtests.c:1261: error: `XML_ERROR_UNDECLARING_PREFIX' undeclared (first use this function) make: *** [tests/runtestspp.o] Error 1 ---------------------------------------------------------------------- Comment By: Miguel Company Company (uamike) Date: 2006-09-22 15:25 Message: Logged In: YES user_id=14562 I had exactly the same problem compiling in a Cygwin environment. The problem was that the C++ version of the test was built using the system default command, and not $(CXXCOMPILE). I modified the Makefile and worked. Here is the diff between the versions 175c175 < .SUFFIXES: .cpp .c .lo .o --- > .SUFFIXES: .c .lo .o 179,180d178 < .cpp.o: < $(CXXCOMPILE) -o $@ -c $< ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-08-08 16:46 Message: Logged In: YES user_id=290026 Works fine for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1535603&group_id=10127 From noreply at sourceforge.net Fri Sep 22 15:53:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Sep 2006 06:53:23 -0700 Subject: [Expat-bugs] [ expat-Bugs-1535603 ] Error testing expat 2.0.0 Message-ID: Bugs item #1535603, was opened at 2006-08-06 20:02 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1535603&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: Pierre (pierre42) Assigned to: Nobody/Anonymous (nobody) Summary: Error testing expat 2.0.0 Initial Comment: # make check gcc -I./lib -I. -s -O3 -march=i686 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o tests/runtests.o -c tests/runtests.c gcc -I./lib -I. -s -O3 -march=i686 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o tests/chardata.o -c tests/chardata.c gcc -I./lib -I. -s -O3 -march=i686 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o tests/minicheck.o -c tests/minicheck.c /bin/sh ./libtool --silent --mode=link gcc -I./lib -I. -s -O3 -march=i686 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o tests/runtests tests/runtests.o tests/chardata.o tests/minicheck.o libexpat.la g++ -s -O3 -march=i686 -c -o tests/runtestspp.o tests/runtestspp.cpp In file included from tests/runtestspp.cpp:6: tests/runtests.c: In function `void test_line_number_after_parse()': tests/runtests.c:410: error: `XML_Size' undeclared (first use this function) tests/runtests.c:410: error: (Each undeclared identifier is reported only once for each function it appears in.) tests/runtests.c:410: error: expected `;' before "lineno" tests/runtests.c:414: error: `lineno' undeclared (first use this function) tests/runtests.c: In function `void test_column_number_after_parse()': tests/runtests.c:428: error: `XML_Size' undeclared (first use this function) tests/runtests.c:428: error: expected `;' before "colno" tests/runtests.c:432: error: `colno' undeclared (first use this function) tests/runtests.c: In function `void test_line_number_after_error()': tests/runtests.c:514: error: `XML_Size' undeclared (first use this function) tests/runtests.c:514: error: expected `;' before "lineno" tests/runtests.c:518: error: `lineno' undeclared (first use this function) tests/runtests.c: In function `void test_column_number_after_error()': tests/runtests.c:534: error: `XML_Size' undeclared (first use this function) tests/runtests.c:534: error: expected `;' before "colno" tests/runtests.c:538: error: `colno' undeclared (first use this function) tests/runtests.c: In function `void test_ns_prefix_with_empty_uri_1()': tests/runtests.c:1230: error: `XML_ERROR_UNDECLARING_PREFIX' undeclared (first use this function) tests/runtests.c: In function `void test_ns_prefix_with_empty_uri_2()': tests/runtests.c:1244: error: `XML_ERROR_UNDECLARING_PREFIX' undeclared (first use this function) tests/runtests.c: In function `void test_ns_prefix_with_empty_uri_3()': tests/runtests.c:1261: error: `XML_ERROR_UNDECLARING_PREFIX' undeclared (first use this function) make: *** [tests/runtestspp.o] Error 1 ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-09-22 09:53 Message: Logged In: YES user_id=290026 Is this a bug in Cygwin? The Makefile looks OK to me. ---------------------------------------------------------------------- Comment By: Miguel Company Company (uamike) Date: 2006-09-22 09:25 Message: Logged In: YES user_id=14562 I had exactly the same problem compiling in a Cygwin environment. The problem was that the C++ version of the test was built using the system default command, and not $(CXXCOMPILE). I modified the Makefile and worked. Here is the diff between the versions 175c175 < .SUFFIXES: .cpp .c .lo .o --- > .SUFFIXES: .c .lo .o 179,180d178 < .cpp.o: < $(CXXCOMPILE) -o $@ -c $< ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-08-08 10:46 Message: Logged In: YES user_id=290026 Works fine for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1535603&group_id=10127 From noreply at sourceforge.net Fri Sep 22 16:48:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Sep 2006 07:48:33 -0700 Subject: [Expat-bugs] [ expat-Bugs-1554618 ] outdated config.sub/config.guess Message-ID: Bugs item #1554618, was opened at 2006-09-08 05:15 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1554618&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: None Status: Open >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: outdated config.sub/config.guess Initial Comment: Please, could you update config.sub/config.guess in conftools subdir. They are over 4 years old, the fail to recognise some platforms. Up-to-date version are available from: http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/config/config.guess http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/config/config.sub Petr ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-09-22 10:48 Message: Logged In: YES user_id=290026 Committed as config.guess 1.4, config.sub 1.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1554618&group_id=10127 From noreply at sourceforge.net Thu Sep 28 09:07:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Sep 2006 00:07:13 -0700 Subject: [Expat-bugs] [ expat-Bugs-1566826 ] More "Frees" than "Allocs" Message-ID: Bugs item #1566826, was opened at 2006-09-28 00:07 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=1566826&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: More "Frees" than "Allocs" Initial Comment: I used the Expat 2.0 in our project and it seems to work fine. I did a kind of component test using the parser including testing the expat sources. As i wrote own memory allocation functions (called ONLY by expat sources) i saw that the free function is called more often than the alloc function. Nevertheless all memory areas allocated with alloc will be freed again. Email: chris_1270 at web.de ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1566826&group_id=10127 From noreply at sourceforge.net Thu Sep 28 09:18:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Sep 2006 00:18:30 -0700 Subject: [Expat-bugs] [ expat-Bugs-1566831 ] More "Frees" than "Allocs" Message-ID: Bugs item #1566831, was opened at 2006-09-28 00:18 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=1566831&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: More "Frees" than "Allocs" Initial Comment: I used the Expat 2.0 in our project and it seems to work fine. I did a kind of component test using the parser including testing the expat sources. As i wrote own memory allocation functions (called ONLY by expat sources) i saw that the free function is called more often than the alloc function. Nevertheless all memory areas allocated with alloc will be freed again. Email: chris_1270 at web.de ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1566831&group_id=10127 From noreply at sourceforge.net Thu Sep 28 15:16:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Sep 2006 06:16:28 -0700 Subject: [Expat-bugs] [ expat-Bugs-1566831 ] More "Frees" than "Allocs" Message-ID: Bugs item #1566831, was opened at 2006-09-28 03:18 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1566831&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: More "Frees" than "Allocs" Initial Comment: I used the Expat 2.0 in our project and it seems to work fine. I did a kind of component test using the parser including testing the expat sources. As i wrote own memory allocation functions (called ONLY by expat sources) i saw that the free function is called more often than the alloc function. Nevertheless all memory areas allocated with alloc will be freed again. Email: chris_1270 at web.de ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-09-28 09:16 Message: Logged In: YES user_id=290026 Should that not trigger some sort of error? Any ideas which free calls are superfluous? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1566831&group_id=10127 From noreply at sourceforge.net Thu Sep 28 15:17:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Sep 2006 06:17:11 -0700 Subject: [Expat-bugs] [ expat-Bugs-1566826 ] More "Frees" than "Allocs" Message-ID: Bugs item #1566826, was opened at 2006-09-28 03:07 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1566826&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: More "Frees" than "Allocs" Initial Comment: I used the Expat 2.0 in our project and it seems to work fine. I did a kind of component test using the parser including testing the expat sources. As i wrote own memory allocation functions (called ONLY by expat sources) i saw that the free function is called more often than the alloc function. Nevertheless all memory areas allocated with alloc will be freed again. Email: chris_1270 at web.de ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-09-28 09:17 Message: Logged In: YES user_id=290026 Should that not trigger some sort of error? Any ideas which free calls are superfluous? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1566826&group_id=10127 From noreply at sourceforge.net Thu Sep 28 15:18:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Sep 2006 06:18:03 -0700 Subject: [Expat-bugs] [ expat-Bugs-1566831 ] More "Frees" than "Allocs" Message-ID: Bugs item #1566831, was opened at 2006-09-28 03:18 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1566831&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: Closed >Resolution: Duplicate Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: More "Frees" than "Allocs" Initial Comment: I used the Expat 2.0 in our project and it seems to work fine. I did a kind of component test using the parser including testing the expat sources. As i wrote own memory allocation functions (called ONLY by expat sources) i saw that the free function is called more often than the alloc function. Nevertheless all memory areas allocated with alloc will be freed again. Email: chris_1270 at web.de ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-09-28 09:18 Message: Logged In: YES user_id=290026 Duplicate of bug # 1566826. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-09-28 09:16 Message: Logged In: YES user_id=290026 Should that not trigger some sort of error? Any ideas which free calls are superfluous? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1566831&group_id=10127 From noreply at sourceforge.net Fri Sep 29 09:57:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Sep 2006 00:57:16 -0700 Subject: [Expat-bugs] [ expat-Bugs-1566826 ] More "Frees" than "Allocs" Message-ID: Bugs item #1566826, was opened at 2006-09-28 00:07 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1566826&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: More "Frees" than "Allocs" Initial Comment: I used the Expat 2.0 in our project and it seems to work fine. I did a kind of component test using the parser including testing the expat sources. As i wrote own memory allocation functions (called ONLY by expat sources) i saw that the free function is called more often than the alloc function. Nevertheless all memory areas allocated with alloc will be freed again. Email: chris_1270 at web.de ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-09-29 00:57 Message: Logged In: NO Sorry it was an error on my side in the functions which realized the counting of free and allocs. SO it seems to work fine. Sorry for your effort. But i have got another question regarding the memory demand. So it seems that also for small XML documents a lot of heap is needed (e.g. for a document with 1000 Bytes about 4000 Bytes memory is allocated). Because i want to use the parser in an embedded device its a lot of memory for my project (perhaps too much!). Perhaps you have an idea that the parser needs less memory!?? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-09-28 06:17 Message: Logged In: YES user_id=290026 Should that not trigger some sort of error? Any ideas which free calls are superfluous? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1566826&group_id=10127 From noreply at sourceforge.net Fri Sep 29 15:13:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Sep 2006 06:13:46 -0700 Subject: [Expat-bugs] [ expat-Bugs-1566826 ] More "Frees" than "Allocs" Message-ID: Bugs item #1566826, was opened at 2006-09-28 03:07 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1566826&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: More "Frees" than "Allocs" Initial Comment: I used the Expat 2.0 in our project and it seems to work fine. I did a kind of component test using the parser including testing the expat sources. As i wrote own memory allocation functions (called ONLY by expat sources) i saw that the free function is called more often than the alloc function. Nevertheless all memory areas allocated with alloc will be freed again. Email: chris_1270 at web.de ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-09-29 09:13 Message: Logged In: YES user_id=290026 As far as I remember, the memory consumption does not increase a lot for larger files, but there is a certain amount of memory allocated initially. Short of re-designing Expat this cannot ve avoided. However, you can probably reduce it by re-building Expat with some symbols undefined, like XML_CONTEXT_BYTES or XML_DTD (if not needed). There is also XML_MIN_SIZE to try. Just search expat-discuss - there have been such discussions in the past. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-09-29 03:57 Message: Logged In: NO Sorry it was an error on my side in the functions which realized the counting of free and allocs. SO it seems to work fine. Sorry for your effort. But i have got another question regarding the memory demand. So it seems that also for small XML documents a lot of heap is needed (e.g. for a document with 1000 Bytes about 4000 Bytes memory is allocated). Because i want to use the parser in an embedded device its a lot of memory for my project (perhaps too much!). Perhaps you have an idea that the parser needs less memory!?? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-09-28 09:17 Message: Logged In: YES user_id=290026 Should that not trigger some sort of error? Any ideas which free calls are superfluous? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1566826&group_id=10127