From noreply@sourceforge.net Mon Apr 1 23:55:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon Apr 1 23:55:24 2002 Subject: [ expat-Patches-538032 ] Borland Win32 project & makefiles Message-ID: Patches item #538032, was opened at 2002-04-01 16:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=538032&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Patrick McConnell (pmcconnell) Assigned to: Nobody/Anonymous (nobody) Summary: Borland Win32 project & makefiles Initial Comment: Borland C++ Builder project file and make file for the command line compiler to build expat.dll Unzip the patch from the directory above expat, then read the README.borland file for instructions. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=538032&group_id=10127 From noreply@sourceforge.net Tue Apr 2 13:58:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Apr 2 13:58:16 2002 Subject: [ expat-Bugs-538445 ] cc: -a conflicts with -dy Message-ID: Bugs item #538445, was opened at 2002-04-02 13:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=538445&group_id=10127 Category: Build control Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: cc: -a conflicts with -dy Initial Comment: I am trying to build expat on a sun solaris system and I get the following error during the build. cc: -a conflicts with -dy I used the --prefix option during the ./configure execution. Everything else was done just as the documentation suggested. Any help would be much appreciated. Thank you. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=538445&group_id=10127 From noreply@sourceforge.net Tue Apr 2 14:48:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Apr 2 14:48:50 2002 Subject: [ expat-Bugs-538445 ] cc: -a conflicts with -dy Message-ID: Bugs item #538445, was opened at 2002-04-02 16:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=538445&group_id=10127 Category: Build control Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: cc: -a conflicts with -dy Initial Comment: I am trying to build expat on a sun solaris system and I get the following error during the build. cc: -a conflicts with -dy I used the --prefix option during the ./configure execution. Everything else was done just as the documentation suggested. Any help would be much appreciated. Thank you. ---------------------------------------------------------------------- Comment By: Mathew Bevilacqua (matbev1) Date: 2002-04-02 17:40 Message: Logged In: YES user_id=501365 I, too, followed the instructions exactly, and some more tweaking was needed. For my build to work, I had to: 1. make sure that LIBTOOL in the makefile in /lib was set correctly 2. build as a super user Also, you could try removing -dy. It's just a debug utility. From noreply@sourceforge.net Wed Apr 3 15:09:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed Apr 3 15:09:37 2002 Subject: [ expat-Bugs-538183 ] Building on Mac OS X Message-ID: Bugs item #538183, was opened at 2002-04-02 07:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=538183&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Peter Lindberg (tesugen) Assigned to: Greg Stein (gstein) Summary: Building on Mac OS X Initial Comment: I had to change the config.objc.m file in order to get ./configure to detect whether Objective-C /really/ works: burger% diff -c old-config.objc.m config.objc.m *** old-config.objc.m Tue Apr 2 07:11:39 2002 --- config.objc.m Tue Apr 2 07:08:33 2002 *************** *** 1,8 **** --- 1,10 ---- /* Dummy NXConstantString impl for so libobjc that doesn't include it */ + #ifndef __APPLE__ #ifndef NeXT_RUNTIME #include @implementation NXConstantString @end + #endif #endif #include burger% I'm not sure whether this is the correct thing to do. I don't recognize the NeXT_RUNTIME define so I'm not sure whether I should check for some define that ./configure passes on. This works, however (although you could actually ASSUME that Objective-C works on Mac OS X, since it is the #1 language for Mac OS X development). Regards, /P. -- Peter Lindberg Computer Programmer, Sweden mailto:peter@oops.se http://tesugen.com ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=538183&group_id=10127 From noreply@sourceforge.net Wed Apr 3 15:14:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed Apr 3 15:14:45 2002 Subject: [ expat-Bugs-538183 ] Building on Mac OS X Message-ID: Bugs item #538183, was opened at 2002-04-02 07:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=538183&group_id=10127 Category: Build control Group: Platform Specific >Status: Deleted Resolution: None Priority: 5 Submitted By: Peter Lindberg (tesugen) Assigned to: Greg Stein (gstein) Summary: Building on Mac OS X Initial Comment: I had to change the config.objc.m file in order to get ./configure to detect whether Objective-C /really/ works: burger% diff -c old-config.objc.m config.objc.m *** old-config.objc.m Tue Apr 2 07:11:39 2002 --- config.objc.m Tue Apr 2 07:08:33 2002 *************** *** 1,8 **** --- 1,10 ---- /* Dummy NXConstantString impl for so libobjc that doesn't include it */ + #ifndef __APPLE__ #ifndef NeXT_RUNTIME #include @implementation NXConstantString @end + #endif #endif #include burger% I'm not sure whether this is the correct thing to do. I don't recognize the NeXT_RUNTIME define so I'm not sure whether I should check for some define that ./configure passes on. This works, however (although you could actually ASSUME that Objective-C works on Mac OS X, since it is the #1 language for Mac OS X development). Regards, /P. -- Peter Lindberg Computer Programmer, Sweden mailto:peter@oops.se http://tesugen.com ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=538183&group_id=10127 From noreply@sourceforge.net Thu Apr 4 06:01:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Apr 4 06:01:20 2002 Subject: [ expat-Bugs-539242 ] make problems on Compaq Alpha Message-ID: Bugs item #539242, was opened at 2002-04-04 06:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=539242&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: make problems on Compaq Alpha Initial Comment: - make in top directory considered the subdirs up to date even after a make clean; had to cd to each subdir and run make by hand - in xmlwf/Makefile, had to manually change -static to -non_shared; it doesn't use the libtools from the top level, apparently - in examples/Makefile, had to manually change -static to -non_shared; it doesn't use the libtools from the top level, apparently; also had to add a -I option to the compile options so that expat.h could be found, e.g. LIBS = -L$(LIBDIR) -lexpat -I$(INCDIR) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=539242&group_id=10127 From noreply@sourceforge.net Mon Apr 15 21:07:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon Apr 15 20:07:02 2002 Subject: [ expat-Bugs-514281 ] french accents errors? Message-ID: Bugs item #514281, was opened at 2002-02-07 09:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=514281&group_id=10127 Category: None Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Vincent Fortier (fortierv) Assigned to: Nobody/Anonymous (nobody) Summary: french accents errors? Initial Comment: I'm having errors with french accents in iso-8859-1 and utf-8 format only at a specific place.. Exemple: Ville Charlesbourg Martin Labbé (xxx)xxx It always stops at Martin Labbé .. If I either change "é" for an "e" it works.. if I simply add 2 chars after the "é" like: Martin LabbéXX it still works... But it always stops when it finishes with "é" or "éX".... I've tried a few patches.. one for expat.h and xmlparse.c wich was unicode changes (#476931, #464837).. and another one wich was about xmltok.c (#477667)... but with no success.. I always get the error message "mismatched tag at line xx"... I have a lot of "éèàçêÈ" everywhere.. but it seems to only stop when it's placed right at the end of a tag.. Anybody can help me out? - vin ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-15 23:06 Message: Logged In: YES user_id=3066 Confirmed, mostly. With the current CVS, I can't seem to get things to work by adding "XX" before the tag. I'm also seeing a different error: "not well-formed (invalid token)". I've attached a patch that adds tests to the test suite. ---------------------------------------------------------------------- Comment By: John Dawson (jdawson) Date: 2002-03-26 16:54 Message: Logged In: YES user_id=30450 I have encountered a similar problem where I work, doing German. My code was in Perl, and used XML::Parser and XML::Parser::Expat, but I believe that Perl is not relevant to this issue. I was using libexpat 1.95.1. I got things to work by doing the following: 1) Giving the input XML document an encoding type of iso- 8859-1. This will keep libexpat from interpreting the Latin Extended characters (like the French accents) as part of a multi-byte UTF-8 sequence. That's what the problem was; it interpreted the '<' character following the accent as the second byte of the same character. 2) Change your code that uses libexpat to convert the data from UTF-8 back into ISO-8859-1. Why do this? It seems to be the case that libexpat is normalizing the input to UTF- 8, regardless of what the original character encoding was. The Perl regex I used to do this transformation: $s =~ s/([\xC0-\xDF])([\x80-\xBF])/chr(ord($1)<<6&0xC0|ord ($2)&0x3F)/eg; If you can't read Perl, you can look at the latin1TOutf8.c program, attached below, and do the inverse of what the C code there does. It's quite trivial. So, this worked for me. A final point I'd like to make is that part of the issue here is documentation and expectation management. It's probably a good thing that libexpat converted the input into UTF-8. The only reason why this didn't work out very well for me was that my code is part of a much larger system, and the other components I interact with deal exclusively with ISO-8859-1. Thus, the path of least resistance was to do the conversion. ---------------------------------------------------------------------- Comment By: Vincent Fortier (fortierv) Date: 2002-02-07 13:37 Message: Logged In: YES user_id=451869 I've found a way to solve my problem.. The problem was actually with the iso- 8859-1 format making errors with "é" at really specefic places.. I've found a converter in C wich transform a text file to utf-8 and the my problems where over.. (see attachement) Here is the web site where I got it: http://developer.iplanet.com/tech/directory/utf8ltn1.html ---------------------------------------------------------------------- Comment By: Vincent Fortier (fortierv) Date: 2002-02-07 10:40 Message: Logged In: YES user_id=451869 Note: BTW.. xmlwf works fine on the file.. so it's supposed to be well- formed in iso-8859-1 format ... and the value of "é" is E9 and 351 (used octal dump..).. thnx. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=514281&group_id=10127 From noreply@sourceforge.net Mon Apr 15 21:26:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon Apr 15 20:26:03 2002 Subject: [ expat-Patches-488187 ] wfcheckmessage.c is unused Message-ID: Patches item #488187, was opened at 2001-12-02 17:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=488187&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Scott Bronson (bronson) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: wfcheckmessage.c is unused Initial Comment: It appears xmlwf/wfcheckmessage.c is antiqutated. You can remove it without trouble. Of course, you must also update the MANIFEST: diff -u -r1.8 MANIFEST --- MANIFEST 2001/08/23 13:12:17 1.8 +++ MANIFEST 2001/12/02 22:25:38 @@ -45,7 +45,6 @@ xmlwf/unixfilemap.c xmlwf/wfcheck.c xmlwf/wfcheck.h -xmlwf/wfcheckmessage.c xmlwf/win32filemap.c xmlwf/xmlfile.c xmlwf/xmlfile.h ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-15 23:25 Message: Logged In: YES user_id=3066 Removed. Also removed xmlwf/wfcheck.[ch], as they were also unused. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=488187&group_id=10127 From noreply@sourceforge.net Mon Apr 15 21:41:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon Apr 15 20:41:03 2002 Subject: [ expat-Bugs-481609 ] Wrong umlauts after parsing Message-ID: Bugs item #481609, was opened at 2001-11-14 03:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=481609&group_id=10127 Category: XML::Parser (Perl module) >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Thomas Frings (frings) Assigned to: Clark Cooper (coopercc) Summary: Wrong umlauts after parsing Initial Comment: Parsing a xml-file that contains german umlauts like ä ö ü or their encoding like ä ä or ü results in 'C$' (instead of 'ä'), 'C<' (instead of 'ü') or 'C6' (instead of 'ö'). What's going wrong? System: Solaris 2.8 expat 1.95.2 XML-Parser 2.30 ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-15 23:39 Message: Logged In: YES user_id=3066 The output shown is not UTF-8, but UTF-8 with the high bit stripped. I expect this was an artifact of the display font or the terminal. Expat should produce UTF-8 in all cases; that's part of the intended interface. ---------------------------------------------------------------------- Comment By: Simon Gordon (si_gordon) Date: 2001-11-14 19:03 Message: Logged In: YES user_id=227124 I believe this is UTF-8. Expat always outputs in UTF-8 rather than either (a) what you want or (b) what the XML encoding is set to. I have long-held the belief that this is a bug even though the relese notes for 1.95 documented this fact. I had to patch my version to output ISO-8859-1 for exactly the same reason - I needed umlauted characters in ISO, not UTF-8. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=481609&group_id=10127 From noreply@sourceforge.net Mon Apr 15 21:44:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon Apr 15 20:44:02 2002 Subject: [ expat-Bugs-465670 ] Having problem to install XML::Parser 2. Message-ID: Bugs item #465670, was opened at 2001-09-27 10:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=465670&group_id=10127 Category: XML::Parser (Perl module) >Group: Third-party Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Clark Cooper (coopercc) Summary: Having problem to install XML::Parser 2. Initial Comment: I have a problem installing XML::Parser 2.30 on Windows 98, Perl v5.6.1 built for MSWin32-x86-multi- thread. I Installed the Expat XML Parser ver. 1.95.2 (expat_win32bin_1_95_2.exe from http://sourceforge.net/projects/expat/) But i get the error : #Expat must be installed prior to building XML::Parser and I can't find #it in the standard library directories. You can download expat from: #http://sourceforge.net/projects/expat/ #If expat is installed, but in a non-standard directory, then use the #following options to Makefile.PL: # EXPATLIBPATH=... To set the directory in which to find libexpat # EXPATINCPATH=... To set the directory in which to find expat.h #For example: # perl Makefile.PL EXPATLIBPATH=/home/me/lib EXPATINCPATH=/home/me/include # #Note that if you build against a shareable library in a non-standard location #you may (on some platforms) also have to set your LD_LIBRARY_PATH environment #variable at run time for perl to find the library. Well expat.h is installed. However there is no file libexpat after the installation of Expat. Thanx in advance, Demetris. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-15 23:42 Message: Logged In: YES user_id=3066 This is an XML::Parser specific build issue, not an Expat issue. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=465670&group_id=10127 From noreply@sourceforge.net Mon Apr 15 21:49:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon Apr 15 20:49:02 2002 Subject: [ expat-Bugs-432762 ] illegal parameter entity reference Message-ID: Bugs item #432762, was opened at 2001-06-13 09:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=432762&group_id=10127 Category: XML::Parser (Perl module) >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Martin Harm (mharm) Assigned to: Clark Cooper (coopercc) Summary: illegal parameter entity reference Initial Comment: Hi folks, this is the error msg from the example prog outline when feeded with the following xml-file: ]> Oha -> Parse error at line 4: illegal parameter entity reference Why ?? (I'm using expat.1.95.1 on Linux) ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-15 23:47 Message: Logged In: YES user_id=3066 The previous comment is right. XML is much stricter about PEs than SGML. Closing this report. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-06-15 13:23 Message: Logged In: NO expat is right. Your example document isn't wellformed XML. See xml recommendation 2.8: Well-Formedness Constraint: PEs in Internal Subset ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=432762&group_id=10127 From noreply@sourceforge.net Mon Apr 15 22:16:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon Apr 15 21:16:05 2002 Subject: [ expat-Bugs-417459 ] illegal instruction fault Message-ID: Bugs item #417459, was opened at 2001-04-19 17:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=417459&group_id=10127 Category: XML::Parser (Perl module) >Group: Third-party Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Clark Cooper (coopercc) Summary: illegal instruction fault Initial Comment: On Solaris 5.6 under apache 1.3.19, using mod_perl or cgi-bin we get a crash of the code saying: [Thu Apr 19 17:13:01 2001] [notice] child pid 16647 exit signal Illegal Instruction (4) The parser does run properly from a command line. The xml we are parsing is: ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-16 00:15 Message: Logged In: YES user_id=3066 This appears to be related to the way Expat was bundled into Apache. This was fixed in Apache 1.3.21. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=417459&group_id=10127 From noreply@sourceforge.net Mon Apr 15 22:19:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon Apr 15 21:19:02 2002 Subject: [ expat-Bugs-539242 ] make problems on Compaq Alpha Message-ID: Bugs item #539242, was opened at 2002-04-04 09:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=539242&group_id=10127 Category: Build control Group: Platform Specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: make problems on Compaq Alpha Initial Comment: - make in top directory considered the subdirs up to date even after a make clean; had to cd to each subdir and run make by hand - in xmlwf/Makefile, had to manually change -static to -non_shared; it doesn't use the libtools from the top level, apparently - in examples/Makefile, had to manually change -static to -non_shared; it doesn't use the libtools from the top level, apparently; also had to add a -I option to the compile options so that expat.h could be found, e.g. LIBS = -L$(LIBDIR) -lexpat -I$(INCDIR) ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-16 00:18 Message: Logged In: YES user_id=3066 These have been changed since 1.95.2 was released; we think these are all fixed in CVS. Please test the next release when available. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=539242&group_id=10127 From noreply@sourceforge.net Mon Apr 15 22:20:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon Apr 15 21:20:02 2002 Subject: [ expat-Bugs-494749 ] Missing .DSP file for MSVC users! Message-ID: Bugs item #494749, was opened at 2001-12-18 15:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=494749&group_id=10127 Category: Build control Group: Platform Specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Missing .DSP file for MSVC users! Initial Comment: The documentation states that to build the software for Windows under MSVC, to just open the "expat.dsp" file in the lib/ directory. However, in the version I downloaded, 1.95.2, this file does not exist. Thanks. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-16 00:19 Message: Logged In: YES user_id=3066 Fixed in the source repository. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=494749&group_id=10127 From Vishal_garg@infy.com Tue Apr 16 04:41:09 2002 From: Vishal_garg@infy.com (Vishal_garg) Date: Tue Apr 16 03:41:09 2002 Subject: installation problem Message-ID: <2B721C6525F0D411B1E900B0D0226BDDF07E6F@mohmsg01.ad.infosys.com> Hi, I am trying to install expat-1.95.2 on SunOS 5.8.I am using native = solaris native compiler for installation. The ./configure command runs successfully.But nothing happens for "make" = command. Please help me in resolving this issue. Regards, Vishal. From noreply@sourceforge.net Tue Apr 16 08:31:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Apr 16 07:31:54 2002 Subject: [ expat-Bugs-544679 ] PEs in external subset error Message-ID: Bugs item #544679, was opened at 2002-04-16 10:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=544679&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) Summary: PEs in external subset error Initial Comment: I ran Expat 1.95.2 against James Clark's test cases version 1998-11-18. There are two files in the directory .../valid/not-sa, which are supposed to be valid, but Expat returns an "illegal parameter entity reference" error. Here is how it looks for the first file: File 004.xml: File 004-1.ent: --> Expat reports error here %e1; File 0004-2.ent: And the second file: File 003.xml: File 003-1.ent: --> Expat error here File 003-2.ent: empty file Expat's behaviour seems to *not* conform to this XML 1.0 rule: Well-formedness constraint: PEs in Internal Subset In the internal DTD subset, parameter-entity references can occur only where markup declarations can occur, not within markup declarations. (This does not apply to references that occur in external parameter entities or to the external subset.) That is, Expat reports an error for external parameter entities too. This might be because a child parser in Expat does not know that it is a child parser - and therefore that it is processing an external entity. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=544679&group_id=10127 From noreply@sourceforge.net Tue Apr 16 08:35:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Apr 16 07:35:48 2002 Subject: [ expat-Bugs-544682 ] Support Pull operation Message-ID: Bugs item #544682, was opened at 2002-04-16 10:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=544682&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) Summary: Support Pull operation Initial Comment: Would it be hard to add the following functions? - suspend() ...suspends parsing, remembers state - resume() ...resumes parsing from where it was suspended - abort() ...cancels parsing This looks like the concept of coroutines, and could have the following benefit: One could implement a "pull" based parser on top of the "push" based model of Expat. This has recently been chosen as Microsoft's new approach, i.e. in XML.NET, SAX has been replaced by a pull based parser("XMLReader"). Typical pull code would look like: while parser.nextNode() do begin //process current node end; It seems to me such a parser could be implemented on top of SAX or Expat, if there was functionality as described above. Microsoft's MSXML3 implementation has the IMXReaderControl interface, which allows exactly that. Makes me think that (maybe) MS's "pull" implementation is implemented on top of their own SAX parser. So, my question again: How hard would it be to add such coroutine-like functionality to Expat? Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=544682&group_id=10127 From noreply@sourceforge.net Thu Apr 18 21:33:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Apr 18 20:33:02 2002 Subject: [ expat-Patches-476931 ] Fix XML_UNICODE Support Message-ID: Patches item #476931, was opened at 2001-10-31 16:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=476931&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Fix XML_UNICODE Support Initial Comment: The attached file fixes problems when compiling with XML_UNICODE defined, which was not completely implemented. See bug #464837. Apply this diff file to Expat.h in version 1.95.2 of Expat. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-04-18 23:32 Message: Logged In: YES user_id=290026 I suggest that the following change is made to the patched expat.h file: Near the top of the file, the patch added these 12 lines: #ifdef XML_UNICODE /* Information is UTF-16 encoded. */ # ifdef XML_UNICODE_WCHAR_T typedef wchar_t XML_Char; typedef wchar_t XML_LChar; # else typedef unsigned short XML_Char; typedef unsigned short XML_LChar; # endif #else /* Information is UTF-8 encoded. */ typedef char XML_Char; typedef char XML_LChar; #endif But I think it is better to have them like this (I saw this in an earlier version of Expat, from which it must have disappeared at one point): #ifdef XML_UNICODE /* Information is UTF-16 encoded. */ # ifdef XML_UNICODE_WCHAR_T typedef wchar_t XML_Char; typedef wchar_t XML_LChar; # else typedef unsigned short XML_Char; typedef char XML_LChar; # endif #else /* Information is UTF-8 encoded. */ typedef char XML_Char; typedef char XML_LChar; #endif Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2001-10-31 16:09 Message: Logged In: YES user_id=290026 To complete the fix, a patch for xmlparse.c has to be added too. Same version requirements as before. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=476931&group_id=10127 From noreply@sourceforge.net Fri Apr 19 09:00:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Apr 19 08:00:06 2002 Subject: [ expat-Bugs-493466 ] install of 1.95.2 failes : FreeBSD 4.4-R Message-ID: Bugs item #493466, was opened at 2001-12-14 16:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=493466&group_id=10127 >Category: Build control Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: install of 1.95.2 failes : FreeBSD 4.4-R Initial Comment: While tring to make && make install on FreeBSD 4.4-R (i386) I got the following error /bin/csh ../conftools/mkinstalldirs /usr/local/expat/bin errstatus=0: Command not found. for: Command not found. do: Command not found. set: Variable name must begin with a letter. *** Error code 1 Stop in /usr/local/src/expat-1.95.2/xmlwf. *** Error code 1 Stop in /usr/local/src/expat-1.95.2 but when I try to install 1.95.1 it installs fine. So I assume it's a bug in 1.95.2 ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-19 10:59 Message: Logged In: YES user_id=3066 This has already been fixed in CVS (or at least I wasn't able to duplicate it when starting csh as my shell, which is probably how this occured to begin with). If this persists for you (with the next release or a CVS checkout), please request that this be re-opened, or submit a new bug report. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-12-27 16:39 Message: Logged In: NO I got a same error! But after I used gmake and it is done! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=493466&group_id=10127 From noreply@sourceforge.net Fri Apr 19 09:06:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Apr 19 08:06:23 2002 Subject: [ expat-Bugs-470041 ] expat doesn't parse xml's with UTF-8 BOM Message-ID: Bugs item #470041, was opened at 2001-10-10 18:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=470041&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: expat doesn't parse xml's with UTF-8 BOM Initial Comment: expat can not correctly parse xml's encoded in UTF-8 and with UTF-8 BOM (EF BB BF). ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-19 11:05 Message: Logged In: YES user_id=3066 Due to the lack of submitter response and the fact that there's a regression test for this (meaning it works now!), this is getting closed as out-of-date. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-02-01 17:31 Message: Logged In: NO Isn't this fixed by libexpat 1.95.2 ? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-02 18:05 Message: Logged In: YES user_id=3066 What version of Expat was this? I thought we'd fixed this in Expat 1.95.2. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=470041&group_id=10127 From noreply@sourceforge.net Fri Apr 19 12:41:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Apr 19 11:41:06 2002 Subject: [ expat-Bugs-514281 ] french accents errors? Message-ID: Bugs item #514281, was opened at 2002-02-07 09:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=514281&group_id=10127 Category: None Group: Not a Bug >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Vincent Fortier (fortierv) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: french accents errors? Initial Comment: I'm having errors with french accents in iso-8859-1 and utf-8 format only at a specific place.. Exemple: Ville Charlesbourg Martin Labbé (xxx)xxx It always stops at Martin Labbé .. If I either change "é" for an "e" it works.. if I simply add 2 chars after the "é" like: Martin LabbéXX it still works... But it always stops when it finishes with "é" or "éX".... I've tried a few patches.. one for expat.h and xmlparse.c wich was unicode changes (#476931, #464837).. and another one wich was about xmltok.c (#477667)... but with no success.. I always get the error message "mismatched tag at line xx"... I have a lot of "éèàçêÈ" everywhere.. but it seems to only stop when it's placed right at the end of a tag.. Anybody can help me out? - vin ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-19 14:40 Message: Logged In: YES user_id=3066 OK, I had a bad assumption in my test setup; fixing that caused the tests to pass. (The basic_setup() function in runtests.c always configured the parser to use US-ASCII instead of determining the encoding from the XML source data; it now determines the encoding from the data.) You example instance does not include an XML declaration stating that it is Latin-1 encoded, so Expat will assume that it is UTF-8. Not sure where the "mismatched tag" message comes from. I can no longer reproduce this. I've added test cases to the test suite to avoid this showing up in the future (tests/runtests.c revision 1.7). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-15 23:06 Message: Logged In: YES user_id=3066 Confirmed, mostly. With the current CVS, I can't seem to get things to work by adding "XX" before the tag. I'm also seeing a different error: "not well-formed (invalid token)". I've attached a patch that adds tests to the test suite. ---------------------------------------------------------------------- Comment By: John Dawson (jdawson) Date: 2002-03-26 16:54 Message: Logged In: YES user_id=30450 I have encountered a similar problem where I work, doing German. My code was in Perl, and used XML::Parser and XML::Parser::Expat, but I believe that Perl is not relevant to this issue. I was using libexpat 1.95.1. I got things to work by doing the following: 1) Giving the input XML document an encoding type of iso- 8859-1. This will keep libexpat from interpreting the Latin Extended characters (like the French accents) as part of a multi-byte UTF-8 sequence. That's what the problem was; it interpreted the '<' character following the accent as the second byte of the same character. 2) Change your code that uses libexpat to convert the data from UTF-8 back into ISO-8859-1. Why do this? It seems to be the case that libexpat is normalizing the input to UTF- 8, regardless of what the original character encoding was. The Perl regex I used to do this transformation: $s =~ s/([\xC0-\xDF])([\x80-\xBF])/chr(ord($1)<<6&0xC0|ord ($2)&0x3F)/eg; If you can't read Perl, you can look at the latin1TOutf8.c program, attached below, and do the inverse of what the C code there does. It's quite trivial. So, this worked for me. A final point I'd like to make is that part of the issue here is documentation and expectation management. It's probably a good thing that libexpat converted the input into UTF-8. The only reason why this didn't work out very well for me was that my code is part of a much larger system, and the other components I interact with deal exclusively with ISO-8859-1. Thus, the path of least resistance was to do the conversion. ---------------------------------------------------------------------- Comment By: Vincent Fortier (fortierv) Date: 2002-02-07 13:37 Message: Logged In: YES user_id=451869 I've found a way to solve my problem.. The problem was actually with the iso- 8859-1 format making errors with "é" at really specefic places.. I've found a converter in C wich transform a text file to utf-8 and the my problems where over.. (see attachement) Here is the web site where I got it: http://developer.iplanet.com/tech/directory/utf8ltn1.html ---------------------------------------------------------------------- Comment By: Vincent Fortier (fortierv) Date: 2002-02-07 10:40 Message: Logged In: YES user_id=451869 Note: BTW.. xmlwf works fine on the file.. so it's supposed to be well- formed in iso-8859-1 format ... and the value of "é" is E9 and 351 (used octal dump..).. thnx. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=514281&group_id=10127 From noreply@sourceforge.net Fri Apr 19 12:47:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Apr 19 11:47:16 2002 Subject: [ expat-Bugs-491986 ] Charset decoding error Message-ID: Bugs item #491986, was opened at 2001-12-12 07:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=491986&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Bent Jensen (bentjensen) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Charset decoding error 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-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: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=491986&group_id=10127 From noreply@sourceforge.net Fri Apr 19 13:22:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Apr 19 12:22:52 2002 Subject: [ expat-Bugs-491986 ] Charset decoding error Message-ID: Bugs item #491986, was opened at 2001-12-12 13:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=491986&group_id=10127 Category: None Group: None Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Bent Jensen (bentjensen) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Charset decoding error 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: Bent Jensen (bentjensen) Date: 2002-04-19 21: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 20: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 13: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: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=491986&group_id=10127 From noreply@sourceforge.net Fri Apr 19 13:28:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Apr 19 12:28:18 2002 Subject: [ expat-Bugs-477667 ] illegal utf-8 seqs do not throw error Message-ID: Bugs item #477667, was opened at 2001-11-02 17:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=477667&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Patrick McCormick (patrickmc) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: illegal utf-8 seqs do not throw error Initial Comment: I have a problem where users like to use iso-8859-1 without declaring it in the prolog, like this: abécdef expat properly defaults to utf-8 in this case. As I understand utf-8, the é character (0xE7) has a bitfield that looks like the start of a three byte sequence. A 3-byte sequence is supposed to look like this: bytes | bits | representation 3 | 16 | 1110vvvv 10vvvvvv 10vvvvvv the above two bytes (c and d) don't match the 10vvvvvv mask, so écd is an illegal utf-8 sequence. But expat doesn't throw a well-formedness error. Expat uses this macro in xmltok.c to figure out what's illegal: #define UTF8_INVALID3(p) \ ((*p) == 0xED \ ? (((p)[1] & 0x20) != 0) \ : ((*p) == 0xEF \ ? ((p)[1] == 0xBF && ((p)[2] == 0xBF || (p)[2] == 0xBE)) \ : 0)) but this doesn't seem strict enough. I wrote a patch that makes expat check UTF-8 sequences against the Table 3.1B of the Unicode 3.1 standard: http://www.unicode.org/unicode/reports/tr27/ as originally clarified in this Corrigendum: http://www.unicode.org/unicode/uni2errata/UTF- 8_Corrigendum.html and it's attached. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-19 15:19 Message: Logged In: YES user_id=3066 Added a test (tests/runtests.c revision 1.9) that shows this bug does not exist in the CVS version. You did not state which version of Expat you're using. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=477667&group_id=10127 From noreply@sourceforge.net Fri Apr 19 13:47:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Apr 19 12:47:18 2002 Subject: [ 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: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=491986&group_id=10127 Category: None Group: None >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-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: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=491986&group_id=10127 From noreply@sourceforge.net Fri Apr 19 15:00:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Apr 19 14:00:07 2002 Subject: [ expat-Bugs-231864 ] XML_SetReturnNSTriplet doesn't work as documented Message-ID: Bugs item #231864, was opened at 2001-02-10 16:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=231864&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ernst Jan Plugge (rmc) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: XML_SetReturnNSTriplet doesn't work as documented Initial Comment: test.xml: When processed with a namespace-enabled parser, after setting the ReturnNSTriplet flag, the foo:bar attribute name is correctly expanded to a triplet, but the foo:doc element type name is not. A trivial event-reporting app says: Namespace declaration start: foo='urn:bar' Element start: 'urn:bar!doc' Attribute: urn:bar!bar!foo='baz' Element end: 'urn:bar!doc' Namespace declaration end: foo A look at the source seems to indicate that the code to do the expansion doesn't exist. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-19 16:59 Message: Logged In: YES user_id=3066 Finally(!) fixed in lib/xmlparse.c revision 1.26 using a modified version of patch #476929. Added tests in tests/runtests.c revision 1.10. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-04-05 15:18 Message: Logged In: YES user_id=3066 --sigh-- I actually expect to look at this in 1-2 weeks. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-02-14 13:18 Message: Assigned to me since I was planning to use this feature in the near-ish future. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=231864&group_id=10127 From noreply@sourceforge.net Fri Apr 19 15:02:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Apr 19 14:02:06 2002 Subject: [ expat-Patches-460042 ] fix XML_SetReturnNSTriplet Message-ID: Patches item #460042, was opened at 2001-09-09 13:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=460042&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: TAKAHASHI Masayoshi (maki) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: fix XML_SetReturnNSTriplet Initial Comment: This is a patch for lib/xmlparser.c, to fix XML_SetReturnNSTriplet. It may be solved "[#231864] XML_SetReturnNSTriplet doesn't work as documented". This patch is written by yoshidam. He writes Ruby's expat library 'XMLParser'. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-19 17:01 Message: Logged In: YES user_id=3066 The bug this addresses is now closed. An alternate version of this patch was used; see SF patch #476929. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2001-09-25 13:09 Message: Logged In: YES user_id=290026 I have applied the patch, and it seem to work with the compile options as installed (release 1.95.2 for Win32). However, if I recompile with XML_UNICODE and XML_UNICODE_WCHAR_T defined, the last (third) element was not returned in my test example: ... ... with the namespace separator '^', the patched code returns the element name 'x-schema:digSchema.xml^camera', instead of 'x-schema:digSchema.xml^camera^dig:camera'. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=460042&group_id=10127 From noreply@sourceforge.net Fri Apr 19 15:06:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Apr 19 14:06:03 2002 Subject: [ expat-Patches-476929 ] Fix XML_SetReturnNSTriplet Message-ID: Patches item #476929, was opened at 2001-10-31 16:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=476929&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Fix XML_SetReturnNSTriplet Initial Comment: This is a modification to the other fix (#460042) supplied by "maki". The attached diff file should be applied against xmlparse.c in version 1.95.2 of Expat, not against the other fix. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-19 17:05 Message: Logged In: YES user_id=3066 Checked in a modified version of this patch in lib/xmlparse.c revision 1.26. Closed bug #231864 and rejected the other patch (#460042). Added a test case in tests/runtests.c revision 1.10. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=476929&group_id=10127 From noreply@sourceforge.net Fri Apr 19 15:43:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Apr 19 14:43:05 2002 Subject: [ expat-Patches-488196 ] Make xmlwf support reading from stdin Message-ID: Patches item #488196, was opened at 2001-12-02 17:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=488196&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Scott Bronson (bronson) Assigned to: Nobody/Anonymous (nobody) Summary: Make xmlwf support reading from stdin Initial Comment: With this patch, xmlwf works exactly as it used to except that, if you don't specify any files on the command line, xmlwf takes its input from stdin. If you use -d to output to a directory, the output file will be named "STDIN". ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-19 17:42 Message: Logged In: YES user_id=3066 Checked in as part of xmlwf/xmlfile.c revision 1.9 and xmlwf/xmlwf.c revision 1.58. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=488196&group_id=10127 From noreply@sourceforge.net Fri Apr 19 15:44:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Apr 19 14:44:04 2002 Subject: [ expat-Patches-488196 ] Make xmlwf support reading from stdin Message-ID: Patches item #488196, was opened at 2001-12-02 17:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=488196&group_id=10127 Category: None >Group: Feature Request Status: Closed Resolution: Accepted Priority: 5 Submitted By: Scott Bronson (bronson) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Make xmlwf support reading from stdin Initial Comment: With this patch, xmlwf works exactly as it used to except that, if you don't specify any files on the command line, xmlwf takes its input from stdin. If you use -d to output to a directory, the output file will be named "STDIN". ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-19 17:43 Message: Logged In: YES user_id=3066 Oops, forgot to update the "assigned-to" field to reflect who acted on this. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-19 17:42 Message: Logged In: YES user_id=3066 Checked in as part of xmlwf/xmlfile.c revision 1.9 and xmlwf/xmlwf.c revision 1.58. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=488196&group_id=10127 From noreply@sourceforge.net Fri Apr 19 15:52:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Apr 19 14:52:02 2002 Subject: [ expat-Bugs-487387 ] Link Error while in Expat. Message-ID: Bugs item #487387, was opened at 2001-11-30 00:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=487387&group_id=10127 >Category: Build control Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Link Error while in Expat. Initial Comment: I am trying to install XML::Parser which uses Expat. I installes expat using expat_win32bin_1_95_2.exe. When I try to build XML::Parser, I get a few errors(Error message given Below). I am using Microsoft VC++ Version 6.0 to compile. Perl was built from Source(Version 5.6.1) and is not activestate perl. What could be wrong?? Error Message: Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. cl -c -nologo -O1 -MD -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -DPERL_MSVCRT_READFIX -O1 -MD -DNDEBUG -DVERSION=\2.30\ -DXS_VERSION=\2.30\ -ID:\perl\5.6.1\lib\MSWin32-x86\ Expat.c "Running Mkbootstrap for XML::Parser::Expat ()" D:\perl\5.6.1\bin\MSWin32-x86\perl.exe -Id:\perl\5.6.1\lib\MSWin32-x86 -Id:\perl\5.6.1\lib -MExtUtils::Command -e chmod 644 Expat.bs link -out:..\blib\arch\auto\XML\Parser\Expat\Expat.dll -dll -nologo -nodefaultlib -release -libpath:"d:\perl\5.6.1\lib\MSWin32-x86\CORE" -machine:x86 Expat.obj D:\perl\5.6.1\li ~1\MICROS~3\VC98\lib\advapi32.lib C:\PROGRA~1\MICROS~3\VC98\lib\shell32.lib C:\PROGRA~1\MICROS~3\VC98\lib\ole32.lib C:\PROGRA~1\MICROS~3\VC98\lib\oleaut32.lib C:\PROGRA~1\MICROS~3\VC98\lib 32.lib C:\PROGRA~1\MICROS~3\VC98\lib\msvcrt.lib -def:Expat.def Creating library ..\blib\arch\auto\XML\Parser\Expat\Expat.lib and object ..\blib\arch\auto\XML\Parser\Expat\Expat.exp Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetParamEntityParsing Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetUnknownEncodingHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetElementHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetUserData Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetNamespaceDeclHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_ParserCreate_MM Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetExternalEntityRefHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetNotationDeclHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetUnparsedEntityDeclHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetCdataSectionHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetCommentHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetProcessingInstructionHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetCharacterDataHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_ParserFree Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetBase Expat.obj : error LNK2001: unresolved external symbol __imp__XML_GetBase Expat.obj : error LNK2001: unresolved external symbol __imp__XML_ExternalEntityParserCreate Expat.obj : error LNK2001: unresolved external symbol __imp__XML_GetCurrentLineNumber Expat.obj : error LNK2001: unresolved external symbol __imp__XML_GetCurrentColumnNumber Expat.obj : error LNK2001: unresolved external symbol __imp__XML_GetCurrentByteIndex Expat.obj : error LNK2001: unresolved external symbol __imp__XML_ErrorString Expat.obj : error LNK2001: unresolved external symbol __imp__XML_GetErrorCode Expat.obj : error LNK2001: unresolved external symbol __imp__XML_Parse Expat.obj : error LNK2001: unresolved external symbol __imp__XML_ParseBuffer Expat.obj : error LNK2001: unresolved external symbol __imp__XML_GetBuffer ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-19 17:51 Message: Logged In: YES user_id=3066 This appears to be a duplicate of bug #432456. See the comments in that report for more explanation. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=487387&group_id=10127 From noreply@sourceforge.net Fri Apr 19 15:56:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Apr 19 14:56:14 2002 Subject: [ expat-Bugs-531936 ] not supported windows-1251 character set Message-ID: Bugs item #531936, was opened at 2002-03-19 11:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=531936&group_id=10127 Category: XML::Parser (Perl module) Group: Feature Request >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Clark Cooper (coopercc) Summary: not supported windows-1251 character set Initial Comment: Hello. I have found a problem with parse XML documents, that contains cyrilic symbols in attribute value something like raises exceprion "not well-formed ....." i test all cyrilic characters and found that exception raises when character code more than 0xF0 but i can be at fault i try use .enc file, but it's not work in my case I think that it is a bug. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-19 17:55 Message: Logged In: YES user_id=3066 This is not a bug. Your sample XML does not include an XML declaration, so it will be treated as UTF-8. If you need it to be treated differently, include an XML declaration with the proper encoding pseudo-attribute. Expat support UTF-8, UTF-16, ISO-8859-1, and US-ASCII encodings natively; you can extend the set of supported encodings using the XML_SetUnknownEncodingHandler() function. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=531936&group_id=10127 From noreply@sourceforge.net Fri Apr 19 16:01:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Apr 19 15:01:19 2002 Subject: [ expat-Bugs-477039 ] Compile Error on HP-UX 10_20 Message-ID: Bugs item #477039, was opened at 2001-10-31 20:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=477039&group_id=10127 >Category: Build control Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Compile Error on HP-UX 10_20 Initial Comment: Not sure if this is a bug or just my lack of understanding. Does anyone have any idea why this refuses to compile ? $ ./configure --prefix=/opt/psfm/batch/scripts/expat loading cache ./config.cache checking host system type... hppa2.0-hp-hpux10.20 checking build system type... hppa2.0-hp-hpux10.20 checking for ranlib... (cached) ranlib checking for gcc... (cached) cc checking whether the C compiler (cc ) works... yes checking whether the C compiler (cc ) is a cross- compiler... no checking whether we are using GNU C... (cached) no checking whether cc accepts -g... (cached) yes checking for non-GNU ld... (cached) /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... (cached) no checking for BSD-compatible nm... (cached) /usr/bin/nm -p checking whether ln -s works... (cached) yes checking whether we are using GNU C... no checking for object suffix... o checking for executable suffix... no checking for cc option to produce PIC... +Z checking if cc PIC flag +Z works... yes checking if cc supports -c -o file.o... yes checking if cc supports -c -o file.lo... yes checking if cc static flag -Wl,-a -Wl,archive works... -Wl,-a -Wl,archive checking if the linker (/usr/bin/ld) is GNU ld... no checking whether the linker (/usr/bin/ld) supports shared libraries... yes checking command to parse /usr/bin/nm -p output... ok checking how to hardcode library paths into programs... relink checking for /usr/bin/ld option to reload object files... -r checking dynamic linker characteristics... hpux10.20 dld.sl checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for objdir... .libs creating libtool loading cache ./config.cache checking for gcc... (cached) cc checking whether the C compiler (cc -g ) works... yes checking whether the C compiler (cc -g ) is a cross- compiler... no checking whether we are using GNU C... (cached) no checking whether cc accepts -g... (cached) yes checking for a BSD compatible install... (cached) /opt/imake/bin/install -c checking how to run the C preprocessor... (cached) cc - E checking for ANSI C header files... (cached) yes checking for fcntl.h... (cached) yes checking for unistd.h... (cached) yes checking whether byte ordering is bigendian... (cached) yes checking for working const... (cached) no checking for off_t... (cached) yes checking for size_t... (cached) yes checking for 8-bit clean memcmp... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... (cached) yes checking for working mmap... (cached) no checking for memmove... (cached) yes checking for bcopy... (cached) yes creating ./config.status creating Makefile creating lib/Makefile creating lib/expat.h creating xmlwf/Makefile creating examples/Makefile creating config.h config.h is unchanged $ make $ make install for dir in lib xmlwf; do \ (cd $dir && make install); \ done /bin/sh ../libtool --mode=compile cc - DHAVE_CONFIG_H -DPACKAGE='"expat"' -DVERSION='"expat_1.95.2"' -I. -I. -I.. -g -c xmlparse.c rm -f .libs/xmlparse.lo cc -DHAVE_CONFIG_H -DPACKAGE=\expat\ - DVERSION=\expat_1.95.2\ -I. -I. -I.. - g -c xmlparse.c +Z -DPIC -o .libs/xmlparse.lo cc: "expat.h", line 80: error 1000: Unexpected symbol: "XML_Char". cc: "expat.h", line 81: error 1000: Unexpected symbol: "*". cc: error 2017: Cannot recover from earlier errors, terminating. *** Error exit code 1 Stop. cc -g -I../lib -c xmlwf.c cpp: "xmltchar.h", line 3: warning 2013: Unknown preprocessing directive. cc: "../lib/expat.h", line 80: warning 5: "const" will become a keyword. cc: "../lib/expat.h", line 80: error 1000: Unexpected symbol: "const". cc: "../lib/expat.h", line 81: error 1000: Unexpected symbol: "*". cc: error 2017: Cannot recover from earlier errors, terminating. *** Error exit code 1 Stop. *** Error exit code 1 Stop. $ Regards, Paul __________________________________________________ Technical Designer Peoplesoft Operations IT@AMP Level 3, 151 Clarence St, Sydney 2000 Ph: +61-2-82962621 Email: paul_rashleigh@amp.com.au ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-19 18:00 Message: Logged In: YES user_id=3066 The way the includes are set up has changed in the CVS version of Expat. Please try again using either the CVS version or the upcoming 1.95.3 release. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-02-26 13:18 Message: Logged In: NO Anything been done on this? I'm also getting the same problem on HP-UX 10.20 using the aCC compiler ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-02-06 15:27 Message: Logged In: NO been able to compile it with gmake and gcc on HPUX 10.20 800 serie.. (version 2.9x).. ---------------------------------------------------------------------- Comment By: Weixiong He (weixionghe) Date: 2002-01-15 14:03 Message: Logged In: YES user_id=424747 It seems to me that the xmldef.h is missing from the lib directory. Any ideas? Thanks. Weixiong ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-13 00:49 Message: Logged In: NO The error appears to indicate that a needed include file is not being included properly. XML_Char is a #define. Check the -I (Uppercase i) options. Sometimes a space is allowed other times is not. I have seen this problem with the -L options some loaders also. (space required/not allowed). There may be specific requirements for the "C" compiler that is actually being used. Also, make sure you have a recent version of libtools. ---------------------------------------------------------------------- Comment By: Weixiong He (weixionghe) Date: 2002-01-11 12:14 Message: Logged In: YES user_id=424747 I'm doing the exact same installation as Paul, and I'm getting the exact same error messages as Paul's. Could anyone help us with it? Please!!! Thank you. Weixiong He ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=477039&group_id=10127 From noreply@sourceforge.net Fri Apr 19 20:48:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Apr 19 19:48:05 2002 Subject: [ expat-Bugs-464837 ] Compile with XML_UNICODE not correct Message-ID: Bugs item #464837, was opened at 2001-09-25 11:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=464837&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Compile with XML_UNICODE not correct Initial Comment: I am trying to re-compile Expat 1.95.2 on Windows with XML_UNICODE and XML_UNICODE_WCHAR_T defined. I am using VC++ 6.0. However, when tested, the Dll does not pass UTF16 strings out, they still seem to be UTF8, but improperly terminated. It seems that I can get it to work properly when I modify expat.h to change the typedefs for XML_CHAR and XML_LCHAR from char tp wchar_t, i.e.: typedef char XML_Char; typedef char XML_LChar; turns into typedef wchar_t XML_Char; typedef wchar_t XML_LChar; Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2001-11-04 08:08 Message: Logged In: YES user_id=290026 I found out that this is not enough to fix it. I have submitted a patch - see patch # 476931. This is under Win32, btw. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=464837&group_id=10127 From noreply@sourceforge.net Sat Apr 20 07:21:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat Apr 20 06:21:03 2002 Subject: [ expat-Bugs-480278 ] UTF-16 Unsupport? Message-ID: Bugs item #480278, was opened at 2001-11-09 20:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=480278&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: UTF-16 Unsupport? Initial Comment: Hi! I did re-compile expat 1.95.2 with VC++ 6.0 to support unicode characters. And I wrote XML document encoding schema as UTF-16, but parser might generate following error message: error code : 19 error text : encoding specified in XML declaration is incorrect. What's wrong??? My test xml doc. ------------------------------ This is a test" ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-20 09:20 Message: Logged In: YES user_id=3066 Could not duplicate; is your file actually encoded in UTF-16? Added a test in tests/runtests.c revision 1.12. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2001-11-11 22:59 Message: Logged In: YES user_id=290026 Worked fine for me. I pasted your text from above into Wordpad, saved it as a Unicode Text file, and Expat accepted it without problems. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=480278&group_id=10127 From noreply@sourceforge.net Sat Apr 20 10:59:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat Apr 20 09:59:32 2002 Subject: [ expat-Bugs-546534 ] Fix for Bug #476929 does not work Message-ID: Bugs item #546534, was opened at 2002-04-20 12:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=546534&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for Bug #476929 does not work Initial Comment: The patch modification gives me null pointer errors. The original patch has been modified when the bug was closed. The modified patch looks like this: if (elementType->prefix) { binding = elementType->prefix->binding; if (!binding) return XML_ERROR_NONE; localPart = tagNamePtr->str; while (*localPart++ != XML_T(':')) ; } else if (dtd.defaultPrefix.binding) { binding = dtd.defaultPrefix.binding; localPart = tagNamePtr->str; } else localPart = NULL; if (ns && ns_triplets && binding->prefix->name) { for (prefixLen = 0; binding->prefix->name [prefixLen++];) ; n += prefixLen; } else return XML_ERROR_NONE; tagNamePtr->localPart = localPart; tagNamePtr->uriLen = binding->uriLen; for (i = 0; localPart[i++];) ; n = i + binding->uriLen; if (n > binding->uriAlloc) {... The patch code "if (ns && ns_triplets && binding- >prefix->name) ..." has no effect, since the value assigned to n will be discarded by the later assignment n = i + binding->uriLen; It also seems that it is possible that the loop "for (i = 0; localPart[i++];)" will be executed against a NULLed localpart. This may be the error, but I haven't run it through the debugger yet, since debugging a VC++ DLL that is used by a non-C++ program requires some effort. The original patch looks like this: if (elementType->prefix) { binding = elementType->prefix->binding; if (!binding) return XML_ERROR_NONE; localPart = tagNamePtr->str; while (*localPart++ != XML_T(':')) ; } else if (dtd.defaultPrefix.binding) { binding = dtd.defaultPrefix.binding; localPart = tagNamePtr->str; } else return XML_ERROR_NONE; tagNamePtr->localPart = localPart; tagNamePtr->uriLen = binding->uriLen; for (i = 0; localPart[i++];) ; n = i + binding->uriLen; //kw1 - added the following 5 lines for NS_Triplets handling if (ns && ns_triplets && binding->prefix->name) { for (prefixLen = 0; binding->prefix->name [prefixLen++];) ; n += prefixLen; } if (n > binding->uriAlloc) { ... I think the problem revolves around: Why does the new code continue on where the old code returns - see return XML_ERROR_NONE; ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=546534&group_id=10127 From noreply@sourceforge.net Sat Apr 20 11:11:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat Apr 20 10:11:22 2002 Subject: [ expat-Patches-546540 ] Patch for Bug #546534 Message-ID: Patches item #546540, was opened at 2002-04-20 13:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=546540&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for Bug #546534 Initial Comment: This patch contains another change to the modified patch that was used to close the original bug # 476929. It also has the XML_UNICODE patch #476931 merged in. The modifications have been applied against the following file revisions for expat.h and xmlparse.c: rev. 1.14 for expat.h rev. 1.26 for xmlparse.c I left my comment in the files. Comments regarding the NSTriplet fix are annotated "/kw1", and comments regarding the XML_UNICODE patch are annotated "/kw2". In addition to the existing XML_UNICODE patch #476931 I also patched the version macro to work for XML_UNICODE. I have to add, that this XML_UNICODE patch will not work when XML_UNICODE is defined, but not XML_UNICODE_WCHAR_T, due to the way XML_T works (for the strings constants). To make the attached files usable, one has to do two things: 1) change the Windows style line breaks to Unix (CRLF --> LF) 2) remove all my comments After that, one can run a diff, to see what I changed. Regards, Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=546540&group_id=10127 From noreply@sourceforge.net Sat Apr 20 12:54:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat Apr 20 11:54:03 2002 Subject: [ expat-Bugs-546534 ] Fix for Bug #476929 does not work Message-ID: Bugs item #546534, was opened at 2002-04-20 12:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=546534&group_id=10127 Category: None Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Karl Waclawek (kwaclaw) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Fix for Bug #476929 does not work Initial Comment: The patch modification gives me null pointer errors. The original patch has been modified when the bug was closed. The modified patch looks like this: if (elementType->prefix) { binding = elementType->prefix->binding; if (!binding) return XML_ERROR_NONE; localPart = tagNamePtr->str; while (*localPart++ != XML_T(':')) ; } else if (dtd.defaultPrefix.binding) { binding = dtd.defaultPrefix.binding; localPart = tagNamePtr->str; } else localPart = NULL; if (ns && ns_triplets && binding->prefix->name) { for (prefixLen = 0; binding->prefix->name [prefixLen++];) ; n += prefixLen; } else return XML_ERROR_NONE; tagNamePtr->localPart = localPart; tagNamePtr->uriLen = binding->uriLen; for (i = 0; localPart[i++];) ; n = i + binding->uriLen; if (n > binding->uriAlloc) {... The patch code "if (ns && ns_triplets && binding- >prefix->name) ..." has no effect, since the value assigned to n will be discarded by the later assignment n = i + binding->uriLen; It also seems that it is possible that the loop "for (i = 0; localPart[i++];)" will be executed against a NULLed localpart. This may be the error, but I haven't run it through the debugger yet, since debugging a VC++ DLL that is used by a non-C++ program requires some effort. The original patch looks like this: if (elementType->prefix) { binding = elementType->prefix->binding; if (!binding) return XML_ERROR_NONE; localPart = tagNamePtr->str; while (*localPart++ != XML_T(':')) ; } else if (dtd.defaultPrefix.binding) { binding = dtd.defaultPrefix.binding; localPart = tagNamePtr->str; } else return XML_ERROR_NONE; tagNamePtr->localPart = localPart; tagNamePtr->uriLen = binding->uriLen; for (i = 0; localPart[i++];) ; n = i + binding->uriLen; //kw1 - added the following 5 lines for NS_Triplets handling if (ns && ns_triplets && binding->prefix->name) { for (prefixLen = 0; binding->prefix->name [prefixLen++];) ; n += prefixLen; } if (n > binding->uriAlloc) { ... I think the problem revolves around: Why does the new code continue on where the old code returns - see return XML_ERROR_NONE; ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=546534&group_id=10127 From noreply@sourceforge.net Sun Apr 21 10:35:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun Apr 21 09:35:04 2002 Subject: [ expat-Patches-546795 ] XML_UNICODE: Improvement on patch 476931 Message-ID: Patches item #546795, was opened at 2002-04-21 12:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=546795&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) Summary: XML_UNICODE: Improvement on patch 476931 Initial Comment: The previous patch would not work when XML_UNICODE was defined, but not XML_UNICODE_WCHAR_T. However, since wchar_t in some Unix systems is 4 bytes long, it is desirable to have Expat work when XML_Char is defined as unsigned short, (for 16bit unicode). To achieve this, I had to split up the XML_T macro into two macros, XML_T for XML output, and XML_L for message strings. This makes the behaviour different between these two cases: 1) XML_UNICODE defined, but not XML_UNICODE_WCHAR_T: - XML output treated as unsigned short arrays - message strings treated as char arrays 2) Both defined, XML_UNICODE and XML_UNICODE_WCHAR_T: - XML output treated as wchar_t arrays - message strings treated as wchar_t arrays Two files are affected, expat.h and xmlparse.c. The modifications are based on the following CVS revisions: - expat.h rev. 1.14 - xmlparse.c rev. 1.26 These files also contain the XML_SetReturnNSTriplet fixes from patch #546540. This obviously needs some more testing, preferably with files containing lots of Unicode characters outside the normal range. I have attached two versions of each file, with, or without annotations (which are marked with "//kw"). Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=546795&group_id=10127 From noreply@sourceforge.net Mon Apr 22 05:21:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon Apr 22 04:21:01 2002 Subject: [ expat-Bugs-481609 ] Wrong umlauts after parsing Message-ID: Bugs item #481609, was opened at 2001-11-14 00:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=481609&group_id=10127 Category: XML::Parser (Perl module) Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Thomas Frings (frings) Assigned to: Clark Cooper (coopercc) Summary: Wrong umlauts after parsing Initial Comment: Parsing a xml-file that contains german umlauts like ä ö ü or their encoding like ä ä or ü results in 'C$' (instead of 'ä'), 'C<' (instead of 'ü') or 'C6' (instead of 'ö'). What's going wrong? System: Solaris 2.8 expat 1.95.2 XML-Parser 2.30 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-04-22 04:20 Message: Logged In: NO When you write umlauts in attributes, it goes completely wrong: Schön results in a value alt="Schn" or (in newer versions of Expat) in a Well-Formed error. When you do alt="Schün" you get alt="Schn" , too. The only workaround is doing: alt="Sch&uuml;n" , and that isn't nice at all. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-15 20:39 Message: Logged In: YES user_id=3066 The output shown is not UTF-8, but UTF-8 with the high bit stripped. I expect this was an artifact of the display font or the terminal. Expat should produce UTF-8 in all cases; that's part of the intended interface. ---------------------------------------------------------------------- Comment By: Simon Gordon (si_gordon) Date: 2001-11-14 16:03 Message: Logged In: YES user_id=227124 I believe this is UTF-8. Expat always outputs in UTF-8 rather than either (a) what you want or (b) what the XML encoding is set to. I have long-held the belief that this is a bug even though the relese notes for 1.95 documented this fact. I had to patch my version to output ISO-8859-1 for exactly the same reason - I needed umlauted characters in ISO, not UTF-8. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=481609&group_id=10127 From noreply@sourceforge.net Mon Apr 22 11:13:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon Apr 22 10:13:13 2002 Subject: [ expat-Bugs-481609 ] Wrong umlauts after parsing Message-ID: Bugs item #481609, was opened at 2001-11-14 03:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=481609&group_id=10127 Category: XML::Parser (Perl module) Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Thomas Frings (frings) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Wrong umlauts after parsing Initial Comment: Parsing a xml-file that contains german umlauts like ä ö ü or their encoding like ä ä or ü results in 'C$' (instead of 'ä'), 'C<' (instead of 'ü') or 'C6' (instead of 'ö'). What's going wrong? System: Solaris 2.8 expat 1.95.2 XML-Parser 2.30 ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-22 13:11 Message: Logged In: YES user_id=3066 I still can't reproduce this. I've tried using "ö" literally with the document marked as iso-8859-1 encoded, and encoded as ö and ö, both in an attribute value and character data. Please attach a complete (but short) document that exhibits this problem, and explain your test in detail. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-04-22 07:20 Message: Logged In: NO When you write umlauts in attributes, it goes completely wrong: Schön results in a value alt="Schn" or (in newer versions of Expat) in a Well-Formed error. When you do alt="Schün" you get alt="Schn" , too. The only workaround is doing: alt="Sch&uuml;n" , and that isn't nice at all. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-15 23:39 Message: Logged In: YES user_id=3066 The output shown is not UTF-8, but UTF-8 with the high bit stripped. I expect this was an artifact of the display font or the terminal. Expat should produce UTF-8 in all cases; that's part of the intended interface. ---------------------------------------------------------------------- Comment By: Simon Gordon (si_gordon) Date: 2001-11-14 19:03 Message: Logged In: YES user_id=227124 I believe this is UTF-8. Expat always outputs in UTF-8 rather than either (a) what you want or (b) what the XML encoding is set to. I have long-held the belief that this is a bug even though the relese notes for 1.95 documented this fact. I had to patch my version to output ISO-8859-1 for exactly the same reason - I needed umlauted characters in ISO, not UTF-8. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=481609&group_id=10127 From noreply@sourceforge.net Mon Apr 22 12:53:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon Apr 22 11:53:06 2002 Subject: [ expat-Bugs-481609 ] Wrong umlauts after parsing Message-ID: Bugs item #481609, was opened at 2001-11-14 03:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=481609&group_id=10127 Category: XML::Parser (Perl module) Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Thomas Frings (frings) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Wrong umlauts after parsing Initial Comment: Parsing a xml-file that contains german umlauts like ä ö ü or their encoding like ä ä or ü results in 'C$' (instead of 'ä'), 'C<' (instead of 'ü') or 'C6' (instead of 'ö'). What's going wrong? System: Solaris 2.8 expat 1.95.2 XML-Parser 2.30 ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-22 14:52 Message: Logged In: YES user_id=3066 Added a test case in tests/runtests.c revision 1.14 that demonstrates that Expat does the right thing. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-22 13:11 Message: Logged In: YES user_id=3066 I still can't reproduce this. I've tried using "ö" literally with the document marked as iso-8859-1 encoded, and encoded as ö and ö, both in an attribute value and character data. Please attach a complete (but short) document that exhibits this problem, and explain your test in detail. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-04-22 07:20 Message: Logged In: NO When you write umlauts in attributes, it goes completely wrong: Schön results in a value alt="Schn" or (in newer versions of Expat) in a Well-Formed error. When you do alt="Schün" you get alt="Schn" , too. The only workaround is doing: alt="Sch&uuml;n" , and that isn't nice at all. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-15 23:39 Message: Logged In: YES user_id=3066 The output shown is not UTF-8, but UTF-8 with the high bit stripped. I expect this was an artifact of the display font or the terminal. Expat should produce UTF-8 in all cases; that's part of the intended interface. ---------------------------------------------------------------------- Comment By: Simon Gordon (si_gordon) Date: 2001-11-14 19:03 Message: Logged In: YES user_id=227124 I believe this is UTF-8. Expat always outputs in UTF-8 rather than either (a) what you want or (b) what the XML encoding is set to. I have long-held the belief that this is a bug even though the relese notes for 1.95 documented this fact. I had to patch my version to output ISO-8859-1 for exactly the same reason - I needed umlauted characters in ISO, not UTF-8. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=481609&group_id=10127 From noreply@sourceforge.net Mon Apr 22 19:25:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon Apr 22 18:25:01 2002 Subject: [ expat-Bugs-547350 ] make install of xmlwf failed on FreeBSD Message-ID: Bugs item #547350, was opened at 2002-04-23 05:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=547350&group_id=10127 Category: Build control Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexey Kulentsov (akul) Assigned to: Greg Stein (gstein) Summary: make install of xmlwf failed on FreeBSD Initial Comment: 1.95.2 # make install /bin/csh ../conftools/mkinstalldirs /usr/local/bin errstatus=0: Command not found. for: Command not found. do: Command not found. set: Variable name must begin with a letter. *** Error code 1 Stop in /usr/src/expat-1.95.2/xmlwf. xmlwf part seems to be windows specific part because .c sources are executable. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=547350&group_id=10127 From noreply@sourceforge.net Tue Apr 23 14:57:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Apr 23 13:57:06 2002 Subject: [ expat-Patches-546540 ] Patch for Bug #546534 Message-ID: Patches item #546540, was opened at 2002-04-20 13:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=546540&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for Bug #546534 Initial Comment: This patch contains another change to the modified patch that was used to close the original bug # 476929. It also has the XML_UNICODE patch #476931 merged in. The modifications have been applied against the following file revisions for expat.h and xmlparse.c: rev. 1.14 for expat.h rev. 1.26 for xmlparse.c I left my comment in the files. Comments regarding the NSTriplet fix are annotated "/kw1", and comments regarding the XML_UNICODE patch are annotated "/kw2". In addition to the existing XML_UNICODE patch #476931 I also patched the version macro to work for XML_UNICODE. I have to add, that this XML_UNICODE patch will not work when XML_UNICODE is defined, but not XML_UNICODE_WCHAR_T, due to the way XML_T works (for the strings constants). To make the attached files usable, one has to do two things: 1) change the Windows style line breaks to Unix (CRLF --> LF) 2) remove all my comments After that, one can run a diff, to see what I changed. Regards, Karl ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-04-23 16:56 Message: Logged In: YES user_id=290026 Checked in a modified version of this patch, that should also work for XML_UNICODE defined without XML_UNICODE_WCHAR_T. (expat.h rev. 1.16, xmlparse.c rev. 1.27). Fixes bugs 476929 and 546534 (hopefully). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=546540&group_id=10127 From noreply@sourceforge.net Tue Apr 23 15:05:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Apr 23 14:05:04 2002 Subject: [ expat-Bugs-464837 ] Compile with XML_UNICODE not correct Message-ID: Bugs item #464837, was opened at 2001-09-25 11:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=464837&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Compile with XML_UNICODE not correct Initial Comment: I am trying to re-compile Expat 1.95.2 on Windows with XML_UNICODE and XML_UNICODE_WCHAR_T defined. I am using VC++ 6.0. However, when tested, the Dll does not pass UTF16 strings out, they still seem to be UTF8, but improperly terminated. It seems that I can get it to work properly when I modify expat.h to change the typedefs for XML_CHAR and XML_LCHAR from char tp wchar_t, i.e.: typedef char XML_Char; typedef char XML_LChar; turns into typedef wchar_t XML_Char; typedef wchar_t XML_LChar; Karl ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-04-23 17:04 Message: Logged In: YES user_id=290026 Fixed (hopefully) with expat.h rev. 1.16, xmlparse.c rev. 1.28. The fix is based on patch # 546795. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2001-11-04 08:08 Message: Logged In: YES user_id=290026 I found out that this is not enough to fix it. I have submitted a patch - see patch # 476931. This is under Win32, btw. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=464837&group_id=10127 From noreply@sourceforge.net Tue Apr 23 15:05:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Apr 23 14:05:09 2002 Subject: [ expat-Patches-546795 ] XML_UNICODE: Improvement on patch 476931 Message-ID: Patches item #546795, was opened at 2002-04-21 12:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=546795&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) Summary: XML_UNICODE: Improvement on patch 476931 Initial Comment: The previous patch would not work when XML_UNICODE was defined, but not XML_UNICODE_WCHAR_T. However, since wchar_t in some Unix systems is 4 bytes long, it is desirable to have Expat work when XML_Char is defined as unsigned short, (for 16bit unicode). To achieve this, I had to split up the XML_T macro into two macros, XML_T for XML output, and XML_L for message strings. This makes the behaviour different between these two cases: 1) XML_UNICODE defined, but not XML_UNICODE_WCHAR_T: - XML output treated as unsigned short arrays - message strings treated as char arrays 2) Both defined, XML_UNICODE and XML_UNICODE_WCHAR_T: - XML output treated as wchar_t arrays - message strings treated as wchar_t arrays Two files are affected, expat.h and xmlparse.c. The modifications are based on the following CVS revisions: - expat.h rev. 1.14 - xmlparse.c rev. 1.26 These files also contain the XML_SetReturnNSTriplet fixes from patch #546540. This obviously needs some more testing, preferably with files containing lots of Unicode characters outside the normal range. I have attached two versions of each file, with, or without annotations (which are marked with "//kw"). Karl ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-04-23 17:04 Message: Logged In: YES user_id=290026 Checked in a modified version of this patch, adding null terminators to the attribute type constants. (expat.h rev. 1.16, xmlparse.c rev. 1.28) This should fix bug # 464837. Bug closed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=546795&group_id=10127 From noreply@sourceforge.net Tue Apr 23 15:08:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Apr 23 14:08:02 2002 Subject: [ expat-Bugs-546534 ] Fix for Bug #476929 does not work Message-ID: Bugs item #546534, was opened at 2002-04-20 12:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=546534&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Works For Me Priority: 7 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Fix for Bug #476929 does not work Initial Comment: The patch modification gives me null pointer errors. The original patch has been modified when the bug was closed. The modified patch looks like this: if (elementType->prefix) { binding = elementType->prefix->binding; if (!binding) return XML_ERROR_NONE; localPart = tagNamePtr->str; while (*localPart++ != XML_T(':')) ; } else if (dtd.defaultPrefix.binding) { binding = dtd.defaultPrefix.binding; localPart = tagNamePtr->str; } else localPart = NULL; if (ns && ns_triplets && binding->prefix->name) { for (prefixLen = 0; binding->prefix->name [prefixLen++];) ; n += prefixLen; } else return XML_ERROR_NONE; tagNamePtr->localPart = localPart; tagNamePtr->uriLen = binding->uriLen; for (i = 0; localPart[i++];) ; n = i + binding->uriLen; if (n > binding->uriAlloc) {... The patch code "if (ns && ns_triplets && binding- >prefix->name) ..." has no effect, since the value assigned to n will be discarded by the later assignment n = i + binding->uriLen; It also seems that it is possible that the loop "for (i = 0; localPart[i++];)" will be executed against a NULLed localpart. This may be the error, but I haven't run it through the debugger yet, since debugging a VC++ DLL that is used by a non-C++ program requires some effort. The original patch looks like this: if (elementType->prefix) { binding = elementType->prefix->binding; if (!binding) return XML_ERROR_NONE; localPart = tagNamePtr->str; while (*localPart++ != XML_T(':')) ; } else if (dtd.defaultPrefix.binding) { binding = dtd.defaultPrefix.binding; localPart = tagNamePtr->str; } else return XML_ERROR_NONE; tagNamePtr->localPart = localPart; tagNamePtr->uriLen = binding->uriLen; for (i = 0; localPart[i++];) ; n = i + binding->uriLen; //kw1 - added the following 5 lines for NS_Triplets handling if (ns && ns_triplets && binding->prefix->name) { for (prefixLen = 0; binding->prefix->name [prefixLen++];) ; n += prefixLen; } if (n > binding->uriAlloc) { ... I think the problem revolves around: Why does the new code continue on where the old code returns - see return XML_ERROR_NONE; ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-04-23 17:07 Message: Logged In: YES user_id=290026 Fixed with expat.h rev. 1.16, xmlparse.c rev. 1.28. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=546534&group_id=10127 From noreply@sourceforge.net Tue Apr 23 15:10:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Apr 23 14:10:08 2002 Subject: [ expat-Patches-476931 ] Fix XML_UNICODE Support Message-ID: Patches item #476931, was opened at 2001-10-31 16:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=476931&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Fix XML_UNICODE Support Initial Comment: The attached file fixes problems when compiling with XML_UNICODE defined, which was not completely implemented. See bug #464837. Apply this diff file to Expat.h in version 1.95.2 of Expat. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-04-23 17:09 Message: Logged In: YES user_id=290026 Fixed in expat.h rev. 1.16, xmlparse.c rev. 1.28. Closed bug # 464837. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-04-18 23:32 Message: Logged In: YES user_id=290026 I suggest that the following change is made to the patched expat.h file: Near the top of the file, the patch added these 12 lines: #ifdef XML_UNICODE /* Information is UTF-16 encoded. */ # ifdef XML_UNICODE_WCHAR_T typedef wchar_t XML_Char; typedef wchar_t XML_LChar; # else typedef unsigned short XML_Char; typedef unsigned short XML_LChar; # endif #else /* Information is UTF-8 encoded. */ typedef char XML_Char; typedef char XML_LChar; #endif But I think it is better to have them like this (I saw this in an earlier version of Expat, from which it must have disappeared at one point): #ifdef XML_UNICODE /* Information is UTF-16 encoded. */ # ifdef XML_UNICODE_WCHAR_T typedef wchar_t XML_Char; typedef wchar_t XML_LChar; # else typedef unsigned short XML_Char; typedef char XML_LChar; # endif #else /* Information is UTF-8 encoded. */ typedef char XML_Char; typedef char XML_LChar; #endif Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2001-10-31 16:09 Message: Logged In: YES user_id=290026 To complete the fix, a patch for xmlparse.c has to be added too. Same version requirements as before. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=476931&group_id=10127 From noreply@sourceforge.net Tue Apr 23 21:39:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Apr 23 20:39:04 2002 Subject: [ expat-Patches-450608 ] Proposal for XML_ParserReset function Message-ID: Patches item #450608, was opened at 2001-08-13 17:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=450608&group_id=10127 Category: None Group: Feature Request >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: David Crowley (dcrowley) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Proposal for XML_ParserReset function Initial Comment: This is my first cut at adding a XML_ParserReset function. My idea was to reset the parser to a state that was almost identical to what it is after XML_ParserCreate() except that any allocated memory is preserved. As this patch is currently, I think it misght still has some potential problems with dtdInit () and possibly internalEncoding and setContext(). But for my documents/application it seems to work great. It passes Purify without any memory leaks and when parsing 5000 documents, I only get ~40 memory allocations instead of ~200,000 :) The function declartion needed for expat.h: /* Resets an existing parser to a state comparable to that after XML_ParserCreate but preserves any allocated memory. */ XMLPARSEAPI(void) XML_ParserReset(XML_Parser parser, const XML_Char *encoding); ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-23 23:38 Message: Logged In: YES user_id=3066 Checked in updated version of patch received by email as lib/xmlparse.c revision 1.30, with a prototype added to lib/expat.h revision 1.17. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-16 00:20 Message: Logged In: YES user_id=3066 Well, the number of allocations being so substantially reduced is nice to know. I don't know just when I'll get a chance to look at this, but I promise I will get to it! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=450608&group_id=10127 From noreply@sourceforge.net Tue Apr 23 21:58:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Apr 23 20:58:04 2002 Subject: [ expat-Patches-501295 ] Cygwin patch-file again, upload failed Message-ID: Patches item #501295, was opened at 2002-01-09 08:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=501295&group_id=10127 Category: Build Control Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Haase (siebenschlaefer) Assigned to: Greg Stein (gstein) Summary: Cygwin patch-file again, upload failed Initial Comment: One more try to upload the patchfile. Gerrit ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-23 23:57 Message: Logged In: YES user_id=3066 Comments from the original patch report, so I can close that one and have this all in one place: ---------------------------------------------------- I figured out that there were some issues with my lightweight patch to build expat on Cygwin with a shared library, so I patched it again, now standard Cygwin libs are created (cygexpat-x.dll) and a standard importlib (libexpat.dll.a) and also a static library (libexpat.a), xmlwf.exe will be linked against the dll. Build just as usual: ./configure make make install puts everything in /usr/local/* Have fun, Gerrit ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-01-09 09:41 Message: Logged In: YES user_id=3066 This goes with SF patch #501294. ---------------------------------------------------------------------- Comment By: Gerrit Haase (siebenschlaefer) Date: 2002-01-09 08:51 Message: Logged In: YES user_id=76037 Where is the uploaded file? G. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=501295&group_id=10127 From noreply@sourceforge.net Tue Apr 23 21:59:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Apr 23 20:59:03 2002 Subject: [ expat-Patches-501294 ] CYGWIN, full patch for dll build Message-ID: Patches item #501294, was opened at 2002-01-09 08:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=501294&group_id=10127 Category: Build Control Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: CYGWIN, full patch for dll build Initial Comment: I figured out that there were some issues with my lightweight patch to build expat on Cygwin with a shared library, so I patched it again, now standard Cygwin libs are created (cygexpat-x.dll) and a standard importlib (libexpat.dll.a) and also a static library (libexpat.a), xmlwf.exe will be linked against the dll. Build just as usual: ./configure make make install puts everything in /usr/local/* Have fun, Gerrit ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-23 23:58 Message: Logged In: YES user_id=3066 Moved patch comments to the report that actually has the patch attached. Closing this as a duplicate. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-01-09 09:40 Message: Logged In: YES user_id=3066 See patch in SF patch #501295. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=501294&group_id=10127 From noreply@sourceforge.net Wed Apr 24 06:48:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed Apr 24 05:48:04 2002 Subject: [ expat-Patches-474548 ] Build expat-1.95.2 with .dll on cygwin Message-ID: Patches item #474548, was opened at 2001-10-24 13:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=474548&group_id=10127 Category: Build Control Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Build expat-1.95.2 with .dll on cygwin Initial Comment: Get libtool-1.4.2, build and install it. Apply the patch to expat, thats it, just run ./configure, make, make check, make install as usual. I don't know why, but with the current release of libtool, libexpat-0-1- 0.dll gets installed in the $prefix/lib directory, you need to copy it in some directory that is in your PATH included, additional you may modify $prefix/lib/libexpat.la to point to the right place, where the dll is and delete the one in $prefix/lib then. Looks for me like this: # The name that we can dlopen(3). dlname='../bin/libexpat-0-1-0.dll' Gerrit ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-24 08:47 Message: Logged In: YES user_id=3066 Out of date according to the submitter. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=474548&group_id=10127 From noreply@sourceforge.net Wed Apr 24 06:51:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed Apr 24 05:51:05 2002 Subject: [ expat-Patches-501295 ] Cygwin patch (use dynamic library) Message-ID: Patches item #501295, was opened at 2002-01-09 08:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=501295&group_id=10127 Category: Build Control Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Haase (siebenschlaefer) Assigned to: Greg Stein (gstein) >Summary: Cygwin patch (use dynamic library) Initial Comment: One more try to upload the patchfile. Gerrit ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-23 23:57 Message: Logged In: YES user_id=3066 Comments from the original patch report, so I can close that one and have this all in one place: ---------------------------------------------------- I figured out that there were some issues with my lightweight patch to build expat on Cygwin with a shared library, so I patched it again, now standard Cygwin libs are created (cygexpat-x.dll) and a standard importlib (libexpat.dll.a) and also a static library (libexpat.a), xmlwf.exe will be linked against the dll. Build just as usual: ./configure make make install puts everything in /usr/local/* Have fun, Gerrit ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-01-09 09:41 Message: Logged In: YES user_id=3066 This goes with SF patch #501294. ---------------------------------------------------------------------- Comment By: Gerrit Haase (siebenschlaefer) Date: 2002-01-09 08:51 Message: Logged In: YES user_id=76037 Where is the uploaded file? G. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=501295&group_id=10127 From noreply@sourceforge.net Wed Apr 24 11:01:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed Apr 24 10:01:13 2002 Subject: [ expat-Patches-548210 ] Enable reporting of external PE declarat Message-ID: Patches item #548210, was opened at 2002-04-24 13:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=548210&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) Summary: Enable reporting of external PE declarat Initial Comment: It seems that Expat does not report declarations of external parameter entities, even though it reports the associated parameter entity references. This patch should enable Expat to call the external entity ref handler when it encounters external PE declarations. I have attached full versions of the modified files xmlparse.c and xmlrole.c, as well as the corresponding diffs. The modifications have been made against xmlrole.c rev. 1.5 and xmlparse.c rev. 1.30. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=548210&group_id=10127 From noreply@sourceforge.net Wed Apr 24 21:11:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed Apr 24 20:11:02 2002 Subject: [ expat-Patches-461763 ] BOM and ExternalSubset Message-ID: Patches item #461763, was opened at 2001-09-15 00:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=461763&group_id=10127 Category: None Group: None Status: Open Resolution: None >Priority: 6 Submitted By: Gilles Marichal (gilou) Assigned to: Nobody/Anonymous (nobody) Summary: BOM and ExternalSubset Initial Comment: Hello, Expat parsing failed when the file to parse had an external subset starting with a BOM. Adding the following two lines at the start of function externalSubset0 in xmlrole.c fixes the problem: if (tok == XML_TOK_BOM) return XML_ROLE_NONE; Note: while correcting that problem, I looked in the xmlrole.c file the others parts of the code handling the XML_TOK_BOM token. I'd like to know the rationale for handling it in prolog1 (wouldn't it always be handled in prolog0 only?). G. Marichal ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=461763&group_id=10127 From noreply@sourceforge.net Thu Apr 25 10:38:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Apr 25 09:38:03 2002 Subject: [ expat-Bugs-548690 ] Incorrect "undefined entity" error Message-ID: Bugs item #548690, was opened at 2002-04-25 12:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=548690&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect "undefined entity" error Initial Comment: I came across the following behaviour, given this document: %worldupdtd; %visiondtd; ]> some text Expat will report an "undefined entity" fatal error for the reference %visiondtd;. However, the XML spec says this (look at the tag: Well-formedness constraint: Entity Declared In a document without any DTD, a document with only an internal DTD subset which contains no parameter entity references, or a document with "standalone='yes'", for an entity reference that does not occur within the external subset or a parameter entity, the Name given in the entity reference must match that in an entity declaration that does not occur within the external subset or a parameter entity, except that well-formed documents need not declare any of the following entities: amp, lt, gt, apos, quot. The declaration of a general entity must precede any reference to it which appears in a default value in an attribute- list declaration. Note that if entities are declared in the external subset or in external parameter entities, a non-validating processor is not obligated to read and process their declarations; for such documents, the rule that an entity must be declared is a well-formedness constraint only if standalone='yes'. Validity constraint: Entity Declared In a document with an external subset or external parameter entities with "standalone='no'", the Name given in the entity reference must match that in an entity declaration. For interoperability, valid documents should declare the entities amp, lt, gt, apos, quot, in the form specified in 4.6 Predefined Entities. The declaration of a parameter entity must precede any reference to it. Similarly, the declaration of a general entity must precede any attribute-list declaration containing a default value with a direct or indirect reference to that general entity. Since Expat is not validating, the emphasized section should apply. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=548690&group_id=10127 From noreply@sourceforge.net Thu Apr 25 14:22:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Apr 25 13:22:35 2002 Subject: [ expat-Bugs-548778 ] Incorrect "undefined entity" error Message-ID: Bugs item #548778, was opened at 2002-04-25 16:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=548778&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect "undefined entity" error Initial Comment: I came across the following behaviour, given this document: %worldupdtd; %visiondtd; ]> some text Expat will report an "undefined entity" fatal error for the reference %visiondtd;. However, the XML spec says this (look at the tag: Well-formedness constraint: Entity Declared In a document without any DTD, a document with only an internal DTD subset which contains no parameter entity references, or a document with "standalone='yes'", for an entity reference that does not occur within the external subset or a parameter entity, the Name given in the entity reference must match that in an entity declaration that does not occur within the external subset or a parameter entity, except that well-formed documents need not declare any of the following entities: amp, lt, gt, apos, quot. The declaration of a general entity must precede any reference to it which appears in a default value in an attribute- list declaration. Note that if entities are declared in the external subset or in external parameter entities, a non-validating processor is not obligated to read and process their declarations; for such documents, the rule that an entity must be declared is a well-formedness constraint only if standalone='yes'. Validity constraint: Entity Declared In a document with an external subset or external parameter entities with "standalone='no'", the Name given in the entity reference must match that in an entity declaration. For interoperability, valid documents should declare the entities amp, lt, gt, apos, quot, in the form specified in 4.6 Predefined Entities. The declaration of a parameter entity must precede any reference to it. Similarly, the declaration of a general entity must precede any attribute-list declaration containing a default value with a direct or indirect reference to that general entity. Since Expat is not validating, the emphasized section should apply. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=548778&group_id=10127 From noreply@sourceforge.net Thu Apr 25 14:23:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Apr 25 13:23:37 2002 Subject: [ expat-Bugs-548778 ] Incorrect "undefined entity" error Message-ID: Bugs item #548778, was opened at 2002-04-25 16:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=548778&group_id=10127 Category: None Group: None >Status: Deleted Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) >Summary: Incorrect "undefined entity" error Initial Comment: I came across the following behaviour, given this document: %worldupdtd; %visiondtd; ]> some text Expat will report an "undefined entity" fatal error for the reference %visiondtd;. However, the XML spec says this (look at the tag: Well-formedness constraint: Entity Declared In a document without any DTD, a document with only an internal DTD subset which contains no parameter entity references, or a document with "standalone='yes'", for an entity reference that does not occur within the external subset or a parameter entity, the Name given in the entity reference must match that in an entity declaration that does not occur within the external subset or a parameter entity, except that well-formed documents need not declare any of the following entities: amp, lt, gt, apos, quot. The declaration of a general entity must precede any reference to it which appears in a default value in an attribute- list declaration. Note that if entities are declared in the external subset or in external parameter entities, a non-validating processor is not obligated to read and process their declarations; for such documents, the rule that an entity must be declared is a well-formedness constraint only if standalone='yes'. Validity constraint: Entity Declared In a document with an external subset or external parameter entities with "standalone='no'", the Name given in the entity reference must match that in an entity declaration. For interoperability, valid documents should declare the entities amp, lt, gt, apos, quot, in the form specified in 4.6 Predefined Entities. The declaration of a parameter entity must precede any reference to it. Similarly, the declaration of a general entity must precede any attribute-list declaration containing a default value with a direct or indirect reference to that general entity. Since Expat is not validating, the emphasized section should apply. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=548778&group_id=10127 From noreply@sourceforge.net Thu Apr 25 14:32:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Apr 25 13:32:27 2002 Subject: [ expat-Patches-548786 ] Fix attempt for bug # 548690 Message-ID: Patches item #548786, was opened at 2002-04-25 16:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=548786&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) Summary: Fix attempt for bug # 548690 Initial Comment: Under the following switch case: case XML_ROLE_PARAM_ENTITY_REF: the original code would simply do return XML_ERROR_UNDEFINED_ENTITY; if the entity's name was not declared before. I have replace this with: if (dtd.standalone) return XML_ERROR_UNDEFINED_ENTITY; if (defaultHandler) reportDefault(parser, enc, s, next); break; In addition, under the following case: case XML_ROLE_PARAM_ENTITY_NAME: the original code would only store the name of the parameter entity if dtd.complete was true. I have removed this condition. Obviously, this could potentially break some other code. Sofar it has been working for me. The attached file xmlparse.c is based on revision 1.30 and also includes patch # 548210. A diff file is attached as well. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=548786&group_id=10127 From noreply@sourceforge.net Thu Apr 25 14:43:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Apr 25 13:43:29 2002 Subject: [ expat-Bugs-548778 ] Incorrect "undefined entity" error Message-ID: Bugs item #548778, was opened at 2002-04-25 16:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=548778&group_id=10127 Category: None Group: None Status: Deleted Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) >Summary: Incorrect "undefined entity" error Initial Comment: I came across the following behaviour, given this document: %worldupdtd; %visiondtd; ]> some text Expat will report an "undefined entity" fatal error for the reference %visiondtd;. However, the XML spec says this (look at the tag: Well-formedness constraint: Entity Declared In a document without any DTD, a document with only an internal DTD subset which contains no parameter entity references, or a document with "standalone='yes'", for an entity reference that does not occur within the external subset or a parameter entity, the Name given in the entity reference must match that in an entity declaration that does not occur within the external subset or a parameter entity, except that well-formed documents need not declare any of the following entities: amp, lt, gt, apos, quot. The declaration of a general entity must precede any reference to it which appears in a default value in an attribute- list declaration. Note that if entities are declared in the external subset or in external parameter entities, a non-validating processor is not obligated to read and process their declarations; for such documents, the rule that an entity must be declared is a well-formedness constraint only if standalone='yes'. Validity constraint: Entity Declared In a document with an external subset or external parameter entities with "standalone='no'", the Name given in the entity reference must match that in an entity declaration. For interoperability, valid documents should declare the entities amp, lt, gt, apos, quot, in the form specified in 4.6 Predefined Entities. The declaration of a parameter entity must precede any reference to it. Similarly, the declaration of a general entity must precede any attribute-list declaration containing a default value with a direct or indirect reference to that general entity. Since Expat is not validating, the emphasized section should apply. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-04-25 16:42 Message: Logged In: YES user_id=290026 Deleted because it was entered twice in error. Original (and now unique) bug: # 548690 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=548778&group_id=10127 From noreply@sourceforge.net Thu Apr 25 19:31:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Apr 25 18:31:06 2002 Subject: [ expat-Bugs-538445 ] cc: -a conflicts with -dy Message-ID: Bugs item #538445, was opened at 2002-04-02 13:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=538445&group_id=10127 Category: Build control Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: cc: -a conflicts with -dy Initial Comment: I am trying to build expat on a sun solaris system and I get the following error during the build. cc: -a conflicts with -dy I used the --prefix option during the ./configure execution. Everything else was done just as the documentation suggested. Any help would be much appreciated. Thank you. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-04-25 18:30 Message: Logged In: NO Isn't cc -flags shows: -d[y|n] dynamic [-dy] or static [-dn] option to linker I simply changed -static to -dn and it worked fine man ld shows-a In static mode only, produces an executable object file; gives errors for undefined references. This is the default behavior for static mode. -a may not be used with the -r option. -d y | n When -d y, the default, is specified, ld uses dynamic linking; when -d n is specified, ld uses static link- ing. See also -B dynamic|static. ---------------------------------------------------------------------- Comment By: Mathew Bevilacqua (matbev1) Date: 2002-04-02 14:40 Message: Logged In: YES user_id=501365 I, too, followed the instructions exactly, and some more tweaking was needed. For my build to work, I had to: 1. make sure that LIBTOOL in the makefile in /lib was set correctly 2. build as a super user Also, you could try removing -dy. It's just a debug utility. From noreply@sourceforge.net Thu Apr 25 19:46:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Apr 25 18:46:06 2002 Subject: [ expat-Bugs-548690 ] Incorrect "undefined entity" error Message-ID: Bugs item #548690, was opened at 2002-04-25 12:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=548690&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) >Summary: Incorrect "undefined entity" error Initial Comment: I came across the following behaviour, given this document: %worldupdtd; %visiondtd; ]> some text Expat will report an "undefined entity" fatal error for the reference %visiondtd;. However, the XML spec says this (look at the tag: Well-formedness constraint: Entity Declared In a document without any DTD, a document with only an internal DTD subset which contains no parameter entity references, or a document with "standalone='yes'", for an entity reference that does not occur within the external subset or a parameter entity, the Name given in the entity reference must match that in an entity declaration that does not occur within the external subset or a parameter entity, except that well-formed documents need not declare any of the following entities: amp, lt, gt, apos, quot. The declaration of a general entity must precede any reference to it which appears in a default value in an attribute- list declaration. Note that if entities are declared in the external subset or in external parameter entities, a non-validating processor is not obligated to read and process their declarations; for such documents, the rule that an entity must be declared is a well-formedness constraint only if standalone='yes'. Validity constraint: Entity Declared In a document with an external subset or external parameter entities with "standalone='no'", the Name given in the entity reference must match that in an entity declaration. For interoperability, valid documents should declare the entities amp, lt, gt, apos, quot, in the form specified in 4.6 Predefined Entities. The declaration of a parameter entity must precede any reference to it. Similarly, the declaration of a general entity must precede any attribute-list declaration containing a default value with a direct or indirect reference to that general entity. Since Expat is not validating, the emphasized section should apply. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-25 21:45 Message: Logged In: YES user_id=3066 I need more information to construct the test case. In particular, is a callback set with XML_SetExternalEntityRefHandler(), how many times is it called (is it called for the entity that isn't declared?), and what does it return? Was XML_SetParamEntityParsing() called, and with which value for the 'code' argument? Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=548690&group_id=10127 From noreply@sourceforge.net Thu Apr 25 20:55:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Apr 25 19:55:22 2002 Subject: [ expat-Bugs-441449 ] problems with parsing external entities Message-ID: Bugs item #441449, was opened at 2001-07-15 08:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=441449&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rafael R. Sevilla (didosevilla) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: problems with parsing external entities Initial Comment: I've tried to use Expat's external entity parsing module in my project (http://xml-lit.sourceforge.net/) and have gotten some very strange results. I used Expat's XML_ExternalEntityParserCreate within an external entity reference handler and used the parser once again. Had mixed results with this. For one particular document referred to by an external entity Expat would give an error: "no element found" at the end of the document (line number). Doesn't happen with all the other documents I have. The document was perfectly legal XML and otherwise Expat can parse it directly...just not through the external entity. The document was also quite large, so I tried to work around it by splitting the document into several more documents...the problem went away. Will cruft together a simpler example document and short program to illustrate this problem. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-04-25 19:54 Message: Logged In: NO In my opinion,function "cdataSectionProcessor" can't call function "contentProcessor",because "contentProcessor" call "doContent" with a zero value of the parameter "startTagLevel".But the CDATA section is in an external entity.The "startTagLevel" should be one.So I think,the key point of the bug is that function "cdataSectionProcessor" can't get the right "startTagLevel". ---------------------------------------------------------------------- Comment By: Rafael R. Sevilla (didosevilla) Date: 2001-09-17 04:32 Message: Logged In: YES user_id=26058 The tarball here contains a sample, minimal program which consists of a parser that simply exits if no errors are found when loading an XML document. I have two pairs of XML documents, each of which differ in only one byte. See the README inside the tarball for an explanation. By the way, I've seen this bug happen with Expat 1.95.1 and with the most recent CVS. Red Hat 7.1, Linux 2.4.5. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-25 12:27 Message: Logged In: YES user_id=3066 Can you attach a short sample program and input file? That would make it a *lot* easier to track this down. Also, which version were you using? ---------------------------------------------------------------------- Comment By: Rafael R. Sevilla (didosevilla) Date: 2001-07-16 00:25 Message: Logged In: YES user_id=26058 Further notes on this apparent bug: It seems that it depends both on the file size and the size of the buffer I use. For a buffer that is 8,192 bytes in size, a file of up to 10,775 bytes can be created that can be parsed without error. Going to 10,776 or larger file size will cause the parser to exit with the above error. Increasing the buffer size made the problem go away, but apparently it will just take a bigger file for Expat to produce the same errorin that case. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=441449&group_id=10127 From noreply@sourceforge.net Thu Apr 25 21:47:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Apr 25 20:47:06 2002 Subject: [ expat-Bugs-548690 ] Incorrect "undefined entity" error Message-ID: Bugs item #548690, was opened at 2002-04-25 12:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=548690&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) >Summary: Incorrect "undefined entity" error Initial Comment: I came across the following behaviour, given this document: %worldupdtd; %visiondtd; ]> some text Expat will report an "undefined entity" fatal error for the reference %visiondtd;. However, the XML spec says this (look at the tag: Well-formedness constraint: Entity Declared In a document without any DTD, a document with only an internal DTD subset which contains no parameter entity references, or a document with "standalone='yes'", for an entity reference that does not occur within the external subset or a parameter entity, the Name given in the entity reference must match that in an entity declaration that does not occur within the external subset or a parameter entity, except that well-formed documents need not declare any of the following entities: amp, lt, gt, apos, quot. The declaration of a general entity must precede any reference to it which appears in a default value in an attribute- list declaration. Note that if entities are declared in the external subset or in external parameter entities, a non-validating processor is not obligated to read and process their declarations; for such documents, the rule that an entity must be declared is a well-formedness constraint only if standalone='yes'. Validity constraint: Entity Declared In a document with an external subset or external parameter entities with "standalone='no'", the Name given in the entity reference must match that in an entity declaration. For interoperability, valid documents should declare the entities amp, lt, gt, apos, quot, in the form specified in 4.6 Predefined Entities. The declaration of a parameter entity must precede any reference to it. Similarly, the declaration of a general entity must precede any attribute-list declaration containing a default value with a direct or indirect reference to that general entity. Since Expat is not validating, the emphasized section should apply. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-04-25 23:46 Message: Logged In: YES user_id=290026 To supply more detail: - the external entityref handler is set - it is called for the entity that isn't declared, as well as the external subset - it always returns 1 - and SetParamEntityParsing was called with XML_PARAM_ENTITY_PARSING_ALWAYS ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-25 21:45 Message: Logged In: YES user_id=3066 I need more information to construct the test case. In particular, is a callback set with XML_SetExternalEntityRefHandler(), how many times is it called (is it called for the entity that isn't declared?), and what does it return? Was XML_SetParamEntityParsing() called, and with which value for the 'code' argument? Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=548690&group_id=10127 From noreply@sourceforge.net Fri Apr 26 04:52:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Apr 26 03:52:02 2002 Subject: [ expat-Bugs-549014 ] May cause memory error in dtdCopy. Message-ID: Bugs item #549014, was opened at 2002-04-26 10:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=549014&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jun Huang (huangjun_se) Assigned to: Nobody/Anonymous (nobody) Summary: May cause memory error in dtdCopy. Initial Comment: This problem may not a bug.If not ,I want somebody to tell me how to use the XML_ExternalEntityParserCreate and XML_ParserFree.Thank you. In function "dtdCopy",there is a comment "/* Don't want deep copying for scaffolding */".I don't understand it's meaning.But the following code set oldDtd->scaffIndex to newDtd->scaffIndex.I found it may cause a memory error. If a parentParser has allocated the memory pointed by scaffIndex,I use XML_ExternalEntityParserCreate to create a subParser.So the subParser will get the scaffIndex of the parentParser.And then I call XML_ParserFree to free the subParser,it will free the memory pointed by scaffIndex of the subParser.But the scaffIndex of the parentParser still pointed the memory freed.Then if the following code visit the memory pointed by the scaffIndex ,it will cause a memory error. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=549014&group_id=10127 From noreply@sourceforge.net Sat Apr 27 07:25:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat Apr 27 06:25:02 2002 Subject: [ expat-Bugs-548690 ] Incorrect "undefined entity" error Message-ID: Bugs item #548690, was opened at 2002-04-25 12:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=548690&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) >Summary: Incorrect "undefined entity" error Initial Comment: I came across the following behaviour, given this document: %worldupdtd; %visiondtd; ]> some text Expat will report an "undefined entity" fatal error for the reference %visiondtd;. However, the XML spec says this (look at the tag: Well-formedness constraint: Entity Declared In a document without any DTD, a document with only an internal DTD subset which contains no parameter entity references, or a document with "standalone='yes'", for an entity reference that does not occur within the external subset or a parameter entity, the Name given in the entity reference must match that in an entity declaration that does not occur within the external subset or a parameter entity, except that well-formed documents need not declare any of the following entities: amp, lt, gt, apos, quot. The declaration of a general entity must precede any reference to it which appears in a default value in an attribute- list declaration. Note that if entities are declared in the external subset or in external parameter entities, a non-validating processor is not obligated to read and process their declarations; for such documents, the rule that an entity must be declared is a well-formedness constraint only if standalone='yes'. Validity constraint: Entity Declared In a document with an external subset or external parameter entities with "standalone='no'", the Name given in the entity reference must match that in an entity declaration. For interoperability, valid documents should declare the entities amp, lt, gt, apos, quot, in the form specified in 4.6 Predefined Entities. The declaration of a parameter entity must precede any reference to it. Similarly, the declaration of a general entity must precede any attribute-list declaration containing a default value with a direct or indirect reference to that general entity. Since Expat is not validating, the emphasized section should apply. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-04-27 09:24 Message: Logged In: YES user_id=290026 This bug and bug # 544679 seem to be related to a set of difficulties Expat has in handling DTDs and PEs. The best way to detect those problems and test them is to subject Expat to James Clark's test cases at ftp://ftp.jclark.com/pub/xml/xmltest.zip, specifically the test cases in the subdirectory /valid/not-sa/ . Expat does not handle most of them correctly, it seems. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-04-25 23:46 Message: Logged In: YES user_id=290026 To supply more detail: - the external entityref handler is set - it is called for the entity that isn't declared, as well as the external subset - it always returns 1 - and SetParamEntityParsing was called with XML_PARAM_ENTITY_PARSING_ALWAYS ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-25 21:45 Message: Logged In: YES user_id=3066 I need more information to construct the test case. In particular, is a callback set with XML_SetExternalEntityRefHandler(), how many times is it called (is it called for the entity that isn't declared?), and what does it return? Was XML_SetParamEntityParsing() called, and with which value for the 'code' argument? Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=548690&group_id=10127 From noreply@sourceforge.net Sat Apr 27 07:26:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat Apr 27 06:26:05 2002 Subject: [ expat-Bugs-544679 ] PEs in external subset error Message-ID: Bugs item #544679, was opened at 2002-04-16 10:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=544679&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) Summary: PEs in external subset error Initial Comment: I ran Expat 1.95.2 against James Clark's test cases version 1998-11-18. There are two files in the directory .../valid/not-sa, which are supposed to be valid, but Expat returns an "illegal parameter entity reference" error. Here is how it looks for the first file: File 004.xml: File 004-1.ent: --> Expat reports error here %e1; File 0004-2.ent: And the second file: File 003.xml: File 003-1.ent: --> Expat error here File 003-2.ent: empty file Expat's behaviour seems to *not* conform to this XML 1.0 rule: Well-formedness constraint: PEs in Internal Subset In the internal DTD subset, parameter-entity references can occur only where markup declarations can occur, not within markup declarations. (This does not apply to references that occur in external parameter entities or to the external subset.) That is, Expat reports an error for external parameter entities too. This might be because a child parser in Expat does not know that it is a child parser - and therefore that it is processing an external entity. Karl ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-04-27 09:25 Message: Logged In: YES user_id=290026 Related to bug # 548690. Check comments there. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=544679&group_id=10127