From noreply@sourceforge.net Fri Nov 1 14:32:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 01 Nov 2002 06:32:30 -0800 Subject: [Expat-bugs] [ expat-Bugs-632068 ] make clean broken under MSYS 1.0.8/MinGW Message-ID: Bugs item #632068, was opened at 2002-11-01 14:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=632068&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Johan Lindh (johanl) Assigned to: Greg Stein (gstein) Summary: make clean broken under MSYS 1.0.8/MinGW Initial Comment: make clean requires xargs, which is not present with MSYS 1.0.8. Possibly make clean could be rewritten to not require this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=632068&group_id=10127 From noreply@sourceforge.net Fri Nov 1 17:15:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 01 Nov 2002 09:15:28 -0800 Subject: [Expat-bugs] [ expat-Bugs-632146 ] xmlwf: memory demands Message-ID: Bugs item #632146, was opened at 2002-11-01 17:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=632146&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Nobody/Anonymous (nobody) Summary: xmlwf: memory demands Initial Comment: expat 1.95.5 Running xmlwf against bigger XML files needs almost the double of the file size of memory (at the end, the process size grows permanently during the processing). This looks pretty wrong to me, since the tool does SAX parsing. Please notice, that this seems to be a problem only with the xmlwf code, not with the expat lib per se. An application by me, build on top of expat, doesn't shows this behavior. Instead, the memory size of the process stays constant and pretty low, even while parsing big XML files - which is, what I also would have expected from the xmlwf tool. I'm sorry, for only reporting the problem and not digging into. rolf ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=632146&group_id=10127 From noreply@sourceforge.net Sat Nov 2 21:29:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 02 Nov 2002 13:29:37 -0800 Subject: [Expat-bugs] [ expat-Bugs-626001 ] ld: Mismatched ABI (not an ELF file) for Message-ID: Bugs item #626001, was opened at 2002-10-20 14:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=626001&group_id=10127 >Category: Build control Group: None Status: Open Resolution: None Priority: 9 Submitted By: Sanjay (sanjaywaza) >Assigned to: Greg Stein (gstein) Summary: ld: Mismatched ABI (not an ELF file) for Initial Comment: I tried to install the expat1.95.4) on HP-UX 11.0 (64 Bit). Then I tried to build XML::Parser2.31.1 and I am getting the error (ld: Mismatched ABI (not an ELF file). I am getting the following error during make . cp Parser/Encodings/README blib/lib/XML/Parser/Encodings/README cp Parser/Encodings/x-sjis-cp932.enc blib/lib/XML/Parser/Encodings/x-sjis-cp932.enc cp Parser/Encodings/iso-8859-7.enc blib/lib/XML/Parser/Encodings/iso-8859-7.enc cp Parser/Encodings/big5.enc blib/lib/XML/Parser/Encodings/big5.enc cp Parser/Encodings/windows-1250.enc blib/lib/XML/Parser/Encodings/windows-1250.enc cp Parser/Encodings/iso-8859-8.enc blib/lib/XML/Parser/Encodings/iso-8859-8.enc cp Parser/Encodings/iso-8859-2.enc blib/lib/XML/Parser/Encodings/iso-8859-2.enc cp Parser/Encodings/x-euc-jp-jisx0221.enc blib/lib/XML/Parser/Encodings/x-euc-jp-jisx0221.enc cp Parser/Encodings/iso-8859-9.enc blib/lib/XML/Parser/Encodings/iso-8859-9.enc cp Parser/Encodings/x-sjis-unicode.enc blib/lib/XML/Parser/Encodings/x-sjis-unicode.enc cp Parser/Encodings/iso-8859-3.enc blib/lib/XML/Parser/Encodings/iso-8859-3.enc cp Parser/Encodings/x-sjis-jdk117.enc blib/lib/XML/Parser/Encodings/x-sjis-jdk117.enc cp Parser/Encodings/euc-kr.enc blib/lib/XML/Parser/Encodings/euc-kr.enc cp Parser/Encodings/iso-8859-4.enc blib/lib/XML/Parser/Encodings/iso-8859-4.enc cp Parser/Encodings/Japanese_Encodings.msg blib/lib/XML/Parser/Encodings/Japanese_Encodings.msg cp Parser/Encodings/x-sjis-jisx0221.enc blib/lib/XML/Parser/Encodings/x-sjis-jisx0221.enc cp Parser.pm blib/lib/XML/Parser.pm cp Parser/Encodings/iso-8859-5.enc blib/lib/XML/Parser/Encodings/iso-8859-5.enc cp Parser/Encodings/x-euc-jp-unicode.enc blib/lib/XML/Parser/Encodings/x-euc-jp-unicode.enc cp Parser/LWPExternEnt.pl blib/lib/XML/Parser/LWPExternEnt.pl cp Expat.pm ../blib/lib/XML/Parser/Expat.pm /bin/perl -I/opt/perl5.6.1/lib/5.6.1/PA-RISC2.0 - I/opt/perl5.6.1/lib/5.6.1 /opt/perl5.6.1/lib/5.6.1/ExtUtils/x s ubpp -noprotc cc -c +z -D_HPUX_SOURCE +DD64 -Ae - I/usr/local/include -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64 -O -DVERSION=\2.31\c Running Mkbootstrap for XML::Parser::Expat () chmod 644 Expat.bs rm -f ../blib/arch/auto/XML/Parser/Expat/Expat.sl LD_RUN_PATH="/usr/local/lib" /usr/bin/ld -b +vnocompatwarnings -L/usr/local/lib -L/lib/pa20_64 Expat.o -o ../blib/arch/au ld: Mismatched ABI (not an ELF file) for -lexpat Fatal error. *** Error exit code 1 Stop. *** Error exit code 1 Thanks ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-11-02 16:29 Message: Logged In: YES user_id=3066 This looks like a build issue to me; I don't know anything about HP-UX, so I might be wrong. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=626001&group_id=10127 From noreply@sourceforge.net Wed Nov 6 13:11:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 05:11:44 -0800 Subject: [Expat-bugs] [ expat-Bugs-634409 ] XML_Feature HP-UX expat-1.95.5 Message-ID: Bugs item #634409, was opened at 2002-11-06 05:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=634409&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: XML_Feature HP-UX expat-1.95.5 Initial Comment: a build of expat-1.95.5.tar.gz on HP-UX 11 fails with gcc -O2 -w -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -O2 -w -I/usr/local/include -I./lib -I. -o xmlwf/xmlwf.o -c xmlwf/xmlwf.c xmlwf/xmlwf.c: In function `showVersion': xmlwf/xmlwf.c:602: syntax error before `*' xmlwf/xmlwf.c:613: `features' undeclared (first use in this function) xmlwf/xmlwf.c:613: (Each undeclared identifier is reported only once xmlwf/xmlwf.c:613: for each function it appears in.) xmlwf/xmlwf.c:613: `XML_FEATURE_END' undeclared (first use in this function) make: *** [xmlwf/xmlwf.o] Error 1 No problem on expat-1.95.4.tar.gz and expat-1.95.2.tar.gz ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=634409&group_id=10127 From noreply@sourceforge.net Thu Nov 7 01:13:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 17:13:40 -0800 Subject: [Expat-bugs] [ expat-Bugs-624724 ] Distinguishing between GE's and PE's Message-ID: Bugs item #624724, was opened at 2002-10-17 11:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=624724&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Ernst Jan Plugge (rmc) Assigned to: Karl Waclawek (kwaclaw) Summary: Distinguishing between GE's and PE's Initial Comment: There is no documented way to distinguish between a general entity and a parameter entity in an ExternalEntityRefHandler. Right now, the undocumented way is to examine the value of the context parameter to the handler, but the docs clearly state that the context should be considered opaque. The feature request is to provide a proper, documented way to distinguish between the two. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-11-06 20:13 Message: Logged In: YES user_id=290026 Reference.html updated accordingly in rev. 1.35. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-10-17 12:30 Message: Logged In: YES user_id=290026 You are right, it is not documented, but it is the right way to check the entity type. Yes, the docs indicate (not clearly, IMO) that context is an opaque pointer, but checking whether the pointer is NULL is still OK, since that is not an attempt to "look behind the curtain". We need to update reference.html to properly document this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=624724&group_id=10127 From noreply@sourceforge.net Thu Nov 7 01:14:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 17:14:24 -0800 Subject: [Expat-bugs] [ expat-Bugs-624724 ] Distinguishing between GE's and PE's Message-ID: Bugs item #624724, was opened at 2002-10-17 11:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=624724&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Ernst Jan Plugge (rmc) Assigned to: Karl Waclawek (kwaclaw) Summary: Distinguishing between GE's and PE's Initial Comment: There is no documented way to distinguish between a general entity and a parameter entity in an ExternalEntityRefHandler. Right now, the undocumented way is to examine the value of the context parameter to the handler, but the docs clearly state that the context should be considered opaque. The feature request is to provide a proper, documented way to distinguish between the two. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-11-06 20:14 Message: Logged In: YES user_id=290026 Reference.html updated accordingly in rev. 1.35. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-11-06 20:13 Message: Logged In: YES user_id=290026 Reference.html updated accordingly in rev. 1.35. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-10-17 12:30 Message: Logged In: YES user_id=290026 You are right, it is not documented, but it is the right way to check the entity type. Yes, the docs indicate (not clearly, IMO) that context is an opaque pointer, but checking whether the pointer is NULL is still OK, since that is not an attempt to "look behind the curtain". We need to update reference.html to properly document this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=624724&group_id=10127 From noreply@sourceforge.net Thu Nov 7 21:31:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 13:31:32 -0800 Subject: [Expat-bugs] [ expat-Bugs-607702 ] expat v1.9.5+ error on Message-ID: Bugs item #607702, was opened at 2002-09-11 04:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=607702&group_id=10127 Category: None Group: None >Status: Closed Resolution: Rejected Priority: 5 Submitted By: Shamim Islam (kellin) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: expat v1.9.5+ error on Initial Comment: PHP 4.2.2 - direct relay into expat 1.9.5 Apache 1.3.x Windows NT Linux-Mandrake Processing instructions according to the W3C workgroup do not form part of the character stream, but are supposed to be passed directly to the application. As such, they should be allowed to appear anywhere. xml and Xml as targets are reserved. The targets can make use of a Notation in the dtd to clarify the application to receive the processing instruction. Expat as constructed does not allow for processing instructions to appear anywhere arbitrarily but requires that they appear outside tags. However, the W3C mandate clearly indicates that is a valid construct. In attempting to make use of this construct, expat repeatedly stopped with an invalid response. Also, it was not clear whether the processing instruction was expected to return a value that would instead be substituted. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-09-11 10:02 Message: Logged In: YES user_id=290026 The start tag is defined as: [40] STag ::= '<' Name (S Attribute)* S? '>' [41] Attribute ::= Name Eq AttValue and AttValue is defined as: [10] AttValue ::= '"' ([^<&"] | Reference)* '"' | "'" ([^<&'] | Reference)* "'" with Reference being a character or entity reference. This does not allow for processing instructions in the attribute value. The Expat behaviour looks correct to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=607702&group_id=10127 From noreply@sourceforge.net Thu Nov 7 21:32:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 13:32:10 -0800 Subject: [Expat-bugs] [ expat-Bugs-624251 ] Problem parsing Latin-1 symbols Message-ID: Bugs item #624251, was opened at 2002-10-16 15:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=624251&group_id=10127 Category: None Group: None >Status: Closed Resolution: Rejected Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Problem parsing Latin-1 symbols Initial Comment: Expat 1.95-5 Getting an extra character from the parser when parsing extended ASCII characters (161 - 255 decimal). The XML_CharacterDataHandler function reports 2 characters for every 1 extended character encountered. Below is a small XML file demonstrating the problem. The character handler function reports two charaters (0xC2 and 0xA9) when the xml file contains only one (0xA9). © Platform: Windows 2000 exe statically linked to expat. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-10-16 15:23 Message: Logged In: YES user_id=290026 Expat reports characters encoded as UTF-8 or UTF-16. It does not generate ISO-8859-1 output. What you are reporting looks lik UTF-8 encoding, which means the character 0xA9 will be encoded in two bytes. This does not appear to be a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=624251&group_id=10127 From noreply@sourceforge.net Thu Nov 7 21:33:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 13:33:15 -0800 Subject: [Expat-bugs] [ expat-Bugs-624724 ] Distinguishing between GE's and PE's Message-ID: Bugs item #624724, was opened at 2002-10-17 11:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=624724&group_id=10127 Category: None Group: Feature Request >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ernst Jan Plugge (rmc) Assigned to: Karl Waclawek (kwaclaw) Summary: Distinguishing between GE's and PE's Initial Comment: There is no documented way to distinguish between a general entity and a parameter entity in an ExternalEntityRefHandler. Right now, the undocumented way is to examine the value of the context parameter to the handler, but the docs clearly state that the context should be considered opaque. The feature request is to provide a proper, documented way to distinguish between the two. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-11-06 20:14 Message: Logged In: YES user_id=290026 Reference.html updated accordingly in rev. 1.35. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-11-06 20:13 Message: Logged In: YES user_id=290026 Reference.html updated accordingly in rev. 1.35. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-10-17 12:30 Message: Logged In: YES user_id=290026 You are right, it is not documented, but it is the right way to check the entity type. Yes, the docs indicate (not clearly, IMO) that context is an opaque pointer, but checking whether the pointer is NULL is still OK, since that is not an attempt to "look behind the curtain". We need to update reference.html to properly document this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=624724&group_id=10127 From noreply@sourceforge.net Thu Nov 7 21:42:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 13:42:55 -0800 Subject: [Expat-bugs] [ expat-Bugs-625156 ] iso-8859-1 support not working? Message-ID: Bugs item #625156, was opened at 2002-10-18 07:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=625156&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: iso-8859-1 support not working? Initial Comment: libversion: expat-1.95.5 os: FreeBSD 4.6-STABLE I've run into problems when using a xml-document with encoding defined to "iso-8859-1" as: The document gets processed ok, but some of the characters, special to this encoding, gets transformed to garbage in the output. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-11-07 16:42 Message: Logged In: YES user_id=290026 This does not seem to be a bug. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-10-18 09:29 Message: Logged In: NO This is because Expat outputs UTF-8 encoded text. You need to convert the output to iso-8859-1 yourself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=625156&group_id=10127 From noreply@sourceforge.net Thu Nov 7 21:43:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 13:43:39 -0800 Subject: [Expat-bugs] [ expat-Bugs-634409 ] XML_Feature HP-UX expat-1.95.5 Message-ID: Bugs item #634409, was opened at 2002-11-06 08:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=634409&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: XML_Feature HP-UX expat-1.95.5 Initial Comment: a build of expat-1.95.5.tar.gz on HP-UX 11 fails with gcc -O2 -w -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -O2 -w -I/usr/local/include -I./lib -I. -o xmlwf/xmlwf.o -c xmlwf/xmlwf.c xmlwf/xmlwf.c: In function `showVersion': xmlwf/xmlwf.c:602: syntax error before `*' xmlwf/xmlwf.c:613: `features' undeclared (first use in this function) xmlwf/xmlwf.c:613: (Each undeclared identifier is reported only once xmlwf/xmlwf.c:613: for each function it appears in.) xmlwf/xmlwf.c:613: `XML_FEATURE_END' undeclared (first use in this function) make: *** [xmlwf/xmlwf.o] Error 1 No problem on expat-1.95.4.tar.gz and expat-1.95.2.tar.gz ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-11-07 16:43 Message: Logged In: YES user_id=3066 The features support was added in 1.95.5. It looks like you're picking up an older revision of the expat.h header file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=634409&group_id=10127 From noreply@sourceforge.net Thu Nov 7 21:48:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 13:48:39 -0800 Subject: [Expat-bugs] [ expat-Bugs-632068 ] make clean broken under MSYS 1.0.8/MinGW Message-ID: Bugs item #632068, was opened at 2002-11-01 09:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=632068&group_id=10127 Category: Build control Group: Platform Specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Johan Lindh (johanl) Assigned to: Greg Stein (gstein) Summary: make clean broken under MSYS 1.0.8/MinGW Initial Comment: make clean requires xargs, which is not present with MSYS 1.0.8. Possibly make clean could be rewritten to not require this. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-11-07 16:48 Message: Logged In: YES user_id=3066 Fixed in Makefile.in revision 1.41. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=632068&group_id=10127 From noreply@sourceforge.net Thu Nov 7 23:02:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 15:02:44 -0800 Subject: [Expat-bugs] [ expat-Bugs-616863 ] Default xmlns=... in external subset Message-ID: Bugs item #616863, was opened at 2002-09-30 23:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=616863&group_id=10127 Category: None Group: Test Required >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Default xmlns=... in external subset Initial Comment: This bug was reported by Jeremy Kloth. It applies to Expat 1.95.2, 1.95.4 and 1.95.5. If an xmlns attribute is defaulted in the external subset, one gets a NULL pointer error when parsing an external general entity. This can be reproduced with the attached files i18n.xml, l10n.xml and en.xml. The fix for that requires switching to a separately allocated DTD structure and is therefore quite extensive. Check the attached files patch.diff and overview.txt. The patch also contains some source code comments. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-11-07 18:02 Message: Logged In: YES user_id=3066 What's missing in the rest of this report is that the StartElementHandler must be set to tickle this bug. ;-) I've checked in a test case in tests/runtests.c revision 1.37. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-07 16:05 Message: Logged In: YES user_id=3066 For the record: The patch was checked in as lib/xmlparse.c 1.90. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=616863&group_id=10127 From noreply@sourceforge.net Sun Nov 10 10:51:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 10 Nov 2002 02:51:51 -0800 Subject: [Expat-bugs] [ expat-Bugs-584483 ] Add expat.h to Windows install Message-ID: Bugs item #584483, was opened at 2002-07-21 06:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=584483&group_id=10127 Category: Build control Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Add expat.h to Windows install Initial Comment: Would it be possible to add expat.h to the Windows binary install. This header file is public heder file needed to build other libraries, and it would be nice to have it in binary distribution (together with libraries). Otherwise source distribution needs to be downloaded for this one file only. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-11-10 02:51 Message: Logged In: NO fdsssssf ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-07-22 08:37 Message: Logged In: YES user_id=3066 expat.h is included in the Source\lib\ directory in the installation. (Where did you expect to find it?) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=584483&group_id=10127 From noreply@sourceforge.net Sun Nov 10 10:51:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 10 Nov 2002 02:51:51 -0800 Subject: [Expat-bugs] [ expat-Bugs-584483 ] Add expat.h to Windows install Message-ID: Bugs item #584483, was opened at 2002-07-21 06:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=584483&group_id=10127 Category: Build control Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Add expat.h to Windows install Initial Comment: Would it be possible to add expat.h to the Windows binary install. This header file is public heder file needed to build other libraries, and it would be nice to have it in binary distribution (together with libraries). Otherwise source distribution needs to be downloaded for this one file only. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-11-10 02:51 Message: Logged In: NO fdsssssf ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-07-22 08:37 Message: Logged In: YES user_id=3066 expat.h is included in the Source\lib\ directory in the installation. (Where did you expect to find it?) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=584483&group_id=10127 From noreply@sourceforge.net Sun Nov 10 10:51:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 10 Nov 2002 02:51:51 -0800 Subject: [Expat-bugs] [ expat-Bugs-584483 ] Add expat.h to Windows install Message-ID: Bugs item #584483, was opened at 2002-07-21 06:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=584483&group_id=10127 Category: Build control Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Add expat.h to Windows install Initial Comment: Would it be possible to add expat.h to the Windows binary install. This header file is public heder file needed to build other libraries, and it would be nice to have it in binary distribution (together with libraries). Otherwise source distribution needs to be downloaded for this one file only. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-11-10 02:51 Message: Logged In: NO fdsssssf ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-07-22 08:37 Message: Logged In: YES user_id=3066 expat.h is included in the Source\lib\ directory in the installation. (Where did you expect to find it?) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=584483&group_id=10127 From noreply@sourceforge.net Sun Nov 10 10:51:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 10 Nov 2002 02:51:51 -0800 Subject: [Expat-bugs] [ expat-Bugs-584483 ] Add expat.h to Windows install Message-ID: Bugs item #584483, was opened at 2002-07-21 06:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=584483&group_id=10127 Category: Build control Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Add expat.h to Windows install Initial Comment: Would it be possible to add expat.h to the Windows binary install. This header file is public heder file needed to build other libraries, and it would be nice to have it in binary distribution (together with libraries). Otherwise source distribution needs to be downloaded for this one file only. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-11-10 02:51 Message: Logged In: NO fdsssssf ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-07-22 08:37 Message: Logged In: YES user_id=3066 expat.h is included in the Source\lib\ directory in the installation. (Where did you expect to find it?) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=584483&group_id=10127 From noreply@sourceforge.net Tue Nov 12 19:23:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Nov 2002 11:23:36 -0800 Subject: [Expat-bugs] [ expat-Bugs-620106 ] XML_SetEncoding and external entities Message-ID: Bugs item #620106, was opened at 2002-10-08 03:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=620106&group_id=10127 Category: None Group: Test Required >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Pavel Hlavnicka (pavel_hlavnicka) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: XML_SetEncoding and external entities Initial Comment: We are using expat with Sablotron XSLT processor. Before parsing (using always XML_Parse) we check the document encoding and in the case it is not supported by expat, we call XML_SetEncoding to set utf-8, and recode the document before feeding the parser. All is ok until we parse external entities. We create an external entity parser with XML_ExternalEntityParserCreate, but we don't know the document encoding at this time. We use XML_SetEncoding later (the same case as for the 'root' document). In this case it doesn't work. I found out, that problem is probably in the XML_SetEncoding function, what just returns zero in the case parsing is in progress. The ``parsing'' macro checks, whether the current processor is ``prologInitProcessor'', what is never true for external entity parser. For this is it ``externalEnityInitProcessor''. The patch seems be easy, but, of course, I'm not sure I'm not breaking anything else. Thanks and keep your good work. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-11-12 14:23 Message: Logged In: YES user_id=3066 Added regression test in tests/runtests.c revision 1.38. ---------------------------------------------------------------------- Comment By: Pavel Hlavnicka (pavel_hlavnicka) Date: 2002-10-11 09:33 Message: Logged In: YES user_id=302801 It makes a good job for me, so I can confirm. Thanks, it was pretty fast. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-10-09 09:23 Message: Logged In: YES user_id=290026 Applied patch - xmlparse.c rev. 1.93. Leave open for Fred, in case he wants to add a regression test. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-10-08 10:43 Message: Logged In: YES user_id=290026 I have changed this to a bug report and accepted it. Your patch seems OK, but does not go far enough.. Please try this one and give it a quick check so that I can commit it to CVS: #define parsing \ (parentParser \ ? \ (isParamEntity \ ? \ (processor != externalParEntInitProcessor) \ : \ (processor != externalEntityInitProcessor)) \ : \ (processor != prologInitProcessor)) ---------------------------------------------------------------------- Comment By: Pavel Hlavnicka (pavel_hlavnicka) Date: 2002-10-08 03:39 Message: Logged In: YES user_id=302801 The patch was not uploaded for some reason (the magic checkbox?? :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=620106&group_id=10127 From noreply@sourceforge.net Tue Nov 12 19:37:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Nov 2002 11:37:10 -0800 Subject: [Expat-bugs] [ expat-Bugs-615606 ] Buffer overrun with XML_ParserCreateNS Message-ID: Bugs item #615606, was opened at 2002-09-27 14:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615606&group_id=10127 Category: None Group: Test Required Status: Open Resolution: Fixed Priority: 5 Submitted By: Daniel Bowen (daniel_bowen) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Buffer overrun with XML_ParserCreateNS Initial Comment: Expat 1.95.5 on Win32 using MSVC 6, 7 A buffer overrun occurs under the following set of circumstances: * In a test program, create an XML_Parser using XML_ParserCreateNS (instead of XML_ParserCreate) * Parse a file (or stdin) where the number of bytes is greater than the size of your buffer (so that you have to do multiple passes). It seems to happen with both XML_GetBuffer / XML_ParseBuffer as well as allocating your own buffer and calling XML_Parse. To see that an error occurs: * Compile a debug version of expat (DLL or static library) * Compile a debug version of your test program that uses the debug version of expat * You get a dialog similar to the following: --------------------------- Microsoft Visual C++ Debug Library --------------------------- Debug Error! Program: ...\Expat-1.95.5 \Source\examples\Debug\elements.exe DAMAGE: after Normal block (#88) at 0x002F7798. (Press Retry to debug the application) --------------------------- Abort Retry Ignore --------------------------- If you click "Retry", it takes you to the _free_dbg function in dbgheap.c, line 1066 in MSVC 6, as a result of a "CheckBytes" call. The call stack indicates that this is on the "XML_ParserFree" call. In the output window, it lists a handful of addresses where the bytes should be "0xFD", such as: memory check error at 0x002F77BF = 0x69, should be 0xFD. If you view memory at this address, you see parts of the input XML file have been written there. If you set a breakpoint to break when data at this location in memory changes, you break at line 2110 in xmlparse.c in the function doContent, at the line: /* don't need to check for space - already done in storeAtts() */ while (*localPart) *uri++ = *localPart++; If you watch memory changing as you do multiple passes through XML_Parse/XML_ParseBuffer, it seems that instead of reusing the internal buffer starting at the beginning, the internal buffer keeps getting appended to (beyond the size of its allocation). This should be easily reproducable. For example, in the "elements" sample, change the "XML_ParserCreate (NULL)" line on line 32 in elements.c to "XML_ParserCreateNS(NULL, '|')". I haven't tested this scenario in builds other than 1.95.5, so I'm not sure if this is a new bug or a bug that hasn't yet been tripped across. Thanks! -Daniel ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-11-12 14:37 Message: Logged In: YES user_id=3066 Oops, this was marked "Test Required" but wasn't assigned; now assigned to me to add a regression test. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-28 21:15 Message: Logged In: NO Ouch! I've been working for the past two days tracking down this bug. Thanks for the patch! ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-09-28 10:56 Message: Logged In: YES user_id=290026 I could trace this bug to the function storeRawNames. What happens is this: when namespace processing is turned on, tag->name.str does not point to tag->buf, but to the binding->uri buffer of the associated PREFIX structure. Therefore, when tag->buf is reallocated, one should update tag->name.str only when namespace processing is off. This condition was not tested and tag->name.str was wrongly updated in those cases when namespace processing was turned on and the storeRawNames function reallocated tag->buf. Fix is already committed to CVS. Patch attached. I tested with your example and it works fine now. ---------------------------------------------------------------------- Comment By: Daniel Bowen (daniel_bowen) Date: 2002-09-27 15:09 Message: Logged In: YES user_id=619351 I had to re-upload with the compiled elements.exe taken out (it made the file too big to upload). You can just rebuild all in debug mode. ---------------------------------------------------------------------- Comment By: Daniel Bowen (daniel_bowen) Date: 2002-09-27 15:02 Message: Logged In: YES user_id=619351 I've attached a copy of the "elements" project along with the expat (static) that it uses. I compiled both in debug, and included in the upload elements.exe. Also in the examples\Debug directory is an XML file that will trigger the bug. I had tried it with only a couple of input XML files. I've tried it with a few more, and I see that to reproduce the problem is not always as simple as "Parse a file (or stdin) where the number of bytes is greater than the size of your buffer". I'm not sure what characteristics trigger the bug, but from what I could tell, this was at least one symptom. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-09-27 14:30 Message: Logged In: YES user_id=290026 I am using XML_ParserCreateNS with multiple buffers all the time and have never had that problem. Could you please attach a complete but simple test case, so that we can reproduce the error. Thanks, Karl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615606&group_id=10127 From John.Hockaday@ga.gov.au Thu Nov 14 04:24:28 2002 From: John.Hockaday@ga.gov.au (John.Hockaday@ga.gov.au) Date: Thu, 14 Nov 2002 15:24:28 +1100 Subject: [Expat-bugs] RE: Solaris make error Message-ID: Hi, I noticed that there was a thread about compiling expat on the Solaris 2.8 platform in September 2002. =20 I have been able to compile expat-1.95.5.tar.gz on a Solaris 2.8 UNIX platform using the following gcc setup: "gcc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.2/specs Configured with: ../configure --with-as=3D/usr/ccs/bin/as --with-ld=3D/usr/ccs/bin/ld --disable-nls Thread model: posix gcc version 3.2" but .... when I run "make check" I get the following output: ################ make check gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -I./lib -I. -o tests/runtes ts.o -c tests/runtests.c tests/runtests.c:2:19: check.h: No such file or directory tests/runtests.c: In function `basic_setup': tests/runtests.c:19: warning: implicit declaration of function `fail' tests/runtests.c: At top level: tests/runtests.c:68: warning: return type defaults to `int' tests/runtests.c:68: warning: function declaration isn't a prototype tests/runtests.c: In function `START_TEST': tests/runtests.c:76: warning: control reaches end of non-void function tests/runtests.c: At top level: tests/runtests.c:80: parse error before "START_TEST" tests/runtests.c:81: warning: return type defaults to `int' tests/runtests.c:81: warning: function declaration isn't a prototype tests/runtests.c:81: redefinition of `START_TEST' tests/runtests.c:68: `START_TEST' previously defined here tests/runtests.c:89: parse error before "START_TEST" tests/runtests.c:90: warning: return type defaults to `int' tests/runtests.c:90: warning: function declaration isn't a prototype tests/runtests.c:90: redefinition of `START_TEST' tests/runtests.c:81: `START_TEST' previously defined here tests/runtests.c:99: parse error before "START_TEST" tests/runtests.c:100: warning: return type defaults to `int' tests/runtests.c:100: warning: function declaration isn't a prototype tests/runtests.c:100: redefinition of `START_TEST' tests/runtests.c:90: `START_TEST' previously defined here tests/runtests.c:108: parse error before "START_TEST" tests/runtests.c:109: warning: return type defaults to `int' tests/runtests.c:109: warning: function declaration isn't a prototype tests/runtests.c:109: redefinition of `START_TEST' tests/runtests.c:100: `START_TEST' previously defined here tests/runtests.c:117: syntax error before "static" tests/runtests.c:163: warning: return type defaults to `int' tests/runtests.c:163: warning: function declaration isn't a prototype tests/runtests.c:163: redefinition of `START_TEST' tests/runtests.c:109: `START_TEST' previously defined here tests/runtests.c:174: parse error before "START_TEST" tests/runtests.c:175: warning: return type defaults to `int' tests/runtests.c:175: warning: function declaration isn't a prototype tests/runtests.c:175: redefinition of `START_TEST' tests/runtests.c:163: `START_TEST' previously defined here tests/runtests.c:184: parse error before "START_TEST" tests/runtests.c:185: warning: return type defaults to `int' tests/runtests.c:185: warning: function declaration isn't a prototype tests/runtests.c:185: redefinition of `START_TEST' tests/runtests.c:175: `START_TEST' previously defined here tests/runtests.c:194: parse error before "START_TEST" tests/runtests.c:195: warning: return type defaults to `int' tests/runtests.c:195: warning: function declaration isn't a prototype tests/runtests.c:195: redefinition of `START_TEST' tests/runtests.c:185: `START_TEST' previously defined here tests/runtests.c:204: parse error before "START_TEST" tests/runtests.c:205: warning: return type defaults to `int' tests/runtests.c:205: warning: function declaration isn't a prototype tests/runtests.c:205: redefinition of `START_TEST' tests/runtests.c:195: `START_TEST' previously defined here tests/runtests.c:218: parse error before "START_TEST" tests/runtests.c:219: warning: return type defaults to `int' tests/runtests.c:219: warning: function declaration isn't a prototype tests/runtests.c:219: redefinition of `START_TEST' tests/runtests.c:205: `START_TEST' previously defined here tests/runtests.c:230: parse error before "START_TEST" tests/runtests.c:231: warning: return type defaults to `int' tests/runtests.c:231: warning: function declaration isn't a prototype tests/runtests.c:231: redefinition of `START_TEST' tests/runtests.c:219: `START_TEST' previously defined here tests/runtests.c:251: parse error before "START_TEST" tests/runtests.c:252: warning: return type defaults to `int' tests/runtests.c:252: warning: function declaration isn't a prototype tests/runtests.c:252: redefinition of `START_TEST' tests/runtests.c:231: `START_TEST' previously defined here tests/runtests.c:269: parse error before "START_TEST" tests/runtests.c:270: warning: return type defaults to `int' tests/runtests.c:270: warning: function declaration isn't a prototype tests/runtests.c:270: redefinition of `START_TEST' tests/runtests.c:252: `START_TEST' previously defined here tests/runtests.c:292: parse error before "START_TEST" tests/runtests.c:293: warning: return type defaults to `int' tests/runtests.c:293: warning: function declaration isn't a prototype tests/runtests.c:293: redefinition of `START_TEST' tests/runtests.c:270: `START_TEST' previously defined here tests/runtests.c:312: parse error before "START_TEST" tests/runtests.c:313: warning: return type defaults to `int' tests/runtests.c:313: warning: function declaration isn't a prototype tests/runtests.c:313: redefinition of `START_TEST' tests/runtests.c:293: `START_TEST' previously defined here tests/runtests.c:331: parse error before "START_TEST" tests/runtests.c:332: warning: return type defaults to `int' tests/runtests.c:332: warning: function declaration isn't a prototype tests/runtests.c:332: redefinition of `START_TEST' tests/runtests.c:313: `START_TEST' previously defined here tests/runtests.c:370: syntax error before "static" tests/runtests.c:379: warning: return type defaults to `int' tests/runtests.c:379: warning: function declaration isn't a prototype tests/runtests.c:379: redefinition of `START_TEST' tests/runtests.c:332: `START_TEST' previously defined here tests/runtests.c:407: syntax error before "static" tests/runtests.c:483: warning: return type defaults to `int' tests/runtests.c:483: warning: function declaration isn't a prototype tests/runtests.c:483: redefinition of `START_TEST' tests/runtests.c:379: `START_TEST' previously defined here tests/runtests.c:510: parse error before "START_TEST" tests/runtests.c:511: warning: return type defaults to `int' tests/runtests.c:511: warning: function declaration isn't a prototype tests/runtests.c:511: redefinition of `START_TEST' tests/runtests.c:483: `START_TEST' previously defined here tests/runtests.c:521: syntax error before "static" tests/runtests.c:537: warning: return type defaults to `int' tests/runtests.c:537: warning: function declaration isn't a prototype tests/runtests.c:537: redefinition of `START_TEST' tests/runtests.c:511: `START_TEST' previously defined here tests/runtests.c:552: parse error before "START_TEST" tests/runtests.c:552: warning: return type defaults to `int' tests/runtests.c:552: warning: function declaration isn't a prototype tests/runtests.c:552: redefinition of `START_TEST' tests/runtests.c:537: `START_TEST' previously defined here tests/runtests.c:565: parse error before "START_TEST" tests/runtests.c:565: warning: return type defaults to `int' tests/runtests.c:565: warning: function declaration isn't a prototype tests/runtests.c:565: redefinition of `START_TEST' tests/runtests.c:552: `START_TEST' previously defined here tests/runtests.c:575: parse error before "START_TEST" tests/runtests.c:575: warning: return type defaults to `int' tests/runtests.c:575: warning: function declaration isn't a prototype tests/runtests.c:575: redefinition of `START_TEST' tests/runtests.c:565: `START_TEST' previously defined here tests/runtests.c:587: syntax error before "static" tests/runtests.c:610: warning: return type defaults to `int' tests/runtests.c:610: warning: function declaration isn't a prototype tests/runtests.c:610: redefinition of `START_TEST' tests/runtests.c:575: `START_TEST' previously defined here tests/runtests.c:627: parse error before "START_TEST" tests/runtests.c:628: warning: return type defaults to `int' tests/runtests.c:628: warning: function declaration isn't a prototype tests/runtests.c:628: redefinition of `START_TEST' tests/runtests.c:610: `START_TEST' previously defined here tests/runtests.c:646: syntax error before "static" tests/runtests.c:697: warning: return type defaults to `int' tests/runtests.c:697: warning: function declaration isn't a prototype tests/runtests.c:697: redefinition of `START_TEST' tests/runtests.c:628: `START_TEST' previously defined here tests/runtests.c:713: syntax error before "static" tests/runtests.c:752: warning: return type defaults to `int' tests/runtests.c:752: warning: function declaration isn't a prototype tests/runtests.c:752: redefinition of `START_TEST' tests/runtests.c:697: `START_TEST' previously defined here tests/runtests.c:772: parse error before "START_TEST" tests/runtests.c:773: warning: return type defaults to `int' tests/runtests.c:773: warning: function declaration isn't a prototype tests/runtests.c:773: redefinition of `START_TEST' tests/runtests.c:752: `START_TEST' previously defined here tests/runtests.c:793: syntax error before "static" tests/runtests.c:795: warning: return type defaults to `int' tests/runtests.c:795: warning: no previous prototype for `make_basic_suite' tests/runtests.c: In function `make_basic_suite': tests/runtests.c:796: `Suite' undeclared (first use in this function) tests/runtests.c:796: (Each undeclared identifier is reported only once tests/runtests.c:796: for each function it appears in.) tests/runtests.c:796: `s' undeclared (first use in this function) tests/runtests.c:796: warning: implicit declaration of function `suite_create' tests/runtests.c:797: `TCase' undeclared (first use in this function) tests/runtests.c:797: `tc_basic' undeclared (first use in this function) tests/runtests.c:797: warning: implicit declaration of function `tcase_create' tests/runtests.c:798: `tc_namespace' undeclared (first use in this function) tests/runtests.c:800: warning: implicit declaration of function `suite_add_tcase' tests/runtests.c:801: warning: implicit declaration of function `tcase_add_checked_fixture' tests/runtests.c:802: warning: implicit declaration of function `tcase_add_test' tests/runtests.c:802: `test_nul_byte' undeclared (first use in this function) tests/runtests.c:803: `test_u0000_char' undeclared (first use in this function) tests/runtests.c:804: `test_bom_utf8' undeclared (first use in this function) tests/runtests.c:805: `test_bom_utf16_be' undeclared (first use in this function) tests/runtests.c:806: `test_bom_utf16_le' undeclared (first use in this function) tests/runtests.c:807: `test_illegal_utf8' undeclared (first use in this function) tests/runtests.c:808: `test_utf16' undeclared (first use in this function) tests/runtests.c:809: `test_utf16_le_epilog_newline' undeclared (first use in this function) tests/runtests.c:810: `test_latin1_umlauts' undeclared (first use in this function) tests/runtests.c:812: `test_danish_latin1' undeclared (first use in this function) tests/runtests.c:814: `test_french_charref_hexidecimal' undeclared (first use in this function) tests/runtests.c:815: `test_french_charref_decimal' undeclared (first use in this function) tests/runtests.c:816: `test_french_latin1' undeclared (first use in this function) tests/runtests.c:817: `test_french_utf8' undeclared (first use in this function) tests/runtests.c:818: `test_utf8_false_rejection' undeclared (first use in this function) tests/runtests.c:819: `test_line_count' undeclared (first use in this function) tests/runtests.c:820: `test_really_long_lines' undeclared (first use in this function) tests/runtests.c:821: `test_end_element_events' undeclared (first use in this function) tests/runtests.c:822: `test_attr_whitespace_normalization' undeclared (first use in this function) tests/runtests.c:823: `test_xmldecl_misplaced' undeclared (first use in this function) tests/runtests.c:824: `test_unknown_encoding_internal_entity' undeclared (first use in this function ) tests/runtests.c:826: `test_wfc_undeclared_entity_unread_external_subset' undeclared (first use in t his function) tests/runtests.c:827: `test_wfc_undeclared_entity_no_external_subset' undeclared (first use in this function) tests/runtests.c:828: `test_wfc_undeclared_entity_standalone' undeclared (first use in this function ) tests/runtests.c:829: `test_wfc_undeclared_entity_with_external_subset' undeclared (first use in thi s function) tests/runtests.c:830: `test_wfc_no_recursive_entity_refs' undeclared (first use in this function) tests/runtests.c:835: `test_return_ns_triplet' undeclared (first use in this function) tests/runtests.c:836: `test_ns_tagname_overwrite' undeclared (first use in this function) tests/runtests.c:837: `test_ns_tagname_overwrite_triplet' undeclared (first use in this function) tests/runtests.c: In function `main': tests/runtests.c:848: `CK_NORMAL' undeclared (first use in this function) tests/runtests.c:849: `Suite' undeclared (first use in this function) tests/runtests.c:849: `s' undeclared (first use in this function) tests/runtests.c:850: `SRunner' undeclared (first use in this function) tests/runtests.c:850: `sr' undeclared (first use in this function) tests/runtests.c:850: warning: implicit declaration of function `srunner_create' tests/runtests.c:858: `CK_VERBOSE' undeclared (first use in this function) tests/runtests.c:860: `CK_SILENT' undeclared (first use in this function) tests/runtests.c:875: warning: implicit declaration of function `srunner_set_fork_status' tests/runtests.c:875: `CK_FORK' undeclared (first use in this function) tests/runtests.c:875: `CK_NOFORK' undeclared (first use in this function) tests/runtests.c:876: warning: implicit declaration of function `srunner_run_all' tests/runtests.c:877: warning: implicit declaration of function `srunner_ntests_failed' tests/runtests.c:878: warning: implicit declaration of function `srunner_free' tests/runtests.c:879: warning: implicit declaration of function `suite_free' make: *** [tests/runtests.o] Error 1 ################ Could this indicate that I am having troubles compiling expat-1.95.5 because of my gcc setup or is there something else that I am missing? If so, what version of gcc should I be using and should I be using GNU "as" and "ld"? Thanks in advance for any help that anyone can provide me. John From fdrake@acm.org Thu Nov 14 04:29:01 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 13 Nov 2002 23:29:01 -0500 Subject: [Expat-bugs] RE: Solaris make error In-Reply-To: References: Message-ID: <15827.9869.957810.371189@grendel.zope.com> John.Hockaday@ga.gov.au writes: > I noticed that there was a thread about compiling expat on the Solaris > 2.8 platform in September 2002. I should spend some time catching up with that; I've been a little swamped with other work lately. > I have been able to compile expat-1.95.5.tar.gz on a Solaris 2.8 UNIX > platform using the following gcc setup: ... > make check > gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions > -I./lib -I. -o tests/runtes > ts.o -c tests/runtests.c > tests/runtests.c:2:19: check.h: No such file or directory Here's the critical clue... > Could this indicate that I am having troubles compiling expat-1.95.5 > because of my gcc setup or is there something else that I am missing? > If so, what version of gcc should I be using and should I be using GNU > "as" and "ld"? The regression test uses an external support library call "check"; this appearanly isn't installed on your system. You can get the package from: http://sourceforge.net/projects/check/ -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From John.Hockaday@ga.gov.au Thu Nov 14 04:59:11 2002 From: John.Hockaday@ga.gov.au (John.Hockaday@ga.gov.au) Date: Thu, 14 Nov 2002 15:59:11 +1100 Subject: [Expat-bugs] RE: Solaris make error Message-ID: Fred, That seems to have worked! Thank you very much. John > -----Original Message----- > From: Fred L. Drake, Jr. [mailto:fdrake@acm.org]=20 > Sent: Thursday, 14 November 2002 3:29=20 > To: Hockaday John > Cc: expat-bugs@libexpat.org > Subject: Re: [Expat-bugs] RE: Solaris make error >=20 >=20 >=20 > John.Hockaday@ga.gov.au writes: > > I noticed that there was a thread about compiling expat on=20 > the Solaris > > 2.8 platform in September 2002. =20 >=20 > I should spend some time catching up with that; I've been a little > swamped with other work lately. >=20 > > I have been able to compile expat-1.95.5.tar.gz on a=20 > Solaris 2.8 UNIX > > platform using the following gcc setup: > ... > > make check > > gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes=20 > -fexceptions > > -I./lib -I. -o tests/runtes > > ts.o -c tests/runtests.c > > tests/runtests.c:2:19: check.h: No such file or directory >=20 > Here's the critical clue... >=20 > > Could this indicate that I am having troubles compiling=20 > expat-1.95.5 > > because of my gcc setup or is there something else that I=20 > am missing? > > If so, what version of gcc should I be using and should I=20 > be using GNU > > "as" and "ld"? >=20 > The regression test uses an external support library call "check"; > this appearanly isn't installed on your system. You can get the > package from: >=20 http://sourceforge.net/projects/check/ -Fred --=20 Fred L. Drake, Jr. PythonLabs at Zope Corporation _______________________________________________ Expat-bugs mailing list Expat-bugs@libexpat.org http://mail.libexpat.org/mailman/listinfo/expat-bugs From noreply@sourceforge.net Wed Nov 20 04:31:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Nov 2002 20:31:03 -0800 Subject: [Expat-bugs] [ expat-Patches-620822 ] Windows DLL build with DEF file Message-ID: Patches item #620822, was opened at 2002-10-09 11:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=620822&group_id=10127 Category: Build Control Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Windows DLL build with DEF file Initial Comment: This patch changes the Windows build (under VC++) to using DEF files, so that the export table for the Dlls remains binary compatible. It is based on the export table in Expat 1.95.2, extracted from the binary distribution Dll. Four exported functions have been added to the end of that table for release 1.95.5. The attached zip archive DefBuild.zip contains two DEF files, one for the expat project, and the other for the expatw project. Just add each file to the corresponding project in VC++. There is also a small patch for xmlparse.c required - included in the zip archive. Please test and provide feedback. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-11-19 23:31 Message: Logged In: YES user_id=3066 This was checked in some time ago. It seems to build fine for me on Windows; I'm not sure what the right way to test this is beyond making sure that finishes without error. Perhaps a Windows programmer can suggest something; my Windows expertise is fairly low. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=620822&group_id=10127 From noreply@sourceforge.net Wed Nov 20 04:33:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Nov 2002 20:33:35 -0800 Subject: [Expat-bugs] [ expat-Bugs-579144 ] DLLs are not drop-in compatible Message-ID: Bugs item #579144, was opened at 2002-07-09 11:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=579144&group_id=10127 Category: Build control Group: Feature Request >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: DLLs are not drop-in compatible Initial Comment: For Windows DLLs, Expat should be using a .DEF file instead of __declspec(dllexport) to control the export of symbols. Using a .DEF file allows symbols to have the same ordinal position in the export table of the DLL regardless of accidents of the compiler's organization of the table, allowing newer DLLs to replace older DLLs by simply dropping them in place. More information on DLL exports: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/HTML/_core_determine_which_exporting_method_to_use.asp This feature request is based on an email conversation with Nick Lehman, following up from: http://sourceforge.net/mailarchive/message.php?msg_id=1783043 ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-11-19 23:33 Message: Logged In: YES user_id=3066 Fixed by patch #620822, which has already been integrated for 1.95.6. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-10-09 11:30 Message: Logged In: YES user_id=290026 I have added a patch #620822. Sorry - I realized too late that there was a bug report where I could have attached the patch. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-07-10 09:24 Message: Logged In: YES user_id=290026 Fred, are you sure a lot of people are reading this? Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-07-10 00:47 Message: Logged In: YES user_id=3066 It looks like the .DEF file should be easy enough to create, and a nuissance to maintain. I'm going to plan on getting this done in the 1.95.5 release, since we're too close to the 1.95.4 release to make a mess of things now. The big question that comes up is this: should the symbols defined in lib/xmltok.h be exported, or only the symbols from expat.h? Originally, these were exported from two separate DLLs, but it's not clear the API defined in xmltok.h is really intended to be public. If you have a reasoned opinion, or use the xmltok.h API, please follow up to this feature request. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=579144&group_id=10127 From noreply@sourceforge.net Wed Nov 20 05:13:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Nov 2002 21:13:48 -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 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=491986&group_id=10127 Category: None Group: Platform Specific Status: Open 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 (where the danish letters is placed as eight bit chars - the parser goes wrong. If the input is: Worker Five Jørgen five@foo.com Jørgen five@foo.com (Remark the danish letters in two forms) The output is: START: email CD: (null) - 'J' - 1 CD: (null) - 'rgen five@foo.com' - 17 END: email CD: (null) - ' ' - 1 CD: (null) - ' ' - 4 START: email CD: (null) - 'JÃ؟rgen five@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@kiya.dk ---------------------------------------------------------------------- >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@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@sourceforge.net Wed Nov 20 05:16:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Nov 2002 21:16:01 -0800 Subject: [Expat-bugs] [ expat-Bugs-634409 ] XML_Feature HP-UX expat-1.95.5 Message-ID: Bugs item #634409, was opened at 2002-11-06 08:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=634409&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: XML_Feature HP-UX expat-1.95.5 Initial Comment: a build of expat-1.95.5.tar.gz on HP-UX 11 fails with gcc -O2 -w -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -O2 -w -I/usr/local/include -I./lib -I. -o xmlwf/xmlwf.o -c xmlwf/xmlwf.c xmlwf/xmlwf.c: In function `showVersion': xmlwf/xmlwf.c:602: syntax error before `*' xmlwf/xmlwf.c:613: `features' undeclared (first use in this function) xmlwf/xmlwf.c:613: (Each undeclared identifier is reported only once xmlwf/xmlwf.c:613: for each function it appears in.) xmlwf/xmlwf.c:613: `XML_FEATURE_END' undeclared (first use in this function) make: *** [xmlwf/xmlwf.o] Error 1 No problem on expat-1.95.4.tar.gz and expat-1.95.2.tar.gz ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-11-20 00:16 Message: Logged In: YES user_id=3066 If this bug can't be confirmed before the 1.95.6 release, it will be closed as user-error (old expat.h getting picked up). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-11-07 16:43 Message: Logged In: YES user_id=3066 The features support was added in 1.95.5. It looks like you're picking up an older revision of the expat.h header file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=634409&group_id=10127 From noreply@sourceforge.net Wed Nov 20 05:18:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Nov 2002 21:18:58 -0800 Subject: [Expat-bugs] [ expat-Bugs-597887 ] ld: Mismatched ABI (not an ELF file) for Message-ID: Bugs item #597887, was opened at 2002-08-20 14:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=597887&group_id=10127 >Category: Build control Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: ld: Mismatched ABI (not an ELF file) for Initial Comment: I installed expat1.95.4 . Now when i build the XML- PARSER2.31 . I am getting the following error during make . cp Parser/Encodings/README blib/lib/XML/Parser/Encodings/README cp Parser/Encodings/x-sjis-cp932.enc blib/lib/XML/Parser/Encodings/x-sjis-cp932.enc cp Parser/Encodings/iso-8859-7.enc blib/lib/XML/Parser/Encodings/iso-8859-7.enc cp Parser/Encodings/big5.enc blib/lib/XML/Parser/Encodings/big5.enc cp Parser/Encodings/windows-1250.enc blib/lib/XML/Parser/Encodings/windows-1250.enc cp Parser/Encodings/iso-8859-8.enc blib/lib/XML/Parser/Encodings/iso-8859-8.enc cp Parser/Encodings/iso-8859-2.enc blib/lib/XML/Parser/Encodings/iso-8859-2.enc cp Parser/Encodings/x-euc-jp-jisx0221.enc blib/lib/XML/Parser/Encodings/x-euc-jp-jisx0221.enc cp Parser/Encodings/iso-8859-9.enc blib/lib/XML/Parser/Encodings/iso-8859-9.enc cp Parser/Encodings/x-sjis-unicode.enc blib/lib/XML/Parser/Encodings/x-sjis-unicode.enc cp Parser/Encodings/iso-8859-3.enc blib/lib/XML/Parser/Encodings/iso-8859-3.enc cp Parser/Encodings/x-sjis-jdk117.enc blib/lib/XML/Parser/Encodings/x-sjis-jdk117.enc cp Parser/Encodings/euc-kr.enc blib/lib/XML/Parser/Encodings/euc-kr.enc cp Parser/Encodings/iso-8859-4.enc blib/lib/XML/Parser/Encodings/iso-8859-4.enc cp Parser/Encodings/Japanese_Encodings.msg blib/lib/XML/Parser/Encodings/Japanese_Encodings.msg cp Parser/Encodings/x-sjis-jisx0221.enc blib/lib/XML/Parser/Encodings/x-sjis-jisx0221.enc cp Parser.pm blib/lib/XML/Parser.pm cp Parser/Encodings/iso-8859-5.enc blib/lib/XML/Parser/Encodings/iso-8859-5.enc cp Parser/Encodings/x-euc-jp-unicode.enc blib/lib/XML/Parser/Encodings/x-euc-jp-unicode.enc cp Parser/LWPExternEnt.pl blib/lib/XML/Parser/LWPExternEnt.pl cp Expat.pm ../blib/lib/XML/Parser/Expat.pm /bin/perl -I/opt/perl5.6.1/lib/5.6.1/PA-RISC2.0 - I/opt/perl5.6.1/lib/5.6.1 /opt/perl5.6.1/lib/5.6.1/ExtUtils/xs ubpp -noprotc cc -c +z -D_HPUX_SOURCE +DD64 -Ae - I/usr/local/include -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64 -O -DVERSION=\2.31\c Running Mkbootstrap for XML::Parser::Expat () chmod 644 Expat.bs rm -f ../blib/arch/auto/XML/Parser/Expat/Expat.sl LD_RUN_PATH="/usr/local/lib" /usr/bin/ld -b +vnocompatwarnings -L/usr/local/lib -L/lib/pa20_64 Expat.o -o ../blib/arch/au ld: Mismatched ABI (not an ELF file) for -lexpat Fatal error. *** Error exit code 1 Stop. *** Error exit code 1 Thanks ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-11-20 00:18 Message: Logged In: YES user_id=3066 This is a duplicate of SF bug #626001, and that one provides a contact for the submitter. Closing this one as a duplicate. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-26 17:45 Message: Logged In: YES user_id=3066 So what's the output of "file /usr/local/lib/libexpat.so" ? Are there other Expat library files lurking? What platform? It's hard to diagnose this without more information. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=597887&group_id=10127 From noreply@sourceforge.net Wed Nov 20 16:07:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 20 Nov 2002 08:07:26 -0800 Subject: [Expat-bugs] [ expat-Bugs-632146 ] xmlwf: memory demands Message-ID: Bugs item #632146, was opened at 2002-11-01 12:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=632146&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rolf Ade (pointsman) >Assigned to: Karl Waclawek (kwaclaw) Summary: xmlwf: memory demands Initial Comment: expat 1.95.5 Running xmlwf against bigger XML files needs almost the double of the file size of memory (at the end, the process size grows permanently during the processing). This looks pretty wrong to me, since the tool does SAX parsing. Please notice, that this seems to be a problem only with the xmlwf code, not with the expat lib per se. An application by me, build on top of expat, doesn't shows this behavior. Instead, the memory size of the process stays constant and pretty low, even while parsing big XML files - which is, what I also would have expected from the xmlwf tool. I'm sorry, for only reporting the problem and not digging into. rolf ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-11-20 11:07 Message: Logged In: YES user_id=290026 What options are you using when calling xmlwf? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=632146&group_id=10127 From noreply@sourceforge.net Wed Nov 20 16:36:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 20 Nov 2002 08:36:00 -0800 Subject: [Expat-bugs] [ expat-Bugs-632146 ] xmlwf: memory demands Message-ID: Bugs item #632146, was opened at 2002-11-01 12:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=632146&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Karl Waclawek (kwaclaw) Summary: xmlwf: memory demands Initial Comment: expat 1.95.5 Running xmlwf against bigger XML files needs almost the double of the file size of memory (at the end, the process size grows permanently during the processing). This looks pretty wrong to me, since the tool does SAX parsing. Please notice, that this seems to be a problem only with the xmlwf code, not with the expat lib per se. An application by me, build on top of expat, doesn't shows this behavior. Instead, the memory size of the process stays constant and pretty low, even while parsing big XML files - which is, what I also would have expected from the xmlwf tool. I'm sorry, for only reporting the problem and not digging into. rolf ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-11-20 11:36 Message: Logged In: YES user_id=290026 I fixed a small memory leak, but don't think this applies here - the leak would only occur under certain error conditions. I couldn't really find a problem in the xmlwf code at a first check. Does this memory leak also happen with older versions of the expat lib? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-11-20 11:07 Message: Logged In: YES user_id=290026 What options are you using when calling xmlwf? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=632146&group_id=10127 From noreply@sourceforge.net Wed Nov 20 18:25:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 20 Nov 2002 10:25:25 -0800 Subject: [Expat-bugs] [ expat-Bugs-632146 ] xmlwf: memory demands Message-ID: Bugs item #632146, was opened at 2002-11-01 17:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=632146&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Karl Waclawek (kwaclaw) Summary: xmlwf: memory demands Initial Comment: expat 1.95.5 Running xmlwf against bigger XML files needs almost the double of the file size of memory (at the end, the process size grows permanently during the processing). This looks pretty wrong to me, since the tool does SAX parsing. Please notice, that this seems to be a problem only with the xmlwf code, not with the expat lib per se. An application by me, build on top of expat, doesn't shows this behavior. Instead, the memory size of the process stays constant and pretty low, even while parsing big XML files - which is, what I also would have expected from the xmlwf tool. I'm sorry, for only reporting the problem and not digging into. rolf ---------------------------------------------------------------------- >Comment By: Rolf Ade (pointsman) Date: 2002-11-20 18:25 Message: Logged In: YES user_id=13222 The problem shows even with no options given to xmlwf. i.e. xmlwf Just use a (big) XML file and watch the xmlwf process grow in the process table. (You need a really big one (several 10 MBytes) to have a change to see it with ordinary ps (on unix) or the task manager (on MS), because otherwise expat is finished, before you had a chance to see anything ;.)). No, I would bet, it's not a (classical) memory leak. I've memory debugged expat based applications several times, and the lib doesn't leak memory (or only very seldom under rare circumstances,) I've just valgrind'ed (mem leak checker) an xmlwf run, which shows the depicted behavior (xmlwf process size grows far to much), but there is no mem leak -. no pointer to allocated memory is lost, and all allocated memory is cleand up at the end. So eventually there are depending on the file size used some really big buffers, or something else. rolf ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-11-20 16:36 Message: Logged In: YES user_id=290026 I fixed a small memory leak, but don't think this applies here - the leak would only occur under certain error conditions. I couldn't really find a problem in the xmlwf code at a first check. Does this memory leak also happen with older versions of the expat lib? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-11-20 16:07 Message: Logged In: YES user_id=290026 What options are you using when calling xmlwf? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=632146&group_id=10127 From noreply@sourceforge.net Wed Nov 20 18:52:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 20 Nov 2002 10:52:30 -0800 Subject: [Expat-bugs] [ expat-Bugs-632146 ] xmlwf: memory demands Message-ID: Bugs item #632146, was opened at 2002-11-01 12:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=632146&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Karl Waclawek (kwaclaw) Summary: xmlwf: memory demands Initial Comment: expat 1.95.5 Running xmlwf against bigger XML files needs almost the double of the file size of memory (at the end, the process size grows permanently during the processing). This looks pretty wrong to me, since the tool does SAX parsing. Please notice, that this seems to be a problem only with the xmlwf code, not with the expat lib per se. An application by me, build on top of expat, doesn't shows this behavior. Instead, the memory size of the process stays constant and pretty low, even while parsing big XML files - which is, what I also would have expected from the xmlwf tool. I'm sorry, for only reporting the problem and not digging into. rolf ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-11-20 13:52 Message: Logged In: YES user_id=290026 The files you used for testing: - Do they have an internal and/or external DTD subset? - Are there external or internal entity references? - Are there attributes on some/all elements? ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-11-20 13:25 Message: Logged In: YES user_id=13222 The problem shows even with no options given to xmlwf. i.e. xmlwf Just use a (big) XML file and watch the xmlwf process grow in the process table. (You need a really big one (several 10 MBytes) to have a change to see it with ordinary ps (on unix) or the task manager (on MS), because otherwise expat is finished, before you had a chance to see anything ;.)). No, I would bet, it's not a (classical) memory leak. I've memory debugged expat based applications several times, and the lib doesn't leak memory (or only very seldom under rare circumstances,) I've just valgrind'ed (mem leak checker) an xmlwf run, which shows the depicted behavior (xmlwf process size grows far to much), but there is no mem leak -. no pointer to allocated memory is lost, and all allocated memory is cleand up at the end. So eventually there are depending on the file size used some really big buffers, or something else. rolf ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-11-20 11:36 Message: Logged In: YES user_id=290026 I fixed a small memory leak, but don't think this applies here - the leak would only occur under certain error conditions. I couldn't really find a problem in the xmlwf code at a first check. Does this memory leak also happen with older versions of the expat lib? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-11-20 11:07 Message: Logged In: YES user_id=290026 What options are you using when calling xmlwf? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=632146&group_id=10127 From noreply@sourceforge.net Thu Nov 21 00:10:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 20 Nov 2002 16:10:32 -0800 Subject: [Expat-bugs] [ expat-Bugs-632146 ] xmlwf: memory demands Message-ID: Bugs item #632146, was opened at 2002-11-01 12:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=632146&group_id=10127 Category: None >Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Rolf Ade (pointsman) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: xmlwf: memory demands Initial Comment: expat 1.95.5 Running xmlwf against bigger XML files needs almost the double of the file size of memory (at the end, the process size grows permanently during the processing). This looks pretty wrong to me, since the tool does SAX parsing. Please notice, that this seems to be a problem only with the xmlwf code, not with the expat lib per se. An application by me, build on top of expat, doesn't shows this behavior. Instead, the memory size of the process stays constant and pretty low, even while parsing big XML files - which is, what I also would have expected from the xmlwf tool. I'm sorry, for only reporting the problem and not digging into. rolf ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-11-20 19:10 Message: Logged In: YES user_id=290026 As it turns out - after reading the manual - the default behaviour of xmlwf is to use memory mapped files. This explains the observed use of memory. With the -r option xmlwf can be made to use regular file I/O, and then memory use is as expected. Maybe the question could be asked if xmlwf should have a different default behaviour. But then it would not be backwards compatible. Leave open for Fred to comment. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-11-20 13:52 Message: Logged In: YES user_id=290026 The files you used for testing: - Do they have an internal and/or external DTD subset? - Are there external or internal entity references? - Are there attributes on some/all elements? ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-11-20 13:25 Message: Logged In: YES user_id=13222 The problem shows even with no options given to xmlwf. i.e. xmlwf Just use a (big) XML file and watch the xmlwf process grow in the process table. (You need a really big one (several 10 MBytes) to have a change to see it with ordinary ps (on unix) or the task manager (on MS), because otherwise expat is finished, before you had a chance to see anything ;.)). No, I would bet, it's not a (classical) memory leak. I've memory debugged expat based applications several times, and the lib doesn't leak memory (or only very seldom under rare circumstances,) I've just valgrind'ed (mem leak checker) an xmlwf run, which shows the depicted behavior (xmlwf process size grows far to much), but there is no mem leak -. no pointer to allocated memory is lost, and all allocated memory is cleand up at the end. So eventually there are depending on the file size used some really big buffers, or something else. rolf ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-11-20 11:36 Message: Logged In: YES user_id=290026 I fixed a small memory leak, but don't think this applies here - the leak would only occur under certain error conditions. I couldn't really find a problem in the xmlwf code at a first check. Does this memory leak also happen with older versions of the expat lib? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-11-20 11:07 Message: Logged In: YES user_id=290026 What options are you using when calling xmlwf? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=632146&group_id=10127 From noreply@sourceforge.net Fri Nov 22 18:25:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 22 Nov 2002 10:25:44 -0800 Subject: [Expat-bugs] [ expat-Bugs-615272 ] Expat 1.95.5 static library name Message-ID: Bugs item #615272, was opened at 2002-09-26 18:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615272&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Karl Waclawek (kwaclaw) Summary: Expat 1.95.5 static library name Initial Comment: Expat 1.95.5 on Win32 using MSVC. I think its great that you include a static library now! It would be more convenient for our build environment though if you called the static .lib files something different than the DLL stub .lib files so that they can live in the same directory. Of course, anyone building expat could do this, but it would be nice to have it this way out of the box. You could then move these files into the "Libs" directory, and delete the "StaticLibs" directory. For other libraries, I've seen "static" appended to the name. Another thing that is often done with MSVC static libraries is to have multiple version based on how you link with the CRT - /MT (Multithreaded) or /MD (Multithreaded DLL) - and to append MT or MD to the name. This way you can use the appropriate static library depending on your situation. It's also common to keep everything in one .dsp, and use multiple configurations. So instead of 4 .dsp files, you'd have 1 .dsp with the configurations: Win32 Debug DLL (libexpat.dll and stub libexpat.lib) Win32 Debug Static MT (static libexpatMT.lib) Win32 Debug Static MD (static libexpatMD.lib) Win32 Release DLL (libexpat.dll and stub libexpat.lib) Win32 Release Static MT (static libexpatMT.lib) Win32 Release Static MD (static libexpatMD.lib) Win32 Unicode Debug DLL (libexpatw.dll and stub libexpatw.lib) Win32 Unicode Debug Static MT (static libexpatwMT.lib) Win32 Unicode Debug Static MD (static libexpatwMD.lib) Win32 Unicode Release DLL (libexpatw.dll and stub libexpatw.lib) Win32 Unicode Release Static MT (static libexpatwMT.lib) Win32 Unicode Release Static MD (static libexpatwMD.lib) It would also be nice if instead of needing to define "_STATIC", it was something a little more specific like "_EXPAT_STATIC" or even "XML_STATIC". Thanks! ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-11-22 13:25 Message: Logged In: YES user_id=290026 For the 1.95.6 release I have made the following changes: - The static projects now build libexpatMT.lib and libexpatwMT.lib by default (i.e. linked to the multithreaded runtime Dll) - in ../Win32/ReadMe.txt there are instructions for how to build the static libs linked to the two other versions of the runtime lib (single-threaded and multi-threaded static) - The naming conventions follow the MS standard (using the MT, ML, MD postfixes) - _STATIC was changed to XML_STATIC I have not had time to change to a more project configuration oriented setup (as described in the original feature request note). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-09-26 19:39 Message: Logged In: YES user_id=290026 Since you already seem to know exactly what to do, why don't you submit a patch with these changes? We would certainly have a look at it, and there is a good chance it could be included in the next release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615272&group_id=10127 From noreply@sourceforge.net Tue Nov 26 21:03:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Nov 2002 13:03:32 -0800 Subject: [Expat-bugs] [ expat-Bugs-644334 ] (expat 1.95.5) Compiling by aCC on HP Message-ID: Bugs item #644334, was opened at 2002-11-27 00:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=644334&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Artyom Bolgar (artyom17) Assigned to: Nobody/Anonymous (nobody) Summary: (expat 1.95.5) Compiling by aCC on HP Initial Comment: I found out that EXPAT can't be compiled by aCC compiler on HP and SUN. It happens because this compiler tries to compile C-files as C++ ones. That is why some lines can't be compiled, for example: parser = memsuite->malloc_fcn(sizeof(struct XML_ParserStruct)); it should be changed to: parser = (struct XML_ParserStruct*)memsuite- >malloc_fcn(sizeof(struct XML_ParserStruct)); In this case it is compatible with both C and C++ languages. There are a lot of such lines in xmlparse.c and one in xmltok.c. I fixed all such places and I attached the .diff-files for 1.95.5 version. This problem could be easyly reproduced by compiling by VC6 or VC7 with '-TP' option ("compile all files as C++"). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=644334&group_id=10127 From noreply@sourceforge.net Tue Nov 26 21:12:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Nov 2002 13:12:21 -0800 Subject: [Expat-bugs] [ expat-Bugs-644343 ] (expat 1.95.5) 'const' keyword Message-ID: Bugs item #644343, was opened at 2002-11-27 00:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=644343&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Artyom Bolgar (artyom17) Assigned to: Nobody/Anonymous (nobody) Summary: (expat 1.95.5) 'const' keyword Initial Comment: Not all C-compilers knows the 'const' keyword (especially old ones). That is why I propse to add the following lines into expat.h file: #ifndef __cplusplus #define const #endif It defines 'const' as empty identifier and everything is compiled OK. I attached the diff file for 1.95.5. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=644343&group_id=10127 From noreply@sourceforge.net Tue Nov 26 21:54:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Nov 2002 13:54:14 -0800 Subject: [Expat-bugs] [ expat-Bugs-644343 ] (expat 1.95.5) 'const' keyword Message-ID: Bugs item #644343, was opened at 2002-11-27 00:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=644343&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Artyom Bolgar (artyom17) Assigned to: Nobody/Anonymous (nobody) Summary: (expat 1.95.5) 'const' keyword Initial Comment: Not all C-compilers knows the 'const' keyword (especially old ones). That is why I propse to add the following lines into expat.h file: #ifndef __cplusplus #define const #endif It defines 'const' as empty identifier and everything is compiled OK. I attached the diff file for 1.95.5. Thanks. ---------------------------------------------------------------------- >Comment By: Artyom Bolgar (artyom17) Date: 2002-11-27 00:54 Message: Logged In: YES user_id=657326 More exactly, will be better to change it to: #ifdef XML_NOCONST #define const #endif I guess. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=644343&group_id=10127 From noreply@sourceforge.net Wed Nov 27 01:10:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Nov 2002 17:10:44 -0800 Subject: [Expat-bugs] [ expat-Bugs-644461 ] (expat 1.95.5) XML_Feature->name -const? Message-ID: Bugs item #644461, was opened at 2002-11-26 17:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=644461&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: (expat 1.95.5) XML_Feature->name -const? Initial Comment: I suppose the memeber 'name' of XML_Feature struct should be declared as const (see 'expat.h'): typedef struct { enum XML_FeatureEnum feature; const XML_LChar *name; /*!AB*/ long int value; } XML_Feature; The absence of 'const' modifier here causes warnings on HP-UX with using aCC comipler. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=644461&group_id=10127 From noreply@sourceforge.net Wed Nov 27 01:12:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Nov 2002 17:12:11 -0800 Subject: [Expat-bugs] [ expat-Bugs-644461 ] (expat 1.95.5) XML_Feature->name -const? Message-ID: Bugs item #644461, was opened at 2002-11-26 17:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=644461&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: (expat 1.95.5) XML_Feature->name -const? Initial Comment: I suppose the memeber 'name' of XML_Feature struct should be declared as const (see 'expat.h'): typedef struct { enum XML_FeatureEnum feature; const XML_LChar *name; /*!AB*/ long int value; } XML_Feature; The absence of 'const' modifier here causes warnings on HP-UX with using aCC comipler. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-11-26 17:12 Message: Logged In: NO I forgot to login before post the bug report, sorry. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=644461&group_id=10127 From noreply@sourceforge.net Wed Nov 27 01:14:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Nov 2002 17:14:44 -0800 Subject: [Expat-bugs] [ expat-Bugs-644461 ] (expat 1.95.5) XML_Feature->name -const? Message-ID: Bugs item #644461, was opened at 2002-11-27 04:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=644461&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: (expat 1.95.5) XML_Feature->name -const? Initial Comment: I suppose the memeber 'name' of XML_Feature struct should be declared as const (see 'expat.h'): typedef struct { enum XML_FeatureEnum feature; const XML_LChar *name; /*!AB*/ long int value; } XML_Feature; The absence of 'const' modifier here causes warnings on HP-UX with using aCC comipler. ---------------------------------------------------------------------- Comment By: Artyom Bolgar (artyom17) Date: 2002-11-27 04:14 Message: Logged In: YES user_id=657326 Yeah, again forgot :) This is me, artyom17. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-11-27 04:12 Message: Logged In: NO I forgot to login before post the bug report, sorry. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=644461&group_id=10127 From noreply@sourceforge.net Wed Nov 27 03:32:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Nov 2002 19:32:21 -0800 Subject: [Expat-bugs] [ expat-Bugs-644461 ] (expat 1.95.5) XML_Feature->name -const? Message-ID: Bugs item #644461, was opened at 2002-11-26 20:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=644461&group_id=10127 Category: None >Group: Platform Specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: (expat 1.95.5) XML_Feature->name -const? Initial Comment: I suppose the memeber 'name' of XML_Feature struct should be declared as const (see 'expat.h'): typedef struct { enum XML_FeatureEnum feature; const XML_LChar *name; /*!AB*/ long int value; } XML_Feature; The absence of 'const' modifier here causes warnings on HP-UX with using aCC comipler. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-11-26 22:32 Message: Logged In: YES user_id=3066 Change committed in lib/expat.h revision 1.46. ---------------------------------------------------------------------- Comment By: Artyom Bolgar (artyom17) Date: 2002-11-26 20:14 Message: Logged In: YES user_id=657326 Yeah, again forgot :) This is me, artyom17. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-11-26 20:12 Message: Logged In: NO I forgot to login before post the bug report, sorry. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=644461&group_id=10127 From noreply@sourceforge.net Wed Nov 27 03:38:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Nov 2002 19:38:10 -0800 Subject: [Expat-bugs] [ expat-Bugs-644343 ] (expat 1.95.5) 'const' keyword Message-ID: Bugs item #644343, was opened at 2002-11-26 16:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=644343&group_id=10127 Category: None >Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Artyom Bolgar (artyom17) Assigned to: Nobody/Anonymous (nobody) Summary: (expat 1.95.5) 'const' keyword Initial Comment: Not all C-compilers knows the 'const' keyword (especially old ones). That is why I propse to add the following lines into expat.h file: #ifndef __cplusplus #define const #endif It defines 'const' as empty identifier and everything is compiled OK. I attached the diff file for 1.95.5. Thanks. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-11-26 22:38 Message: Logged In: YES user_id=3066 What C compilers don't support "const"? That's not exactly a recent addition. Unless you can make the case that there are important platforms which can't be supported at all (with any compiler) without this, I'll reject it. It just doesn't make a lot of sense to support C implementations that don't comply with at least C89. ---------------------------------------------------------------------- Comment By: Artyom Bolgar (artyom17) Date: 2002-11-26 16:54 Message: Logged In: YES user_id=657326 More exactly, will be better to change it to: #ifdef XML_NOCONST #define const #endif I guess. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=644343&group_id=10127 From noreply@sourceforge.net Wed Nov 27 04:05:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Nov 2002 20:05:17 -0800 Subject: [Expat-bugs] [ expat-Bugs-644334 ] (expat 1.95.5) Compiling by aCC on HP Message-ID: Bugs item #644334, was opened at 2002-11-26 16:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=644334&group_id=10127 Category: None >Group: Platform Specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Artyom Bolgar (artyom17) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: (expat 1.95.5) Compiling by aCC on HP Initial Comment: I found out that EXPAT can't be compiled by aCC compiler on HP and SUN. It happens because this compiler tries to compile C-files as C++ ones. That is why some lines can't be compiled, for example: parser = memsuite->malloc_fcn(sizeof(struct XML_ParserStruct)); it should be changed to: parser = (struct XML_ParserStruct*)memsuite- >malloc_fcn(sizeof(struct XML_ParserStruct)); In this case it is compatible with both C and C++ languages. There are a lot of such lines in xmlparse.c and one in xmltok.c. I fixed all such places and I attached the .diff-files for 1.95.5 version. This problem could be easyly reproduced by compiling by VC6 or VC7 with '-TP' option ("compile all files as C++"). ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-11-26 23:05 Message: Logged In: YES user_id=3066 Committed changes based on the supplied patch as lib/xmlparse.c 1.96 and lib/xmltok.c 1.27. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=644334&group_id=10127 From noreply@sourceforge.net Wed Nov 27 17:08:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 27 Nov 2002 09:08:32 -0800 Subject: [Expat-bugs] [ expat-Bugs-644334 ] (expat 1.95.5) Compiling by aCC on HP Message-ID: Bugs item #644334, was opened at 2002-11-26 16:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=644334&group_id=10127 Category: None Group: Platform Specific >Status: Open Resolution: Fixed Priority: 5 Submitted By: Artyom Bolgar (artyom17) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: (expat 1.95.5) Compiling by aCC on HP Initial Comment: I found out that EXPAT can't be compiled by aCC compiler on HP and SUN. It happens because this compiler tries to compile C-files as C++ ones. That is why some lines can't be compiled, for example: parser = memsuite->malloc_fcn(sizeof(struct XML_ParserStruct)); it should be changed to: parser = (struct XML_ParserStruct*)memsuite- >malloc_fcn(sizeof(struct XML_ParserStruct)); In this case it is compatible with both C and C++ languages. There are a lot of such lines in xmlparse.c and one in xmltok.c. I fixed all such places and I attached the .diff-files for 1.95.5 version. This problem could be easyly reproduced by compiling by VC6 or VC7 with '-TP' option ("compile all files as C++"). ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-11-27 12:08 Message: Logged In: YES user_id=290026 There were more things to fix, some cosmetic changes, and I uncovered a problem with the API - the externalEntityRefHandler type definition: This is how the externalEntityRefHandler is called: if (!externalEntityRefHandler( externalEntityRefHandlerArg, 0, entity->base, entity->systemId, entity->publicId)) and this is how one sets externalEntityRefHandlerArg: void XML_SetExternalEntityRefHandlerArg( XML_Parser parser, void *arg) { if (arg) externalEntityRefHandlerArg = arg; else externalEntityRefHandlerArg = parser; } So, externalEntityRefHandlerArg is a void pointer, but can contain a user defined pointer or a parser pointer. Unfortunately the externalEntityRefHandler is defined like this: typedef int (*XML_ExternalEntityRefHandler)( XML_Parser parser, const XML_Char *context, const XML_Char *base, const XML_Char *systemId, const XML_Char *publicId); In order to fix that I changed the type of externalEntityRefHandlerArg from void * to XML_Parser (= struct struct XML_ParserStruct *) and added a type cast in XML_SetExternalEntityRefHandlerArg. However, this is not a real fix, since ideally the API should be changed. Needs documentation. Attached as xmlparse.diff. Leave open for Fred to document the API issue. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-11-26 23:05 Message: Logged In: YES user_id=3066 Committed changes based on the supplied patch as lib/xmlparse.c 1.96 and lib/xmltok.c 1.27. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=644334&group_id=10127 From noreply@sourceforge.net Wed Nov 27 17:34:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 27 Nov 2002 09:34:11 -0800 Subject: [Expat-bugs] [ expat-Bugs-644334 ] (expat 1.95.5) Compiling by aCC on HP Message-ID: Bugs item #644334, was opened at 2002-11-26 16:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=644334&group_id=10127 >Category: Documentation Group: Platform Specific Status: Open Resolution: Fixed Priority: 5 Submitted By: Artyom Bolgar (artyom17) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: (expat 1.95.5) Compiling by aCC on HP Initial Comment: I found out that EXPAT can't be compiled by aCC compiler on HP and SUN. It happens because this compiler tries to compile C-files as C++ ones. That is why some lines can't be compiled, for example: parser = memsuite->malloc_fcn(sizeof(struct XML_ParserStruct)); it should be changed to: parser = (struct XML_ParserStruct*)memsuite- >malloc_fcn(sizeof(struct XML_ParserStruct)); In this case it is compatible with both C and C++ languages. There are a lot of such lines in xmlparse.c and one in xmltok.c. I fixed all such places and I attached the .diff-files for 1.95.5 version. This problem could be easyly reproduced by compiling by VC6 or VC7 with '-TP' option ("compile all files as C++"). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-11-27 12:08 Message: Logged In: YES user_id=290026 There were more things to fix, some cosmetic changes, and I uncovered a problem with the API - the externalEntityRefHandler type definition: This is how the externalEntityRefHandler is called: if (!externalEntityRefHandler( externalEntityRefHandlerArg, 0, entity->base, entity->systemId, entity->publicId)) and this is how one sets externalEntityRefHandlerArg: void XML_SetExternalEntityRefHandlerArg( XML_Parser parser, void *arg) { if (arg) externalEntityRefHandlerArg = arg; else externalEntityRefHandlerArg = parser; } So, externalEntityRefHandlerArg is a void pointer, but can contain a user defined pointer or a parser pointer. Unfortunately the externalEntityRefHandler is defined like this: typedef int (*XML_ExternalEntityRefHandler)( XML_Parser parser, const XML_Char *context, const XML_Char *base, const XML_Char *systemId, const XML_Char *publicId); In order to fix that I changed the type of externalEntityRefHandlerArg from void * to XML_Parser (= struct struct XML_ParserStruct *) and added a type cast in XML_SetExternalEntityRefHandlerArg. However, this is not a real fix, since ideally the API should be changed. Needs documentation. Attached as xmlparse.diff. Leave open for Fred to document the API issue. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-11-26 23:05 Message: Logged In: YES user_id=3066 Committed changes based on the supplied patch as lib/xmlparse.c 1.96 and lib/xmltok.c 1.27. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=644334&group_id=10127 From noreply@sourceforge.net Wed Nov 27 18:10:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 27 Nov 2002 10:10:44 -0800 Subject: [Expat-bugs] [ expat-Bugs-644334 ] (expat 1.95.5) Compiling by aCC on HP Message-ID: Bugs item #644334, was opened at 2002-11-26 13:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=644334&group_id=10127 Category: Documentation Group: Platform Specific Status: Open Resolution: Fixed Priority: 5 Submitted By: Artyom Bolgar (artyom17) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: (expat 1.95.5) Compiling by aCC on HP Initial Comment: I found out that EXPAT can't be compiled by aCC compiler on HP and SUN. It happens because this compiler tries to compile C-files as C++ ones. That is why some lines can't be compiled, for example: parser = memsuite->malloc_fcn(sizeof(struct XML_ParserStruct)); it should be changed to: parser = (struct XML_ParserStruct*)memsuite- >malloc_fcn(sizeof(struct XML_ParserStruct)); In this case it is compatible with both C and C++ languages. There are a lot of such lines in xmlparse.c and one in xmltok.c. I fixed all such places and I attached the .diff-files for 1.95.5 version. This problem could be easyly reproduced by compiling by VC6 or VC7 with '-TP' option ("compile all files as C++"). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-11-27 10:10 Message: Logged In: NO Couldn't this problem be simply solved by specifying using c89 (not aCC) when compiling? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-11-27 09:08 Message: Logged In: YES user_id=290026 There were more things to fix, some cosmetic changes, and I uncovered a problem with the API - the externalEntityRefHandler type definition: This is how the externalEntityRefHandler is called: if (!externalEntityRefHandler( externalEntityRefHandlerArg, 0, entity->base, entity->systemId, entity->publicId)) and this is how one sets externalEntityRefHandlerArg: void XML_SetExternalEntityRefHandlerArg( XML_Parser parser, void *arg) { if (arg) externalEntityRefHandlerArg = arg; else externalEntityRefHandlerArg = parser; } So, externalEntityRefHandlerArg is a void pointer, but can contain a user defined pointer or a parser pointer. Unfortunately the externalEntityRefHandler is defined like this: typedef int (*XML_ExternalEntityRefHandler)( XML_Parser parser, const XML_Char *context, const XML_Char *base, const XML_Char *systemId, const XML_Char *publicId); In order to fix that I changed the type of externalEntityRefHandlerArg from void * to XML_Parser (= struct struct XML_ParserStruct *) and added a type cast in XML_SetExternalEntityRefHandlerArg. However, this is not a real fix, since ideally the API should be changed. Needs documentation. Attached as xmlparse.diff. Leave open for Fred to document the API issue. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-11-26 20:05 Message: Logged In: YES user_id=3066 Committed changes based on the supplied patch as lib/xmlparse.c 1.96 and lib/xmltok.c 1.27. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=644334&group_id=10127 From noreply@sourceforge.net Wed Nov 27 20:14:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 27 Nov 2002 12:14:49 -0800 Subject: [Expat-bugs] [ expat-Bugs-644343 ] (expat 1.95.5) 'const' keyword Message-ID: Bugs item #644343, was opened at 2002-11-27 00:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=644343&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Artyom Bolgar (artyom17) Assigned to: Nobody/Anonymous (nobody) Summary: (expat 1.95.5) 'const' keyword Initial Comment: Not all C-compilers knows the 'const' keyword (especially old ones). That is why I propse to add the following lines into expat.h file: #ifndef __cplusplus #define const #endif It defines 'const' as empty identifier and everything is compiled OK. I attached the diff file for 1.95.5. Thanks. ---------------------------------------------------------------------- >Comment By: Artyom Bolgar (artyom17) Date: 2002-11-27 23:14 Message: Logged In: YES user_id=657326 I seem to recall the xlc compiler on the IBM AIX box. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-11-27 06:38 Message: Logged In: YES user_id=3066 What C compilers don't support "const"? That's not exactly a recent addition. Unless you can make the case that there are important platforms which can't be supported at all (with any compiler) without this, I'll reject it. It just doesn't make a lot of sense to support C implementations that don't comply with at least C89. ---------------------------------------------------------------------- Comment By: Artyom Bolgar (artyom17) Date: 2002-11-27 00:54 Message: Logged In: YES user_id=657326 More exactly, will be better to change it to: #ifdef XML_NOCONST #define const #endif I guess. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=644343&group_id=10127 From noreply@sourceforge.net Wed Nov 27 20:34:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 27 Nov 2002 12:34:04 -0800 Subject: [Expat-bugs] [ expat-Bugs-644343 ] (expat 1.95.5) 'const' keyword Message-ID: Bugs item #644343, was opened at 2002-11-26 16:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=644343&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Artyom Bolgar (artyom17) Assigned to: Nobody/Anonymous (nobody) Summary: (expat 1.95.5) 'const' keyword Initial Comment: Not all C-compilers knows the 'const' keyword (especially old ones). That is why I propse to add the following lines into expat.h file: #ifndef __cplusplus #define const #endif It defines 'const' as empty identifier and everything is compiled OK. I attached the diff file for 1.95.5. Thanks. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-11-27 15:34 Message: Logged In: YES user_id=290026 But is xlc the only C compiler for AIX? A quick google search turned up: - IBM C for AIX - VisualAge C++ for AIX - gcc (version 2.9.aix51.020209 ) - XL C for AIX (seems to have a C89 compliance option) ---------------------------------------------------------------------- Comment By: Artyom Bolgar (artyom17) Date: 2002-11-27 15:14 Message: Logged In: YES user_id=657326 I seem to recall the xlc compiler on the IBM AIX box. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-11-26 22:38 Message: Logged In: YES user_id=3066 What C compilers don't support "const"? That's not exactly a recent addition. Unless you can make the case that there are important platforms which can't be supported at all (with any compiler) without this, I'll reject it. It just doesn't make a lot of sense to support C implementations that don't comply with at least C89. ---------------------------------------------------------------------- Comment By: Artyom Bolgar (artyom17) Date: 2002-11-26 16:54 Message: Logged In: YES user_id=657326 More exactly, will be better to change it to: #ifdef XML_NOCONST #define const #endif I guess. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=644343&group_id=10127 From noreply@sourceforge.net Thu Nov 28 01:12:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 27 Nov 2002 17:12:50 -0800 Subject: [Expat-bugs] [ expat-Bugs-644343 ] (expat 1.95.5) 'const' keyword Message-ID: Bugs item #644343, was opened at 2002-11-27 00:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=644343&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Artyom Bolgar (artyom17) Assigned to: Nobody/Anonymous (nobody) Summary: (expat 1.95.5) 'const' keyword Initial Comment: Not all C-compilers knows the 'const' keyword (especially old ones). That is why I propse to add the following lines into expat.h file: #ifndef __cplusplus #define const #endif It defines 'const' as empty identifier and everything is compiled OK. I attached the diff file for 1.95.5. Thanks. ---------------------------------------------------------------------- >Comment By: Artyom Bolgar (artyom17) Date: 2002-11-28 04:12 Message: Logged In: YES user_id=657326 Well, I have to check it out to be sure. I'll post an additional info later. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-11-27 23:34 Message: Logged In: YES user_id=290026 But is xlc the only C compiler for AIX? A quick google search turned up: - IBM C for AIX - VisualAge C++ for AIX - gcc (version 2.9.aix51.020209 ) - XL C for AIX (seems to have a C89 compliance option) ---------------------------------------------------------------------- Comment By: Artyom Bolgar (artyom17) Date: 2002-11-27 23:14 Message: Logged In: YES user_id=657326 I seem to recall the xlc compiler on the IBM AIX box. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-11-27 06:38 Message: Logged In: YES user_id=3066 What C compilers don't support "const"? That's not exactly a recent addition. Unless you can make the case that there are important platforms which can't be supported at all (with any compiler) without this, I'll reject it. It just doesn't make a lot of sense to support C implementations that don't comply with at least C89. ---------------------------------------------------------------------- Comment By: Artyom Bolgar (artyom17) Date: 2002-11-27 00:54 Message: Logged In: YES user_id=657326 More exactly, will be better to change it to: #ifdef XML_NOCONST #define const #endif I guess. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=644343&group_id=10127