From noreply at sourceforge.net Mon Mar 6 15:25:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 06:25:49 -0800 Subject: [Expat-bugs] [ expat-Patches-1437840 ] Compile fix rollup patch against 2.0.0 Message-ID: Patches item #1437840, was opened at 2006-02-23 21:58 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=1437840&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: Accepted Priority: 5 Submitted By: Mark F. Haigh (mfhaigh) Assigned to: Greg Stein (gstein) Summary: Compile fix rollup patch against 2.0.0 Initial Comment: The attached rollup patch fixes the following bugs: #1414066 - make failes on hpux #1033965 - Building application fails with Intel C compiler (1.95.7) #N/A - Build fails on Tru64 UNIX. The patch was tested on x86-64 Linux, i386 NetBSD, HP-UX 11i, and Tru64 5.1b. All tests passed on each machine. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-03-06 09:25 Message: Logged In: YES user_id=290026 Patch applied March 6, 2006. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-02-27 17:02 Message: Logged In: NO You could get really anal and note that the conversion from a pointer type to an integer type is implementation-defined by the C standard in the first place. But we all know it "just works" nearly everywhere. The code here is broken anyways. And since the value is never really _used_, it doesn't matter. But changing the cast to long prevents a warning on all architectures I know of except for Windows-64, which uses a 32 bit long and 64 bit pointers (LLP64 model). Using the newer C99 types is preferable, of course, and the best thing to do is to provide an autoconf-assisted stdint.h that can be used if the system doesn't have stdint.h. Note that uintptr_t and friends are optional types under C99 anyways! But, like I said, all this does is paper-over a (well-deserved) warning, nothing more. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-02-27 09:42 Message: Logged In: YES user_id=290026 Actually, it should be uintptr_t or intptr_t, but the question is, how many compilers recognize these types (were they not introduced with C99?). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-02-27 09:26 Message: Logged In: YES user_id=290026 One question about the patch to runtests.c: - int callno = 1 + (int)XML_GetUserData(parser); + long callno = 1 + (long)XML_GetUserData(parser); Why changing from int to long? If we really want to be anal, why not change to ptrdiff_t, as callno hast to fit into a pointer? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-02-24 10:16 Message: Logged In: YES user_id=290026 Thanks. Seems to work on Cygwin as well. Will check it in if Greg has no objections. ---------------------------------------------------------------------- Comment By: Mark F. Haigh (mfhaigh) Date: 2006-02-23 23:10 Message: Logged In: YES user_id=1458985 The patch was against the 2.0.0 release. I'm attaching the same patch against CVS as of Feb 23, 2006, 8:00 PST. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-02-23 22:10 Message: Logged In: YES user_id=290026 Is this patch against CVS? It fails for me on Makefile.in: $ patch -i compile-rollup.patch -p 1 patching file lib/expat_external.h patching file Makefile.in Hunk #3 succeeded at 157 (offset 1 line). Hunk #4 FAILED at 172. 1 out of 4 hunks FAILED -- saving rejects to file Makefile.in.rej patching file tests/minicheck.h patching file tests/runtests.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=1437840&group_id=10127 From noreply at sourceforge.net Mon Mar 6 15:43:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 06:43:30 -0800 Subject: [Expat-bugs] [ expat-Bugs-1414066 ] make failes on hpux Message-ID: Bugs item #1414066, was opened at 2006-01-24 16:25 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1414066&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: Warren Smith (warren_smith) Assigned to: Greg Stein (gstein) Summary: make failes on hpux Initial Comment: Make fails with builtin make with this error: Make: Must be a separator on rules line 48. Stop. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-03-06 09:43 Message: Logged In: YES user_id=290026 Patch #1437840 applied on March 6, 2006. ---------------------------------------------------------------------- Comment By: Mark F. Haigh (mfhaigh) Date: 2006-02-23 22:04 Message: Logged In: YES user_id=1458985 I rolled up the compile fixes for 2.0.0 into patch #1437840. Use that instead of #1436978 (which has been deleted). ---------------------------------------------------------------------- Comment By: Mark F. Haigh (mfhaigh) Date: 2006-02-22 15:46 Message: Logged In: YES user_id=1458985 Check out patch #1436978. I can't seem to attach a file here. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-01-24 17:52 Message: Logged In: YES user_id=290026 I don't have HPUX available, and neither does the SF compile farm. Unless Greg has an idea, I am afraid the best help you can get is by debugging this on your own, and then post the solution here for others to see. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1414066&group_id=10127 From noreply at sourceforge.net Mon Mar 6 15:44:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 06:44:53 -0800 Subject: [Expat-bugs] [ expat-Bugs-1284386 ] Byte count in large XML files fails Message-ID: Bugs item #1284386, was opened at 2005-09-07 21:01 Message generated for change (Comment added) made by kwaclaw 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: Karl Waclawek (kwaclaw) Date: 2006-03-06 09:44 Message: Logged In: YES user_id=290026 Closing this issue - no complaints received. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-01-12 19: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 16: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 23: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 18: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 09: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 21: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 20: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 19: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 18: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 15: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 15: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 14: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 Mon Mar 6 15:45:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 06:45:39 -0800 Subject: [Expat-bugs] [ expat-Bugs-1271642 ] ill-formed output for `xmlwf -c -d` on ISO-8859-1 Message-ID: Bugs item #1271642, was opened at 2005-08-25 07:26 Message generated for change (Settings changed) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1271642&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: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: ill-formed output for `xmlwf -c -d` on ISO-8859-1 Initial Comment: If I run: xmlwf -c -d /tmp bug.xml with bug.xml containing: 123 then the result is: é123 The start tag for e is lost and the entity ref in the attribute is copied. Note that this bug does not happen if the encoding is UTF-8 or US-ASCII. Bug reproduced by a third party, see: http://mail.libexpat.org/pipermail/expat-discuss/2005-August/001880.html ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-03-06 09:45 Message: Logged In: YES user_id=290026 Closing this issue - no complaints received. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-11-24 09:16 Message: Logged In: YES user_id=290026 Fixed in xmlparse.c rev. 1.149. Needs testing. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-08-25 11:46 Message: Logged In: YES user_id=290026 It appears this is caused by an inapproriate call to the default handler in appendAttributeValue(). Removing this call seems to fix the problem. Please apply and test the patch attached as file patch1.diff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1271642&group_id=10127 From noreply at sourceforge.net Mon Mar 6 15:48:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 06:48:38 -0800 Subject: [Expat-bugs] [ expat-Bugs-946506 ] PublicId for DOCTYPE not checked & normalized Message-ID: Bugs item #946506, was opened at 2004-05-02 13:28 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=946506&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: Closed Resolution: Fixed Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: PublicId for DOCTYPE not checked & normalized Initial Comment: The public id passed to the StartDocTypeDeclHandler() is not checked for legal characters and not normalized. However, the same public id passed to the ExternalEntityRefHandler() is normalized. This is because the former uses the docTypePubId member and the latter uses a hash table lookup for a declared entity. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-03-06 09:48 Message: Logged In: YES user_id=290026 No test cases were built, but since there were no complaints for a long time, we close this issue. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-05-02 13:33 Message: Logged In: YES user_id=290026 Fixed with attached patch in xmlparse.c rev. 1.133. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=946506&group_id=10127 From noreply at sourceforge.net Mon Mar 6 15:49:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 06:49:28 -0800 Subject: [Expat-bugs] [ expat-Bugs-1090885 ] Problem with Suspend/Resume mechanism Message-ID: Bugs item #1090885, was opened at 2004-12-24 11:19 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1090885&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: Closed Resolution: Fixed Priority: 5 Submitted By: Peter Van der Beken (peter_vdb) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Problem with Suspend/Resume mechanism Initial Comment: I block the parser and there is still some data left in the buffer, that data is not the last data of the XML file and it ends on a partial token ("Comment By: Karl Waclawek (kwaclaw) Date: 2006-03-06 09:49 Message: Logged In: YES user_id=290026 No test cases were built, but since there were no complaints for a long time, we close this issue. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-12-24 11:32 Message: Logged In: YES user_id=290026 Fixed in xml_parse.c 1.141. Thanks for reporting this, Peter. Leaving it open for testing. Assigned to Fred. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1090885&group_id=10127 From noreply at sourceforge.net Mon Mar 6 15:51:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 06:51:06 -0800 Subject: [Expat-bugs] [ expat-Bugs-1023646 ] Error in codepageMap, codepage.c Message-ID: Bugs item #1023646, was opened at 2004-09-07 08:39 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1023646&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: Platform Specific >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Error in codepageMap, codepage.c Initial Comment: Applies to expat v.1.95.8 >From MS: "LeadByte: Specifies a fixed-length array of lead-byte ranges, where the number of lead-byte ranges is variable. If there are no lead bytes in this code page, then every element of the array is NULL. If there are lead bytes in this code page, a starting value and ending value is specified for each range. Ranges are inclusive. The maximum number of lead-byte ranges for any code page is five. The array uses two bytes to describe each range, with a double-byte null terminator after the last range." Note that "Ranges are inclusive". Therefore the function codepageMap should be changed: for (i = 0; i < MAX_LEADBYTES; i+=2) { int j, lim; if (info.LeadByte[i] == 0 && info.LeadByte[i + 1] == 0) break; lim = info.LeadByte[i + 1]; for (j = info.LeadByte[i]; j <= lim; j++) map[j] = -2; } Regards, Ole Stauning, spam at uning.dk ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-03-06 09:51 Message: Logged In: YES user_id=290026 No test cases were built, but since there were no complaints for a long time, we close this issue. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-04-19 14:26 Message: Logged In: YES user_id=290026 Forget my question, I went ahead and committed it. See codepage.c rev. 1.12. Assigned to Fred for testing. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-04-19 13:56 Message: Logged In: YES user_id=290026 To Fred: Has this been committed yet? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-27 10:17 Message: Logged In: YES user_id=3066 Then I think this is ok to commit if everything continues to work for you on Windows. I'll email the original poster since it doesn't look like SF will be sending him updates automatically. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-27 09:46 Message: Logged In: YES user_id=290026 FWIW, I agree with the above conclusions as well. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-27 00:44 Message: Logged In: YES user_id=3066 I'm inclined to agree, having read the CPINFO documentation. Do you have a test case that breaks using the current code, and which your proposed change would fix? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1023646&group_id=10127 From noreply at sourceforge.net Mon Mar 6 15:51:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 06:51:49 -0800 Subject: [Expat-bugs] [ expat-Bugs-1088215 ] Inconsistent namespace separator Message-ID: Bugs item #1088215, was opened at 2004-12-20 00:16 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1088215&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: Closed Resolution: Fixed Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Inconsistent namespace separator Initial Comment: When the namespace separator is the null character, it will be omitted between uri and local name. However, when namespace triplets are turned on, the namespace separator between local name and prefix is inconsistently treated, sometimes omitted, sometimes not. The attached patch enforces consistent behaviour such that the separator between local name and prefix is never omitted. This is OK because it is an error to use a null separator in the case of namespace triplets, as per the documentation for XML_ParserCreateNS(). ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-03-06 09:51 Message: Logged In: YES user_id=290026 No test cases were built, but since there were no complaints for a long time, we close this issue. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-12-20 00:17 Message: Logged In: YES user_id=290026 The patch was applied in xmlparse.c rev. 1.139. Testing required - assigned to Fred. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1088215&group_id=10127 From noreply at sourceforge.net Mon Mar 6 15:52:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 06:52:20 -0800 Subject: [Expat-bugs] [ expat-Bugs-920274 ] xml: namespace not closed after entity Message-ID: Bugs item #920274, was opened at 2004-03-20 18:35 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=920274&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: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: xml: namespace not closed after entity Initial Comment: When an external entity is parsed, StartNamespaceDecl is called for xml http://www.w3.org/1998/namespace (from setContext). On exit, EndNamespaceDecl is not called, and the calls become unbalanced. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-03-06 09:52 Message: Logged In: YES user_id=290026 No test cases were built, but since there were no complaints for a long time, we close this issue. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-04-30 00:25 Message: Logged In: YES user_id=290026 The patch has been committed to xmlparse.c - forgot which revision. Needs testing. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-04-07 20:10 Message: Logged In: YES user_id=290026 Please check if the attached patch - nsDecl.diff - works for you. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-03-22 22:58 Message: Logged In: YES user_id=290026 Assigned to me - would like to have this resolved before releasing 1.95.8. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-03-20 21:52 Message: Logged In: YES user_id=290026 I looked at the code, and I am wondering why startNamespaceDecl() is called at all. Why should Expat call it when starting to parse an external entity? Am I overlooking something? At the moment it appears to me that this call-back is an undesirable side-effect of a child parser inheriting namespace scopes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=920274&group_id=10127 From noreply at sourceforge.net Mon Mar 6 15:52:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 06:52:50 -0800 Subject: [Expat-bugs] [ expat-Bugs-916228 ] Crash when XML_DTD not defined Message-ID: Bugs item #916228, was opened at 2004-03-14 19:39 Message generated for change (Settings changed) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=916228&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: Closed Resolution: Fixed Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Crash when XML_DTD not defined Initial Comment: Reported by Nicholas Hendricks: When XML_DTD is not defined, but an internal general entity is declared, Expat crashes in storeEntityValue, since the string pool "entityValuePool" is not initialized in this case. The solution is to remove the compile condition for initializing and finalizing entityValuePool. The attached file test1.xml causes the crash when using an instance of Expat compiled with XML_DTD undefined. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-03-06 09:52 Message: Logged In: YES user_id=290026 No test cases were built, but since there were no complaints for a long time, we close this issue. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-03-14 19:45 Message: Logged In: YES user_id=290026 Fixed in revision 1.124 of xmlparse.c - see attached file xmlparse.diff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=916228&group_id=10127 From noreply at sourceforge.net Mon Mar 6 15:50:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 06:50:12 -0800 Subject: [Expat-bugs] [ expat-Bugs-1156398 ] XML_UseForeignDTD forces incorrect WF checking Message-ID: Bugs item #1156398, was opened at 2005-03-03 21:19 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1156398&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: Closed Resolution: Fixed Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: XML_UseForeignDTD forces incorrect WF checking Initial Comment: When Expat calls the externalEntityRefHandler within the prolog, then it concludes that there must be an external subset, as there was an external identifier encountered. This information influences how the WFC: Entity Declared is checked. However, when Expat calls the externalEntityRefHandler in order to allow the application to supply an external subset when there was none, then Expat should not make this assumption unless an actual subset has been processed, as indicated by the dtd->paramEntityRead flag. The attached patch fixes this. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-03-06 09:50 Message: Logged In: YES user_id=290026 No test cases were built, but since there were no complaints for a long time, we close this issue. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-06-20 09:57 Message: Logged In: YES user_id=290026 Forgot to mention: This patch was applied in xmlparse.c rev. 1.147. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-03-03 23:18 Message: Logged In: YES user_id=290026 We could use the following document for a test case:: ]> reference doesn't match delaration This document violates WFC: Entity Declared and Expat must return an error. However, if this document had an external subset then WFC: Entity Declared would not apply. Now, if one calls XML_UseForeignDTD() at the start of parsing the document above, then Expat 1.95.8 will accept the document, which is not correct. The patched version of Expat will return an error as it should. Assigned to Fred for testing. I really want this to be in release 2.0, as it improves the conformance against the XML_Test-Suite. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1156398&group_id=10127 From noreply at sourceforge.net Mon Mar 6 15:42:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 06:42:19 -0800 Subject: [Expat-bugs] [ expat-Patches-1210586 ] Typo fixes Message-ID: Patches item #1210586, was opened at 2005-05-28 21:27 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=1210586&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: Documentation Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Olly Betts (olly) Assigned to: Nobody/Anonymous (nobody) Summary: Typo fixes Initial Comment: I noticed a few typos in expat while preparing a patch to clean up the wxwindows docs (wxwindows includes a copy of expat in its tree). It seemed to make most sense to send these upstream. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-03-06 09:42 Message: Logged In: YES user_id=290026 Thanks. Patch applied March 6, 2006. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=1210586&group_id=10127 From noreply at sourceforge.net Mon Mar 6 15:44:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 06:44:16 -0800 Subject: [Expat-bugs] [ expat-Bugs-1033965 ] Building application fails with Intel C compiler (1.95.7) Message-ID: Bugs item #1033965, was opened at 2004-09-24 07:12 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1033965&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: Arjen Markus (arjenmarkus) Assigned to: Greg Stein (gstein) Summary: Building application fails with Intel C compiler (1.95.7) Initial Comment: I tried to build a small application using the Intel C compiler under Linux. The compiler chokes on the use of the macro XMLCALL: ../lib/include/expat.h(261): warning #1287: invalid attribute for field "malloc_fcn" void *(XMLCALL *malloc_fcn)(size_t size); ^ The macro seems to be set to an empty string, as there is no specific information for that compiler in the header file, but I have not thoroughly investigated this. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-03-06 09:44 Message: Logged In: YES user_id=290026 Patch #1437840 applied on March 6, 2006. ---------------------------------------------------------------------- Comment By: Mark F. Haigh (mfhaigh) Date: 2006-02-23 22:05 Message: Logged In: YES user_id=1458985 I rolled up the compile fixes for 2.0.0 into patch #1437840. Use that instead of #1437014 (which has been deleted). ---------------------------------------------------------------------- Comment By: Mark F. Haigh (mfhaigh) Date: 2006-02-22 16:34 Message: Logged In: YES user_id=1458985 Patch #1437014 should fix the problem. Unfortunately I am not able to attach a patch directly to this bug. ---------------------------------------------------------------------- Comment By: Mark F. Haigh (mfhaigh) Date: 2006-02-22 16:33 Message: Logged In: YES user_id=1458985 Patch #1437014 should fix the problem. Unfortunately I am not able to attach a patch directly to this bug. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-28 11:02 Message: Logged In: YES user_id=3066 The second document refers to a compatibility guide which hints at the right information, but doesn't contain the specific details I'm looking for. I'll try contacting Intel or getting a copy of the compiler. It notes that the current version of the Intel compiler supports "most" of the GCC function attributes, but it doesn't say which ones specifically. The download page for the compatibility guide is: http://www.intel.com/software/products/compilers/techtopics/LinuxCompilersCompatibility.htm ---------------------------------------------------------------------- Comment By: Arjen Markus (arjenmarkus) Date: 2005-01-28 08:59 Message: Logged In: YES user_id=400048 Here are some comments on the Intel C compiler from a Linux user that seem relevant: http://www.mcsr.olemiss.edu/parallelogram/01_03/icc.html >From the Intel site: http://www.intel.com/software/products/compilers/clin/clinux.htm I do not know whether this will actually help you solve the problem. Perhaps a direct question to the Intel support people might help. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-27 23:42 Message: Logged In: YES user_id=3066 I really don't like having bogus warnings being generated; if those can be cleared up, I'd like to do so. Is documentation for the Intel compiler available online? I'd be especially interested in material on compiler hints and attributes. ---------------------------------------------------------------------- Comment By: Arjen Markus (arjenmarkus) Date: 2004-09-27 05:41 Message: Logged In: YES user_id=400048 I tried with Expat 1.95.8: the result was two warnings only, but the C source was compiled and the program that finally results does the job correctly. Here are the warnings: ../expat-1.95.8/lib/expat.h(501): warning #1287: invalid attribute for field "convert" int (XMLCALL *convert)(void *data, const char *s); ^ ../expat-1.95.8/lib/expat.h(502): warning #1287: invalid attribute for field "release" void (XMLCALL *release)(void *data); ^ (As far as I am concerned: this version is okay :)) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-09-24 08:58 Message: Logged In: YES user_id=290026 This might not be a problem with Expat 1.95.8. Could you please try? Karl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1033965&group_id=10127 From noreply at sourceforge.net Mon Mar 6 15:55:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 06:55:16 -0800 Subject: [Expat-bugs] [ expat-Bugs-1408143 ] "make check" failure Message-ID: Bugs item #1408143, was opened at 2006-01-17 07:20 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1408143&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: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: "make check" failure Initial Comment: From: Peter Breitenlohner expat-2.0.0 When running "make check" (with VPATH, i.e. outside the source tree), g++ was invoked without any '-I' and thus has included some old installed headers from 1.95.8 resulting in a compilation error due to the missing declaration of XML_Size. Attached is a small patch fixing this. The patch also makes a difference between CFLAGS and CXXFLAGS in order to avoid the warnings that g++ doesn't want "-Wmissing-prototypes -Wstrict-prototypes". ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-03-06 09:55 Message: Logged In: YES user_id=290026 No further complaints - closing this issue. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-01-25 18:07 Message: Logged In: YES user_id=290026 After some discussion and testing from other team members, the attached patch was accepted (except for the changes to configure, as this file is a generated file and not in CVS). Applied in Makefile.in rev. 1.54 and configure.in rev. 1.42. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1408143&group_id=10127 From noreply at sourceforge.net Mon Mar 6 15:56:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 06:56:34 -0800 Subject: [Expat-bugs] [ expat-Bugs-695407 ] Reserved prefixes and namespace names Message-ID: Bugs item #695407, was opened at 2003-02-28 20:46 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=695407&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: Closed Resolution: Fixed Priority: 3 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Reserved prefixes and namespace names Initial Comment: Expat does not reject illegal declarations for reserved prefixes and namespace names. From the errata for the Namespaces in XML 1.0 specs: <quote> The prefix xml is by definition bound to the namespace name http://www.w3.org/XML/1998/namespace. It may, but need not, be declared, and must not be bound to any other namespace name. No other prefix may be bound to this namespace name. The prefix xmlns is used only to declare namespace bindings and is by definition bound to the namespace name http://www.w3.org/2000/xmlns/. It must not be declared. No other prefix may be bound to this namespace name. </quote> The following four not-well-formed documents are not rejected by Expat: <?xml version="1.0"?> <!-- Reserved prefixes and namespaces: declaring the xml prefix incorrectly --> <foo xmlns:xml="http://example.org/namespace"/> <?xml version="1.0"?> <!-- Reserved prefixes and namespaces: binding another prefix to the xml namespace --> <foo xmlns:yml="http://www.w3.org/XML/1998/namespace"/> <?xml version="1.0"?> <!-- Reserved prefixes and namespaces: declaring the xmlns prefix with its correct URI (illegal) --> <foo xmlns:xmlns="http://www.w3.org/2000/xmlns/"/> <?xml version="1.0"?> <!-- Reserved prefixes and namespaces: declaring the xmlns prefix with an incorrect URI --> <foo xmlns:xmlns="http://example.org/namespace"/> ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-03-06 09:56 Message: Logged In: YES user_id=290026 No test cases were built, but since there were no complaints for a long time, we close this issue. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-12-24 13:02 Message: Logged In: YES user_id=290026 Finally fixed in expat.h rev. 1.75 and xmlparse.c rev. 1.142. Fix contributed by Peter van der Beken. Thank you, Peter. We should be very close to passing all test cases in the XML-Test-Suite. Left open for regression test case. Assigned to Fred. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-13 08:26 Message: Logged In: YES user_id=290026 Lowered priority to 3. This bug really doesn't have much impact in practical applications, but fixing it may add noticeable overhead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=695407&group_id=10127 From noreply at sourceforge.net Thu Mar 9 14:56:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Mar 2006 05:56:48 -0800 Subject: [Expat-bugs] [ expat-Bugs-1196180 ] Error durring Make under Solaris 9 Message-ID: Bugs item #1196180, was opened at 2005-05-05 13:26 Message generated for change (Comment added) made by mfhaigh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1196180&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: Fred L. Drake, Jr. (fdrake) Summary: Error durring Make under Solaris 9 Initial Comment: I am getting the following error during the make. I am running SOlaris 9 with gcc ver 3.1 bash-2.05# make /bin/bash ./libtool --silent --mode=link gcc -g -O2 -Wall - Wmissing-prototypes -Wstrict-prototypes -fexceptions - DHAVE_EXPAT_CONFIG_H -I./lib -I. -no-undefined - version-info 5:0:5 -rpath /usr/local/lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo Undefined first referenced symbol in file __eprintf lib/xmlparse.lo ld: fatal: Symbol referencing errors. No output written to .libs/libexpat.so.0.5.0 make: *** [libexpat.la] Error 1 ---------------------------------------------------------------------- Comment By: Mark F. Haigh (mfhaigh) Date: 2006-03-09 05:56 Message: Logged In: YES user_id=1458985 The 2.0.0 release doesn't compile, but the compile fix rollup patch that's been already applied to CVS fixes them. Verified on a Solaris 9 box / gcc: Expat version: expat_2.0.0 100%: Checks: 48, Failed: 0 tests/runtestspp Expat version: expat_2.0.0 100%: Checks: 48, Failed: 0 mfhaigh at solaris$ This can probably be closed. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-06-30 13:01 Message: Logged In: NO I am getting something similar: root at f2sys1 (2133)[/home/ken/expat/expat-1.95.8]# make all /bin/sh ./libtool --silent --mode=compile gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONF IG_H -I./lib -I. -o lib/xmlparse.lo -c lib/xmlparse.c /bin/sh ./libtool --silent --mode=compile gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONF IG_H -I./lib -I. -o lib/xmltok.lo -c lib/xmltok.c /bin/sh ./libtool --silent --mode=compile gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONF IG_H -I./lib -I. -o lib/xmlrole.lo -c lib/xmlrole.c /bin/sh ./libtool --silent --mode=link gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_ H -I./lib -I. -no-undefined -version-info 5:0:5 -rpath /usr/local/lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo ld: 0711-415 WARNING: Symbol _GLOBAL__F_XML_ParserCreate is already exported. ld: 0711-415 WARNING: Symbol _GLOBAL__F_XmlUtf8Encode is already exported. ld: 0711-415 WARNING: Symbol _GLOBAL__F_XmlPrologStateInit is already exported. gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -I./lib -I. -o xmlwf/xmlwf.o -c xml wf/xmlwf.c gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -I./lib -I. -o xmlwf/xmlfile.o -c x mlwf/xmlfile.c gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -I./lib -I. -o xmlwf/codepage.o -c xmlwf/codepage.c gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -I./lib -I. -o xmlwf/readfilemap.o -c xmlwf/readfilemap.c /bin/sh ./libtool --silent --mode=link gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_ H -I./lib -I. -o xmlwf/xmlwf xmlwf/xmlwf.o xmlwf/xmlfile.o xmlwf/codepage.o xmlwf/readfilemap.o libexpat.la gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -I./lib -I. -o examples/elements.o -c examples/elements.c /bin/sh ./libtool --silent --mode=link gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_ H -I./lib -I. -o examples/elements libexpat.la ld: 0711-317 ERROR: Undefined symbol: .main ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status make: 1254-004 The error code from the last command is 1. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-06-15 05:39 Message: Logged In: YES user_id=290026 Fred, what about the posted patch? ---------------------------------------------------------------------- Comment By: SylikC (sylikc) Date: 2005-05-24 17:13 Message: Logged In: YES user_id=1060368 Hi, I've found a quick-fix to this problem compiling on solaris identified by configure as "sparc-sun-solaris2.8" The reference to __eprintf from lib/xmlparse.c is somewhat misleading. It ends up that xmlparse.c has included the system header assert.h, and it is there where the source of the error lies. I can't seem to find libgcc.a on my system, and I've read a few things on the web that talk about needing that static library in order to link to __eprintf(). Anyhow, the logical temporary fix (just so you could compile and be on your way) was just to comment out the 2 references to assert, both the include and the call, on lines 7 and 1739 in expat-1.95.8. I'm assuming this should be harmless in that assert() calls are just debug calls. Here's the diff ----------------------- 7c7 < #include --- > //#include 1739c1739 < assert(status != NULL); --- > //assert(status != NULL); ----------------------- /sylikc ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1196180&group_id=10127 From noreply at sourceforge.net Thu Mar 9 15:04:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Mar 2006 06:04:53 -0800 Subject: [Expat-bugs] [ expat-Bugs-1196180 ] Error durring Make under Solaris 9 Message-ID: Bugs item #1196180, was opened at 2005-05-05 16:26 Message generated for change (Settings changed) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1196180&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: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Error durring Make under Solaris 9 Initial Comment: I am getting the following error during the make. I am running SOlaris 9 with gcc ver 3.1 bash-2.05# make /bin/bash ./libtool --silent --mode=link gcc -g -O2 -Wall - Wmissing-prototypes -Wstrict-prototypes -fexceptions - DHAVE_EXPAT_CONFIG_H -I./lib -I. -no-undefined - version-info 5:0:5 -rpath /usr/local/lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo Undefined first referenced symbol in file __eprintf lib/xmlparse.lo ld: fatal: Symbol referencing errors. No output written to .libs/libexpat.so.0.5.0 make: *** [libexpat.la] Error 1 ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-03-09 09:04 Message: Logged In: YES user_id=290026 Closing this issue as per Mark's successful test. ---------------------------------------------------------------------- Comment By: Mark F. Haigh (mfhaigh) Date: 2006-03-09 08:56 Message: Logged In: YES user_id=1458985 The 2.0.0 release doesn't compile, but the compile fix rollup patch that's been already applied to CVS fixes them. Verified on a Solaris 9 box / gcc: Expat version: expat_2.0.0 100%: Checks: 48, Failed: 0 tests/runtestspp Expat version: expat_2.0.0 100%: Checks: 48, Failed: 0 mfhaigh at solaris$ This can probably be closed. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-06-30 16:01 Message: Logged In: NO I am getting something similar: root at f2sys1 (2133)[/home/ken/expat/expat-1.95.8]# make all /bin/sh ./libtool --silent --mode=compile gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONF IG_H -I./lib -I. -o lib/xmlparse.lo -c lib/xmlparse.c /bin/sh ./libtool --silent --mode=compile gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONF IG_H -I./lib -I. -o lib/xmltok.lo -c lib/xmltok.c /bin/sh ./libtool --silent --mode=compile gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONF IG_H -I./lib -I. -o lib/xmlrole.lo -c lib/xmlrole.c /bin/sh ./libtool --silent --mode=link gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_ H -I./lib -I. -no-undefined -version-info 5:0:5 -rpath /usr/local/lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo ld: 0711-415 WARNING: Symbol _GLOBAL__F_XML_ParserCreate is already exported. ld: 0711-415 WARNING: Symbol _GLOBAL__F_XmlUtf8Encode is already exported. ld: 0711-415 WARNING: Symbol _GLOBAL__F_XmlPrologStateInit is already exported. gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -I./lib -I. -o xmlwf/xmlwf.o -c xml wf/xmlwf.c gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -I./lib -I. -o xmlwf/xmlfile.o -c x mlwf/xmlfile.c gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -I./lib -I. -o xmlwf/codepage.o -c xmlwf/codepage.c gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -I./lib -I. -o xmlwf/readfilemap.o -c xmlwf/readfilemap.c /bin/sh ./libtool --silent --mode=link gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_ H -I./lib -I. -o xmlwf/xmlwf xmlwf/xmlwf.o xmlwf/xmlfile.o xmlwf/codepage.o xmlwf/readfilemap.o libexpat.la gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -I./lib -I. -o examples/elements.o -c examples/elements.c /bin/sh ./libtool --silent --mode=link gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_ H -I./lib -I. -o examples/elements libexpat.la ld: 0711-317 ERROR: Undefined symbol: .main ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status make: 1254-004 The error code from the last command is 1. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-06-15 08:39 Message: Logged In: YES user_id=290026 Fred, what about the posted patch? ---------------------------------------------------------------------- Comment By: SylikC (sylikc) Date: 2005-05-24 20:13 Message: Logged In: YES user_id=1060368 Hi, I've found a quick-fix to this problem compiling on solaris identified by configure as "sparc-sun-solaris2.8" The reference to __eprintf from lib/xmlparse.c is somewhat misleading. It ends up that xmlparse.c has included the system header assert.h, and it is there where the source of the error lies. I can't seem to find libgcc.a on my system, and I've read a few things on the web that talk about needing that static library in order to link to __eprintf(). Anyhow, the logical temporary fix (just so you could compile and be on your way) was just to comment out the 2 references to assert, both the include and the call, on lines 7 and 1739 in expat-1.95.8. I'm assuming this should be harmless in that assert() calls are just debug calls. Here's the diff ----------------------- 7c7 < #include --- > //#include 1739c1739 < assert(status != NULL); --- > //assert(status != NULL); ----------------------- /sylikc ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1196180&group_id=10127 From noreply at sourceforge.net Thu Mar 9 17:13:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Mar 2006 08:13:08 -0800 Subject: [Expat-bugs] [ expat-Bugs-1007100 ] Release and Debug DLLs should have different names Message-ID: Bugs item #1007100, was opened at 2004-08-11 04:26 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1007100&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: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Release and Debug DLLs should have different names Initial Comment: On windows, (unlike on Unix) it is a wise idea to have output dlls and libs for release and debug with different names, possibly following the Python convention: python.exe python_d.exe python23.dll python23_d.dll etc... The ACE library is another one: ace.dll aced.dll And IBMs unicode libraries (ICU) follow a similar converntion. The reason for this is that applications may encounter runtime errors when linking to libraries that use a different heap, and release and debug versions generally do this. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-03-09 11:13 Message: Logged In: YES user_id=290026 I am not convinced that this is a good idea for Expat. Everytime I would like to debug I need to link to a different library. This is inconvenient. I am not sure that Expat will have a problem with different heaps, as the API does not require cross-allocation or cross-deallocation of memory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1007100&group_id=10127 From noreply at sourceforge.net Thu Mar 9 17:15:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Mar 2006 08:15:12 -0800 Subject: [Expat-bugs] [ expat-Bugs-491986 ] Charset decoding error (64-bit systems) Message-ID: Bugs item #491986, was opened at 2001-12-12 07:48 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=491986&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: Platform Specific >Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Bent Jensen (bentjensen) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Charset decoding error (64-bit systems) Initial Comment: When parsing xml with Danish letters (??????) with eight bit set and declaring the encoding as <?xml version="1.0" encoding="iso-8859-1"?> (where the danish letters is placed as eight bit chars - the parser goes wrong. If the input is: <person id="five.worker"> <name><family>Worker</family> <given>Five</given></name> <email>J&oslash;rgen five at foo.com</email> <email>J?rgen five at foo.com</email> <link manager="Big.Boss"/> </person> (Remark the danish letters in two forms) The output is: START: email CD: (null) - 'J' - 1 CD: (null) - 'rgen five at foo.com' - 17 END: email CD: (null) - ' ' - 1 CD: (null) - ' ' - 4 START: email CD: (null) - 'J?&#1567;rgen five at foo.com' - 20 END: email CD: (null) - ' ' - 1 CD: (null) - ' ' - 4 What am i doing wrong ? If I embedd the string '??????' in the xml file - it goes all rigth ?!?! I have modifyed the 'outline' example program for the above test. Sincerly Bent Jensen, Senior consultant. bent at kiya.dk ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-03-09 11:15 Message: Logged In: YES user_id=290026 Closing this issue as out-of-date. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-11-20 00:13 Message: Logged In: YES user_id=3066 Using the SourceForge compile farm, I'm not able to get the test to trigger a failure on either Alpha or Sparc64 processors (both running Linux). If there's not a confirmation that this can still be triggered by the 1.95.6 release, I'll close this as out-of-date. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-10-05 11:37 Message: Logged In: YES user_id=290026 About the portability of bit shifts: If Expat used integer types with fixed sizes (e.g.those defined in C99) instead of platform dependent ones, or if we defined our own types to be always of the desired size regardless of platform, should that not solve the problem? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-07-10 13:59 Message: Logged In: YES user_id=3066 I just tried this on the Alpha system on the SourceForge compile farm and the CVS version of Expat, and the regression test I added doesn't trigger. Can you still reproduce this with the CVS version of Expat? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-19 15:45 Message: Logged In: YES user_id=3066 Good point. I've re-opened the report and noted the 64-bit dependency in the summary. ---------------------------------------------------------------------- Comment By: Bent Jensen (bentjensen) Date: 2002-04-19 15:14 Message: Logged In: YES user_id=392963 Hi again I have tried all combinations of telleing the parset that i want to use iso-8859-1 encoding - also to the XML_ParserCreate function. But you have to remark that i am running on a 64 bit machine and in the routine where you are reading the input chars you are doing bit shifts 'en masse' - and here everything can goes wrong - bitshifts are not portable ! Sincerly Bent Jensen, Senior consultant. bent at kiya.dk ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-19 14:46 Message: Logged In: YES user_id=3066 I cannot reproduce this using CVS Expat. I've added a regression test for this to be sure it doesn't crop up (tests/runtests.c revision 1.7). Make sure that you're passing either NULL or "iso-8859-1" to the XML_ParserCreate*() function as the encoding name. ---------------------------------------------------------------------- Comment By: Bent Jensen (bentjensen) Date: 2001-12-12 07:56 Message: Logged In: YES user_id=392963 Info: The expat package (version 1.95.2) was build on alpha/axp OSF1 4.0D with gcc version 2.95.3. The test was run on the same machine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=491986&group_id=10127 From noreply at sourceforge.net Thu Mar 9 17:17:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Mar 2006 08:17:40 -0800 Subject: [Expat-bugs] [ expat-Bugs-1426640 ] Build fails on Darwin Message-ID: Bugs item #1426640, was opened at 2006-02-07 16:30 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1426640&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: Closed >Resolution: Rejected Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Build fails on Darwin Initial Comment: Unable to install expat 2.0.0 on my Mac. I get the following nonsense trying to build expat 2.0.0 on Mac OSX 10.4.4 : make /bin/sh ./libtool --silent --mode=link gcc -I./lib -I. -g -O2 -Wall - Wmissing-prototypes -Wstrict-prototypes -fexceptions - DHAVE_EXPAT_CONFIG_H -no-undefined -version-info 6:0:5 -rpath / usr/local/lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo /usr/bin/libtool: for architecture: cputype (16777234) cpusubtype (0) file: -lSystem is not an object file (not allowed in a library) make: *** [libexpat.la] Error 1 ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-03-09 11:17 Message: Logged In: YES user_id=290026 This seems to be a gcc problem, not an Expat issue. Closing due to lack of follow-up by the original poster. ---------------------------------------------------------------------- Comment By: Ryan Schmidt (ryandesign) Date: 2006-02-13 19:33 Message: Logged In: YES user_id=838923 I don't have any problem building expat 2.0.0 with Mac OS X 10.4.4 PPC. Googling for your error turned up this page http://www.petercooper.co.uk/archives/000698.html which says that it's a problem with GCC 3.x and since you're using Tiger you should be using GCC 4.x. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-02-07 18:15 Message: Logged In: YES user_id=290026 It seems we have no Mac OS X experts here. If you figure out the problem, can you provide a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1426640&group_id=10127 From noreply at sourceforge.net Fri Mar 17 10:53:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Mar 2006 01:53:27 -0800 Subject: [Expat-bugs] [ expat-Bugs-1452136 ] Expat-2.0.0: Win2003 - Buffer Overrun in XML_Parse Message-ID: Bugs item #1452136, was opened at 2006-03-17 01:53 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=1452136&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: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Expat-2.0.0: Win2003 - Buffer Overrun in XML_Parse Initial Comment: The following problem only occurs in Windows 2003 platform ! Buffer Overrun occurs when the following XML data is being parsed: ---------xml--------- LN.MRS.MRS.JE.EOS.EOS.ACCOUNT -label JE.EOS.EOS.ACCOUNT -sqm LNGDC1P1 - dqm JEEOS1P1 at JECHQ1P1 - spath /shared/home/mrsop/fub/ACCT.CSV -dpath E:\ISIS\FINRPT\Account_Master.CSV -type text -exit 8 - exitdll isispost.dll -exitentry isispost -exitdata "@JBE:\\ISIS\\scripts\\FINRPT.BAT;@JBE:\\ISIS\\scr ipts\\FINRPT\_FAIL.BAT" -exit 4 -exitdll isispost -exitentry isispost -exitdata "@JB/shared/home/mrsop/scr/isis\_postproc.sh_/shar ed/home/mrsop/fub/ACCT.CSV_ARC;@JB/shared/home/mrsop/sc r/isis\_failproc.sh_/shared/home/mrsop/fub/ACCT.CSV_ERR OR" -oqm LNGDC1P1 Future Bank 16162f01-ad5c-11da-9fb4-92c88c876801 ---------xml--------- Below are the list of function calls to describe the steps: int depth = 0; int done = 0 ; int XML_rc; char MQ_buffer[8192]; MQLONG MQ_buffer_len; XML_Parser parser = XML_ParserCreate(NULL); XML_SetUserData(parser, &depth); XML_SetDefaultHandler(parser, XMLParse); XML_rc = XML_Parse(parser, MQ_buffer, MQ_buffer_len, done); -------Parser Function----------- void XMLParse(void *userData, const char *name, int len ) { strncpy(temp,name,len); temp[len]='\0'; TrimString(temp); if ( StartCheck == 0 ) { if (strcmp(temp, "" ) == 0 ) MessageType = MSG_DETAIL; else if (strcmp (temp, "" ) == 0 ) MessageType = MSG_CONTROL; else if (strcmp (temp, "" ) == 0 ) MessageType = MSG_TRANSFER; else if (strncmp(temp,"") == 0 ) || (strcmp(temp, "") == 0 ) || (strcmp(temp, "") == 0 )) { StartCheck = 0 ; } } -------Parser Function----------- If you have any suggestion, please let me know. Thanks & Regards, Madavan Raman madavan.raman at my.standardchartered.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1452136&group_id=10127 From noreply at sourceforge.net Fri Mar 17 14:53:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Mar 2006 05:53:33 -0800 Subject: [Expat-bugs] [ expat-Bugs-1452136 ] Expat-2.0.0: Win2003 - Buffer Overrun in XML_Parse Message-ID: Bugs item #1452136, was opened at 2006-03-17 04:53 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1452136&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: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Expat-2.0.0: Win2003 - Buffer Overrun in XML_Parse Initial Comment: The following problem only occurs in Windows 2003 platform ! Buffer Overrun occurs when the following XML data is being parsed: ---------xml--------- LN.MRS.MRS.JE.EOS.EOS.ACCOUNT -label JE.EOS.EOS.ACCOUNT -sqm LNGDC1P1 - dqm JEEOS1P1 at JECHQ1P1 - spath /shared/home/mrsop/fub/ACCT.CSV -dpath E:\ISIS\FINRPT\Account_Master.CSV -type text -exit 8 - exitdll isispost.dll -exitentry isispost -exitdata "@JBE:\\ISIS\\scripts\\FINRPT.BAT;@JBE:\\ISIS\\scr ipts\\FINRPT\_FAIL.BAT" -exit 4 -exitdll isispost -exitentry isispost -exitdata "@JB/shared/home/mrsop/scr/isis\_postproc.sh_/shar ed/home/mrsop/fub/ACCT.CSV_ARC;@JB/shared/home/mrsop/sc r/isis\_failproc.sh_/shared/home/mrsop/fub/ACCT.CSV_ERR OR" -oqm LNGDC1P1 Future Bank 16162f01-ad5c-11da-9fb4-92c88c876801 ---------xml--------- Below are the list of function calls to describe the steps: int depth = 0; int done = 0 ; int XML_rc; char MQ_buffer[8192]; MQLONG MQ_buffer_len; XML_Parser parser = XML_ParserCreate(NULL); XML_SetUserData(parser, &depth); XML_SetDefaultHandler(parser, XMLParse); XML_rc = XML_Parse(parser, MQ_buffer, MQ_buffer_len, done); -------Parser Function----------- void XMLParse(void *userData, const char *name, int len ) { strncpy(temp,name,len); temp[len]='\0'; TrimString(temp); if ( StartCheck == 0 ) { if (strcmp(temp, "" ) == 0 ) MessageType = MSG_DETAIL; else if (strcmp (temp, "" ) == 0 ) MessageType = MSG_CONTROL; else if (strcmp (temp, "" ) == 0 ) MessageType = MSG_TRANSFER; else if (strncmp(temp,"") == 0 ) || (strcmp(temp, "") == 0 ) || (strcmp(temp, "") == 0 )) { StartCheck = 0 ; } } -------Parser Function----------- If you have any suggestion, please let me know. Thanks & Regards, Madavan Raman madavan.raman at my.standardchartered.com ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-03-17 08:53 Message: Logged In: YES user_id=290026 Since I don't have access to Windows 2003 I cannot debug it. I suggest you create a debug build (VC++ 6.0 or later) and find out where the buffer overrun is happening. That will give me a starting point for my investigation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1452136&group_id=10127 From noreply at sourceforge.net Mon Mar 20 07:51:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Mar 2006 22:51:50 -0800 Subject: [Expat-bugs] [ expat-Bugs-1452136 ] Expat-2.0.0: Win2003 - Buffer Overrun in XML_Parse Message-ID: Bugs item #1452136, was opened at 2006-03-17 01:53 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1452136&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: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Expat-2.0.0: Win2003 - Buffer Overrun in XML_Parse Initial Comment: The following problem only occurs in Windows 2003 platform ! Buffer Overrun occurs when the following XML data is being parsed: ---------xml--------- LN.MRS.MRS.JE.EOS.EOS.ACCOUNT -label JE.EOS.EOS.ACCOUNT -sqm LNGDC1P1 - dqm JEEOS1P1 at JECHQ1P1 - spath /shared/home/mrsop/fub/ACCT.CSV -dpath E:\ISIS\FINRPT\Account_Master.CSV -type text -exit 8 - exitdll isispost.dll -exitentry isispost -exitdata "@JBE:\\ISIS\\scripts\\FINRPT.BAT;@JBE:\\ISIS\\scr ipts\\FINRPT\_FAIL.BAT" -exit 4 -exitdll isispost -exitentry isispost -exitdata "@JB/shared/home/mrsop/scr/isis\_postproc.sh_/shar ed/home/mrsop/fub/ACCT.CSV_ARC;@JB/shared/home/mrsop/sc r/isis\_failproc.sh_/shared/home/mrsop/fub/ACCT.CSV_ERR OR" -oqm LNGDC1P1 Future Bank 16162f01-ad5c-11da-9fb4-92c88c876801 ---------xml--------- Below are the list of function calls to describe the steps: int depth = 0; int done = 0 ; int XML_rc; char MQ_buffer[8192]; MQLONG MQ_buffer_len; XML_Parser parser = XML_ParserCreate(NULL); XML_SetUserData(parser, &depth); XML_SetDefaultHandler(parser, XMLParse); XML_rc = XML_Parse(parser, MQ_buffer, MQ_buffer_len, done); -------Parser Function----------- void XMLParse(void *userData, const char *name, int len ) { strncpy(temp,name,len); temp[len]='\0'; TrimString(temp); if ( StartCheck == 0 ) { if (strcmp(temp, "" ) == 0 ) MessageType = MSG_DETAIL; else if (strcmp (temp, "" ) == 0 ) MessageType = MSG_CONTROL; else if (strcmp (temp, "" ) == 0 ) MessageType = MSG_TRANSFER; else if (strncmp(temp,"") == 0 ) || (strcmp(temp, "") == 0 ) || (strcmp(temp, "") == 0 )) { StartCheck = 0 ; } } -------Parser Function----------- If you have any suggestion, please let me know. Thanks & Regards, Madavan Raman madavan.raman at my.standardchartered.com ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-03-19 22:51 Message: Logged In: NO It breaks at doContent() function. The sequence is doProlog-> contentProcessor-> doContent() The memory violation occurs when processing "" tag. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-03-17 05:53 Message: Logged In: YES user_id=290026 Since I don't have access to Windows 2003 I cannot debug it. I suggest you create a debug build (VC++ 6.0 or later) and find out where the buffer overrun is happening. That will give me a starting point for my investigation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1452136&group_id=10127 From noreply at sourceforge.net Mon Mar 20 14:56:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Mar 2006 05:56:09 -0800 Subject: [Expat-bugs] [ expat-Bugs-1452136 ] Expat-2.0.0: Win2003 - Buffer Overrun in XML_Parse Message-ID: Bugs item #1452136, was opened at 2006-03-17 04:53 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1452136&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: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Expat-2.0.0: Win2003 - Buffer Overrun in XML_Parse Initial Comment: The following problem only occurs in Windows 2003 platform ! Buffer Overrun occurs when the following XML data is being parsed: ---------xml--------- LN.MRS.MRS.JE.EOS.EOS.ACCOUNT -label JE.EOS.EOS.ACCOUNT -sqm LNGDC1P1 - dqm JEEOS1P1 at JECHQ1P1 - spath /shared/home/mrsop/fub/ACCT.CSV -dpath E:\ISIS\FINRPT\Account_Master.CSV -type text -exit 8 - exitdll isispost.dll -exitentry isispost -exitdata "@JBE:\\ISIS\\scripts\\FINRPT.BAT;@JBE:\\ISIS\\scr ipts\\FINRPT\_FAIL.BAT" -exit 4 -exitdll isispost -exitentry isispost -exitdata "@JB/shared/home/mrsop/scr/isis\_postproc.sh_/shar ed/home/mrsop/fub/ACCT.CSV_ARC;@JB/shared/home/mrsop/sc r/isis\_failproc.sh_/shared/home/mrsop/fub/ACCT.CSV_ERR OR" -oqm LNGDC1P1 Future Bank 16162f01-ad5c-11da-9fb4-92c88c876801 ---------xml--------- Below are the list of function calls to describe the steps: int depth = 0; int done = 0 ; int XML_rc; char MQ_buffer[8192]; MQLONG MQ_buffer_len; XML_Parser parser = XML_ParserCreate(NULL); XML_SetUserData(parser, &depth); XML_SetDefaultHandler(parser, XMLParse); XML_rc = XML_Parse(parser, MQ_buffer, MQ_buffer_len, done); -------Parser Function----------- void XMLParse(void *userData, const char *name, int len ) { strncpy(temp,name,len); temp[len]='\0'; TrimString(temp); if ( StartCheck == 0 ) { if (strcmp(temp, "" ) == 0 ) MessageType = MSG_DETAIL; else if (strcmp (temp, "" ) == 0 ) MessageType = MSG_CONTROL; else if (strcmp (temp, "" ) == 0 ) MessageType = MSG_TRANSFER; else if (strncmp(temp,"") == 0 ) || (strcmp(temp, "") == 0 ) || (strcmp(temp, "") == 0 )) { StartCheck = 0 ; } } -------Parser Function----------- If you have any suggestion, please let me know. Thanks & Regards, Madavan Raman madavan.raman at my.standardchartered.com ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-03-20 08:56 Message: Logged In: YES user_id=290026 What happens if you don't set the default handler? Do you still get a buffer overrun? Karl ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-03-20 01:51 Message: Logged In: NO It breaks at doContent() function. The sequence is doProlog-> contentProcessor-> doContent() The memory violation occurs when processing "" tag. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-03-17 08:53 Message: Logged In: YES user_id=290026 Since I don't have access to Windows 2003 I cannot debug it. I suggest you create a debug build (VC++ 6.0 or later) and find out where the buffer overrun is happening. That will give me a starting point for my investigation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1452136&group_id=10127 From noreply at sourceforge.net Mon Mar 20 16:50:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Mar 2006 07:50:44 -0800 Subject: [Expat-bugs] [ expat-Bugs-1454652 ] make check failes to compile "test_line_number_after_parse" Message-ID: Bugs item #1454652, was opened at 2006-03-20 07:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1454652&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: make check failes to compile "test_line_number_after_parse" Initial Comment: Opensuse-10.1, gcc-4.0.2. ./configure --prefix=/opt/expat/2.0.0; make -wk; make -wk check; g++ -c -o tests/runtestspp.o tests/runtestspp.cpp tests/runtests.c: In function 'void test_line_number_after_parse()': tests/runtests.c:410: error: 'XML_Size' was not declared in this scope tests/runtests.c:410: error: expected `;' before 'lineno' tests/runtests.c:414: error: 'lineno' was not declared in this scope tests/runtests.c: In function 'void test_column_number_after_parse()': tests/runtests.c:428: error: 'XML_Size' was not declared in this scope tests/runtests.c:428: error: expected `;' before 'colno' tests/runtests.c:432: error: 'colno' was not declared in this scope tests/runtests.c: In function 'void test_line_number_after_error()': tests/runtests.c:514: error: 'XML_Size' was not declared in this scope tests/runtests.c:514: error: expected `;' before 'lineno' tests/runtests.c:518: error: 'lineno' was not declared in this scope tests/runtests.c: In function 'void test_column_number_after_error()': tests/runtests.c:534: error: 'XML_Size' was not declared in this scope tests/runtests.c:534: error: expected `;' before 'colno' tests/runtests.c:538: error: 'colno' was not declared in this scope make: *** [tests/runtestspp.o] Error 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1454652&group_id=10127 From noreply at sourceforge.net Mon Mar 20 16:58:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Mar 2006 07:58:08 -0800 Subject: [Expat-bugs] [ expat-Bugs-1454652 ] make check failes to compile "test_line_number_after_parse" Message-ID: Bugs item #1454652, was opened at 2006-03-20 10:50 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1454652&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: make check failes to compile "test_line_number_after_parse" Initial Comment: Opensuse-10.1, gcc-4.0.2. ./configure --prefix=/opt/expat/2.0.0; make -wk; make -wk check; g++ -c -o tests/runtestspp.o tests/runtestspp.cpp tests/runtests.c: In function 'void test_line_number_after_parse()': tests/runtests.c:410: error: 'XML_Size' was not declared in this scope tests/runtests.c:410: error: expected `;' before 'lineno' tests/runtests.c:414: error: 'lineno' was not declared in this scope tests/runtests.c: In function 'void test_column_number_after_parse()': tests/runtests.c:428: error: 'XML_Size' was not declared in this scope tests/runtests.c:428: error: expected `;' before 'colno' tests/runtests.c:432: error: 'colno' was not declared in this scope tests/runtests.c: In function 'void test_line_number_after_error()': tests/runtests.c:514: error: 'XML_Size' was not declared in this scope tests/runtests.c:514: error: expected `;' before 'lineno' tests/runtests.c:518: error: 'lineno' was not declared in this scope tests/runtests.c: In function 'void test_column_number_after_error()': tests/runtests.c:534: error: 'XML_Size' was not declared in this scope tests/runtests.c:534: error: expected `;' before 'colno' tests/runtests.c:538: error: 'colno' was not declared in this scope make: *** [tests/runtestspp.o] Error 1 ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-03-20 10:58 Message: Logged In: YES user_id=290026 Make check must be run after make install, otherwise it might run against an old Expat version. Alternatively, this behaviour might have been fixed in CVS. Try again amd let us know. Karl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1454652&group_id=10127 From noreply at sourceforge.net Wed Mar 22 13:08:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Mar 2006 04:08:42 -0800 Subject: [Expat-bugs] [ expat-Bugs-1452136 ] Expat-2.0.0: Win2003 - Buffer Overrun in XML_Parse Message-ID: Bugs item #1452136, was opened at 2006-03-17 01:53 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1452136&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: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Expat-2.0.0: Win2003 - Buffer Overrun in XML_Parse Initial Comment: The following problem only occurs in Windows 2003 platform ! Buffer Overrun occurs when the following XML data is being parsed: ---------xml--------- LN.MRS.MRS.JE.EOS.EOS.ACCOUNT -label JE.EOS.EOS.ACCOUNT -sqm LNGDC1P1 - dqm JEEOS1P1 at JECHQ1P1 - spath /shared/home/mrsop/fub/ACCT.CSV -dpath E:\ISIS\FINRPT\Account_Master.CSV -type text -exit 8 - exitdll isispost.dll -exitentry isispost -exitdata "@JBE:\\ISIS\\scripts\\FINRPT.BAT;@JBE:\\ISIS\\scr ipts\\FINRPT\_FAIL.BAT" -exit 4 -exitdll isispost -exitentry isispost -exitdata "@JB/shared/home/mrsop/scr/isis\_postproc.sh_/shar ed/home/mrsop/fub/ACCT.CSV_ARC;@JB/shared/home/mrsop/sc r/isis\_failproc.sh_/shared/home/mrsop/fub/ACCT.CSV_ERR OR" -oqm LNGDC1P1 Future Bank 16162f01-ad5c-11da-9fb4-92c88c876801 ---------xml--------- Below are the list of function calls to describe the steps: int depth = 0; int done = 0 ; int XML_rc; char MQ_buffer[8192]; MQLONG MQ_buffer_len; XML_Parser parser = XML_ParserCreate(NULL); XML_SetUserData(parser, &depth); XML_SetDefaultHandler(parser, XMLParse); XML_rc = XML_Parse(parser, MQ_buffer, MQ_buffer_len, done); -------Parser Function----------- void XMLParse(void *userData, const char *name, int len ) { strncpy(temp,name,len); temp[len]='\0'; TrimString(temp); if ( StartCheck == 0 ) { if (strcmp(temp, "" ) == 0 ) MessageType = MSG_DETAIL; else if (strcmp (temp, "" ) == 0 ) MessageType = MSG_CONTROL; else if (strcmp (temp, "" ) == 0 ) MessageType = MSG_TRANSFER; else if (strncmp(temp,"") == 0 ) || (strcmp(temp, "") == 0 ) || (strcmp(temp, "") == 0 )) { StartCheck = 0 ; } } -------Parser Function----------- If you have any suggestion, please let me know. Thanks & Regards, Madavan Raman madavan.raman at my.standardchartered.com ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-03-22 04:08 Message: Logged In: NO Managed to track down the error in the default handler. Line which was causing the error was a string manipulation code using "strcat()" function. I have fixed it using "strncat()" to control the size. Surprisingly this code is running fine in Win2000 platform. Thanks for your help. We can close this item. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-03-22 03:35 Message: Logged In: NO If I remove the default handler, I dont get the buffer overrun error. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-03-20 05:56 Message: Logged In: YES user_id=290026 What happens if you don't set the default handler? Do you still get a buffer overrun? Karl ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-03-19 22:51 Message: Logged In: NO It breaks at doContent() function. The sequence is doProlog-> contentProcessor-> doContent() The memory violation occurs when processing "" tag. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-03-17 05:53 Message: Logged In: YES user_id=290026 Since I don't have access to Windows 2003 I cannot debug it. I suggest you create a debug build (VC++ 6.0 or later) and find out where the buffer overrun is happening. That will give me a starting point for my investigation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1452136&group_id=10127 From noreply at sourceforge.net Wed Mar 22 12:35:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Mar 2006 03:35:33 -0800 Subject: [Expat-bugs] [ expat-Bugs-1452136 ] Expat-2.0.0: Win2003 - Buffer Overrun in XML_Parse Message-ID: Bugs item #1452136, was opened at 2006-03-17 01:53 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1452136&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: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Expat-2.0.0: Win2003 - Buffer Overrun in XML_Parse Initial Comment: The following problem only occurs in Windows 2003 platform ! Buffer Overrun occurs when the following XML data is being parsed: ---------xml--------- LN.MRS.MRS.JE.EOS.EOS.ACCOUNT -label JE.EOS.EOS.ACCOUNT -sqm LNGDC1P1 - dqm JEEOS1P1 at JECHQ1P1 - spath /shared/home/mrsop/fub/ACCT.CSV -dpath E:\ISIS\FINRPT\Account_Master.CSV -type text -exit 8 - exitdll isispost.dll -exitentry isispost -exitdata "@JBE:\\ISIS\\scripts\\FINRPT.BAT;@JBE:\\ISIS\\scr ipts\\FINRPT\_FAIL.BAT" -exit 4 -exitdll isispost -exitentry isispost -exitdata "@JB/shared/home/mrsop/scr/isis\_postproc.sh_/shar ed/home/mrsop/fub/ACCT.CSV_ARC;@JB/shared/home/mrsop/sc r/isis\_failproc.sh_/shared/home/mrsop/fub/ACCT.CSV_ERR OR" -oqm LNGDC1P1 Future Bank 16162f01-ad5c-11da-9fb4-92c88c876801 ---------xml--------- Below are the list of function calls to describe the steps: int depth = 0; int done = 0 ; int XML_rc; char MQ_buffer[8192]; MQLONG MQ_buffer_len; XML_Parser parser = XML_ParserCreate(NULL); XML_SetUserData(parser, &depth); XML_SetDefaultHandler(parser, XMLParse); XML_rc = XML_Parse(parser, MQ_buffer, MQ_buffer_len, done); -------Parser Function----------- void XMLParse(void *userData, const char *name, int len ) { strncpy(temp,name,len); temp[len]='\0'; TrimString(temp); if ( StartCheck == 0 ) { if (strcmp(temp, "" ) == 0 ) MessageType = MSG_DETAIL; else if (strcmp (temp, "" ) == 0 ) MessageType = MSG_CONTROL; else if (strcmp (temp, "" ) == 0 ) MessageType = MSG_TRANSFER; else if (strncmp(temp,"") == 0 ) || (strcmp(temp, "") == 0 ) || (strcmp(temp, "") == 0 )) { StartCheck = 0 ; } } -------Parser Function----------- If you have any suggestion, please let me know. Thanks & Regards, Madavan Raman madavan.raman at my.standardchartered.com ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-03-22 03:35 Message: Logged In: NO If I remove the default handler, I dont get the buffer overrun error. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-03-20 05:56 Message: Logged In: YES user_id=290026 What happens if you don't set the default handler? Do you still get a buffer overrun? Karl ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-03-19 22:51 Message: Logged In: NO It breaks at doContent() function. The sequence is doProlog-> contentProcessor-> doContent() The memory violation occurs when processing "" tag. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-03-17 05:53 Message: Logged In: YES user_id=290026 Since I don't have access to Windows 2003 I cannot debug it. I suggest you create a debug build (VC++ 6.0 or later) and find out where the buffer overrun is happening. That will give me a starting point for my investigation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1452136&group_id=10127 From noreply at sourceforge.net Wed Mar 22 15:32:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Mar 2006 06:32:07 -0800 Subject: [Expat-bugs] [ expat-Bugs-1452136 ] Expat-2.0.0: Win2003 - Buffer Overrun in XML_Parse Message-ID: Bugs item #1452136, was opened at 2006-03-17 04:53 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1452136&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: Platform Specific >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Expat-2.0.0: Win2003 - Buffer Overrun in XML_Parse Initial Comment: The following problem only occurs in Windows 2003 platform ! Buffer Overrun occurs when the following XML data is being parsed: ---------xml--------- LN.MRS.MRS.JE.EOS.EOS.ACCOUNT -label JE.EOS.EOS.ACCOUNT -sqm LNGDC1P1 - dqm JEEOS1P1 at JECHQ1P1 - spath /shared/home/mrsop/fub/ACCT.CSV -dpath E:\ISIS\FINRPT\Account_Master.CSV -type text -exit 8 - exitdll isispost.dll -exitentry isispost -exitdata "@JBE:\\ISIS\\scripts\\FINRPT.BAT;@JBE:\\ISIS\\scr ipts\\FINRPT\_FAIL.BAT" -exit 4 -exitdll isispost -exitentry isispost -exitdata "@JB/shared/home/mrsop/scr/isis\_postproc.sh_/shar ed/home/mrsop/fub/ACCT.CSV_ARC;@JB/shared/home/mrsop/sc r/isis\_failproc.sh_/shared/home/mrsop/fub/ACCT.CSV_ERR OR" -oqm LNGDC1P1 Future Bank 16162f01-ad5c-11da-9fb4-92c88c876801 ---------xml--------- Below are the list of function calls to describe the steps: int depth = 0; int done = 0 ; int XML_rc; char MQ_buffer[8192]; MQLONG MQ_buffer_len; XML_Parser parser = XML_ParserCreate(NULL); XML_SetUserData(parser, &depth); XML_SetDefaultHandler(parser, XMLParse); XML_rc = XML_Parse(parser, MQ_buffer, MQ_buffer_len, done); -------Parser Function----------- void XMLParse(void *userData, const char *name, int len ) { strncpy(temp,name,len); temp[len]='\0'; TrimString(temp); if ( StartCheck == 0 ) { if (strcmp(temp, "" ) == 0 ) MessageType = MSG_DETAIL; else if (strcmp (temp, "" ) == 0 ) MessageType = MSG_CONTROL; else if (strcmp (temp, "" ) == 0 ) MessageType = MSG_TRANSFER; else if (strncmp(temp,"") == 0 ) || (strcmp(temp, "") == 0 ) || (strcmp(temp, "") == 0 )) { StartCheck = 0 ; } } -------Parser Function----------- If you have any suggestion, please let me know. Thanks & Regards, Madavan Raman madavan.raman at my.standardchartered.com ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-03-22 09:32 Message: Logged In: YES user_id=290026 OK, closing this item. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-03-22 07:08 Message: Logged In: NO Managed to track down the error in the default handler. Line which was causing the error was a string manipulation code using "strcat()" function. I have fixed it using "strncat()" to control the size. Surprisingly this code is running fine in Win2000 platform. Thanks for your help. We can close this item. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-03-22 06:35 Message: Logged In: NO If I remove the default handler, I dont get the buffer overrun error. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-03-20 08:56 Message: Logged In: YES user_id=290026 What happens if you don't set the default handler? Do you still get a buffer overrun? Karl ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-03-20 01:51 Message: Logged In: NO It breaks at doContent() function. The sequence is doProlog-> contentProcessor-> doContent() The memory violation occurs when processing "" tag. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-03-17 08:53 Message: Logged In: YES user_id=290026 Since I don't have access to Windows 2003 I cannot debug it. I suggest you create a debug build (VC++ 6.0 or later) and find out where the buffer overrun is happening. That will give me a starting point for my investigation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1452136&group_id=10127 From noreply at sourceforge.net Thu Mar 23 02:07:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Mar 2006 17:07:38 -0800 Subject: [Expat-bugs] [ expat-Bugs-1452136 ] Expat-2.0.0: Win2003 - Buffer Overrun in XML_Parse Message-ID: Bugs item #1452136, was opened at 2006-03-17 01:53 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1452136&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: Platform Specific Status: Closed Resolution: Rejected Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Expat-2.0.0: Win2003 - Buffer Overrun in XML_Parse Initial Comment: The following problem only occurs in Windows 2003 platform ! Buffer Overrun occurs when the following XML data is being parsed: ---------xml--------- LN.MRS.MRS.JE.EOS.EOS.ACCOUNT -label JE.EOS.EOS.ACCOUNT -sqm LNGDC1P1 - dqm JEEOS1P1 at JECHQ1P1 - spath /shared/home/mrsop/fub/ACCT.CSV -dpath E:\ISIS\FINRPT\Account_Master.CSV -type text -exit 8 - exitdll isispost.dll -exitentry isispost -exitdata "@JBE:\\ISIS\\scripts\\FINRPT.BAT;@JBE:\\ISIS\\scr ipts\\FINRPT\_FAIL.BAT" -exit 4 -exitdll isispost -exitentry isispost -exitdata "@JB/shared/home/mrsop/scr/isis\_postproc.sh_/shar ed/home/mrsop/fub/ACCT.CSV_ARC;@JB/shared/home/mrsop/sc r/isis\_failproc.sh_/shared/home/mrsop/fub/ACCT.CSV_ERR OR" -oqm LNGDC1P1 Future Bank 16162f01-ad5c-11da-9fb4-92c88c876801 ---------xml--------- Below are the list of function calls to describe the steps: int depth = 0; int done = 0 ; int XML_rc; char MQ_buffer[8192]; MQLONG MQ_buffer_len; XML_Parser parser = XML_ParserCreate(NULL); XML_SetUserData(parser, &depth); XML_SetDefaultHandler(parser, XMLParse); XML_rc = XML_Parse(parser, MQ_buffer, MQ_buffer_len, done); -------Parser Function----------- void XMLParse(void *userData, const char *name, int len ) { strncpy(temp,name,len); temp[len]='\0'; TrimString(temp); if ( StartCheck == 0 ) { if (strcmp(temp, "" ) == 0 ) MessageType = MSG_DETAIL; else if (strcmp (temp, "" ) == 0 ) MessageType = MSG_CONTROL; else if (strcmp (temp, "" ) == 0 ) MessageType = MSG_TRANSFER; else if (strncmp(temp,"") == 0 ) || (strcmp(temp, "") == 0 ) || (strcmp(temp, "") == 0 )) { StartCheck = 0 ; } } -------Parser Function----------- If you have any suggestion, please let me know. Thanks & Regards, Madavan Raman madavan.raman at my.standardchartered.com ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-03-22 17:07 Message: Logged In: NO Managed to track down the error in the default handler. Line which was causing the error was a string manipulation code using "strcat()" function. I have fixed it using "strncat()" to control the size. Surprisingly this code is running fine in Win2000 platform. Thanks for your help. We can close this item. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-03-22 06:32 Message: Logged In: YES user_id=290026 OK, closing this item. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-03-22 04:08 Message: Logged In: NO Managed to track down the error in the default handler. Line which was causing the error was a string manipulation code using "strcat()" function. I have fixed it using "strncat()" to control the size. Surprisingly this code is running fine in Win2000 platform. Thanks for your help. We can close this item. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-03-22 03:35 Message: Logged In: NO If I remove the default handler, I dont get the buffer overrun error. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-03-20 05:56 Message: Logged In: YES user_id=290026 What happens if you don't set the default handler? Do you still get a buffer overrun? Karl ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-03-19 22:51 Message: Logged In: NO It breaks at doContent() function. The sequence is doProlog-> contentProcessor-> doContent() The memory violation occurs when processing "" tag. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-03-17 05:53 Message: Logged In: YES user_id=290026 Since I don't have access to Windows 2003 I cannot debug it. I suggest you create a debug build (VC++ 6.0 or later) and find out where the buffer overrun is happening. That will give me a starting point for my investigation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1452136&group_id=10127