From noreply@sourceforge.net Sat Jun 1 16:17:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat Jun 1 15:17:29 2002 Subject: [ expat-Bugs-462960 ] configure fails on OSX Message-ID: Bugs item #462960, was opened at 2001-09-19 12:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=462960&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 7 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: configure fails on OSX Initial Comment: [mda@IDRG401 expat-1.95.2]$ ./configure -- prefix=/opt creating cache ./config.cache checking host system type... Invalid configuration `unknown-apple-darwin1.3.7': machine `unknown- apple' not recognized checking build system type... Invalid configuration `unknown-apple-darwin1.3.7': machine `unknown- apple' not recognized checking for ranlib... ranlib checking for gcc... no checking for cc... 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... yes checking whether cc accepts -g... yes checking for ld used by GCC... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for BSD-compatible nm... /usr/bin/nm -p checking whether ln -s works... yes updating cache ./config.cache ltconfig: you must specify a host type if you use `-- no-verify' Try `ltconfig --help' for more information. configure: error: libtool configure failed [mda@IDRG401 expat-1.95.2]$ ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2002-06-01 15:16 Message: Logged In: YES user_id=6501 Working on it now... ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-31 19:17 Message: Logged In: YES user_id=3066 Greg, if you can get this done in the next 24 hours, we should be able to include this in Expat 1.95.3. ---------------------------------------------------------------------- Comment By: Greg Stein (gstein) Date: 2002-05-20 04:12 Message: Logged In: YES user_id=6501 Thanks for the additional clarifications. Your comments about patching libtool are exactly what I was referring to: plain old libtool 1.4.2 isn't going to help the MacOS X users. Note that *we* run libtool when creating a distribution. Since that isn't the "good" libtool, the resulting distribution will not be usable by MacOS X users :-( That said, until libtool gets their act together with the submitted patches, then we can/should point people at the fink package instead. After we release 1.95.3, we should try to get the fink pkg updated to that. Regarding config.sub/.guess, I am planning to pull the most recent copies of those from Apache. They have additional fixes (including MacOS X fixes) that improve them over any of the standard distro'd versions. (if we check them into source control, and tweak our libtoolize call, then it shouldn't overwrite them) ---------------------------------------------------------------------- Comment By: Max Horn (fingolfin) Date: 2002-05-18 09:32 Message: Logged In: YES user_id=12935 I disagree, being somebody who has ported several dozen Unix packages using libtool to OS X. First off, the problem in this bug report is caused by the fact that the configure script is not checking for the HOST type as it should; adding a simple statment to it would fix that, provided you made sure to use current versions of config.sub / config.guess. For hints on libtool patches on OS X, check out http:// fink.sourceforge.net/doc/porting/libtool.php All of these fixes have been cleaned up and submitted to the libtool team by us, and most should be in the next version (I really hope they make a 1.4.3 some day soon with these bugs fixed). For Fink, we also have an expat package: http:// fink.sourceforge.net/pdb/package.php/expat I see that it's not the current expat version, though I doubt that there are fundamental problems; I will contact the author. ---------------------------------------------------------------------- Comment By: Greg Stein (gstein) Date: 2002-05-17 17:53 Message: Logged In: YES user_id=6501 Mac OS X is notoriously problematic w.r.t libtool. Even if we generated the scripts with libtool 1.4.2, additional patches are needed. I believe the only answer is that Mac OS X users would need to get the source, install the properly-patched libtool, and run buildconf to generate new config stuff. With some additional work, I think we can get this fixed up, but it'll take some more investigation that I don't have right now. [ I believe the patched libtool stuff has been posted on the 'net by Pier Fumagalli; need to look that up ] ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-10 14:40 Message: Logged In: NO After copying the files from /usr/share/libtool, and also trying to copy the files from an alternate GNU version of libtool that I have, the exact same error results. What now? ---------------------------------------------------------------------- Comment By: Max Horn (fingolfin) Date: 2001-10-31 13:37 Message: Logged In: YES user_id=12935 This problem is due to old version of config.guess and config.sub being used. In OS X, you can usually copy the ones from /usr/share/libtool/ over the ones supplied in the source to be compiled. The package maintainers can easily fix this issue by updating to the latest versions of the files (and/or also to newer version of autoconf/automake) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=462960&group_id=10127 From noreply@sourceforge.net Sat Jun 1 17:22:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat Jun 1 16:22:28 2002 Subject: [ expat-Bugs-462960 ] configure fails on OSX Message-ID: Bugs item #462960, was opened at 2001-09-19 12:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=462960&group_id=10127 Category: Build control Group: Platform Specific >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: configure fails on OSX Initial Comment: [mda@IDRG401 expat-1.95.2]$ ./configure -- prefix=/opt creating cache ./config.cache checking host system type... Invalid configuration `unknown-apple-darwin1.3.7': machine `unknown- apple' not recognized checking build system type... Invalid configuration `unknown-apple-darwin1.3.7': machine `unknown- apple' not recognized checking for ranlib... ranlib checking for gcc... no checking for cc... 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... yes checking whether cc accepts -g... yes checking for ld used by GCC... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for BSD-compatible nm... /usr/bin/nm -p checking whether ln -s works... yes updating cache ./config.cache ltconfig: you must specify a host type if you use `-- no-verify' Try `ltconfig --help' for more information. configure: error: libtool configure failed [mda@IDRG401 expat-1.95.2]$ ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2002-06-01 16:19 Message: Logged In: YES user_id=6501 Okay. The new system is in. Could somebody try the HEAD of CVS? Or try out 1.95.3 when it gets released? (RSN) I'm going to close this. Please feel free to reopen or to file a new bug if the current CVS doesn't work on Darwin. ---------------------------------------------------------------------- Comment By: Greg Stein (gstein) Date: 2002-06-01 15:16 Message: Logged In: YES user_id=6501 Working on it now... ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-31 19:17 Message: Logged In: YES user_id=3066 Greg, if you can get this done in the next 24 hours, we should be able to include this in Expat 1.95.3. ---------------------------------------------------------------------- Comment By: Greg Stein (gstein) Date: 2002-05-20 04:12 Message: Logged In: YES user_id=6501 Thanks for the additional clarifications. Your comments about patching libtool are exactly what I was referring to: plain old libtool 1.4.2 isn't going to help the MacOS X users. Note that *we* run libtool when creating a distribution. Since that isn't the "good" libtool, the resulting distribution will not be usable by MacOS X users :-( That said, until libtool gets their act together with the submitted patches, then we can/should point people at the fink package instead. After we release 1.95.3, we should try to get the fink pkg updated to that. Regarding config.sub/.guess, I am planning to pull the most recent copies of those from Apache. They have additional fixes (including MacOS X fixes) that improve them over any of the standard distro'd versions. (if we check them into source control, and tweak our libtoolize call, then it shouldn't overwrite them) ---------------------------------------------------------------------- Comment By: Max Horn (fingolfin) Date: 2002-05-18 09:32 Message: Logged In: YES user_id=12935 I disagree, being somebody who has ported several dozen Unix packages using libtool to OS X. First off, the problem in this bug report is caused by the fact that the configure script is not checking for the HOST type as it should; adding a simple statment to it would fix that, provided you made sure to use current versions of config.sub / config.guess. For hints on libtool patches on OS X, check out http:// fink.sourceforge.net/doc/porting/libtool.php All of these fixes have been cleaned up and submitted to the libtool team by us, and most should be in the next version (I really hope they make a 1.4.3 some day soon with these bugs fixed). For Fink, we also have an expat package: http:// fink.sourceforge.net/pdb/package.php/expat I see that it's not the current expat version, though I doubt that there are fundamental problems; I will contact the author. ---------------------------------------------------------------------- Comment By: Greg Stein (gstein) Date: 2002-05-17 17:53 Message: Logged In: YES user_id=6501 Mac OS X is notoriously problematic w.r.t libtool. Even if we generated the scripts with libtool 1.4.2, additional patches are needed. I believe the only answer is that Mac OS X users would need to get the source, install the properly-patched libtool, and run buildconf to generate new config stuff. With some additional work, I think we can get this fixed up, but it'll take some more investigation that I don't have right now. [ I believe the patched libtool stuff has been posted on the 'net by Pier Fumagalli; need to look that up ] ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-10 14:40 Message: Logged In: NO After copying the files from /usr/share/libtool, and also trying to copy the files from an alternate GNU version of libtool that I have, the exact same error results. What now? ---------------------------------------------------------------------- Comment By: Max Horn (fingolfin) Date: 2001-10-31 13:37 Message: Logged In: YES user_id=12935 This problem is due to old version of config.guess and config.sub being used. In OS X, you can usually copy the ones from /usr/share/libtool/ over the ones supplied in the source to be compiled. The package maintainers can easily fix this issue by updating to the latest versions of the files (and/or also to newer version of autoconf/automake) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=462960&group_id=10127 From noreply@sourceforge.net Sat Jun 1 17:28:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat Jun 1 16:28:40 2002 Subject: [ expat-Bugs-524247 ] linking problems Message-ID: Bugs item #524247, was opened at 2002-03-01 01:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=524247&group_id=10127 Category: Build control Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: linking problems Initial Comment: i've downloaded and installed (succesfully) the last version of expat (expat-1.95.2) on a linux red hat 7.1 machine - g++ version is (gcc version 2.96 20000731) i create a lib (.a) that uses expat whenever i want to use this lib i get the following error message ../expat/lib/libexpat.a(xmlparse.o): In function `XML_ParserCreate_MM': /users/xxx/tmp/expat-1.95.2/lib/xmlparse.c:589: undefined reference to `XmlPrologStateInit' ../expat/lib/libexpat.a(xmlparse.o): In function `XML_ExternalEntityParserCreate': /users/xxx/tmp/expat-1.95.2/lib/xmlparse.c:794: undefined reference to `XmlPrologStateInitExternalEntity' collect2: ld returned 1 exit status (right before this one i had /usr/bin/ld: xmlrole.o: invalid string offset 2090860544 >= 0 for section `.shstrtab' /usr/bin/ld: xmlrole.o: invalid string offset 3407872 >= 0 for section `' /usr/bin/ld: xmlrole.o: invalid string offset 2090860544 >= 0 for section `.shstrtab' /usr/bin/ld: xmlrole.o: invalid string offset 2297954304 >= 0 for section `' /usr/bin/ld: xmlrole.o: invalid string offset 2090860544 >= 0 for section `.shstrtab' .... then i tried to use the -O option and it seems to have solved the 1st problem) ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2002-06-01 16:27 Message: Logged In: YES user_id=6501 I've never seen anything like that before. The reference problems could be caused by lack of a 'ranlib' being run on the .a file. The string offsets are just whacked -- that would be symptomatic of some problems in the build/link tools. All of that is well outside of Expat's realm. I'm going to close this bug as user error. Please reopen if the problem persists; remember to attach a build log and a better explanation of "I create a lib (.a) that uses expat" (which sounds like it has nothing really to do with expat) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=524247&group_id=10127 From noreply@sourceforge.net Sat Jun 1 17:34:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat Jun 1 16:34:28 2002 Subject: [ expat-Bugs-557530 ] Cygwin install fails Message-ID: Bugs item #557530, was opened at 2002-05-17 19:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=557530&group_id=10127 Category: Build control Group: Platform Specific >Status: Closed >Resolution: Works For Me Priority: 6 Submitted By: Chad Austin (aegis) Assigned to: Greg Stein (gstein) Summary: Cygwin install fails Initial Comment: Building expat within Cygwin succeeds now, but 'make install' fails. $ gmake install /bin/sh ./conftools/mkinstalldirs /usr/local/bin /usr/local/lib /usr/local/inclu de /bin/sh ./libtool --mode=install /usr/bin/install -c xmlwf/xmlwf /usr/local/bin/ xmlwf libtool: install: warning: `lib/libexpat.la' has not been installed in `/usr/loc al/lib' /usr/bin/install -c xmlwf/.libs/xmlwf /usr/local/bin/xmlwf /bin/sh ./libtool --mode=install /usr/bin/install -c lib/libexpat.la /usr/local/ lib/libexpat.la /usr/bin/install -c lib/.libs/libexpat.dll.a /usr/local/lib/libexpat.dll.a dlpath=`bash 2>&1 -c '. lib/.libs/lib/libexpat.lai;echo $dlname'` dldir=/usr/local/lib/`dirname $dlpath` dirname: too many arguments Try `dirname --help' for more information. make: *** [install] Error 1 ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2002-06-01 16:33 Message: Logged In: YES user_id=6501 That definitely looks like a bug in libtool, rather than in our code. Looking at the text, it seems that it is libtool being invoked and, in turn, invoking 'dirname'. I'm guessing that the directory name has a space in it, and dirname ends up with two arguments. That line in libtool should probably read `dirname "$dlpath"` Closing as "works for me", based on Gerrit's comments about updating libtool. ---------------------------------------------------------------------- Comment By: Gerrit Haase (siebenschlaefer) Date: 2002-05-25 03:06 Message: Logged In: YES user_id=76037 I saw this too. Probably a bug in libtool? Though it works ok. with 1.95.2 after updating the libtool and other parts. Gerrit ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=557530&group_id=10127 From noreply@sourceforge.net Sat Jun 1 17:46:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat Jun 1 16:46:02 2002 Subject: [ expat-Patches-458907 ] config.h appears to be unused Message-ID: Patches item #458907, was opened at 2001-09-05 14:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=458907&group_id=10127 Category: Build Control Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Greg Stein (gstein) Summary: config.h appears to be unused Initial Comment: To compile expat as part of another package (e.g. PyXML), the expat configure might not have been run. For that kind of application, it is necessary to wrap each occurrence of config.h into HAVE_CONFIG_H; the attached patch does that. While trying to figure out which of the defines are needed, it appears that none of them are (i.e. HAVE_ is never used). For stand-along compilation, I found that only VERSION, XML_NS, XML_DTD, XML_BYTE_ORDER, and XML_CONTEXT_BYTES must be defined. Is that impression correct? ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2002-06-01 16:44 Message: Logged In: YES user_id=6501 We may not use most of those (autoconf creates them as part of searching for particular functions and stuff), but xmlwf does use some. That said: if you're going to embed Expat into another application, then you'll need to adjust things accordingly. Note that we've switched to "expat_config.h", so it might be possible to just include that into your own application since a conflict on config.h won't occur any more. Also, note that the premise of "not running configure" is probably quite wrong. Expat is embedded into the ASF's apr-util project, and we *do* run configure for that, and build expat as a sub-library. (heck, we even run expat's buildconf.sh at the appropriate time) Given the change to expat_config.h, and how I believe embedding should work, I'm going to close this patch as rejected. However, even with that said, I'm quite happy to be corrected and/or to make other changes to simplify Expat's ability to be embedded. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-30 21:10 Message: Logged In: YES user_id=3066 Greg, can you please respond to this? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-08 20:48 Message: Logged In: YES user_id=3066 It certainly looks like it can be reduced and possibly removed; I'll read up on a few of the autoconf things before removing it completely. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=458907&group_id=10127 From noreply@sourceforge.net Sat Jun 1 17:49:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat Jun 1 16:49:01 2002 Subject: [ expat-Patches-502187 ] How to build Expat-1.95.2 on OS X 10.1.2 Message-ID: Patches item #502187, was opened at 2002-01-10 20:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=502187&group_id=10127 Category: Build Control Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: How to build Expat-1.95.2 on OS X 10.1.2 Initial Comment: How to build expat-1.95.2 on OS X 10.1.2 - Joel Rodrigues 1. username% tar -zxvf expat-1.95.2.tar.gz 2. cd expat-1.95.2 3. cp /usr/share/libtool/config.guess conftools/config.guess cp /usr/share/libtool/config.sub conftools/config.sub cp /usr/share/libtool/ltconfig conftools/ltconfig cp /usr/share/libtool/ltmain.sh conftools/ltmain.sh 4. Change line 1375 of conftools/Itconfig to read like so : darwin* | rhapsody*) allow_undefined_flag='-undefined warning -flat_namespace' 5. In xmlwf/Makefile.in change "LDFLAGS = @LDFLAGS@ -static" to "LDFLAGS = @LDFLAGS@ -dynamic" 6. Make the same change in examples/makefile.in : "LDFLAGS = @LDFLAGS@ -static" to "LDFLAGS = @LDFLAGS@ -dynamic" 7. Run the following commands : ./configure make make check sudo make install 8. You should see the foll. in the subsequent output : ---------------------------------------------------------------------- Libraries have been installed in: /usr/local/lib If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `DYLD_LIBRARY_PATH' environment variable during execution usage: basename string [suffix] - use the `-install_name LIBDIR/' linker flag See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. ---------------------------------------------------------------------- Cheers ! ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2002-06-01 16:48 Message: Logged In: YES user_id=6501 We've revamped the config/build system in the CVS version of Expat (and the upcoming 1.95.3 release). Please see how well those work for you. I'm going to close this bug/patch as "fixed". Please feel free to reopen with further fixes, based on the upcoming release. ---------------------------------------------------------------------- Comment By: Greg Stein (gstein) Date: 2002-05-17 18:51 Message: Logged In: YES user_id=6501 libtool is simply whacked on Mac OS X. We've got some work to get things working properly. Some of the above problems have been resolve (e.g. we don't use -static any more). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-03-06 17:37 Message: Logged In: NO Me too. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-02-16 13:02 Message: Logged In: NO This does not work.. I get the following errors: /usr/bin/libtool: file: xmltok.lo is not an object file (not allowed in a library) /usr/bin/libtool: file: xmlrole.lo is not an object file (not allowed in a library) make[1]: *** [libexpat.la] Error 1 make: *** [lib] Error 2 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=502187&group_id=10127 From noreply@sourceforge.net Sun Jun 2 03:16:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun Jun 2 02:16:04 2002 Subject: [ expat-Patches-458907 ] config.h appears to be unused Message-ID: Patches item #458907, was opened at 2001-09-05 23:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=458907&group_id=10127 Category: Build Control Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Greg Stein (gstein) Summary: config.h appears to be unused Initial Comment: To compile expat as part of another package (e.g. PyXML), the expat configure might not have been run. For that kind of application, it is necessary to wrap each occurrence of config.h into HAVE_CONFIG_H; the attached patch does that. While trying to figure out which of the defines are needed, it appears that none of them are (i.e. HAVE_ is never used). For stand-along compilation, I found that only VERSION, XML_NS, XML_DTD, XML_BYTE_ORDER, and XML_CONTEXT_BYTES must be defined. Is that impression correct? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-06-02 11:15 Message: Logged In: YES user_id=21627 Can you elaborate which defines of expat_config.h is used in xmlwf? I could not find any. Why is it wrong to not run configure? autoconf packages, historically, always supported "manual" configuration, by editing config.h manually. Also, your own build process does not use expat_config.h if COMPILED_FROM_DSP is set. In general, it is not possible to run configure if you don't have /bin/sh on a system; this is a scenario that PyXML needs to support. Also, traditionally, autoconf supports both configuration with and without a config.h; files including config.h would always wrap this with a #ifdef HAVE_CONFIG_H (should be HAVE_EXPAT_CONFIG_H in your case). All I'm asking is that the combination "manual configuration" and "no config.h" is supported. If this is not available, I have to fake-generate a config.h, which is ugly. It would also help if config.h was reduced to the set of defines which are actually used, instead of autoconfiscating every line of the source. ---------------------------------------------------------------------- Comment By: Greg Stein (gstein) Date: 2002-06-02 01:44 Message: Logged In: YES user_id=6501 We may not use most of those (autoconf creates them as part of searching for particular functions and stuff), but xmlwf does use some. That said: if you're going to embed Expat into another application, then you'll need to adjust things accordingly. Note that we've switched to "expat_config.h", so it might be possible to just include that into your own application since a conflict on config.h won't occur any more. Also, note that the premise of "not running configure" is probably quite wrong. Expat is embedded into the ASF's apr-util project, and we *do* run configure for that, and build expat as a sub-library. (heck, we even run expat's buildconf.sh at the appropriate time) Given the change to expat_config.h, and how I believe embedding should work, I'm going to close this patch as rejected. However, even with that said, I'm quite happy to be corrected and/or to make other changes to simplify Expat's ability to be embedded. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-31 06:10 Message: Logged In: YES user_id=3066 Greg, can you please respond to this? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-09 05:48 Message: Logged In: YES user_id=3066 It certainly looks like it can be reduced and possibly removed; I'll read up on a few of the autoconf things before removing it completely. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=458907&group_id=10127 From noreply@sourceforge.net Mon Jun 3 11:27:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon Jun 3 10:27:04 2002 Subject: [ expat-Bugs-563184 ] warnings for close/read in xmlfile.c Message-ID: Bugs item #563184, was opened at 2002-05-31 23:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=563184&group_id=10127 Category: Build control Group: Platform Specific Status: Open >Resolution: Later Priority: 2 Submitted By: Patrick McCormick (patrickmc) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: warnings for close/read in xmlfile.c Initial Comment: On Solaris 7 with tip of tree, the build throws warnings: gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict- prototypes -fexceptions -Ilib -I. -o xmlwf/xmlfile.o -c xmlwf/xmlfile.c xmlwf/xmlfile.c: In function `processStream': xmlwf/xmlfile.c:155: warning: implicit declaration of function `close' xmlwf/xmlfile.c:160: warning: implicit declaration of function `read' This is because unistd.h isn't included. I see that in xmlfile.c it will be included if _POSIX_SOURCE is defined, but I'm not sure what that means or if the config should be defining that. This is really low priority, and the only warning I see when building expat. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-03 13:25 Message: Logged In: YES user_id=3066 We're avoiding code changes before release; this will wait for Expat 1.95.4. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=563184&group_id=10127 From noreply@sourceforge.net Tue Jun 4 03:01:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Jun 4 02:01:04 2002 Subject: [ expat-Bugs-564275 ] Test 11 in stream.t fails Message-ID: Bugs item #564275, was opened at 2002-06-04 02:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=564275&group_id=10127 Category: XML::Parser (Perl module) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Clark Cooper (coopercc) Summary: Test 11 in stream.t fails Initial Comment: System: Linux 2.4.10-4GB i686 Expat-Version: 1.95.3 Perl-Version: 5.6.1 in stream.t, problem with encoding: $string differs from $expected at index 333: $string is result of parsing a document in ISO-8859-1 encoding, input contains character chr(160) which sneaks into output (UTF-8 encoding) unchanged, instead of being converted to chr(192)chr(160). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=564275&group_id=10127 From noreply@sourceforge.net Tue Jun 4 06:49:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Jun 4 05:49:06 2002 Subject: [ expat-Bugs-564342 ] reading uninitialized variable Message-ID: Bugs item #564342, was opened at 2002-06-04 14:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=564342&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Somers (moundsmere) Assigned to: Nobody/Anonymous (nobody) Summary: reading uninitialized variable Initial Comment: in xmlparse.c, line 3600 eventEndPtr = next; my debugger complains that this is causing an attempt to read unitialized data. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=564342&group_id=10127 From noreply@sourceforge.net Tue Jun 4 08:12:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Jun 4 07:12:10 2002 Subject: [ expat-Bugs-553318 ] XML_ParserReset does not reset everythi Message-ID: Bugs item #553318, was opened at 2002-05-07 11:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=553318&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) Summary: XML_ParserReset does not reset everythi Initial Comment: I have identified three problems with XML_ParserReset in xmlparse.ca rev. 1.31: 1) tempPool and temp2Pool are not cleared, which means that they may grow much larger than needed (the poolClear function does not deallocate memory!) 2) the dtd structure is not reset 3) it should not be legal to call XML_ParserReset on a child parser, since sometimes the child parser shares the dtd structure with the parent parser, and because a child parser created for parsing an external entity cannot be used for the same purpose anymore - the initialization would need to be different I propose to split XML_ParserReset into two functions, an internal one, called parserInit, and an exported one with the original name. This one would then use parserInit like this: int XML_ParserReset(XML_Parser parser, const XML_Char *encodingName) { if (parentParser) return 0; #ifdef XML_DTD if (dtd.scaffold) dtdDestroy(&dtd, parser); #endif poolClear(&tempPool); poolClear(&temp2Pool); return parserInit(parser, encodingName); } whereas parserInit would be called by XML_ParserCreate_MM instead of XML_ParserReset, since not everything that applies to the exported version applies to the internal one. This examples necessitates that parentParser is always set for a child parser, which is currently not the case, but patch # 551599 includes it as a "byproduct" of fixing bug # 549014. Also, parserInit (and consequently XML_ParserReset) may potentially fail (since parserInit calls dtdInit internally) and therefore the return type should be changed from void to int. Changes according to this have been included in patch # 551599 (2nd improved version). Karl ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-04 10:11 Message: Logged In: YES user_id=3066 The referenced fix is part of the 1.95.3 release; closing this report. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-18 14:16 Message: Logged In: YES user_id=290026 Proposed fix is part of patch # 551599 which has been checked in. Let's wait until more testing has been done. Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-07 11:53 Message: Logged In: YES user_id=3066 Sounds good to me. Assigning to you since you've already written the patch. ;-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=553318&group_id=10127 From noreply@sourceforge.net Tue Jun 4 08:13:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Jun 4 07:13:03 2002 Subject: [ expat-Bugs-478611 ] expat.h not included in RPMs Message-ID: Bugs item #478611, was opened at 2001-11-06 05:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=478611&group_id=10127 Category: Build control Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: expat.h not included in RPMs Initial Comment: The include file 'expat.h' seems not to be included in the binary releases of expat (at least 1.95.2-1). It will only be installed if you build expat from source. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-04 10:12 Message: Logged In: YES user_id=3066 Fixed in the 1.95.3 release. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=478611&group_id=10127 From noreply@sourceforge.net Tue Jun 4 08:16:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Jun 4 07:16:07 2002 Subject: [ expat-Bugs-443205 ] XML_UNICODE_WCHAR_T on Unix Message-ID: Bugs item #443205, was opened at 2001-07-20 17:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=443205&group_id=10127 Category: XML::Parser (Perl module) Group: Platform Specific >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: XML_UNICODE_WCHAR_T on Unix Initial Comment: Expat when compiled in wide character mode (using the flag XML_UNICODE_WCHAR_T) on Unix results in "t@1 (l@1) signal BUS (invalid address alignment) in poolStoreString at line 4459 in file xmlparse.c" ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-04 10:15 Message: Logged In: YES user_id=3066 The XML_UNICODE_WCHAR_T support has been substantially changed with many fixes for all platforms. Please try Expat 1.95.3. If the problem persists, please file a new bug report with information on the version of Expat you're using so we know it's current. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-16 22:23 Message: Logged In: YES user_id=3066 Removed assignment to Clark since he's no longer working on Expat. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-26 17:52 Message: Logged In: NO To answer fdrake question: The platform is unix os on solaris. wchar_t on unix is 4 bytes as opposed to 2 bytes on windows. -- manisha ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-20 22:17 Message: Logged In: YES user_id=3066 We need more specific platform information on this; what hardware and operating system was used? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=443205&group_id=10127 From noreply@sourceforge.net Tue Jun 4 08:18:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Jun 4 07:18:08 2002 Subject: [ expat-Bugs-551852 ] BOM causes error with small buffers Message-ID: Bugs item #551852, was opened at 2002-05-03 09:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=551852&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) Summary: BOM causes error with small buffers Initial Comment: This happens when an external entity that has a BOM *and* a text declaration, is parsed, and the buffer size is very small. For instance, take these two files: --- test.xml --- ]> &e; --- end of file --- and this external entity, saved in UTF-16 with BOM: --- test.ent --- some text --- end of file --- When parsing this with a buffer size of 1 (using XML_GetBuffer), you get the error "xml processing instruction not at start of entity". This error won't happen if you remove the BOM. I have traced this to the function externalEntityInitProcessor2. I found a fix for this: original code: ... switch (tok) { case XML_TOK_BOM: start = next; break; ... fixed code: ... switch (tok) { case XML_TOK_BOM: if (next == end && endPtr) { *endPtr = next; return XML_ERROR_NONE; } start = next; break; ... Explanation for fix: If we are at the end of the buffer, the original code would pass control to the next stage, i.e. externalEntityInitProcessor3, which would detect XML_TOK_NONE and pass control directly to doContent without processing any xml text declaration. However, in doContent the xml text declaration will then be parsed and this will cause the error XML_ERROR_MISPLACED_XML_PI, sinc doContent does not allow text declarations. The fix simply prevents control to be passed to doContent before externalEntityInitProcessor2 can process the xml text declaration. Karl ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-04 10:17 Message: Logged In: YES user_id=3066 The fix for this was released as part of Expat 1.95.3. Closing this report. If the problem persists with the new version of Expat, please file a new bug report, including the version number of the Expat you're using. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-18 14:15 Message: Logged In: YES user_id=290026 Patch # 551599 containing the proposed fix has been checked in. I'd like to leave this issue open until more people have tested it. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 23:46 Message: Logged In: YES user_id=290026 Should we check this in, or wait until the PE references patch is tested also. The reason I am mentioning this is that parsing external PE references has the same problem. It just does not show in the current revision, since Expat does not pass such references to the external entity ref handler. Karl Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-04 17:10 Message: Logged In: YES user_id=3066 Karl, I have a test case for this one and can confirm your suggested fix. Check it in whenever you're ready, and I'll follow with the test case. (Still working on the other tests; I got swamped by work & kids this week.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=551852&group_id=10127 From noreply@sourceforge.net Tue Jun 4 08:20:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Jun 4 07:20:03 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: Closed >Resolution: Fixed Priority: 5 Submitted By: Karl Waclawek (kwaclaw) >Assigned to: Karl Waclawek (kwaclaw) 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: Fred L. Drake, Jr. (fdrake) Date: 2002-06-04 10:19 Message: Logged In: YES user_id=3066 Since the fix was released with 1.95.3, I'm closing this report. It can be re-opened or a new bug can be filed if needed. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-18 14:33 Message: Logged In: YES user_id=290026 Expat 1.95.2 had various problems with external PE references, among them that it simply would not pass them to the ExternalEntityRefHandler, when encountering them within entity values, and that it would not pass the entity declaration to the EntityDeclHandler. This has been fixed with patch # 551599 which has been checked in. Let's wait until more testing has been done, before we close this one. 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 From noreply@sourceforge.net Tue Jun 4 08:23:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Jun 4 07:23:02 2002 Subject: [ expat-Bugs-558977 ] Avoid breaking PCDATA at line ends Message-ID: Bugs item #558977, was opened at 2002-05-21 22:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=558977&group_id=10127 Category: None Group: Feature Request >Status: Closed >Resolution: Rejected Priority: 4 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Nobody/Anonymous (nobody) Summary: Avoid breaking PCDATA at line ends Initial Comment: Many applications are poorly served by the line-breaking behavior in which a separate call to the character data handler is made for line content and the line terminator. (Others probably rely on it, even though they shouldn't.) An option to attempt to use the smallest possible number of calls to the character data handler (without changing the buffer management) would be welcome, especially to the implementors and users of scripting-language bindings to Expat. (This in particular is interesting since the call overhead tends to be much higher than plain C callbacks primarily due to the construction of temporary data structures.) ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-04 10:22 Message: Logged In: YES user_id=3066 Ok, I can live with this approach. Closing this feature request as rejected (too uch risk). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-25 00:11 Message: Logged In: YES user_id=290026 I don't think that is trivial. Another option could be to accumulate character data from adjacent character handler calls, and only call out to the scripting language when another handler "interrupts" the character data. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=558977&group_id=10127 From noreply@sourceforge.net Tue Jun 4 08:38:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Jun 4 07:38:03 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: Closed >Resolution: Fixed Priority: 6 Submitted By: Gilles Marichal (gilou) Assigned to: Karl Waclawek (kwaclaw) 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 ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-04 10:37 Message: Logged In: YES user_id=290026 Closed, since bug # 551852 was closed too. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-31 09:38 Message: Logged In: YES user_id=290026 Looked at it. It is the same problem as reported in bug # 551852. Patch # 551599 deals with this problem in a more general way, i.e. including general external entities. So when bug # 551852 is closed, we should close this patch too. Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-31 00:12 Message: Logged In: YES user_id=3066 Karl, can this be closed? Do we need a test case? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-09 21:26 Message: Logged In: YES user_id=290026 It seems this is related to bug # 551852. In this bug, as well as in patch #551599, a fix has been proposed as well. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=461763&group_id=10127 From noreply@sourceforge.net Thu Jun 6 12:00:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Jun 6 11:00:07 2002 Subject: [ expat-Bugs-564275 ] Test 11 in stream.t fails Message-ID: Bugs item #564275, was opened at 2002-06-04 05:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=564275&group_id=10127 Category: XML::Parser (Perl module) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Clark Cooper (coopercc) Summary: Test 11 in stream.t fails Initial Comment: System: Linux 2.4.10-4GB i686 Expat-Version: 1.95.3 Perl-Version: 5.6.1 in stream.t, problem with encoding: $string differs from $expected at index 333: $string is result of parsing a document in ISO-8859-1 encoding, input contains character chr(160) which sneaks into output (UTF-8 encoding) unchanged, instead of being converted to chr(192)chr(160). ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-06 13:59 Message: Logged In: YES user_id=290026 Works for me. Expat 1.95.3 returns 0xC2 0xA0 which corresponds to chr(194) chr(160). I assume you made a typo, since chr(192) = 0xC0 is not valid for the first byte in a UTF-8 sequence. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=564275&group_id=10127 From noreply@sourceforge.net Thu Jun 6 13:26:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Jun 6 12:26:42 2002 Subject: [ expat-Bugs-564342 ] reading uninitialized variable Message-ID: Bugs item #564342, was opened at 2002-06-04 08:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=564342&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Somers (moundsmere) Assigned to: Nobody/Anonymous (nobody) Summary: reading uninitialized variable Initial Comment: in xmlparse.c, line 3600 eventEndPtr = next; my debugger complains that this is causing an attempt to read unitialized data. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-06 14:43 Message: Logged In: YES user_id=290026 Does this happen with version 1.95.3 too? Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=564342&group_id=10127 From noreply@sourceforge.net Thu Jun 6 13:27:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Jun 6 12:27:48 2002 Subject: [ expat-Bugs-564342 ] reading uninitialized variable Message-ID: Bugs item #564342, was opened at 2002-06-04 14:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=564342&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Somers (moundsmere) Assigned to: Nobody/Anonymous (nobody) Summary: reading uninitialized variable Initial Comment: in xmlparse.c, line 3600 eventEndPtr = next; my debugger complains that this is causing an attempt to read unitialized data. ---------------------------------------------------------------------- >Comment By: David Somers (moundsmere) Date: 2002-06-06 20:52 Message: Logged In: YES user_id=36164 Yes, it happends with 1.95.3 too. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-06 20:43 Message: Logged In: YES user_id=290026 Does this happen with version 1.95.3 too? Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=564342&group_id=10127 From noreply@sourceforge.net Thu Jun 6 13:30:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Jun 6 12:30:57 2002 Subject: [ expat-Bugs-564342 ] reading uninitialized variable Message-ID: Bugs item #564342, was opened at 2002-06-04 08:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=564342&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Somers (moundsmere) Assigned to: Nobody/Anonymous (nobody) Summary: reading uninitialized variable Initial Comment: in xmlparse.c, line 3600 eventEndPtr = next; my debugger complains that this is causing an attempt to read unitialized data. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-06 15:29 Message: Logged In: YES user_id=290026 OK, there is only one such line, but I have it on line 3618, in xmlparse.c rev. 1.41. Are you sure you have 1.95.3? Anyway, the code there looks like: ... for (;;) { const char *next; int tok = XmlPrologTok(encoding, s, end, &next); eventEndPtr = next; switch (tok) { ... It looks as if XMLPrologTok initilaizes next, but since this is dynamic behaviour (XMLPrologTok is actually a function pointer), it cannot be assumed for sure that it is happening. Maybe that is what the debugger is complaining about? Does this cause an actual error? Karl ---------------------------------------------------------------------- Comment By: David Somers (moundsmere) Date: 2002-06-06 15:17 Message: Logged In: YES user_id=36164 Like I said in the original message: line 3600 (eventEndPtr = next) Cheers, David ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-06 15:13 Message: Logged In: YES user_id=290026 On which line? ---------------------------------------------------------------------- Comment By: David Somers (moundsmere) Date: 2002-06-06 14:52 Message: Logged In: YES user_id=36164 Yes, it happends with 1.95.3 too. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-06 14:43 Message: Logged In: YES user_id=290026 Does this happen with version 1.95.3 too? Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=564342&group_id=10127 From noreply@sourceforge.net Thu Jun 6 13:32:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Jun 6 12:32:31 2002 Subject: [ expat-Bugs-564342 ] reading uninitialized variable Message-ID: Bugs item #564342, was opened at 2002-06-04 08:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=564342&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Somers (moundsmere) Assigned to: Nobody/Anonymous (nobody) Summary: reading uninitialized variable Initial Comment: in xmlparse.c, line 3600 eventEndPtr = next; my debugger complains that this is causing an attempt to read unitialized data. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-06 15:13 Message: Logged In: YES user_id=290026 On which line? ---------------------------------------------------------------------- Comment By: David Somers (moundsmere) Date: 2002-06-06 14:52 Message: Logged In: YES user_id=36164 Yes, it happends with 1.95.3 too. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-06 14:43 Message: Logged In: YES user_id=290026 Does this happen with version 1.95.3 too? Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=564342&group_id=10127 From noreply@sourceforge.net Thu Jun 6 13:39:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Jun 6 12:39:55 2002 Subject: [ expat-Bugs-564342 ] reading uninitialized variable Message-ID: Bugs item #564342, was opened at 2002-06-04 14:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=564342&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Somers (moundsmere) Assigned to: Nobody/Anonymous (nobody) Summary: reading uninitialized variable Initial Comment: in xmlparse.c, line 3600 eventEndPtr = next; my debugger complains that this is causing an attempt to read unitialized data. ---------------------------------------------------------------------- >Comment By: David Somers (moundsmere) Date: 2002-06-06 21:17 Message: Logged In: YES user_id=36164 Like I said in the original message: line 3600 (eventEndPtr = next) Cheers, David ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-06 21:13 Message: Logged In: YES user_id=290026 On which line? ---------------------------------------------------------------------- Comment By: David Somers (moundsmere) Date: 2002-06-06 20:52 Message: Logged In: YES user_id=36164 Yes, it happends with 1.95.3 too. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-06 20:43 Message: Logged In: YES user_id=290026 Does this happen with version 1.95.3 too? Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=564342&group_id=10127 From noreply@sourceforge.net Thu Jun 6 13:57:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Jun 6 12:57:06 2002 Subject: [ expat-Bugs-564342 ] reading uninitialized variable Message-ID: Bugs item #564342, was opened at 2002-06-04 14:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=564342&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Somers (moundsmere) Assigned to: Nobody/Anonymous (nobody) Summary: reading uninitialized variable Initial Comment: in xmlparse.c, line 3600 eventEndPtr = next; my debugger complains that this is causing an attempt to read unitialized data. ---------------------------------------------------------------------- >Comment By: David Somers (moundsmere) Date: 2002-06-06 21:56 Message: Logged In: YES user_id=36164 Hi Karl, You found the place I mean. I'm referring to the file as I found it in expat-1.95.3.tar.gz, so I guess the line numbers have slipped somewhere. Yep, the debugger complains because its coming across eventEndPtr = next for a case when next hasn't been assigned (so it doesn't like eventEndPtr being set to garbage). OK. It doesn't cause an actual error, per se, but its the *only* thing that my debugger has found to complain about in Expat, so it would be great to quash it (which is very easy: just do const char *next = NULL; two lines before) David ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-06 21:29 Message: Logged In: YES user_id=290026 OK, there is only one such line, but I have it on line 3618, in xmlparse.c rev. 1.41. Are you sure you have 1.95.3? Anyway, the code there looks like: ... for (;;) { const char *next; int tok = XmlPrologTok(encoding, s, end, &next); eventEndPtr = next; switch (tok) { ... It looks as if XMLPrologTok initilaizes next, but since this is dynamic behaviour (XMLPrologTok is actually a function pointer), it cannot be assumed for sure that it is happening. Maybe that is what the debugger is complaining about? Does this cause an actual error? Karl ---------------------------------------------------------------------- Comment By: David Somers (moundsmere) Date: 2002-06-06 21:17 Message: Logged In: YES user_id=36164 Like I said in the original message: line 3600 (eventEndPtr = next) Cheers, David ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-06 21:13 Message: Logged In: YES user_id=290026 On which line? ---------------------------------------------------------------------- Comment By: David Somers (moundsmere) Date: 2002-06-06 20:52 Message: Logged In: YES user_id=36164 Yes, it happends with 1.95.3 too. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-06 20:43 Message: Logged In: YES user_id=290026 Does this happen with version 1.95.3 too? Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=564342&group_id=10127 From noreply@sourceforge.net Thu Jun 6 14:03:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Jun 6 13:03:12 2002 Subject: [ expat-Bugs-564342 ] reading uninitialized variable Message-ID: Bugs item #564342, was opened at 2002-06-04 08:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=564342&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Somers (moundsmere) Assigned to: Nobody/Anonymous (nobody) Summary: reading uninitialized variable Initial Comment: in xmlparse.c, line 3600 eventEndPtr = next; my debugger complains that this is causing an attempt to read unitialized data. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-06 16:02 Message: Logged In: YES user_id=290026 I propose you submit a patch! :-) Is there anything special about the situation when this happens (first loop iteration, ...)? Karl ---------------------------------------------------------------------- Comment By: David Somers (moundsmere) Date: 2002-06-06 15:56 Message: Logged In: YES user_id=36164 Hi Karl, You found the place I mean. I'm referring to the file as I found it in expat-1.95.3.tar.gz, so I guess the line numbers have slipped somewhere. Yep, the debugger complains because its coming across eventEndPtr = next for a case when next hasn't been assigned (so it doesn't like eventEndPtr being set to garbage). OK. It doesn't cause an actual error, per se, but its the *only* thing that my debugger has found to complain about in Expat, so it would be great to quash it (which is very easy: just do const char *next = NULL; two lines before) David ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-06 15:29 Message: Logged In: YES user_id=290026 OK, there is only one such line, but I have it on line 3618, in xmlparse.c rev. 1.41. Are you sure you have 1.95.3? Anyway, the code there looks like: ... for (;;) { const char *next; int tok = XmlPrologTok(encoding, s, end, &next); eventEndPtr = next; switch (tok) { ... It looks as if XMLPrologTok initilaizes next, but since this is dynamic behaviour (XMLPrologTok is actually a function pointer), it cannot be assumed for sure that it is happening. Maybe that is what the debugger is complaining about? Does this cause an actual error? Karl ---------------------------------------------------------------------- Comment By: David Somers (moundsmere) Date: 2002-06-06 15:17 Message: Logged In: YES user_id=36164 Like I said in the original message: line 3600 (eventEndPtr = next) Cheers, David ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-06 15:13 Message: Logged In: YES user_id=290026 On which line? ---------------------------------------------------------------------- Comment By: David Somers (moundsmere) Date: 2002-06-06 14:52 Message: Logged In: YES user_id=36164 Yes, it happends with 1.95.3 too. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-06 14:43 Message: Logged In: YES user_id=290026 Does this happen with version 1.95.3 too? Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=564342&group_id=10127 From noreply@sourceforge.net Thu Jun 6 14:17:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Jun 6 13:17:04 2002 Subject: [ expat-Patches-565510 ] reading uninitialized variable Message-ID: Patches item #565510, was opened at 2002-06-06 22:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=565510&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Somers (moundsmere) Assigned to: Nobody/Anonymous (nobody) Summary: reading uninitialized variable Initial Comment: Somewhere within xmlparse.c there is the snippet: ... for (;;) { const char *next; int tok = XmlPrologTok(encoding, s, end, &next); eventEndPtr = next; switch (tok) { ... (Somewhere being line 3600 in expat-1.95.3.tar.gz, or 3618 according to kwaclaw). Anyhow, my debugger warns that in some cases eventEndPtr is being assigned to an uninitialized ptr... to stop this happening, change: const char *next; to const char *next = NULL; Cheers, David. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=565510&group_id=10127 From noreply@sourceforge.net Thu Jun 6 14:20:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Jun 6 13:20:03 2002 Subject: [ expat-Bugs-564342 ] reading uninitialized variable Message-ID: Bugs item #564342, was opened at 2002-06-04 14:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=564342&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Somers (moundsmere) Assigned to: Nobody/Anonymous (nobody) Summary: reading uninitialized variable Initial Comment: in xmlparse.c, line 3600 eventEndPtr = next; my debugger complains that this is causing an attempt to read unitialized data. ---------------------------------------------------------------------- >Comment By: David Somers (moundsmere) Date: 2002-06-06 22:19 Message: Logged In: YES user_id=36164 Patch submitted. David. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-06 22:02 Message: Logged In: YES user_id=290026 I propose you submit a patch! :-) Is there anything special about the situation when this happens (first loop iteration, ...)? Karl ---------------------------------------------------------------------- Comment By: David Somers (moundsmere) Date: 2002-06-06 21:56 Message: Logged In: YES user_id=36164 Hi Karl, You found the place I mean. I'm referring to the file as I found it in expat-1.95.3.tar.gz, so I guess the line numbers have slipped somewhere. Yep, the debugger complains because its coming across eventEndPtr = next for a case when next hasn't been assigned (so it doesn't like eventEndPtr being set to garbage). OK. It doesn't cause an actual error, per se, but its the *only* thing that my debugger has found to complain about in Expat, so it would be great to quash it (which is very easy: just do const char *next = NULL; two lines before) David ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-06 21:29 Message: Logged In: YES user_id=290026 OK, there is only one such line, but I have it on line 3618, in xmlparse.c rev. 1.41. Are you sure you have 1.95.3? Anyway, the code there looks like: ... for (;;) { const char *next; int tok = XmlPrologTok(encoding, s, end, &next); eventEndPtr = next; switch (tok) { ... It looks as if XMLPrologTok initilaizes next, but since this is dynamic behaviour (XMLPrologTok is actually a function pointer), it cannot be assumed for sure that it is happening. Maybe that is what the debugger is complaining about? Does this cause an actual error? Karl ---------------------------------------------------------------------- Comment By: David Somers (moundsmere) Date: 2002-06-06 21:17 Message: Logged In: YES user_id=36164 Like I said in the original message: line 3600 (eventEndPtr = next) Cheers, David ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-06 21:13 Message: Logged In: YES user_id=290026 On which line? ---------------------------------------------------------------------- Comment By: David Somers (moundsmere) Date: 2002-06-06 20:52 Message: Logged In: YES user_id=36164 Yes, it happends with 1.95.3 too. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-06 20:43 Message: Logged In: YES user_id=290026 Does this happen with version 1.95.3 too? Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=564342&group_id=10127 From fdrake@acm.org Thu Jun 6 14:35:02 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu Jun 6 13:35:02 2002 Subject: installation problem In-Reply-To: <2B721C6525F0D411B1E900B0D0226BDDF07E6F@mohmsg01.ad.infosys.com> References: <2B721C6525F0D411B1E900B0D0226BDDF07E6F@mohmsg01.ad.infosys.com> Message-ID: <15615.47419.977659.56019@grendel.zope.com> Vishal_garg writes: > 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. Please try the recently-announced Expat 1.95.3 package. Look for the download link on http://www.libexpat.org/. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From noreply@sourceforge.net Thu Jun 6 14:52:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Jun 6 13:52:09 2002 Subject: [ expat-Patches-565510 ] reading uninitialized variable Message-ID: Patches item #565510, was opened at 2002-06-06 16:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=565510&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Somers (moundsmere) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: reading uninitialized variable Initial Comment: Somewhere within xmlparse.c there is the snippet: ... for (;;) { const char *next; int tok = XmlPrologTok(encoding, s, end, &next); eventEndPtr = next; switch (tok) { ... (Somewhere being line 3600 in expat-1.95.3.tar.gz, or 3618 according to kwaclaw). Anyhow, my debugger warns that in some cases eventEndPtr is being assigned to an uninitialized ptr... to stop this happening, change: const char *next; to const char *next = NULL; Cheers, David. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-06 16:51 Message: Logged In: YES user_id=290026 Assigned to Fred, since he is our NULL specialist. ;-) Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=565510&group_id=10127 From noreply@sourceforge.net Fri Jun 7 00:14:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Jun 6 23:14:01 2002 Subject: [ expat-Bugs-564275 ] Test 11 in stream.t fails Message-ID: Bugs item #564275, was opened at 2002-06-04 02:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=564275&group_id=10127 Category: XML::Parser (Perl module) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Clark Cooper (coopercc) Summary: Test 11 in stream.t fails Initial Comment: System: Linux 2.4.10-4GB i686 Expat-Version: 1.95.3 Perl-Version: 5.6.1 in stream.t, problem with encoding: $string differs from $expected at index 333: $string is result of parsing a document in ISO-8859-1 encoding, input contains character chr(160) which sneaks into output (UTF-8 encoding) unchanged, instead of being converted to chr(192)chr(160). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-06-06 23:13 Message: Logged In: NO Sorry, was a typo indeed. After parsing the test string (in stream.t) following expressions evaluate to true: ord( substr($string, 332, 1) ) == 160; ord( substr($expected, 332, 1) ) == 194; ord( substr($expected, 333, 1) ) == 160; The test failed yesterday on my freshly installed Suse 8.0 System at home, the expat-library was compiled on Suse 7.3 here at work, though. Some ideas, what's responsible for this test failing? Thank you. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-06 10:59 Message: Logged In: YES user_id=290026 Works for me. Expat 1.95.3 returns 0xC2 0xA0 which corresponds to chr(194) chr(160). I assume you made a typo, since chr(192) = 0xC0 is not valid for the first byte in a UTF-8 sequence. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=564275&group_id=10127 From noreply@sourceforge.net Fri Jun 7 05:25:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Jun 7 04:25:02 2002 Subject: [ expat-Patches-559910 ] SkippedEntityHandler added Message-ID: Patches item #559910, was opened at 2002-05-23 21:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=559910&group_id=10127 Category: None Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Karl Waclawek (kwaclaw) >Assigned to: Karl Waclawek (kwaclaw) Summary: SkippedEntityHandler added Initial Comment: This patch is an implementation of bug/feature request # 552297. It implements the simplified version of the original proposal. The skippedEntityHandler is called in two situations: 1) An entity reference is encountered for which no declaration has been read *and* this is not an error. 2) An internal entity reference is read, but not expanded, because XML_SetDefaultHandler has been called. The attached Diff file is based on expat.h rev. 1.22 and xmlparse.c rev. 1.41. Karl ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-07 07:24 Message: Logged In: YES user_id=3066 Let's get this cecked in! ;-) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-24 15:18 Message: Logged In: YES user_id=290026 Added the full files for those non-Unix people (like me) that are not used to diff and patch Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=559910&group_id=10127 From noreply@sourceforge.net Fri Jun 7 22:24:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Jun 7 21:24:14 2002 Subject: [ expat-Bugs-566088 ] php make fails @ libexpat.la on OSX Message-ID: Bugs item #566088, was opened at 2002-06-07 21:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566088&group_id=10127 Category: Build control Group: Third-party Bug Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: php make fails @ libexpat.la on OSX Initial Comment: hi all, a build of php-latest (php4-200206071800) on OSX Server 10.1.4 with: ./configure --enable-shared --enable-static --prefix=/usr/local/php4 --with-layout=PHP --with-apxs2=/usr/local/apache2/sbin/apxs --with-config-file-path=/private/etc/php4/ --mandir=/usr/local/man --localstatedir=/private/var/php4 --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --with-expat-dir=/usr/local/expat --with-mysql=/usr/local/mysql --with-openssl --with-imap-ssl --with-mcrypt --with-mhash=/usr/local --with-kerberos --with-imap=/usr/local/imap --enable-mailparse --enable-magic-quotes --enable-ftp --enable-force-cgi-redirect --enable-discard-path --enable-inline-optimization --with-pear --with-zlib --enable-calendar --disable-safe-mode --with-tsrm-pthreads fails with: .o Zend/zend_qsort.o Zend/zend_multibyte.o Zend/zend_execute.o sapi/apache2filter/sapi_apache2.o sapi/apache2filter/apache_config.o sapi/apache2filter/php_functions.o main/internal_functions.o -lcrypto -lssl -lc-client -lexpat -lmysqlclient -lmhash -lmcrypt -lltdl -lz -lssl -lcrypto -lbind -lm -ldl -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -ldl -o libs/libphp4.bundle && cp libs/libphp4.bundle libs/libphp4.so /usr/bin/ld: warning -L: directory name (/lib) does not exist /usr/bin/ld: /usr/local/expat/lib/libexpat.la bad magic number (not a Mach-O file) make: *** [libs/libphp4.bundle] Error 1 expat build went fine on OSX, with: cd expat-1.95.3; ./configure --prefix=/usr/local/expat --mandir=/usr/local/man --x-include=/usr to be used by a number of other progrs successfully ...... any thoughts/suggestions on either would be much appreciated! fyi, details of my environment are doc'd on my web-page, below ..... thanks! richard -------------------------------------- R Blake blakers mac.com http://homepage.mac.com/blakers -------------------------------------- ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566088&group_id=10127 From noreply@sourceforge.net Fri Jun 7 22:54:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Jun 7 21:54:20 2002 Subject: [ expat-Bugs-566095 ] php make fails @ libexpat.la on OSX Message-ID: Bugs item #566095, was opened at 2002-06-07 21:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566095&group_id=10127 Category: Build control Group: Third-party Bug Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: php make fails @ libexpat.la on OSX Initial Comment: hi all, a build of php-latest (php4-200206071800) on OSX Server 10.1.4 with: ./configure --enable-shared --enable-static --prefix=/usr/local/php4 --with-layout=PHP --with-apxs2=/usr/local/apache2/sbin/apxs --with-config-file-path=/private/etc/php4/ --mandir=/usr/local/man --localstatedir=/private/var/php4 --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --with-expat-dir=/usr/local/expat --with-mysql=/usr/local/mysql --with-openssl --with-imap-ssl --with-mcrypt --with-mhash=/usr/local --with-kerberos --with-imap=/usr/local/imap --enable-mailparse --enable-magic-quotes --enable-ftp --enable-force-cgi-redirect --enable-discard-path --enable-inline-optimization --with-pear --with-zlib --enable-calendar --disable-safe-mode --with-tsrm-pthreads fails with: .o Zend/zend_qsort.o Zend/zend_multibyte.o Zend/zend_execute.o sapi/apache2filter/sapi_apache2.o sapi/apache2filter/apache_config.o sapi/apache2filter/php_functions.o main/internal_functions.o -lcrypto -lssl -lc-client -lexpat -lmysqlclient -lmhash -lmcrypt -lltdl -lz -lssl -lcrypto -lbind -lm -ldl -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -ldl -o libs/libphp4.bundle && cp libs/libphp4.bundle libs/libphp4.so /usr/bin/ld: warning -L: directory name (/lib) does not exist /usr/bin/ld: /usr/local/expat/lib/libexpat.la bad magic number (not a Mach-O file) make: *** [libs/libphp4.bundle] Error 1 expat build went fine on OSX, with: cd expat-1.95.3; ./configure --prefix=/usr/local/expat --mandir=/usr/local/man --x-include=/usr to be used by a number of other progrs successfully ...... any thoughts/suggestions on either would be much appreciated! fyi, details of my environment are doc'd on my web-page, below ..... thanks! richard -------------------------------------- R Blake blakers mac.com http://homepage.mac.com/blakers -------------------------------------- ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566095&group_id=10127 From noreply@sourceforge.net Sat Jun 8 16:41:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat Jun 8 15:41:09 2002 Subject: [ expat-Bugs-552297 ] Request for skippedEntity handler Message-ID: Bugs item #552297, was opened at 2002-05-04 17:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=552297&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) Summary: Request for skippedEntity handler Initial Comment: It would be very useful if Expat reported skipped entities, like in the SAX2 specification. I have identified the following situations for that: B) External Entities are reported as skipped: - if no external entity ref handler is set - if the entity ref handler returns a special value (e.g. we can define 2 as meaning: "skip this one") B) Internal Entities are reported as skipped: - SetDefaultHandler was called (which turns off expansion of internal general entities) C) Any entity reference is reported as skipped - if no declaration is found & that is not an error (otherwise return a well-formedness error) Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-06-08 17:20 Message: Logged In: YES user_id=13222 As longer, as I think about it, I more and more believe, it was a mistake, to change the reporting of undeclared entities along the line as described in bug 544679 without also adding a skippedEntitiy handler. (I already mentioned my objection in the discussion of 544679, but maybe I wasn't loud enough.) Please consider adding the skippedEntity handler, as described by Karl. Without a skippedEntity handler, it isn't possible to detect a misstyped internal entitiy, if your document has a external subset or external parameter entities, even if you parse all external entities. This may break existing applications (well, it breaks at least one of mine), and should have been mentioned in the announcement (even if the new behaviour is more correct, according to the _letters_ of the XML rec.) And I think, it was a bad idea, to fix 544679 without adding a skippedEntity handler at the same time. rolf ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-24 01:09 Message: Logged In: YES user_id=290026 Have a look at patch # 559910, where the latest, simplified proposal is implemented. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-22 19:51 Message: Logged In: YES user_id=290026 I forgot case B) from the initial request. This would, of course, still be valid, but would also not require more than the simple callback interface I proposed. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-22 13:55 Message: Logged In: YES user_id=290026 Thinking some more about it, I believe that the signature I proposed is overkill, and we can get away with his: typedef void (*XML_SkippedEntityHandler) (void *userData, const XML_Char *entityName, int is_parameter_entity); Reasons: In the old proposal there were two cases when PublicId and SystemId would have been reported: 1) The application decided to skip the entity and passed a return value of 2 from the ExternalEntityRefHandler 2) No ExternalEntityRefHandler was installed I think both of them don't need a skippedEntityHandler, because For 1) It is of no particular usefulness if the application code in the ExternalEntityRefHandler delegates the skip-notification back to Expat. This can be done directly from the handler at least as easily and efficiently, and Expat itself does not need this information, since the very fact of nothing being parsed is all that is important to it. For 2) If no ExternalEntityRefHandler is installed, then why install a skippedEntityHandler? They would have essentially the same signature, and in the end that would mean the same as in 1) - telling Expat we want to skip the entity. Again, that can already be easily achieved with the exisiting API. So, which events then remain that would require a skippedEntityHandler? Only when entity refs are encountered for which no declaration was read, *and* when this is not an error. Now, as far as Fred's suggestion of combining this with some InternalEntityRefHandler, is concerned: In that case we should also report the entity value. Would we not be mixing two different problems here? Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-16 23:44 Message: Logged In: YES user_id=3066 This feature description and proposed callback interface sounds good to me. We might want to think about how such a handler would interact with (or be combined with) a handler so that defined general entities (including "standard" ones like < and friends) can be reported, for applications that need to produce output with minimal changes. (This is commonly needed if the output is going to land in front of a human rather than another processing tool.) Let's target this for 1.95.4. Assigning to Karl since he's indicated specific interest. ;-) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-09 13:35 Message: Logged In: YES user_id=290026 I propose the following signature for the handler: enum XML_Skip_Reason { XML_SKIP_UNDEFINED, XML_SKIP_NOHANDLER, XML_SKIP_REQUESTED }; typedef void (*XML_SkippedEntityHandler) (void *userData, const XML_Char *entityName, int is_parameter_entity, const XML_Char *systemId, const XML_Char *publicId, enum XML_Skip_Reason skipReason); where the values of skipReason have the following meanings: - XML_SKIP_UNDEFINED: entity was skipped because no declaration was found, and this was not an error - XML_SKIP_NOHANDLER: entity was skipped because there was no ExternalEntityRefHandler installed - XML_SKIP_REQUESTED: the ExternalEntityRefHandler returned a value of 2, which means the handler requested the entity to be skipped I hope this makes sense. Comments welcome! Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=552297&group_id=10127 From noreply@sourceforge.net Sat Jun 8 16:41:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat Jun 8 15:41:23 2002 Subject: [ expat-Bugs-566238 ] 1.95.3: xmlwf startup time much longer Message-ID: Bugs item #566238, was opened at 2002-06-08 17:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566238&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Nobody/Anonymous (nobody) Summary: 1.95.3: xmlwf startup time much longer Initial Comment: At least at my linux box, I seems that the new way of starting xmlwf - with a shell wrapper - heavily increases the startup time of xmlwf. For most people, this may be a really minor problem (it isn't even a big one for me, though). But if you check a lot of really small xml files with xmlwf in one commandline or a shell script, this is very notable. I've noticed it, while checking the (very small) test files of the OASIS test suite. My shell scripts, that does this, needed up to 10 times (!) longer, to finished. To be sure, it's really the startup time, I checked xmlwf against some bigger XML files (around 30 Mbyte) and found only minor speed differences between 1.95.2 and 1.95.3. It seems, 1.95.3 is around 6 or 7 percent slower than 1.95.2 (I've substracted the mesured longer startup time of the 1.95.3 xmlwf from the running time, befor calculation.) rolf ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566238&group_id=10127 From noreply@sourceforge.net Sat Jun 8 16:47:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat Jun 8 15:47:28 2002 Subject: [ expat-Bugs-566240 ] UTF-8 char handling still broken(1.95.3) Message-ID: Bugs item #566240, was opened at 2002-06-08 17:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566240&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Nobody/Anonymous (nobody) Summary: UTF-8 char handling still broken(1.95.3) Initial Comment: The changes, to fix bug 477667 seems to have also messed up some things. I've run all not-wellformedness tests (should all raise error) and all valid tests (should all not raise an error) of the OASIS xml test suite Version 2. I found, that in this tests xmltest/not-wf/sa/166.xml xmltest/not-wf/sa/167.xml xmltest/not-wf/sa/171.xml xmltest/not-wf/sa/172.xml xmltest/not-wf/sa/173.xml xmltest/not-wf/sa/174.xml xmltest/not-wf/sa/175.xml xmltest/not-wf/sa/177.xml ibm/not-wf/P02/ibm02n32.xml ibm/not-wf/P02/ibm02n33.xml a invalid UTF-8 char isn't reported as error In this test: ibm/valid/ibm02v01.xml expat claims error for a valid UTF-8 char. rolf ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566240&group_id=10127 From noreply@sourceforge.net Sat Jun 8 18:10:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat Jun 8 17:10:07 2002 Subject: [ expat-Bugs-552297 ] Request for skippedEntity handler Message-ID: Bugs item #552297, was opened at 2002-05-04 13:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=552297&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) Summary: Request for skippedEntity handler Initial Comment: It would be very useful if Expat reported skipped entities, like in the SAX2 specification. I have identified the following situations for that: B) External Entities are reported as skipped: - if no external entity ref handler is set - if the entity ref handler returns a special value (e.g. we can define 2 as meaning: "skip this one") B) Internal Entities are reported as skipped: - SetDefaultHandler was called (which turns off expansion of internal general entities) C) Any entity reference is reported as skipped - if no declaration is found & that is not an error (otherwise return a well-formedness error) Karl ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-08 20:09 Message: Logged In: YES user_id=290026 Rolf, stop twisting my arm - I checked the patch in. :-) It may be necessary to make changes to it when we add the InternalEntityRefHandler. Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-06-08 13:20 Message: Logged In: YES user_id=13222 As longer, as I think about it, I more and more believe, it was a mistake, to change the reporting of undeclared entities along the line as described in bug 544679 without also adding a skippedEntitiy handler. (I already mentioned my objection in the discussion of 544679, but maybe I wasn't loud enough.) Please consider adding the skippedEntity handler, as described by Karl. Without a skippedEntity handler, it isn't possible to detect a misstyped internal entitiy, if your document has a external subset or external parameter entities, even if you parse all external entities. This may break existing applications (well, it breaks at least one of mine), and should have been mentioned in the announcement (even if the new behaviour is more correct, according to the _letters_ of the XML rec.) And I think, it was a bad idea, to fix 544679 without adding a skippedEntity handler at the same time. rolf ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-23 21:09 Message: Logged In: YES user_id=290026 Have a look at patch # 559910, where the latest, simplified proposal is implemented. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-22 15:51 Message: Logged In: YES user_id=290026 I forgot case B) from the initial request. This would, of course, still be valid, but would also not require more than the simple callback interface I proposed. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-22 09:55 Message: Logged In: YES user_id=290026 Thinking some more about it, I believe that the signature I proposed is overkill, and we can get away with his: typedef void (*XML_SkippedEntityHandler) (void *userData, const XML_Char *entityName, int is_parameter_entity); Reasons: In the old proposal there were two cases when PublicId and SystemId would have been reported: 1) The application decided to skip the entity and passed a return value of 2 from the ExternalEntityRefHandler 2) No ExternalEntityRefHandler was installed I think both of them don't need a skippedEntityHandler, because For 1) It is of no particular usefulness if the application code in the ExternalEntityRefHandler delegates the skip-notification back to Expat. This can be done directly from the handler at least as easily and efficiently, and Expat itself does not need this information, since the very fact of nothing being parsed is all that is important to it. For 2) If no ExternalEntityRefHandler is installed, then why install a skippedEntityHandler? They would have essentially the same signature, and in the end that would mean the same as in 1) - telling Expat we want to skip the entity. Again, that can already be easily achieved with the exisiting API. So, which events then remain that would require a skippedEntityHandler? Only when entity refs are encountered for which no declaration was read, *and* when this is not an error. Now, as far as Fred's suggestion of combining this with some InternalEntityRefHandler, is concerned: In that case we should also report the entity value. Would we not be mixing two different problems here? Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-16 19:44 Message: Logged In: YES user_id=3066 This feature description and proposed callback interface sounds good to me. We might want to think about how such a handler would interact with (or be combined with) a handler so that defined general entities (including "standard" ones like < and friends) can be reported, for applications that need to produce output with minimal changes. (This is commonly needed if the output is going to land in front of a human rather than another processing tool.) Let's target this for 1.95.4. Assigning to Karl since he's indicated specific interest. ;-) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-09 09:35 Message: Logged In: YES user_id=290026 I propose the following signature for the handler: enum XML_Skip_Reason { XML_SKIP_UNDEFINED, XML_SKIP_NOHANDLER, XML_SKIP_REQUESTED }; typedef void (*XML_SkippedEntityHandler) (void *userData, const XML_Char *entityName, int is_parameter_entity, const XML_Char *systemId, const XML_Char *publicId, enum XML_Skip_Reason skipReason); where the values of skipReason have the following meanings: - XML_SKIP_UNDEFINED: entity was skipped because no declaration was found, and this was not an error - XML_SKIP_NOHANDLER: entity was skipped because there was no ExternalEntityRefHandler installed - XML_SKIP_REQUESTED: the ExternalEntityRefHandler returned a value of 2, which means the handler requested the entity to be skipped I hope this makes sense. Comments welcome! Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=552297&group_id=10127 From noreply@sourceforge.net Sat Jun 8 19:06:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat Jun 8 18:06:02 2002 Subject: [ expat-Bugs-566333 ] Default namespace => wrong element names Message-ID: Bugs item #566333, was opened at 2002-06-08 18:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566333&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Default namespace => wrong element names Initial Comment: When a document uses a default namespace and expat is set up to be aware of namespaces the tag names reported in the endElementHandler become incorrect. It seems that the endElementHandler always reports the same thing that was last reported in the startElementHandler. With a document as follows and with the namespace separator char set to '@' Test the start and end element handlers of expat will report start: http://w3.org/SMIL20/@smil start: http://w3.org/SMIL20/@head start: http://w3.org/SMIL20/@title end: http://w3.org/SMIL20/@title end: http://w3.org/SMIL20/@title <-- should be head start: http://w3.org/SMIL20/@body end: http://w3.org/SMIL20/@body end: http://w3.org/SMIL20/@body <-- should be smil This has been observed in the win32 version of 1.95.3 with XML_UNICODE_WCHAR_T defined. I had a quick look at the tag structure and saw that localName had the correct value. If namespace processing is turned off the correct names are reported. /Roland d95-rpe@nada.kth.se ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566333&group_id=10127 From noreply@sourceforge.net Sat Jun 8 19:07:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat Jun 8 18:07:02 2002 Subject: [ expat-Bugs-566334 ] Default namespace => wrong element names Message-ID: Bugs item #566334, was opened at 2002-06-08 18:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566334&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Default namespace => wrong element names Initial Comment: When a document uses a default namespace and expat is set up to be aware of namespaces the tag names reported in the endElementHandler become incorrect. It seems that the endElementHandler always reports the same thing that was last reported in the startElementHandler. With a document as follows and with the namespace separator char set to '@' Test the start and end element handlers of expat will report start: http://w3.org/SMIL20/@smil start: http://w3.org/SMIL20/@head start: http://w3.org/SMIL20/@title end: http://w3.org/SMIL20/@title end: http://w3.org/SMIL20/@title <-- should be head start: http://w3.org/SMIL20/@body end: http://w3.org/SMIL20/@body end: http://w3.org/SMIL20/@body <-- should be smil This has been observed in the win32 version of 1.95.3 with XML_UNICODE_WCHAR_T defined. I had a quick look at the tag structure and saw that localName had the correct value. If namespace processing is turned off the correct names are reported. /Roland d95-rpe@nada.kth.se ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566334&group_id=10127 From noreply@sourceforge.net Sat Jun 8 19:16:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat Jun 8 18:16:01 2002 Subject: [ expat-Bugs-566240 ] UTF-8 char handling still broken(1.95.3) Message-ID: Bugs item #566240, was opened at 2002-06-08 13:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566240&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Nobody/Anonymous (nobody) Summary: UTF-8 char handling still broken(1.95.3) Initial Comment: The changes, to fix bug 477667 seems to have also messed up some things. I've run all not-wellformedness tests (should all raise error) and all valid tests (should all not raise an error) of the OASIS xml test suite Version 2. I found, that in this tests xmltest/not-wf/sa/166.xml xmltest/not-wf/sa/167.xml xmltest/not-wf/sa/171.xml xmltest/not-wf/sa/172.xml xmltest/not-wf/sa/173.xml xmltest/not-wf/sa/174.xml xmltest/not-wf/sa/175.xml xmltest/not-wf/sa/177.xml ibm/not-wf/P02/ibm02n32.xml ibm/not-wf/P02/ibm02n33.xml a invalid UTF-8 char isn't reported as error In this test: ibm/valid/ibm02v01.xml expat claims error for a valid UTF-8 char. rolf ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-08 21:15 Message: Logged In: YES user_id=290026 I looked at these test cases, and checked them against Table 3.1B in Unicode 3.2 - have a look at First, lets deal with James Clark's test cases: The docs state that they test if the invalid character FFFF (or FFFE for test case not-wf-sa-167) is present. This would map to the sequence EF BF BF (or EF BF BE). Now, the sequences in question are indeed present, but they are actually valid UTF-8! So, where does it say that they are not valid in XML? XMLSpy accepts these test cases as well-formed, btw. The same then applies to the IBM test cases: ibm02n32.xml tests for FFFE and ibm02n33.xml tests for FFFF. Same question as above - valid UTF-8, but invalid XML? About the last test case, file ibm/valid/iP02/bm02v01.xml : It contains the sequence F0 90 80 5F, which is an illegal UTF-8 sequnce according to Table 3.1B in Unicode 3.2. So, as far as I can tell Expat is correct in how it checks the UTF-8 sequences, but I am not sure if XML imposes further restrictions on them. Anybody care to comment? Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566240&group_id=10127 From noreply@sourceforge.net Sat Jun 8 19:33:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat Jun 8 18:33:02 2002 Subject: [ expat-Bugs-566334 ] Default namespace => wrong element names Message-ID: Bugs item #566334, was opened at 2002-06-08 21:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566334&group_id=10127 Category: None Group: None Status: Open Resolution: None >Priority: 8 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Default namespace => wrong element names Initial Comment: When a document uses a default namespace and expat is set up to be aware of namespaces the tag names reported in the endElementHandler become incorrect. It seems that the endElementHandler always reports the same thing that was last reported in the startElementHandler. With a document as follows and with the namespace separator char set to '@' Test the start and end element handlers of expat will report start: http://w3.org/SMIL20/@smil start: http://w3.org/SMIL20/@head start: http://w3.org/SMIL20/@title end: http://w3.org/SMIL20/@title end: http://w3.org/SMIL20/@title <-- should be head start: http://w3.org/SMIL20/@body end: http://w3.org/SMIL20/@body end: http://w3.org/SMIL20/@body <-- should be smil This has been observed in the win32 version of 1.95.3 with XML_UNICODE_WCHAR_T defined. I had a quick look at the tag structure and saw that localName had the correct value. If namespace processing is turned off the correct names are reported. /Roland d95-rpe@nada.kth.se ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-08 21:32 Message: Logged In: YES user_id=290026 I can confirm your observation, even for the case of XML_UNICODE_WCHAR_T not defined, and using "^" as namespace separator. Can anybody duplicate this on another platofrm? Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566334&group_id=10127 From noreply@sourceforge.net Sat Jun 8 19:35:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat Jun 8 18:35:01 2002 Subject: [ expat-Bugs-566333 ] Default namespace => wrong element names Message-ID: Bugs item #566333, was opened at 2002-06-08 21:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566333&group_id=10127 Category: None Group: None >Status: Deleted >Resolution: Duplicate Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Default namespace => wrong element names Initial Comment: When a document uses a default namespace and expat is set up to be aware of namespaces the tag names reported in the endElementHandler become incorrect. It seems that the endElementHandler always reports the same thing that was last reported in the startElementHandler. With a document as follows and with the namespace separator char set to '@' Test the start and end element handlers of expat will report start: http://w3.org/SMIL20/@smil start: http://w3.org/SMIL20/@head start: http://w3.org/SMIL20/@title end: http://w3.org/SMIL20/@title end: http://w3.org/SMIL20/@title <-- should be head start: http://w3.org/SMIL20/@body end: http://w3.org/SMIL20/@body end: http://w3.org/SMIL20/@body <-- should be smil This has been observed in the win32 version of 1.95.3 with XML_UNICODE_WCHAR_T defined. I had a quick look at the tag structure and saw that localName had the correct value. If namespace processing is turned off the correct names are reported. /Roland d95-rpe@nada.kth.se ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-08 21:34 Message: Logged In: YES user_id=290026 Duplicate bug report - deleted. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566333&group_id=10127 From noreply@sourceforge.net Sat Jun 8 20:52:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat Jun 8 19:52:03 2002 Subject: [ expat-Bugs-566240 ] UTF-8 char handling still broken(1.95.3) Message-ID: Bugs item #566240, was opened at 2002-06-08 13:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566240&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Nobody/Anonymous (nobody) Summary: UTF-8 char handling still broken(1.95.3) Initial Comment: The changes, to fix bug 477667 seems to have also messed up some things. I've run all not-wellformedness tests (should all raise error) and all valid tests (should all not raise an error) of the OASIS xml test suite Version 2. I found, that in this tests xmltest/not-wf/sa/166.xml xmltest/not-wf/sa/167.xml xmltest/not-wf/sa/171.xml xmltest/not-wf/sa/172.xml xmltest/not-wf/sa/173.xml xmltest/not-wf/sa/174.xml xmltest/not-wf/sa/175.xml xmltest/not-wf/sa/177.xml ibm/not-wf/P02/ibm02n32.xml ibm/not-wf/P02/ibm02n33.xml a invalid UTF-8 char isn't reported as error In this test: ibm/valid/ibm02v01.xml expat claims error for a valid UTF-8 char. rolf ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-08 22:51 Message: Logged In: YES user_id=290026 Looking at the spec, it seems that there are in fact additional restrictions: Character Range [2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000- #xFFFD] | [#x10000-#x10FFFF] /* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */ This means we have to re-visit the UTF-8 fix. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-08 21:15 Message: Logged In: YES user_id=290026 I looked at these test cases, and checked them against Table 3.1B in Unicode 3.2 - have a look at First, lets deal with James Clark's test cases: The docs state that they test if the invalid character FFFF (or FFFE for test case not-wf-sa-167) is present. This would map to the sequence EF BF BF (or EF BF BE). Now, the sequences in question are indeed present, but they are actually valid UTF-8! So, where does it say that they are not valid in XML? XMLSpy accepts these test cases as well-formed, btw. The same then applies to the IBM test cases: ibm02n32.xml tests for FFFE and ibm02n33.xml tests for FFFF. Same question as above - valid UTF-8, but invalid XML? About the last test case, file ibm/valid/iP02/bm02v01.xml : It contains the sequence F0 90 80 5F, which is an illegal UTF-8 sequnce according to Table 3.1B in Unicode 3.2. So, as far as I can tell Expat is correct in how it checks the UTF-8 sequences, but I am not sure if XML imposes further restrictions on them. Anybody care to comment? Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566240&group_id=10127 From noreply@sourceforge.net Sun Jun 9 08:04:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun Jun 9 07:04:04 2002 Subject: [ expat-Bugs-566240 ] UTF-8 char handling still broken(1.95.3) Message-ID: Bugs item #566240, was opened at 2002-06-08 13:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566240&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Nobody/Anonymous (nobody) Summary: UTF-8 char handling still broken(1.95.3) Initial Comment: The changes, to fix bug 477667 seems to have also messed up some things. I've run all not-wellformedness tests (should all raise error) and all valid tests (should all not raise an error) of the OASIS xml test suite Version 2. I found, that in this tests xmltest/not-wf/sa/166.xml xmltest/not-wf/sa/167.xml xmltest/not-wf/sa/171.xml xmltest/not-wf/sa/172.xml xmltest/not-wf/sa/173.xml xmltest/not-wf/sa/174.xml xmltest/not-wf/sa/175.xml xmltest/not-wf/sa/177.xml ibm/not-wf/P02/ibm02n32.xml ibm/not-wf/P02/ibm02n33.xml a invalid UTF-8 char isn't reported as error In this test: ibm/valid/ibm02v01.xml expat claims error for a valid UTF-8 char. rolf ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-09 10:03 Message: Logged In: YES user_id=290026 Fix checked in. Please test CVS rev. 1.17 of xmltok.c. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-08 22:51 Message: Logged In: YES user_id=290026 Looking at the spec, it seems that there are in fact additional restrictions: Character Range [2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000- #xFFFD] | [#x10000-#x10FFFF] /* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */ This means we have to re-visit the UTF-8 fix. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-08 21:15 Message: Logged In: YES user_id=290026 I looked at these test cases, and checked them against Table 3.1B in Unicode 3.2 - have a look at First, lets deal with James Clark's test cases: The docs state that they test if the invalid character FFFF (or FFFE for test case not-wf-sa-167) is present. This would map to the sequence EF BF BF (or EF BF BE). Now, the sequences in question are indeed present, but they are actually valid UTF-8! So, where does it say that they are not valid in XML? XMLSpy accepts these test cases as well-formed, btw. The same then applies to the IBM test cases: ibm02n32.xml tests for FFFE and ibm02n33.xml tests for FFFF. Same question as above - valid UTF-8, but invalid XML? About the last test case, file ibm/valid/iP02/bm02v01.xml : It contains the sequence F0 90 80 5F, which is an illegal UTF-8 sequnce according to Table 3.1B in Unicode 3.2. So, as far as I can tell Expat is correct in how it checks the UTF-8 sequences, but I am not sure if XML imposes further restrictions on them. Anybody care to comment? Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566240&group_id=10127 From noreply@sourceforge.net Mon Jun 10 07:02:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon Jun 10 06:02:06 2002 Subject: [ expat-Patches-566827 ] expat-1.95.3 does no with .dll on cygwin Message-ID: Patches item #566827, was opened at 2002-06-10 15:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=566827&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: expat-1.95.3 does no with .dll on cygwin Initial Comment: libtool-1.4 fails to build a shared version on Cygwin. I've not tested it, but it should work with libtool-1.4.2 which is the latest release of libtool. Gerrit -- =^..^= ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=566827&group_id=10127 From noreply@sourceforge.net Mon Jun 10 09:31:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon Jun 10 08:31:03 2002 Subject: [ expat-Patches-566901 ] building outside the sourcedir fails Message-ID: Patches item #566901, was opened at 2002-06-10 17:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=566901&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: building outside the sourcedir fails Initial Comment: 1. It is not possible to build outside the sourcedir. Starts with wrong paths and after fixing this I get problems because expat.h and the manfile were not found. e.g. error , please see below. 2. Calling autoconf gives this message: conftools/get-version.sh: not found /usr/bin/install -c lib/.libs/libexpat.dll.a /var/www/htdocs/cywgin/ex pat/test/expat-1.95.3/.inst/usr/lib/libexpat.dll.a dlpath=`bash 2>&1 -c '. lib/.libs/lib/libexpat.lai;echo $dlname'` dldir=/var/www/htdocs/cywgin/expat/test/expat- 1.95.3/.inst/usr/lib/`dirname $dlpath` dirname: too many arguments Try `dirname --help' for more information. make: *** [installlib] Error 1 Attached is the diff from my changes to Makefile.in to get it to install successfull outside the sourcedir. Gerrit -- =^..^= ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=566901&group_id=10127 From noreply@sourceforge.net Mon Jun 10 09:34:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon Jun 10 08:34:58 2002 Subject: [ expat-Patches-566901 ] building outside the sourcedir fails Message-ID: Patches item #566901, was opened at 2002-06-10 17:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=566901&group_id=10127 Category: Build Control Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Gerrit Haase (siebenschlaefer) Assigned to: Greg Stein (gstein) Summary: building outside the sourcedir fails Initial Comment: 1. It is not possible to build outside the sourcedir. Starts with wrong paths and after fixing this I get problems because expat.h and the manfile were not found. e.g. error , please see below. 2. Calling autoconf gives this message: conftools/get-version.sh: not found /usr/bin/install -c lib/.libs/libexpat.dll.a /var/www/htdocs/cywgin/ex pat/test/expat-1.95.3/.inst/usr/lib/libexpat.dll.a dlpath=`bash 2>&1 -c '. lib/.libs/lib/libexpat.lai;echo $dlname'` dldir=/var/www/htdocs/cywgin/expat/test/expat- 1.95.3/.inst/usr/lib/`dirname $dlpath` dirname: too many arguments Try `dirname --help' for more information. make: *** [installlib] Error 1 Attached is the diff from my changes to Makefile.in to get it to install successfull outside the sourcedir. Gerrit -- =^..^= ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=566901&group_id=10127 From noreply@sourceforge.net Mon Jun 10 09:35:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon Jun 10 08:35:32 2002 Subject: [ expat-Patches-566901 ] install (if building outside the sourcedir) fails Message-ID: Patches item #566901, was opened at 2002-06-10 17:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=566901&group_id=10127 Category: Build Control Group: None Status: Open Resolution: None Priority: 7 Submitted By: Gerrit Haase (siebenschlaefer) Assigned to: Greg Stein (gstein) >Summary: install (if building outside the sourcedir) fails Initial Comment: 1. It is not possible to build outside the sourcedir. Starts with wrong paths and after fixing this I get problems because expat.h and the manfile were not found. e.g. error , please see below. 2. Calling autoconf gives this message: conftools/get-version.sh: not found /usr/bin/install -c lib/.libs/libexpat.dll.a /var/www/htdocs/cywgin/ex pat/test/expat-1.95.3/.inst/usr/lib/libexpat.dll.a dlpath=`bash 2>&1 -c '. lib/.libs/lib/libexpat.lai;echo $dlname'` dldir=/var/www/htdocs/cywgin/expat/test/expat- 1.95.3/.inst/usr/lib/`dirname $dlpath` dirname: too many arguments Try `dirname --help' for more information. make: *** [installlib] Error 1 Attached is the diff from my changes to Makefile.in to get it to install successfull outside the sourcedir. Gerrit -- =^..^= ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=566901&group_id=10127 From noreply@sourceforge.net Mon Jun 10 13:54:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon Jun 10 12:54:04 2002 Subject: [ expat-Patches-567035 ] Patch for bug # 566334 Message-ID: Patches item #567035, was opened at 2002-06-10 15:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=567035&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 8 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) Summary: Patch for bug # 566334 Initial Comment: This patch tries to fix the problem with wrong names reported in the endElement handler, when namespace processing is on. The reason for the problem is that Expat passes the buffer for the namespace URI to the handler, copying the element's local name (and prefix) to the end of the buffer, right after the URI. This saves re-copying the URI. However, if multiple nested elements use the same namespace URI, the names of the top elements get overwritten, since only one buffer is used, and therefore the endElement handler will only report the name of the last, most deeply nested element . I have tried to fix this by re-copying localPart and prefix before the endelement handler is called. Another approach could have been to use separate buffers (e.g. tag->buf), but this would have meant copying the whole URI for each element in the namespace, so I think the solution I tried is at least as efficient. This type of solution was already tried once by the user "maki", but only for NSTriplets reporting, not for NS processing in general. The patch applies to xmlparse.c rev. 1.44. Please test thoroughly - this patch needs to be done right. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=567035&group_id=10127 From noreply@sourceforge.net Mon Jun 10 13:58:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon Jun 10 12:58:02 2002 Subject: [ expat-Bugs-566334 ] Default namespace => wrong element names Message-ID: Bugs item #566334, was opened at 2002-06-08 21:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566334&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 8 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Karl Waclawek (kwaclaw) Summary: Default namespace => wrong element names Initial Comment: When a document uses a default namespace and expat is set up to be aware of namespaces the tag names reported in the endElementHandler become incorrect. It seems that the endElementHandler always reports the same thing that was last reported in the startElementHandler. With a document as follows and with the namespace separator char set to '@' Test the start and end element handlers of expat will report start: http://w3.org/SMIL20/@smil start: http://w3.org/SMIL20/@head start: http://w3.org/SMIL20/@title end: http://w3.org/SMIL20/@title end: http://w3.org/SMIL20/@title <-- should be head start: http://w3.org/SMIL20/@body end: http://w3.org/SMIL20/@body end: http://w3.org/SMIL20/@body <-- should be smil This has been observed in the win32 version of 1.95.3 with XML_UNICODE_WCHAR_T defined. I had a quick look at the tag structure and saw that localName had the correct value. If namespace processing is turned off the correct names are reported. /Roland d95-rpe@nada.kth.se ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-10 15:57 Message: Logged In: YES user_id=290026 This problems looks as if it could be an old bug that has existed for a long time. It actually happens whenever multiple nested elements use the same prefix. Could anyone please test this with Expat 1.95.2? I have submitted a patch (# 567035). Please review and test. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-08 21:32 Message: Logged In: YES user_id=290026 I can confirm your observation, even for the case of XML_UNICODE_WCHAR_T not defined, and using "^" as namespace separator. Can anybody duplicate this on another platofrm? Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566334&group_id=10127 From noreply@sourceforge.net Mon Jun 10 21:03:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon Jun 10 20:03:02 2002 Subject: [ expat-Bugs-566240 ] UTF-8 char handling still broken(1.95.3) Message-ID: Bugs item #566240, was opened at 2002-06-08 17:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566240&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Nobody/Anonymous (nobody) Summary: UTF-8 char handling still broken(1.95.3) Initial Comment: The changes, to fix bug 477667 seems to have also messed up some things. I've run all not-wellformedness tests (should all raise error) and all valid tests (should all not raise an error) of the OASIS xml test suite Version 2. I found, that in this tests xmltest/not-wf/sa/166.xml xmltest/not-wf/sa/167.xml xmltest/not-wf/sa/171.xml xmltest/not-wf/sa/172.xml xmltest/not-wf/sa/173.xml xmltest/not-wf/sa/174.xml xmltest/not-wf/sa/175.xml xmltest/not-wf/sa/177.xml ibm/not-wf/P02/ibm02n32.xml ibm/not-wf/P02/ibm02n33.xml a invalid UTF-8 char isn't reported as error In this test: ibm/valid/ibm02v01.xml expat claims error for a valid UTF-8 char. rolf ---------------------------------------------------------------------- >Comment By: Rolf Ade (pointsman) Date: 2002-06-11 03:02 Message: Logged In: YES user_id=13222 (You're of course right. I better should have distinguished between legal UTF-8 chars and legal XML PCDATA chars. I confess I still have to re-lookup the releated parts of the notorious specs. At the moment, I only mechanical bang it against the OASIS suite and report the strange (ie new) things. Sorry, for omitting deeper analysis.) Better now, according to the OASIS test suite. Only ibm/valid/ibm02v01.xml still seems to be wrong. Expat claims "invalid token", while the test suite claims, that this is valid XML. rolf ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-09 14:03 Message: Logged In: YES user_id=290026 Fix checked in. Please test CVS rev. 1.17 of xmltok.c. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-09 02:51 Message: Logged In: YES user_id=290026 Looking at the spec, it seems that there are in fact additional restrictions: Character Range [2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000- #xFFFD] | [#x10000-#x10FFFF] /* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */ This means we have to re-visit the UTF-8 fix. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-09 01:15 Message: Logged In: YES user_id=290026 I looked at these test cases, and checked them against Table 3.1B in Unicode 3.2 - have a look at First, lets deal with James Clark's test cases: The docs state that they test if the invalid character FFFF (or FFFE for test case not-wf-sa-167) is present. This would map to the sequence EF BF BF (or EF BF BE). Now, the sequences in question are indeed present, but they are actually valid UTF-8! So, where does it say that they are not valid in XML? XMLSpy accepts these test cases as well-formed, btw. The same then applies to the IBM test cases: ibm02n32.xml tests for FFFE and ibm02n33.xml tests for FFFF. Same question as above - valid UTF-8, but invalid XML? About the last test case, file ibm/valid/iP02/bm02v01.xml : It contains the sequence F0 90 80 5F, which is an illegal UTF-8 sequnce according to Table 3.1B in Unicode 3.2. So, as far as I can tell Expat is correct in how it checks the UTF-8 sequences, but I am not sure if XML imposes further restrictions on them. Anybody care to comment? Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566240&group_id=10127 From noreply@sourceforge.net Mon Jun 10 21:07:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon Jun 10 20:07:02 2002 Subject: [ expat-Bugs-566240 ] UTF-8 char handling still broken(1.95.3) Message-ID: Bugs item #566240, was opened at 2002-06-08 17:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566240&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Nobody/Anonymous (nobody) Summary: UTF-8 char handling still broken(1.95.3) Initial Comment: The changes, to fix bug 477667 seems to have also messed up some things. I've run all not-wellformedness tests (should all raise error) and all valid tests (should all not raise an error) of the OASIS xml test suite Version 2. I found, that in this tests xmltest/not-wf/sa/166.xml xmltest/not-wf/sa/167.xml xmltest/not-wf/sa/171.xml xmltest/not-wf/sa/172.xml xmltest/not-wf/sa/173.xml xmltest/not-wf/sa/174.xml xmltest/not-wf/sa/175.xml xmltest/not-wf/sa/177.xml ibm/not-wf/P02/ibm02n32.xml ibm/not-wf/P02/ibm02n33.xml a invalid UTF-8 char isn't reported as error In this test: ibm/valid/ibm02v01.xml expat claims error for a valid UTF-8 char. rolf ---------------------------------------------------------------------- >Comment By: Rolf Ade (pointsman) Date: 2002-06-11 03:06 Message: Logged In: YES user_id=13222 That problematic test file is ibm/valid/P02/ibm02v01.xml Sorry. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-06-11 03:02 Message: Logged In: YES user_id=13222 (You're of course right. I better should have distinguished between legal UTF-8 chars and legal XML PCDATA chars. I confess I still have to re-lookup the releated parts of the notorious specs. At the moment, I only mechanical bang it against the OASIS suite and report the strange (ie new) things. Sorry, for omitting deeper analysis.) Better now, according to the OASIS test suite. Only ibm/valid/ibm02v01.xml still seems to be wrong. Expat claims "invalid token", while the test suite claims, that this is valid XML. rolf ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-09 14:03 Message: Logged In: YES user_id=290026 Fix checked in. Please test CVS rev. 1.17 of xmltok.c. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-09 02:51 Message: Logged In: YES user_id=290026 Looking at the spec, it seems that there are in fact additional restrictions: Character Range [2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000- #xFFFD] | [#x10000-#x10FFFF] /* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */ This means we have to re-visit the UTF-8 fix. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-09 01:15 Message: Logged In: YES user_id=290026 I looked at these test cases, and checked them against Table 3.1B in Unicode 3.2 - have a look at First, lets deal with James Clark's test cases: The docs state that they test if the invalid character FFFF (or FFFE for test case not-wf-sa-167) is present. This would map to the sequence EF BF BF (or EF BF BE). Now, the sequences in question are indeed present, but they are actually valid UTF-8! So, where does it say that they are not valid in XML? XMLSpy accepts these test cases as well-formed, btw. The same then applies to the IBM test cases: ibm02n32.xml tests for FFFE and ibm02n33.xml tests for FFFF. Same question as above - valid UTF-8, but invalid XML? About the last test case, file ibm/valid/iP02/bm02v01.xml : It contains the sequence F0 90 80 5F, which is an illegal UTF-8 sequnce according to Table 3.1B in Unicode 3.2. So, as far as I can tell Expat is correct in how it checks the UTF-8 sequences, but I am not sure if XML imposes further restrictions on them. Anybody care to comment? Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566240&group_id=10127 From noreply@sourceforge.net Mon Jun 10 22:08:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon Jun 10 21:08:02 2002 Subject: [ expat-Bugs-566240 ] UTF-8 char handling still broken(1.95.3) Message-ID: Bugs item #566240, was opened at 2002-06-08 13:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566240&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Nobody/Anonymous (nobody) Summary: UTF-8 char handling still broken(1.95.3) Initial Comment: The changes, to fix bug 477667 seems to have also messed up some things. I've run all not-wellformedness tests (should all raise error) and all valid tests (should all not raise an error) of the OASIS xml test suite Version 2. I found, that in this tests xmltest/not-wf/sa/166.xml xmltest/not-wf/sa/167.xml xmltest/not-wf/sa/171.xml xmltest/not-wf/sa/172.xml xmltest/not-wf/sa/173.xml xmltest/not-wf/sa/174.xml xmltest/not-wf/sa/175.xml xmltest/not-wf/sa/177.xml ibm/not-wf/P02/ibm02n32.xml ibm/not-wf/P02/ibm02n33.xml a invalid UTF-8 char isn't reported as error In this test: ibm/valid/ibm02v01.xml expat claims error for a valid UTF-8 char. rolf ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-11 00:07 Message: Logged In: YES user_id=290026 I think in this case, i.e. ibm/valid/P02/ibm02v01.xml, the test case is in error, since the file contains the UTF-8 sequence F0 90 80 5F, which is invalid. At this point I am not planning further fixes, unless somebody can show me a reason why this sequence should be considered valid. Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-06-10 23:06 Message: Logged In: YES user_id=13222 That problematic test file is ibm/valid/P02/ibm02v01.xml Sorry. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-06-10 23:02 Message: Logged In: YES user_id=13222 (You're of course right. I better should have distinguished between legal UTF-8 chars and legal XML PCDATA chars. I confess I still have to re-lookup the releated parts of the notorious specs. At the moment, I only mechanical bang it against the OASIS suite and report the strange (ie new) things. Sorry, for omitting deeper analysis.) Better now, according to the OASIS test suite. Only ibm/valid/ibm02v01.xml still seems to be wrong. Expat claims "invalid token", while the test suite claims, that this is valid XML. rolf ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-09 10:03 Message: Logged In: YES user_id=290026 Fix checked in. Please test CVS rev. 1.17 of xmltok.c. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-08 22:51 Message: Logged In: YES user_id=290026 Looking at the spec, it seems that there are in fact additional restrictions: Character Range [2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000- #xFFFD] | [#x10000-#x10FFFF] /* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */ This means we have to re-visit the UTF-8 fix. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-08 21:15 Message: Logged In: YES user_id=290026 I looked at these test cases, and checked them against Table 3.1B in Unicode 3.2 - have a look at First, lets deal with James Clark's test cases: The docs state that they test if the invalid character FFFF (or FFFE for test case not-wf-sa-167) is present. This would map to the sequence EF BF BF (or EF BF BE). Now, the sequences in question are indeed present, but they are actually valid UTF-8! So, where does it say that they are not valid in XML? XMLSpy accepts these test cases as well-formed, btw. The same then applies to the IBM test cases: ibm02n32.xml tests for FFFE and ibm02n33.xml tests for FFFF. Same question as above - valid UTF-8, but invalid XML? About the last test case, file ibm/valid/iP02/bm02v01.xml : It contains the sequence F0 90 80 5F, which is an illegal UTF-8 sequnce according to Table 3.1B in Unicode 3.2. So, as far as I can tell Expat is correct in how it checks the UTF-8 sequences, but I am not sure if XML imposes further restrictions on them. Anybody care to comment? Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566240&group_id=10127 From noreply@sourceforge.net Tue Jun 11 07:49:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Jun 11 06:49:02 2002 Subject: [ expat-Patches-567400 ] Patch for cdataSectionProcessor Message-ID: Patches item #567400, was opened at 2002-06-11 09:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=567400&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) Summary: Patch for cdataSectionProcessor Initial Comment: This patch applies to bug # 441449. It seems that doContent() should be called with startTagLevel = 0 for the document entity, and startTagLevel = 1 for external entities. This is how contentProcessor() and externalEntityContentProcessor() are doing it. So, I propose to change cdataSectionProcessor like this: ... if (start) { if (parentParser) { processor = externalEntityContentProcessor; return externalEntityContentProcessor(parser, start, end, endPtr); } else { processor = contentProcessor; return contentProcessor(parser, start, end, endPtr); } } ... This seems to fix at least the bug demo example supplied with bug # 441449. The patch requires that parentParser is always set for external entities, therefore it will only work on newer versions of Expat (1.95.3+). I also found a small bug that needs fixing: In function ExternalEntityparserCreate(), the assignment to parentParser should be pulled out of the conditional section, like this: ... parentParser = oldParser; #ifdef XML_DTD paramEntityParsing = oldParamEntityParsing; prologState.inEntityValue = oldInEntityValue; // parentParser = oldParser; -> move out of here if (context) { #endif /* XML_DTD */ ... Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=567400&group_id=10127 From noreply@sourceforge.net Tue Jun 11 07:50:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Jun 11 06:50:01 2002 Subject: [ expat-Bugs-441449 ] problems with parsing external entities Message-ID: Bugs item #441449, was opened at 2001-07-15 11: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: Karl Waclawek (kwaclaw) Date: 2002-06-11 09:49 Message: Logged In: YES user_id=290026 I agree - it seems for external entities, the processor must be set to externalEntityContentProcessor. I have submitted patch # 567400. Please review and test. I hope it doesn't break anything else. Karl ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-04-25 22: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 07: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 15: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 03: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 Tue Jun 11 08:15:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Jun 11 07:15:05 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: Karl Waclawek (kwaclaw) >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-06-11 10:14 Message: Logged In: YES user_id=290026 There have not been reports of negative side effects of patch # 551599 regarding this issue, and the skippedEntityHandler patch has been checked in. We can close this now. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-18 14:19 Message: Logged In: YES user_id=290026 Patch # 551599 contains fixes which make Expat conform to the spec. Leave this open until a skippedEntityHandler patch has been submitted, so that we don't loose sight of the related issues. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 13:43 Message: Logged In: YES user_id=290026 OK, I have added a bug report as feature request for a skippedEntity handler (# 552297). Please review and add your comments. Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-04 12:58 Message: Logged In: YES user_id=13222 _Please_ don't change expats behavior in this area without giving the programmer a chance to get noticed about such not resolvable entities. A skippedEntity callback seems to be a way. The reason for this is, that it is possible to do DTD validation on top of the current expat. If expat silently skip not resolvable entities, this is would be over. (Well,almost complete DTD validation. I mentioned a few remainig problems in http://sourceforge.net/mailarchive/message.php?msg_id=839092 with a bit more information to the nested parameter entities problem also discoverd by Karl in http://sourceforge.net/mailarchive/message.php?msg_id=839078) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 00:12 Message: Logged In: YES user_id=290026 I think the priority should be that Expat conforms to the spec. So, if there is no well-formedness violation, then Expat should not report one. However, your concern is valid, but should be dealt with differently. We were already discussing the introduction of a skippedEntity callback, like the one in SAX. Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-03 23:15 Message: Logged In: YES user_id=13222 I'm a bit confused about the subject. While Karl Waclawe's observation is right by it's own, I don't want to loose the ability of exapt, to claim about not to be able to resolve an external parameter entity. ---------------------------------------------------------------------- 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 Tue Jun 11 08:15:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Jun 11 07:15:07 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: Closed Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) >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-06-11 10:14 Message: Logged In: YES user_id=290026 There have not been reports of negative side effects of patch # 551599 regarding this issue, and the skippedEntityHandler patch has been checked in. We can close this now. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-18 14:19 Message: Logged In: YES user_id=290026 Patch # 551599 contains fixes which make Expat conform to the spec. Leave this open until a skippedEntityHandler patch has been submitted, so that we don't loose sight of the related issues. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 13:43 Message: Logged In: YES user_id=290026 OK, I have added a bug report as feature request for a skippedEntity handler (# 552297). Please review and add your comments. Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-04 12:58 Message: Logged In: YES user_id=13222 _Please_ don't change expats behavior in this area without giving the programmer a chance to get noticed about such not resolvable entities. A skippedEntity callback seems to be a way. The reason for this is, that it is possible to do DTD validation on top of the current expat. If expat silently skip not resolvable entities, this is would be over. (Well,almost complete DTD validation. I mentioned a few remainig problems in http://sourceforge.net/mailarchive/message.php?msg_id=839092 with a bit more information to the nested parameter entities problem also discoverd by Karl in http://sourceforge.net/mailarchive/message.php?msg_id=839078) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 00:12 Message: Logged In: YES user_id=290026 I think the priority should be that Expat conforms to the spec. So, if there is no well-formedness violation, then Expat should not report one. However, your concern is valid, but should be dealt with differently. We were already discussing the introduction of a skippedEntity callback, like the one in SAX. Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-03 23:15 Message: Logged In: YES user_id=13222 I'm a bit confused about the subject. While Karl Waclawe's observation is right by it's own, I don't want to loose the ability of exapt, to claim about not to be able to resolve an external parameter entity. ---------------------------------------------------------------------- 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 Tue Jun 11 08:18:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Jun 11 07:18:02 2002 Subject: [ expat-Bugs-549014 ] May cause memory error in dtdCopy. Message-ID: Bugs item #549014, was opened at 2002-04-26 06:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=549014&group_id=10127 Category: None Group: None >Status: Closed 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. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-11 10:17 Message: Logged In: YES user_id=290026 No complaints received so far. Let's close it now. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-18 14:13 Message: Logged In: YES user_id=290026 The fix in patch # 551599 seems to fix this, but I suggest we leave this bug open until more people have tested it. Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-04 17:16 Message: Logged In: YES user_id=13222 In other words, your mean: if (prologState.documentEntity) { if (p->scaffIndex) FREE(p->scaffIndex); if (p->scaffold) FREE(p->scaffold); } at the end of dtdDestroy? Nope, still seg faults. And it seems for the same reason, why parentParser could not used for this. As far, as I see, documentEntity is only set in XmlPrologStateInit() (to 1) and in XmlPrologStateInitExternalEntity() (to 0). Now take again a look at the already quoted end of XML_ExternalEntityParserCreate(): if (context) { #endif /* XML_DTD */ if (!dtdCopy(&dtd, oldDtd, parser) || !setContext(parser, context)) { XML_ParserFree(parser); return 0; } processor = externalEntityInitProcessor; #ifdef XML_DTD } else { dtdSwap(&dtd, oldDtd); parentParser = oldParser; XmlPrologStateInitExternalEntity(&prologState); dtd.complete = 1; hadExternalDoctype = 1; } XmlPrologStateInitExternalEntity() is only called for external parameter entities and the external DTD subset (for this, context is 0). For external general entities, documentEntity isn't set to 0. And therefor the test in dtdDestroy() above doesn't work. I can track this in my test case. This test case has an external subset (for which documentEntity is set to 0) and various external general entities in the content. documentEntity is set to 0 for the parser, that parses the external subset. The external entity parser created to parse the external general entities doesn't have set documentEntity to 0. Consequently, the scaffolding stuff is free'ed in dtdDestroy() - in the current CVS the same as with both proposed tests - at the moment, the parser for the first external general entity is free'ed. If the 'child' parser created for the second external general entity is freed, it makes *bang*: seg fault. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 16:44 Message: Logged In: YES user_id=290026 No, documentEntity does not fit the bill either, so it seems we need a new member. After having a closer look: parentParser is not set for external general entities probably because none of the related code uses it. As far as I can tell, parentParser is used exclusively by DTD processing code, except for the XML_ParserFree function. I have put together a patch (based on my patch # 551599) that does the following: - adds a new member m_isParamEntity and the associated macro - sets parentParser to oldParser for both, external GEs and PEs, in XML_ExternalEntityParserCreate - initializes isParamEntity to 0, but sets it to 1 where parentParser used to be set to oldParser - replaces "if (parentParser)" with "if (isParamEntity)" in XML_ParserFree - keeps the previously suggested code in dtdDestroy: if (!parentParser) { if (p->scaffIndex) FREE(p->scaffIndex); if (p->scaffold) FREE(p->scaffold); } which should guarantee that dtd.scaffold is freed for the root parser only, since parentParser will always be set for child parsers - all other checks of parentParentParser in the DTD handling code should probably be replaced with checks for isParamEntity, however, in DTD handling code, whenever parentParser is set, isParamEntity = 1, and whenever parentParser is null, isParamEntity = 0, so the two are equivalent. Only outside of DTD handling code can they be different If anybody is interested, I can e-mail the patch. If it works - for those that can test it - then I will probably add it as another improvement to patch # 551599. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 14:44 Message: Logged In: YES user_id=290026 You are right - damn! I have to revisit my recent patch for PE handling! Anyway, if parentParser does not fit the bill, then prologState.documentEntity might. Could you please check that too. Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-04 12:23 Message: Logged In: YES user_id=13222 I'm sure, I don't understand all the internals in every detail. But: I would say, Karl Waclawek's code if (!parentParser) { if (p->scaffIndex) FREE(p->scaffIndex); if (p->scaffold) FREE(p->scaffold); } goes into the right direction, but this alone doesn't fix the problem (at least doesn't fix the problem completely). I've an example, which triggers the seg fault (it's a bit complex, a hole application, to much, to attach it, but if somebody is interested enough, I can point you to the code and supply test data.) Even with Karls modification, this example still seg faults. But, as said, where at the right trace. If I remove the freeing of p->scaffIndex and p->scaffold from dtdDestroy(), everthing works as expected (but with a memory leak, of course). But how could this be? Well, as far as I see, parentParser is _not_ set in every case in XML_ExternalEntityParserCreate(). Take a look at the end of this function: if (context) { #endif /* XML_DTD */ if (!dtdCopy(&dtd, oldDtd, parser) || !setContext(parser, context)) { XML_ParserFree(parser); return 0; } processor = externalEntityInitProcessor; #ifdef XML_DTD } else { dtdSwap(&dtd, oldDtd); parentParser = oldParser; XmlPrologStateInitExternalEntity(&prologState); dtd.complete = 1; hadExternalDoctype = 1; } parentParser is only set (to a value != 0), if context is false. If I use parentParser = oldParser; if (context) { #endif /* XML_DTD */ if (!dtdCopy(&dtd, oldDtd, parser) || !setContext(parser, context)) { XML_ParserFree(parser); return 0; } processor = externalEntityInitProcessor; #ifdef XML_DTD } else { dtdSwap(&dtd, oldDtd); XmlPrologStateInitExternalEntity(&prologState); dtd.complete = 1; hadExternalDoctype = 1; } (moved the parentParser setting outside the if, so that it's always set). This, together with Karl's code fixes the problem for me. But I'm really not sure, if this could (should) be done. I don't recall all details of my debugging sessions (it was some month ago), but if I recall right, there are reasons, for that the parentParser is not always set. It's a way to distinguish, if the external entity parser parses an external parameter entity or a general external entity (for parameter entities context is 0). This distinction seems to be used at some places and it looks like, we need it (please correct me, if I'm wrong). So, what to do? Back to Fred's propose of a new interal flag, that's only set for the master parser? Looks like this would be the simplest solution, with the lowest risk of unexpected side effects. Does somebody knows, if this distinction is necessary somewhere, for the parser, to work correct? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 10:05 Message: Logged In: YES user_id=290026 Here is some more analysis (I am fairly new to Expat, so I may repeat what you already know): dtd.scaffold is used as a "working memory" pool for building content models passed to an element declaration handler. It is passed between parsers only so that the working memory does not have to be allocated again (speed). The passing from parent to child is done using dtdCopy or dtdSwap. From all of that I would say that it should only be freed at the very end, when the root parser gets destroyed. So, to achieve that, simply change the code in dtdDestroy from: ... if (p->scaffIndex) FREE(p->scaffIndex); if (p->scaffold) FREE(p->scaffold); ... to: ... if (!parentParser) { if (p->scaffIndex) FREE(p->scaffIndex); if (p->scaffold) FREE(p->scaffold); } ... Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 01:25 Message: Logged In: YES user_id=290026 Just tested my solution for the dangling pointers: Won't work, since it should only be applied when a dtdCopy was performed (external GE), not when a dtdSwap was done (external PE). However, we don't have a flag that tells us which type of external entity was parsed. Another approach could be to clear the old pointers right when dtdCopy is performed (and also reset scaffCount and scaffSize). That way, even if dtd.scaffold was used again, it would be allocated fram scratch, since the code will detect the null pointers. A lot depends on how dtdCopy and dtd.scaffold are used. Currently dtdCopy is only called for creating an external GE parser, and dtd.scaffold is only used for building the content model of an element declaration, which means it is not shared across parsers. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 23:45 Message: Logged In: YES user_id=290026 There is already a flag: look at the parentParser macro. However, as I said, this dangling pointer does not cause an actual problem. I found this out by looking at the code as well as creating a specific test situation, where an external parser would be created, then freed, and then element declaration would be parsed which would require use of the dtd.scaffold member. However, as it appeared to me, all of this happens during parsing of the DTD, but the dtdCopy function will not have been be called since it is only called when the childparser has context !=0, which means it parses a general entity. And that never happens before the DTD parsing is completed. The dangling pointers could simply be set to null like this in XML_ParserFree: ... #ifdef XML_DTD if (parentParser) { dtdSwap(&dtd, &((Parser *)parentParser)->m_dtd); } #endif /* XML_DTD */ dtdDestroy(&dtd, parser); // now, add this code: ((Parser *)parentParser)->m_dtd.scaffold = 0; ((Parser *)parentParser)->m_dtd.scaffIndex = 0; Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-03 23:06 Message: Logged In: YES user_id=13222 An internal flag for this would be great; the simplest solution, very low cost in speed and memory. I would love, to have a this way fixed expat. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-03 22:54 Message: Logged In: YES user_id=3066 Since the "master" and descendent parsers are created using different functions, we should just add an internal field that indicates whether the parser is the master or not. I think we just need to know whether the parser is the master, but don't need a pointer to the master. Karl, does this sound sufficient? I think we can do this with no public API changes. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-03 22:49 Message: Logged In: YES user_id=13222 Exactly. I came to the same conclusion as Jun Huang, while debugging some rare seg faults of an expat based application, I work with. You have to work with external entities (must use XML_ExternalEntityParserCreate()) to see the error. I second this bug report, saying loud that this man is right, not only in that there is a very hard problem (seg fault) with using external enitities with expat but also with his analysis of the reason for this problem. OK, given that, the obvious question is, how to fix that? As far as I see, there isn't a simple way to determine, if a parser is, well, the 'master', or the 'main' parser or if it's a parser, created to parse an external entity. It's OK, to collect the DTD Information of the internal subset and the parts in the (could be) multiple parameter entities in one memory structure, ie I think, it's OK to not deep dopying the scaffolding. But the memory has to be freed in the outmost parser. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 14:57 Message: Logged In: YES user_id=290026 Looking closer at the code: dtdCopy will only be called for a child parser, if the entity is a general entity, not a parameter entity. dtd.scaffold will only be used when the parser is processing the external or internal subset, which always happens *before* any general external entity is processed. So, by planning (or coincidence ) dtd.scaffold will not get used after being freed as described. However, we still have a dangling pointer, which should be set to null. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 12:37 Message: Logged In: YES user_id=290026 It seems your observation is correct. This can cause memory errors. I am just curious why I haven't seen them yet. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=549014&group_id=10127 From noreply@sourceforge.net Tue Jun 11 11:25:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Jun 11 10:25:04 2002 Subject: [ expat-Bugs-566240 ] UTF-8 char handling still broken(1.95.3) Message-ID: Bugs item #566240, was opened at 2002-06-08 17:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566240&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Nobody/Anonymous (nobody) Summary: UTF-8 char handling still broken(1.95.3) Initial Comment: The changes, to fix bug 477667 seems to have also messed up some things. I've run all not-wellformedness tests (should all raise error) and all valid tests (should all not raise an error) of the OASIS xml test suite Version 2. I found, that in this tests xmltest/not-wf/sa/166.xml xmltest/not-wf/sa/167.xml xmltest/not-wf/sa/171.xml xmltest/not-wf/sa/172.xml xmltest/not-wf/sa/173.xml xmltest/not-wf/sa/174.xml xmltest/not-wf/sa/175.xml xmltest/not-wf/sa/177.xml ibm/not-wf/P02/ibm02n32.xml ibm/not-wf/P02/ibm02n33.xml a invalid UTF-8 char isn't reported as error In this test: ibm/valid/ibm02v01.xml expat claims error for a valid UTF-8 char. rolf ---------------------------------------------------------------------- >Comment By: Rolf Ade (pointsman) Date: 2002-06-11 17:24 Message: Logged In: YES user_id=13222 Karl is right. This in deed appears to be a bug in the OASIS test suite - this was already discussed in the test result report to #551599. Even more. Up to (and including) 1.95.2, this wasn't detected by expat and now is. So, this test file isn't an example of an expat bug, but the contrary an example for the improved char checking in 1.95.3. rolf ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-11 04:07 Message: Logged In: YES user_id=290026 I think in this case, i.e. ibm/valid/P02/ibm02v01.xml, the test case is in error, since the file contains the UTF-8 sequence F0 90 80 5F, which is invalid. At this point I am not planning further fixes, unless somebody can show me a reason why this sequence should be considered valid. Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-06-11 03:06 Message: Logged In: YES user_id=13222 That problematic test file is ibm/valid/P02/ibm02v01.xml Sorry. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-06-11 03:02 Message: Logged In: YES user_id=13222 (You're of course right. I better should have distinguished between legal UTF-8 chars and legal XML PCDATA chars. I confess I still have to re-lookup the releated parts of the notorious specs. At the moment, I only mechanical bang it against the OASIS suite and report the strange (ie new) things. Sorry, for omitting deeper analysis.) Better now, according to the OASIS test suite. Only ibm/valid/ibm02v01.xml still seems to be wrong. Expat claims "invalid token", while the test suite claims, that this is valid XML. rolf ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-09 14:03 Message: Logged In: YES user_id=290026 Fix checked in. Please test CVS rev. 1.17 of xmltok.c. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-09 02:51 Message: Logged In: YES user_id=290026 Looking at the spec, it seems that there are in fact additional restrictions: Character Range [2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000- #xFFFD] | [#x10000-#x10FFFF] /* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */ This means we have to re-visit the UTF-8 fix. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-09 01:15 Message: Logged In: YES user_id=290026 I looked at these test cases, and checked them against Table 3.1B in Unicode 3.2 - have a look at First, lets deal with James Clark's test cases: The docs state that they test if the invalid character FFFF (or FFFE for test case not-wf-sa-167) is present. This would map to the sequence EF BF BF (or EF BF BE). Now, the sequences in question are indeed present, but they are actually valid UTF-8! So, where does it say that they are not valid in XML? XMLSpy accepts these test cases as well-formed, btw. The same then applies to the IBM test cases: ibm02n32.xml tests for FFFE and ibm02n33.xml tests for FFFF. Same question as above - valid UTF-8, but invalid XML? About the last test case, file ibm/valid/iP02/bm02v01.xml : It contains the sequence F0 90 80 5F, which is an illegal UTF-8 sequnce according to Table 3.1B in Unicode 3.2. So, as far as I can tell Expat is correct in how it checks the UTF-8 sequences, but I am not sure if XML imposes further restrictions on them. Anybody care to comment? Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566240&group_id=10127 From noreply@sourceforge.net Tue Jun 11 11:29:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Jun 11 10:29:03 2002 Subject: [ expat-Bugs-566240 ] UTF-8 char handling still broken(1.95.3) Message-ID: Bugs item #566240, was opened at 2002-06-08 13:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566240&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Nobody/Anonymous (nobody) Summary: UTF-8 char handling still broken(1.95.3) Initial Comment: The changes, to fix bug 477667 seems to have also messed up some things. I've run all not-wellformedness tests (should all raise error) and all valid tests (should all not raise an error) of the OASIS xml test suite Version 2. I found, that in this tests xmltest/not-wf/sa/166.xml xmltest/not-wf/sa/167.xml xmltest/not-wf/sa/171.xml xmltest/not-wf/sa/172.xml xmltest/not-wf/sa/173.xml xmltest/not-wf/sa/174.xml xmltest/not-wf/sa/175.xml xmltest/not-wf/sa/177.xml ibm/not-wf/P02/ibm02n32.xml ibm/not-wf/P02/ibm02n33.xml a invalid UTF-8 char isn't reported as error In this test: ibm/valid/ibm02v01.xml expat claims error for a valid UTF-8 char. rolf ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-11 13:28 Message: Logged In: YES user_id=290026 Closed due to user enthusiasm. :-) Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-06-11 13:24 Message: Logged In: YES user_id=13222 Karl is right. This in deed appears to be a bug in the OASIS test suite - this was already discussed in the test result report to #551599. Even more. Up to (and including) 1.95.2, this wasn't detected by expat and now is. So, this test file isn't an example of an expat bug, but the contrary an example for the improved char checking in 1.95.3. rolf ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-11 00:07 Message: Logged In: YES user_id=290026 I think in this case, i.e. ibm/valid/P02/ibm02v01.xml, the test case is in error, since the file contains the UTF-8 sequence F0 90 80 5F, which is invalid. At this point I am not planning further fixes, unless somebody can show me a reason why this sequence should be considered valid. Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-06-10 23:06 Message: Logged In: YES user_id=13222 That problematic test file is ibm/valid/P02/ibm02v01.xml Sorry. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-06-10 23:02 Message: Logged In: YES user_id=13222 (You're of course right. I better should have distinguished between legal UTF-8 chars and legal XML PCDATA chars. I confess I still have to re-lookup the releated parts of the notorious specs. At the moment, I only mechanical bang it against the OASIS suite and report the strange (ie new) things. Sorry, for omitting deeper analysis.) Better now, according to the OASIS test suite. Only ibm/valid/ibm02v01.xml still seems to be wrong. Expat claims "invalid token", while the test suite claims, that this is valid XML. rolf ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-09 10:03 Message: Logged In: YES user_id=290026 Fix checked in. Please test CVS rev. 1.17 of xmltok.c. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-08 22:51 Message: Logged In: YES user_id=290026 Looking at the spec, it seems that there are in fact additional restrictions: Character Range [2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000- #xFFFD] | [#x10000-#x10FFFF] /* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */ This means we have to re-visit the UTF-8 fix. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-08 21:15 Message: Logged In: YES user_id=290026 I looked at these test cases, and checked them against Table 3.1B in Unicode 3.2 - have a look at First, lets deal with James Clark's test cases: The docs state that they test if the invalid character FFFF (or FFFE for test case not-wf-sa-167) is present. This would map to the sequence EF BF BF (or EF BF BE). Now, the sequences in question are indeed present, but they are actually valid UTF-8! So, where does it say that they are not valid in XML? XMLSpy accepts these test cases as well-formed, btw. The same then applies to the IBM test cases: ibm02n32.xml tests for FFFE and ibm02n33.xml tests for FFFF. Same question as above - valid UTF-8, but invalid XML? About the last test case, file ibm/valid/iP02/bm02v01.xml : It contains the sequence F0 90 80 5F, which is an illegal UTF-8 sequnce according to Table 3.1B in Unicode 3.2. So, as far as I can tell Expat is correct in how it checks the UTF-8 sequences, but I am not sure if XML imposes further restrictions on them. Anybody care to comment? Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566240&group_id=10127 From noreply@sourceforge.net Tue Jun 11 11:33:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Jun 11 10:33: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: Closed >Resolution: Fixed Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) >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-06-11 10:14 Message: Logged In: YES user_id=290026 There have not been reports of negative side effects of patch # 551599 regarding this issue, and the skippedEntityHandler patch has been checked in. We can close this now. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-18 14:19 Message: Logged In: YES user_id=290026 Patch # 551599 contains fixes which make Expat conform to the spec. Leave this open until a skippedEntityHandler patch has been submitted, so that we don't loose sight of the related issues. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 13:43 Message: Logged In: YES user_id=290026 OK, I have added a bug report as feature request for a skippedEntity handler (# 552297). Please review and add your comments. Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-04 12:58 Message: Logged In: YES user_id=13222 _Please_ don't change expats behavior in this area without giving the programmer a chance to get noticed about such not resolvable entities. A skippedEntity callback seems to be a way. The reason for this is, that it is possible to do DTD validation on top of the current expat. If expat silently skip not resolvable entities, this is would be over. (Well,almost complete DTD validation. I mentioned a few remainig problems in http://sourceforge.net/mailarchive/message.php?msg_id=839092 with a bit more information to the nested parameter entities problem also discoverd by Karl in http://sourceforge.net/mailarchive/message.php?msg_id=839078) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 00:12 Message: Logged In: YES user_id=290026 I think the priority should be that Expat conforms to the spec. So, if there is no well-formedness violation, then Expat should not report one. However, your concern is valid, but should be dealt with differently. We were already discussing the introduction of a skippedEntity callback, like the one in SAX. Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-03 23:15 Message: Logged In: YES user_id=13222 I'm a bit confused about the subject. While Karl Waclawe's observation is right by it's own, I don't want to loose the ability of exapt, to claim about not to be able to resolve an external parameter entity. ---------------------------------------------------------------------- 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 Tue Jun 11 11:33:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Jun 11 10:33:03 2002 Subject: [ expat-Bugs-549014 ] May cause memory error in dtdCopy. Message-ID: Bugs item #549014, was opened at 2002-04-26 06:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=549014&group_id=10127 Category: None Group: None Status: Closed >Resolution: Fixed 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. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-11 10:17 Message: Logged In: YES user_id=290026 No complaints received so far. Let's close it now. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-18 14:13 Message: Logged In: YES user_id=290026 The fix in patch # 551599 seems to fix this, but I suggest we leave this bug open until more people have tested it. Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-04 17:16 Message: Logged In: YES user_id=13222 In other words, your mean: if (prologState.documentEntity) { if (p->scaffIndex) FREE(p->scaffIndex); if (p->scaffold) FREE(p->scaffold); } at the end of dtdDestroy? Nope, still seg faults. And it seems for the same reason, why parentParser could not used for this. As far, as I see, documentEntity is only set in XmlPrologStateInit() (to 1) and in XmlPrologStateInitExternalEntity() (to 0). Now take again a look at the already quoted end of XML_ExternalEntityParserCreate(): if (context) { #endif /* XML_DTD */ if (!dtdCopy(&dtd, oldDtd, parser) || !setContext(parser, context)) { XML_ParserFree(parser); return 0; } processor = externalEntityInitProcessor; #ifdef XML_DTD } else { dtdSwap(&dtd, oldDtd); parentParser = oldParser; XmlPrologStateInitExternalEntity(&prologState); dtd.complete = 1; hadExternalDoctype = 1; } XmlPrologStateInitExternalEntity() is only called for external parameter entities and the external DTD subset (for this, context is 0). For external general entities, documentEntity isn't set to 0. And therefor the test in dtdDestroy() above doesn't work. I can track this in my test case. This test case has an external subset (for which documentEntity is set to 0) and various external general entities in the content. documentEntity is set to 0 for the parser, that parses the external subset. The external entity parser created to parse the external general entities doesn't have set documentEntity to 0. Consequently, the scaffolding stuff is free'ed in dtdDestroy() - in the current CVS the same as with both proposed tests - at the moment, the parser for the first external general entity is free'ed. If the 'child' parser created for the second external general entity is freed, it makes *bang*: seg fault. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 16:44 Message: Logged In: YES user_id=290026 No, documentEntity does not fit the bill either, so it seems we need a new member. After having a closer look: parentParser is not set for external general entities probably because none of the related code uses it. As far as I can tell, parentParser is used exclusively by DTD processing code, except for the XML_ParserFree function. I have put together a patch (based on my patch # 551599) that does the following: - adds a new member m_isParamEntity and the associated macro - sets parentParser to oldParser for both, external GEs and PEs, in XML_ExternalEntityParserCreate - initializes isParamEntity to 0, but sets it to 1 where parentParser used to be set to oldParser - replaces "if (parentParser)" with "if (isParamEntity)" in XML_ParserFree - keeps the previously suggested code in dtdDestroy: if (!parentParser) { if (p->scaffIndex) FREE(p->scaffIndex); if (p->scaffold) FREE(p->scaffold); } which should guarantee that dtd.scaffold is freed for the root parser only, since parentParser will always be set for child parsers - all other checks of parentParentParser in the DTD handling code should probably be replaced with checks for isParamEntity, however, in DTD handling code, whenever parentParser is set, isParamEntity = 1, and whenever parentParser is null, isParamEntity = 0, so the two are equivalent. Only outside of DTD handling code can they be different If anybody is interested, I can e-mail the patch. If it works - for those that can test it - then I will probably add it as another improvement to patch # 551599. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 14:44 Message: Logged In: YES user_id=290026 You are right - damn! I have to revisit my recent patch for PE handling! Anyway, if parentParser does not fit the bill, then prologState.documentEntity might. Could you please check that too. Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-04 12:23 Message: Logged In: YES user_id=13222 I'm sure, I don't understand all the internals in every detail. But: I would say, Karl Waclawek's code if (!parentParser) { if (p->scaffIndex) FREE(p->scaffIndex); if (p->scaffold) FREE(p->scaffold); } goes into the right direction, but this alone doesn't fix the problem (at least doesn't fix the problem completely). I've an example, which triggers the seg fault (it's a bit complex, a hole application, to much, to attach it, but if somebody is interested enough, I can point you to the code and supply test data.) Even with Karls modification, this example still seg faults. But, as said, where at the right trace. If I remove the freeing of p->scaffIndex and p->scaffold from dtdDestroy(), everthing works as expected (but with a memory leak, of course). But how could this be? Well, as far as I see, parentParser is _not_ set in every case in XML_ExternalEntityParserCreate(). Take a look at the end of this function: if (context) { #endif /* XML_DTD */ if (!dtdCopy(&dtd, oldDtd, parser) || !setContext(parser, context)) { XML_ParserFree(parser); return 0; } processor = externalEntityInitProcessor; #ifdef XML_DTD } else { dtdSwap(&dtd, oldDtd); parentParser = oldParser; XmlPrologStateInitExternalEntity(&prologState); dtd.complete = 1; hadExternalDoctype = 1; } parentParser is only set (to a value != 0), if context is false. If I use parentParser = oldParser; if (context) { #endif /* XML_DTD */ if (!dtdCopy(&dtd, oldDtd, parser) || !setContext(parser, context)) { XML_ParserFree(parser); return 0; } processor = externalEntityInitProcessor; #ifdef XML_DTD } else { dtdSwap(&dtd, oldDtd); XmlPrologStateInitExternalEntity(&prologState); dtd.complete = 1; hadExternalDoctype = 1; } (moved the parentParser setting outside the if, so that it's always set). This, together with Karl's code fixes the problem for me. But I'm really not sure, if this could (should) be done. I don't recall all details of my debugging sessions (it was some month ago), but if I recall right, there are reasons, for that the parentParser is not always set. It's a way to distinguish, if the external entity parser parses an external parameter entity or a general external entity (for parameter entities context is 0). This distinction seems to be used at some places and it looks like, we need it (please correct me, if I'm wrong). So, what to do? Back to Fred's propose of a new interal flag, that's only set for the master parser? Looks like this would be the simplest solution, with the lowest risk of unexpected side effects. Does somebody knows, if this distinction is necessary somewhere, for the parser, to work correct? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 10:05 Message: Logged In: YES user_id=290026 Here is some more analysis (I am fairly new to Expat, so I may repeat what you already know): dtd.scaffold is used as a "working memory" pool for building content models passed to an element declaration handler. It is passed between parsers only so that the working memory does not have to be allocated again (speed). The passing from parent to child is done using dtdCopy or dtdSwap. From all of that I would say that it should only be freed at the very end, when the root parser gets destroyed. So, to achieve that, simply change the code in dtdDestroy from: ... if (p->scaffIndex) FREE(p->scaffIndex); if (p->scaffold) FREE(p->scaffold); ... to: ... if (!parentParser) { if (p->scaffIndex) FREE(p->scaffIndex); if (p->scaffold) FREE(p->scaffold); } ... Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 01:25 Message: Logged In: YES user_id=290026 Just tested my solution for the dangling pointers: Won't work, since it should only be applied when a dtdCopy was performed (external GE), not when a dtdSwap was done (external PE). However, we don't have a flag that tells us which type of external entity was parsed. Another approach could be to clear the old pointers right when dtdCopy is performed (and also reset scaffCount and scaffSize). That way, even if dtd.scaffold was used again, it would be allocated fram scratch, since the code will detect the null pointers. A lot depends on how dtdCopy and dtd.scaffold are used. Currently dtdCopy is only called for creating an external GE parser, and dtd.scaffold is only used for building the content model of an element declaration, which means it is not shared across parsers. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 23:45 Message: Logged In: YES user_id=290026 There is already a flag: look at the parentParser macro. However, as I said, this dangling pointer does not cause an actual problem. I found this out by looking at the code as well as creating a specific test situation, where an external parser would be created, then freed, and then element declaration would be parsed which would require use of the dtd.scaffold member. However, as it appeared to me, all of this happens during parsing of the DTD, but the dtdCopy function will not have been be called since it is only called when the childparser has context !=0, which means it parses a general entity. And that never happens before the DTD parsing is completed. The dangling pointers could simply be set to null like this in XML_ParserFree: ... #ifdef XML_DTD if (parentParser) { dtdSwap(&dtd, &((Parser *)parentParser)->m_dtd); } #endif /* XML_DTD */ dtdDestroy(&dtd, parser); // now, add this code: ((Parser *)parentParser)->m_dtd.scaffold = 0; ((Parser *)parentParser)->m_dtd.scaffIndex = 0; Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-03 23:06 Message: Logged In: YES user_id=13222 An internal flag for this would be great; the simplest solution, very low cost in speed and memory. I would love, to have a this way fixed expat. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-03 22:54 Message: Logged In: YES user_id=3066 Since the "master" and descendent parsers are created using different functions, we should just add an internal field that indicates whether the parser is the master or not. I think we just need to know whether the parser is the master, but don't need a pointer to the master. Karl, does this sound sufficient? I think we can do this with no public API changes. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-03 22:49 Message: Logged In: YES user_id=13222 Exactly. I came to the same conclusion as Jun Huang, while debugging some rare seg faults of an expat based application, I work with. You have to work with external entities (must use XML_ExternalEntityParserCreate()) to see the error. I second this bug report, saying loud that this man is right, not only in that there is a very hard problem (seg fault) with using external enitities with expat but also with his analysis of the reason for this problem. OK, given that, the obvious question is, how to fix that? As far as I see, there isn't a simple way to determine, if a parser is, well, the 'master', or the 'main' parser or if it's a parser, created to parse an external entity. It's OK, to collect the DTD Information of the internal subset and the parts in the (could be) multiple parameter entities in one memory structure, ie I think, it's OK to not deep dopying the scaffolding. But the memory has to be freed in the outmost parser. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 14:57 Message: Logged In: YES user_id=290026 Looking closer at the code: dtdCopy will only be called for a child parser, if the entity is a general entity, not a parameter entity. dtd.scaffold will only be used when the parser is processing the external or internal subset, which always happens *before* any general external entity is processed. So, by planning (or coincidence ) dtd.scaffold will not get used after being freed as described. However, we still have a dangling pointer, which should be set to null. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 12:37 Message: Logged In: YES user_id=290026 It seems your observation is correct. This can cause memory errors. I am just curious why I haven't seen them yet. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=549014&group_id=10127 From noreply@sourceforge.net Wed Jun 12 08:07:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed Jun 12 07:07:11 2002 Subject: [ expat-Patches-566901 ] install (if building outside the sourcedir) fails Message-ID: Patches item #566901, was opened at 2002-06-10 15:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=566901&group_id=10127 Category: Build Control Group: None Status: Open Resolution: None Priority: 7 Submitted By: Gerrit Haase (siebenschlaefer) Assigned to: Greg Stein (gstein) Summary: install (if building outside the sourcedir) fails Initial Comment: 1. It is not possible to build outside the sourcedir. Starts with wrong paths and after fixing this I get problems because expat.h and the manfile were not found. e.g. error , please see below. 2. Calling autoconf gives this message: conftools/get-version.sh: not found /usr/bin/install -c lib/.libs/libexpat.dll.a /var/www/htdocs/cywgin/ex pat/test/expat-1.95.3/.inst/usr/lib/libexpat.dll.a dlpath=`bash 2>&1 -c '. lib/.libs/lib/libexpat.lai;echo $dlname'` dldir=/var/www/htdocs/cywgin/expat/test/expat- 1.95.3/.inst/usr/lib/`dirname $dlpath` dirname: too many arguments Try `dirname --help' for more information. make: *** [installlib] Error 1 Attached is the diff from my changes to Makefile.in to get it to install successfull outside the sourcedir. Gerrit -- =^..^= ---------------------------------------------------------------------- Comment By: David Starks-Browning (davidsb) Date: 2002-06-12 14:06 Message: Logged In: YES user_id=561928 Yes, please do get "make" and "make install" working when building outside the source tree. I also need it, and not for Cygwin. :-) Gerrit's patch almost works for me. However, I also had to change INCLUDES = -Ilib -I. to INCLUDES = -I$(srcdir)/lib -I. Gerrit, if you didn't need this, then you probably compiled with whatever expat.h had been installed in the default location (or as augmented by CPPFLAGS). Moreover, I don't understand the need for the docdir macro. There's no target that uses this, AFAICT. For the record, I had reported similar problems with 1.95.1 in bug #406262, but had not tracked expat development since then. Thanks everyone! David ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=566901&group_id=10127 From noreply@sourceforge.net Wed Jun 12 08:43:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed Jun 12 07:43:07 2002 Subject: [ expat-Bugs-566334 ] Default namespace => wrong element names Message-ID: Bugs item #566334, was opened at 2002-06-08 21:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566334&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 8 Submitted By: Nobody/Anonymous (nobody) Assigned to: Karl Waclawek (kwaclaw) Summary: Default namespace => wrong element names Initial Comment: When a document uses a default namespace and expat is set up to be aware of namespaces the tag names reported in the endElementHandler become incorrect. It seems that the endElementHandler always reports the same thing that was last reported in the startElementHandler. With a document as follows and with the namespace separator char set to '@' Test the start and end element handlers of expat will report start: http://w3.org/SMIL20/@smil start: http://w3.org/SMIL20/@head start: http://w3.org/SMIL20/@title end: http://w3.org/SMIL20/@title end: http://w3.org/SMIL20/@title <-- should be head start: http://w3.org/SMIL20/@body end: http://w3.org/SMIL20/@body end: http://w3.org/SMIL20/@body <-- should be smil This has been observed in the win32 version of 1.95.3 with XML_UNICODE_WCHAR_T defined. I had a quick look at the tag structure and saw that localName had the correct value. If namespace processing is turned off the correct names are reported. /Roland d95-rpe@nada.kth.se ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-12 10:42 Message: Logged In: YES user_id=290026 This bug was actually my fault, introduced when I fixed the NSTriplets functionality. I took out a section of code I thought was redundant. :-( My apologies, Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-10 15:57 Message: Logged In: YES user_id=290026 This problems looks as if it could be an old bug that has existed for a long time. It actually happens whenever multiple nested elements use the same prefix. Could anyone please test this with Expat 1.95.2? I have submitted a patch (# 567035). Please review and test. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-08 21:32 Message: Logged In: YES user_id=290026 I can confirm your observation, even for the case of XML_UNICODE_WCHAR_T not defined, and using "^" as namespace separator. Can anybody duplicate this on another platofrm? Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566334&group_id=10127 From noreply@sourceforge.net Wed Jun 12 08:44:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed Jun 12 07:44:05 2002 Subject: [ expat-Patches-566901 ] install (if building outside the sourcedir) fails Message-ID: Patches item #566901, was opened at 2002-06-10 17:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=566901&group_id=10127 Category: Build Control Group: None Status: Open Resolution: None Priority: 7 Submitted By: Gerrit Haase (siebenschlaefer) Assigned to: Greg Stein (gstein) Summary: install (if building outside the sourcedir) fails Initial Comment: 1. It is not possible to build outside the sourcedir. Starts with wrong paths and after fixing this I get problems because expat.h and the manfile were not found. e.g. error , please see below. 2. Calling autoconf gives this message: conftools/get-version.sh: not found /usr/bin/install -c lib/.libs/libexpat.dll.a /var/www/htdocs/cywgin/ex pat/test/expat-1.95.3/.inst/usr/lib/libexpat.dll.a dlpath=`bash 2>&1 -c '. lib/.libs/lib/libexpat.lai;echo $dlname'` dldir=/var/www/htdocs/cywgin/expat/test/expat- 1.95.3/.inst/usr/lib/`dirname $dlpath` dirname: too many arguments Try `dirname --help' for more information. make: *** [installlib] Error 1 Attached is the diff from my changes to Makefile.in to get it to install successfull outside the sourcedir. Gerrit -- =^..^= ---------------------------------------------------------------------- >Comment By: Gerrit Haase (siebenschlaefer) Date: 2002-06-12 16:43 Message: Logged In: YES user_id=76037 Hi David, you wrote: >Gerrit's patch almost works for me. However, I also had >to change > INCLUDES = -Ilib -I. >to > INCLUDES = -I$(srcdir)/lib -I. you are right. This is an oversight from me, since I have expat already installed in the standard locations I got no problems. This needs to be fixed in my latest package which I offered for inclusion to the Cygwin netrelease. >Moreover, I don't understand the need >for the docdir macro. There's no target that uses this, >AFAICT. Yes, also true, this is only used for internal (Cygwin) use, we install docs into /usr/doc/${package-name}, I wanted to create the docdir from the make run, but never used it. (docs here are including license information and the README included in the expat source dist.) I do this with my build script, no need to include it in the dist since expat doesn't install docs besides the manfile. Many thanks for your patch review;) Gerrit -- =^..^= ---------------------------------------------------------------------- Comment By: David Starks-Browning (davidsb) Date: 2002-06-12 16:06 Message: Logged In: YES user_id=561928 Yes, please do get "make" and "make install" working when building outside the source tree. I also need it, and not for Cygwin. :-) Gerrit's patch almost works for me. However, I also had to change INCLUDES = -Ilib -I. to INCLUDES = -I$(srcdir)/lib -I. Gerrit, if you didn't need this, then you probably compiled with whatever expat.h had been installed in the default location (or as augmented by CPPFLAGS). Moreover, I don't understand the need for the docdir macro. There's no target that uses this, AFAICT. For the record, I had reported similar problems with 1.95.1 in bug #406262, but had not tracked expat development since then. Thanks everyone! David ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=566901&group_id=10127 From noreply@sourceforge.net Wed Jun 12 08:45:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed Jun 12 07:45:06 2002 Subject: [ expat-Patches-566901 ] install (if building outside the sourcedir) fails Message-ID: Patches item #566901, was opened at 2002-06-10 17:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=566901&group_id=10127 Category: Build Control Group: None Status: Open Resolution: None Priority: 7 Submitted By: Gerrit Haase (siebenschlaefer) Assigned to: Greg Stein (gstein) Summary: install (if building outside the sourcedir) fails Initial Comment: 1. It is not possible to build outside the sourcedir. Starts with wrong paths and after fixing this I get problems because expat.h and the manfile were not found. e.g. error , please see below. 2. Calling autoconf gives this message: conftools/get-version.sh: not found /usr/bin/install -c lib/.libs/libexpat.dll.a /var/www/htdocs/cywgin/ex pat/test/expat-1.95.3/.inst/usr/lib/libexpat.dll.a dlpath=`bash 2>&1 -c '. lib/.libs/lib/libexpat.lai;echo $dlname'` dldir=/var/www/htdocs/cywgin/expat/test/expat- 1.95.3/.inst/usr/lib/`dirname $dlpath` dirname: too many arguments Try `dirname --help' for more information. make: *** [installlib] Error 1 Attached is the diff from my changes to Makefile.in to get it to install successfull outside the sourcedir. Gerrit -- =^..^= ---------------------------------------------------------------------- >Comment By: Gerrit Haase (siebenschlaefer) Date: 2002-06-12 16:44 Message: Logged In: YES user_id=76037 Hi David, you wrote: >Gerrit's patch almost works for me. However, I also had >to change > INCLUDES = -Ilib -I. >to > INCLUDES = -I$(srcdir)/lib -I. you are right. This is an oversight from me, since I have expat already installed in the standard locations I got no problems. This needs to be fixed in my latest package which I offered for inclusion to the Cygwin netrelease. >Moreover, I don't understand the need >for the docdir macro. There's no target that uses this, >AFAICT. Yes, also true, this is only used for internal (Cygwin) use, we install docs into /usr/doc/${package-name}, I wanted to create the docdir from the make run, but never used it. (docs here are including license information and the README included in the expat source dist.) I do this with my build script, no need to include it in the dist since expat doesn't install docs besides the manfile. Many thanks for your patch review;) Gerrit -- =^..^= ---------------------------------------------------------------------- Comment By: Gerrit Haase (siebenschlaefer) Date: 2002-06-12 16:43 Message: Logged In: YES user_id=76037 Hi David, you wrote: >Gerrit's patch almost works for me. However, I also had >to change > INCLUDES = -Ilib -I. >to > INCLUDES = -I$(srcdir)/lib -I. you are right. This is an oversight from me, since I have expat already installed in the standard locations I got no problems. This needs to be fixed in my latest package which I offered for inclusion to the Cygwin netrelease. >Moreover, I don't understand the need >for the docdir macro. There's no target that uses this, >AFAICT. Yes, also true, this is only used for internal (Cygwin) use, we install docs into /usr/doc/${package-name}, I wanted to create the docdir from the make run, but never used it. (docs here are including license information and the README included in the expat source dist.) I do this with my build script, no need to include it in the dist since expat doesn't install docs besides the manfile. Many thanks for your patch review;) Gerrit -- =^..^= ---------------------------------------------------------------------- Comment By: David Starks-Browning (davidsb) Date: 2002-06-12 16:06 Message: Logged In: YES user_id=561928 Yes, please do get "make" and "make install" working when building outside the source tree. I also need it, and not for Cygwin. :-) Gerrit's patch almost works for me. However, I also had to change INCLUDES = -Ilib -I. to INCLUDES = -I$(srcdir)/lib -I. Gerrit, if you didn't need this, then you probably compiled with whatever expat.h had been installed in the default location (or as augmented by CPPFLAGS). Moreover, I don't understand the need for the docdir macro. There's no target that uses this, AFAICT. For the record, I had reported similar problems with 1.95.1 in bug #406262, but had not tracked expat development since then. Thanks everyone! David ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=566901&group_id=10127 From noreply@sourceforge.net Wed Jun 12 13:52:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed Jun 12 12:52:03 2002 Subject: [ expat-Patches-565510 ] reading uninitialized variable Message-ID: Patches item #565510, was opened at 2002-06-06 16:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=565510&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: David Somers (moundsmere) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: reading uninitialized variable Initial Comment: Somewhere within xmlparse.c there is the snippet: ... for (;;) { const char *next; int tok = XmlPrologTok(encoding, s, end, &next); eventEndPtr = next; switch (tok) { ... (Somewhere being line 3600 in expat-1.95.3.tar.gz, or 3618 according to kwaclaw). Anyhow, my debugger warns that in some cases eventEndPtr is being assigned to an uninitialized ptr... to stop this happening, change: const char *next; to const char *next = NULL; Cheers, David. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-12 15:51 Message: Logged In: YES user_id=3066 Closing as accepted since Karl's already checked in the fix. ;-) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-06 16:51 Message: Logged In: YES user_id=290026 Assigned to Fred, since he is our NULL specialist. ;-) Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=565510&group_id=10127 From noreply@sourceforge.net Wed Jun 12 13:54:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed Jun 12 12:54:06 2002 Subject: [ expat-Patches-566827 ] expat-1.95.3 does no with .dll on cygwin Message-ID: Patches item #566827, was opened at 2002-06-10 09:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=566827&group_id=10127 Category: Build Control Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Haase (siebenschlaefer) >Assigned to: Gerrit Haase (siebenschlaefer) Summary: expat-1.95.3 does no with .dll on cygwin Initial Comment: libtool-1.4 fails to build a shared version on Cygwin. I've not tested it, but it should work with libtool-1.4.2 which is the latest release of libtool. Gerrit -- =^..^= ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-12 15:53 Message: Logged In: YES user_id=3066 Gerrit, this is yours now! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=566827&group_id=10127 From noreply@sourceforge.net Wed Jun 12 13:55:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed Jun 12 12:55:08 2002 Subject: [ expat-Patches-559910 ] SkippedEntityHandler added Message-ID: Patches item #559910, was opened at 2002-05-23 21:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=559910&group_id=10127 Category: None Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) Summary: SkippedEntityHandler added Initial Comment: This patch is an implementation of bug/feature request # 552297. It implements the simplified version of the original proposal. The skippedEntityHandler is called in two situations: 1) An entity reference is encountered for which no declaration has been read *and* this is not an error. 2) An internal entity reference is read, but not expanded, because XML_SetDefaultHandler has been called. The attached Diff file is based on expat.h rev. 1.22 and xmlparse.c rev. 1.41. Karl ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-12 15:54 Message: Logged In: YES user_id=3066 Closed since this is already checked in. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-07 07:24 Message: Logged In: YES user_id=3066 Let's get this cecked in! ;-) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-24 15:18 Message: Logged In: YES user_id=290026 Added the full files for those non-Unix people (like me) that are not used to diff and patch Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=559910&group_id=10127 From noreply@sourceforge.net Wed Jun 12 14:19:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed Jun 12 13:19:02 2002 Subject: [ expat-Patches-567035 ] Patch for bug # 566334 Message-ID: Patches item #567035, was opened at 2002-06-10 15:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=567035&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 8 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) Summary: Patch for bug # 566334 Initial Comment: This patch tries to fix the problem with wrong names reported in the endElement handler, when namespace processing is on. The reason for the problem is that Expat passes the buffer for the namespace URI to the handler, copying the element's local name (and prefix) to the end of the buffer, right after the URI. This saves re-copying the URI. However, if multiple nested elements use the same namespace URI, the names of the top elements get overwritten, since only one buffer is used, and therefore the endElement handler will only report the name of the last, most deeply nested element . I have tried to fix this by re-copying localPart and prefix before the endelement handler is called. Another approach could have been to use separate buffers (e.g. tag->buf), but this would have meant copying the whole URI for each element in the namespace, so I think the solution I tried is at least as efficient. This type of solution was already tried once by the user "maki", but only for NSTriplets reporting, not for NS processing in general. The patch applies to xmlparse.c rev. 1.44. Please test thoroughly - this patch needs to be done right. Karl ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-12 16:18 Message: Logged In: YES user_id=3066 Your description of the problem and proposed solution sounds good, and a quick test of your patch using xmlwf works. I'll see if I can knock out a quick test case for this for the regression suite. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=567035&group_id=10127 From noreply@sourceforge.net Wed Jun 12 14:23:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed Jun 12 13:23:08 2002 Subject: [ expat-Patches-567035 ] Patch for bug # 566334 Message-ID: Patches item #567035, was opened at 2002-06-10 15:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=567035&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 8 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) Summary: Patch for bug # 566334 Initial Comment: This patch tries to fix the problem with wrong names reported in the endElement handler, when namespace processing is on. The reason for the problem is that Expat passes the buffer for the namespace URI to the handler, copying the element's local name (and prefix) to the end of the buffer, right after the URI. This saves re-copying the URI. However, if multiple nested elements use the same namespace URI, the names of the top elements get overwritten, since only one buffer is used, and therefore the endElement handler will only report the name of the last, most deeply nested element . I have tried to fix this by re-copying localPart and prefix before the endelement handler is called. Another approach could have been to use separate buffers (e.g. tag->buf), but this would have meant copying the whole URI for each element in the namespace, so I think the solution I tried is at least as efficient. This type of solution was already tried once by the user "maki", but only for NSTriplets reporting, not for NS processing in general. The patch applies to xmlparse.c rev. 1.44. Please test thoroughly - this patch needs to be done right. Karl ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-12 16:22 Message: Logged In: YES user_id=290026 If you go back to 1.95.2, you will see that a similar approach was used, except for the NSTriplets part, of course. Btw, if you find my coding inefficient or simply sub-optimal, please feel free to correct. Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-12 16:18 Message: Logged In: YES user_id=3066 Your description of the problem and proposed solution sounds good, and a quick test of your patch using xmlwf works. I'll see if I can knock out a quick test case for this for the regression suite. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=567035&group_id=10127 From noreply@sourceforge.net Wed Jun 12 14:49:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed Jun 12 13:49:07 2002 Subject: [ expat-Patches-567035 ] Patch for bug # 566334 Message-ID: Patches item #567035, was opened at 2002-06-10 15:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=567035&group_id=10127 Category: None Group: None Status: Open >Resolution: Accepted Priority: 8 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) Summary: Patch for bug # 566334 Initial Comment: This patch tries to fix the problem with wrong names reported in the endElement handler, when namespace processing is on. The reason for the problem is that Expat passes the buffer for the namespace URI to the handler, copying the element's local name (and prefix) to the end of the buffer, right after the URI. This saves re-copying the URI. However, if multiple nested elements use the same namespace URI, the names of the top elements get overwritten, since only one buffer is used, and therefore the endElement handler will only report the name of the last, most deeply nested element . I have tried to fix this by re-copying localPart and prefix before the endelement handler is called. Another approach could have been to use separate buffers (e.g. tag->buf), but this would have meant copying the whole URI for each element in the namespace, so I think the solution I tried is at least as efficient. This type of solution was already tried once by the user "maki", but only for NSTriplets reporting, not for NS processing in general. The patch applies to xmlparse.c rev. 1.44. Please test thoroughly - this patch needs to be done right. Karl ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-12 16:48 Message: Logged In: YES user_id=3066 I've attached a patch to tests/runtests.c that adds tests for this, both with and without NS triplets enabled. I think this patch should be checked in and closed (along with the bug). If there are further problems, additional reports can be filed. (This is the advantage of "release early, release often", which we should do whenever possible.) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-12 16:22 Message: Logged In: YES user_id=290026 If you go back to 1.95.2, you will see that a similar approach was used, except for the NSTriplets part, of course. Btw, if you find my coding inefficient or simply sub-optimal, please feel free to correct. Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-12 16:18 Message: Logged In: YES user_id=3066 Your description of the problem and proposed solution sounds good, and a quick test of your patch using xmlwf works. I'll see if I can knock out a quick test case for this for the regression suite. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=567035&group_id=10127 From noreply@sourceforge.net Wed Jun 12 20:19:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed Jun 12 19:19:02 2002 Subject: [ expat-Bugs-441449 ] problems with parsing external entities Message-ID: Bugs item #441449, was opened at 2001-07-15 11:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=441449&group_id=10127 Category: None Group: None >Status: Pending 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: Fred L. Drake, Jr. (fdrake) Date: 2002-06-12 22:18 Message: Logged In: YES user_id=3066 Rafael Sevilla: May we have permission to incorporate the test program and sample XML directly into the Expat test suite? This will mean that every copy of (future versions of) Expat will include these files. Prompt response will help us get this fixed and released quickly. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-11 09:49 Message: Logged In: YES user_id=290026 I agree - it seems for external entities, the processor must be set to externalEntityContentProcessor. I have submitted patch # 567400. Please review and test. I hope it doesn't break anything else. Karl ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-04-25 22: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 07: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 15: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 03: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 Wed Jun 12 20:21:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed Jun 12 19:21:02 2002 Subject: [ expat-Bugs-566095 ] php make fails @ libexpat.la on OSX Message-ID: Bugs item #566095, was opened at 2002-06-08 00:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566095&group_id=10127 Category: Build control Group: Third-party Bug >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: php make fails @ libexpat.la on OSX Initial Comment: hi all, a build of php-latest (php4-200206071800) on OSX Server 10.1.4 with: ./configure --enable-shared --enable-static --prefix=/usr/local/php4 --with-layout=PHP --with-apxs2=/usr/local/apache2/sbin/apxs --with-config-file-path=/private/etc/php4/ --mandir=/usr/local/man --localstatedir=/private/var/php4 --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --with-expat-dir=/usr/local/expat --with-mysql=/usr/local/mysql --with-openssl --with-imap-ssl --with-mcrypt --with-mhash=/usr/local --with-kerberos --with-imap=/usr/local/imap --enable-mailparse --enable-magic-quotes --enable-ftp --enable-force-cgi-redirect --enable-discard-path --enable-inline-optimization --with-pear --with-zlib --enable-calendar --disable-safe-mode --with-tsrm-pthreads fails with: .o Zend/zend_qsort.o Zend/zend_multibyte.o Zend/zend_execute.o sapi/apache2filter/sapi_apache2.o sapi/apache2filter/apache_config.o sapi/apache2filter/php_functions.o main/internal_functions.o -lcrypto -lssl -lc-client -lexpat -lmysqlclient -lmhash -lmcrypt -lltdl -lz -lssl -lcrypto -lbind -lm -ldl -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -ldl -o libs/libphp4.bundle && cp libs/libphp4.bundle libs/libphp4.so /usr/bin/ld: warning -L: directory name (/lib) does not exist /usr/bin/ld: /usr/local/expat/lib/libexpat.la bad magic number (not a Mach-O file) make: *** [libs/libphp4.bundle] Error 1 expat build went fine on OSX, with: cd expat-1.95.3; ./configure --prefix=/usr/local/expat --mandir=/usr/local/man --x-include=/usr to be used by a number of other progrs successfully ...... any thoughts/suggestions on either would be much appreciated! fyi, details of my environment are doc'd on my web-page, below ..... thanks! richard -------------------------------------- R Blake blakers mac.com http://homepage.mac.com/blakers -------------------------------------- ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-12 22:21 Message: Logged In: YES user_id=3066 Closed; this is a duplicate of SF bug #566088. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566095&group_id=10127 From noreply@sourceforge.net Wed Jun 12 20:24:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed Jun 12 19:24:05 2002 Subject: [ expat-Bugs-564342 ] reading uninitialized variable Message-ID: Bugs item #564342, was opened at 2002-06-04 08:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=564342&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: David Somers (moundsmere) >Assigned to: Karl Waclawek (kwaclaw) Summary: reading uninitialized variable Initial Comment: in xmlparse.c, line 3600 eventEndPtr = next; my debugger complains that this is causing an attempt to read unitialized data. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-12 22:23 Message: Logged In: YES user_id=3066 Closing; patch #565510 already checked in. ---------------------------------------------------------------------- Comment By: David Somers (moundsmere) Date: 2002-06-06 16:19 Message: Logged In: YES user_id=36164 Patch submitted. David. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-06 16:02 Message: Logged In: YES user_id=290026 I propose you submit a patch! :-) Is there anything special about the situation when this happens (first loop iteration, ...)? Karl ---------------------------------------------------------------------- Comment By: David Somers (moundsmere) Date: 2002-06-06 15:56 Message: Logged In: YES user_id=36164 Hi Karl, You found the place I mean. I'm referring to the file as I found it in expat-1.95.3.tar.gz, so I guess the line numbers have slipped somewhere. Yep, the debugger complains because its coming across eventEndPtr = next for a case when next hasn't been assigned (so it doesn't like eventEndPtr being set to garbage). OK. It doesn't cause an actual error, per se, but its the *only* thing that my debugger has found to complain about in Expat, so it would be great to quash it (which is very easy: just do const char *next = NULL; two lines before) David ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-06 15:29 Message: Logged In: YES user_id=290026 OK, there is only one such line, but I have it on line 3618, in xmlparse.c rev. 1.41. Are you sure you have 1.95.3? Anyway, the code there looks like: ... for (;;) { const char *next; int tok = XmlPrologTok(encoding, s, end, &next); eventEndPtr = next; switch (tok) { ... It looks as if XMLPrologTok initilaizes next, but since this is dynamic behaviour (XMLPrologTok is actually a function pointer), it cannot be assumed for sure that it is happening. Maybe that is what the debugger is complaining about? Does this cause an actual error? Karl ---------------------------------------------------------------------- Comment By: David Somers (moundsmere) Date: 2002-06-06 15:17 Message: Logged In: YES user_id=36164 Like I said in the original message: line 3600 (eventEndPtr = next) Cheers, David ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-06 15:13 Message: Logged In: YES user_id=290026 On which line? ---------------------------------------------------------------------- Comment By: David Somers (moundsmere) Date: 2002-06-06 14:52 Message: Logged In: YES user_id=36164 Yes, it happends with 1.95.3 too. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-06 14:43 Message: Logged In: YES user_id=290026 Does this happen with version 1.95.3 too? Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=564342&group_id=10127 From noreply@sourceforge.net Wed Jun 12 20:34:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed Jun 12 19:34:03 2002 Subject: [ expat-Bugs-557739 ] make fails on IRIX 6.2 Message-ID: Bugs item #557739, was opened at 2002-05-18 15:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=557739&group_id=10127 Category: Build control Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: make fails on IRIX 6.2 Initial Comment: # make cd lib && make make[1]: Entering directory `/usr/people/michaelg/expat-1.95.2/lib' /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H - DPACKAGE='"expat"' -DVERSION='"expat_1.95.2"' -I. -I. - I.. -O2 -Wall -Wmissing-prototypes -Wstrict- prototypes -fexceptions -c xmlparse.c mkdir .libs gcc -DHAVE_CONFIG_H -DPACKAGE=\expat\ - DVERSION=\expat_1.95.2\ -I. -I. -I.. -O2 -Wall - Wmissing-prototypes -Wstrict-prototypes -fexceptions - c xmlparse.c -DPIC -o .libs/xmlparse.lo cc1: Invalid option `-fexceptions' In file included from xmlparse.c:26: /usr/include/string.h:57: warning: conflicting types for built-in function `memcpy' /usr/include/string.h:58: parse error before `;' /usr/include/string.h:58: warning: data definition has no type or storage class /usr/include/string.h:59: warning: conflicting types for built-in function `strcpy' /usr/include/string.h:64: warning: conflicting types for built-in function `memcmp' /usr/include/string.h:65: warning: conflicting types for built-in function `strcmp' xmlparse.c: In function `XML_GetBuffer': xmlparse.c:1178: `punting' undeclared (first use this function) xmlparse.c:1178: (Each undeclared identifier is reported only once xmlparse.c:1178: for each function it appears in.) xmlparse.c:1178: parse error before `on' make[1]: *** [xmlparse.lo] Error 1 make[1]: Leaving directory `/usr/people/michaelg/expat- 1.95.2/lib' make: *** [lib] Error 2 ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-12 22:33 Message: Logged In: YES user_id=3066 Reassigning to myself since I have (temporary) access to an IRIX box. I could not reproduce this on IRIX 6.6; is it possible to test Expat 1.95.3 on your system? I suspect the problem has already been fixed, but would appreciate confirmation. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=557739&group_id=10127 From noreply@sourceforge.net Wed Jun 12 20:35:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed Jun 12 19:35:01 2002 Subject: [ expat-Bugs-557739 ] make fails on IRIX 6.2 Message-ID: Bugs item #557739, was opened at 2002-05-18 15:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=557739&group_id=10127 Category: Build control Group: None >Status: Pending Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: make fails on IRIX 6.2 Initial Comment: # make cd lib && make make[1]: Entering directory `/usr/people/michaelg/expat-1.95.2/lib' /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H - DPACKAGE='"expat"' -DVERSION='"expat_1.95.2"' -I. -I. - I.. -O2 -Wall -Wmissing-prototypes -Wstrict- prototypes -fexceptions -c xmlparse.c mkdir .libs gcc -DHAVE_CONFIG_H -DPACKAGE=\expat\ - DVERSION=\expat_1.95.2\ -I. -I. -I.. -O2 -Wall - Wmissing-prototypes -Wstrict-prototypes -fexceptions - c xmlparse.c -DPIC -o .libs/xmlparse.lo cc1: Invalid option `-fexceptions' In file included from xmlparse.c:26: /usr/include/string.h:57: warning: conflicting types for built-in function `memcpy' /usr/include/string.h:58: parse error before `;' /usr/include/string.h:58: warning: data definition has no type or storage class /usr/include/string.h:59: warning: conflicting types for built-in function `strcpy' /usr/include/string.h:64: warning: conflicting types for built-in function `memcmp' /usr/include/string.h:65: warning: conflicting types for built-in function `strcmp' xmlparse.c: In function `XML_GetBuffer': xmlparse.c:1178: `punting' undeclared (first use this function) xmlparse.c:1178: (Each undeclared identifier is reported only once xmlparse.c:1178: for each function it appears in.) xmlparse.c:1178: parse error before `on' make[1]: *** [xmlparse.lo] Error 1 make[1]: Leaving directory `/usr/people/michaelg/expat- 1.95.2/lib' make: *** [lib] Error 2 ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-12 22:33 Message: Logged In: YES user_id=3066 Reassigning to myself since I have (temporary) access to an IRIX box. I could not reproduce this on IRIX 6.6; is it possible to test Expat 1.95.3 on your system? I suspect the problem has already been fixed, but would appreciate confirmation. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=557739&group_id=10127 From noreply@sourceforge.net Wed Jun 12 20:53:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed Jun 12 19:53:03 2002 Subject: [ expat-Bugs-563184 ] warnings for close/read in xmlfile.c Message-ID: Bugs item #563184, was opened at 2002-05-31 23:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=563184&group_id=10127 Category: Build control Group: Platform Specific >Status: Closed >Resolution: Fixed Priority: 2 Submitted By: Patrick McCormick (patrickmc) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: warnings for close/read in xmlfile.c Initial Comment: On Solaris 7 with tip of tree, the build throws warnings: gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict- prototypes -fexceptions -Ilib -I. -o xmlwf/xmlfile.o -c xmlwf/xmlfile.c xmlwf/xmlfile.c: In function `processStream': xmlwf/xmlfile.c:155: warning: implicit declaration of function `close' xmlwf/xmlfile.c:160: warning: implicit declaration of function `read' This is because unistd.h isn't included. I see that in xmlfile.c it will be included if _POSIX_SOURCE is defined, but I'm not sure what that means or if the config should be defining that. This is really low priority, and the only warning I see when building expat. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-12 22:52 Message: Logged In: YES user_id=3066 Fixed in xmlwf/xmlfile.c revision 1.10. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-03 13:25 Message: Logged In: YES user_id=3066 We're avoiding code changes before release; this will wait for Expat 1.95.4. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=563184&group_id=10127 From noreply@sourceforge.net Wed Jun 12 21:07:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed Jun 12 20:07:03 2002 Subject: [ expat-Bugs-422239 ] Bug in XmlUpdatePosition() Message-ID: Bugs item #422239, was opened at 2001-05-08 05:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=422239&group_id=10127 Category: None Group: None >Status: Pending >Resolution: Works For Me Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Bug in XmlUpdatePosition() Initial Comment: If I call XML_GetCurrentLineNumber() at the end of a document, it appears to double count the lines. Calling XML_GetCurrentLineNumber() on every end element event seems to solve the problem. I have no explanation for this, other than supposing there may be a bug in the call to XmlUpdatePosition(), from XML_Parse(). ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-12 23:06 Message: Logged In: YES user_id=3066 Do you still see this in Expat 1.95.3? Does this only occur on long documents? Any other special considerations? I am not able to reproduce this using a short input document: If anyone can provide a failing sample document, please attach it to this bug report, otherwise I'll close it after a short waiting period (say, 2 weeks). I've attached a patch to tests/runtests.c that shows the test I wrote. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-25 17:00 Message: Logged In: YES user_id=3066 Removing the assignment to Clark, since he does not seem to be available, and this doesn't appear to be an XML::Parser specific bug. I need to generate a test case for this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=422239&group_id=10127 From noreply@sourceforge.net Wed Jun 12 21:12:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed Jun 12 20:12:06 2002 Subject: [ expat-Bugs-552297 ] Request for skippedEntity handler Message-ID: Bugs item #552297, was opened at 2002-05-04 13:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=552297&group_id=10127 Category: None Group: Feature Request >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) Summary: Request for skippedEntity handler Initial Comment: It would be very useful if Expat reported skipped entities, like in the SAX2 specification. I have identified the following situations for that: B) External Entities are reported as skipped: - if no external entity ref handler is set - if the entity ref handler returns a special value (e.g. we can define 2 as meaning: "skip this one") B) Internal Entities are reported as skipped: - SetDefaultHandler was called (which turns off expansion of internal general entities) C) Any entity reference is reported as skipped - if no declaration is found & that is not an error (otherwise return a well-formedness error) Karl ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-12 23:11 Message: Logged In: YES user_id=3066 Closed since this has already been checked in. If it needs tweaking, thats either a bug report or a request for more performance or whatever (a feature request). Since this doesn't seem like a performance-relevant feature, I'm not going to expect the later. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-08 20:09 Message: Logged In: YES user_id=290026 Rolf, stop twisting my arm - I checked the patch in. :-) It may be necessary to make changes to it when we add the InternalEntityRefHandler. Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-06-08 13:20 Message: Logged In: YES user_id=13222 As longer, as I think about it, I more and more believe, it was a mistake, to change the reporting of undeclared entities along the line as described in bug 544679 without also adding a skippedEntitiy handler. (I already mentioned my objection in the discussion of 544679, but maybe I wasn't loud enough.) Please consider adding the skippedEntity handler, as described by Karl. Without a skippedEntity handler, it isn't possible to detect a misstyped internal entitiy, if your document has a external subset or external parameter entities, even if you parse all external entities. This may break existing applications (well, it breaks at least one of mine), and should have been mentioned in the announcement (even if the new behaviour is more correct, according to the _letters_ of the XML rec.) And I think, it was a bad idea, to fix 544679 without adding a skippedEntity handler at the same time. rolf ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-23 21:09 Message: Logged In: YES user_id=290026 Have a look at patch # 559910, where the latest, simplified proposal is implemented. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-22 15:51 Message: Logged In: YES user_id=290026 I forgot case B) from the initial request. This would, of course, still be valid, but would also not require more than the simple callback interface I proposed. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-22 09:55 Message: Logged In: YES user_id=290026 Thinking some more about it, I believe that the signature I proposed is overkill, and we can get away with his: typedef void (*XML_SkippedEntityHandler) (void *userData, const XML_Char *entityName, int is_parameter_entity); Reasons: In the old proposal there were two cases when PublicId and SystemId would have been reported: 1) The application decided to skip the entity and passed a return value of 2 from the ExternalEntityRefHandler 2) No ExternalEntityRefHandler was installed I think both of them don't need a skippedEntityHandler, because For 1) It is of no particular usefulness if the application code in the ExternalEntityRefHandler delegates the skip-notification back to Expat. This can be done directly from the handler at least as easily and efficiently, and Expat itself does not need this information, since the very fact of nothing being parsed is all that is important to it. For 2) If no ExternalEntityRefHandler is installed, then why install a skippedEntityHandler? They would have essentially the same signature, and in the end that would mean the same as in 1) - telling Expat we want to skip the entity. Again, that can already be easily achieved with the exisiting API. So, which events then remain that would require a skippedEntityHandler? Only when entity refs are encountered for which no declaration was read, *and* when this is not an error. Now, as far as Fred's suggestion of combining this with some InternalEntityRefHandler, is concerned: In that case we should also report the entity value. Would we not be mixing two different problems here? Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-16 19:44 Message: Logged In: YES user_id=3066 This feature description and proposed callback interface sounds good to me. We might want to think about how such a handler would interact with (or be combined with) a handler so that defined general entities (including "standard" ones like < and friends) can be reported, for applications that need to produce output with minimal changes. (This is commonly needed if the output is going to land in front of a human rather than another processing tool.) Let's target this for 1.95.4. Assigning to Karl since he's indicated specific interest. ;-) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-09 09:35 Message: Logged In: YES user_id=290026 I propose the following signature for the handler: enum XML_Skip_Reason { XML_SKIP_UNDEFINED, XML_SKIP_NOHANDLER, XML_SKIP_REQUESTED }; typedef void (*XML_SkippedEntityHandler) (void *userData, const XML_Char *entityName, int is_parameter_entity, const XML_Char *systemId, const XML_Char *publicId, enum XML_Skip_Reason skipReason); where the values of skipReason have the following meanings: - XML_SKIP_UNDEFINED: entity was skipped because no declaration was found, and this was not an error - XML_SKIP_NOHANDLER: entity was skipped because there was no ExternalEntityRefHandler installed - XML_SKIP_REQUESTED: the ExternalEntityRefHandler returned a value of 2, which means the handler requested the entity to be skipped I hope this makes sense. Comments welcome! Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=552297&group_id=10127 From noreply@sourceforge.net Thu Jun 13 06:55:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Jun 13 05:55:06 2002 Subject: [ expat-Patches-567035 ] Patch for bug # 566334 Message-ID: Patches item #567035, was opened at 2002-06-10 15:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=567035&group_id=10127 Category: None Group: None >Status: Closed Resolution: Accepted Priority: 8 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) Summary: Patch for bug # 566334 Initial Comment: This patch tries to fix the problem with wrong names reported in the endElement handler, when namespace processing is on. The reason for the problem is that Expat passes the buffer for the namespace URI to the handler, copying the element's local name (and prefix) to the end of the buffer, right after the URI. This saves re-copying the URI. However, if multiple nested elements use the same namespace URI, the names of the top elements get overwritten, since only one buffer is used, and therefore the endElement handler will only report the name of the last, most deeply nested element . I have tried to fix this by re-copying localPart and prefix before the endelement handler is called. Another approach could have been to use separate buffers (e.g. tag->buf), but this would have meant copying the whole URI for each element in the namespace, so I think the solution I tried is at least as efficient. This type of solution was already tried once by the user "maki", but only for NSTriplets reporting, not for NS processing in general. The patch applies to xmlparse.c rev. 1.44. Please test thoroughly - this patch needs to be done right. Karl ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-13 08:54 Message: Logged In: YES user_id=290026 Patch checked in. Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-12 16:48 Message: Logged In: YES user_id=3066 I've attached a patch to tests/runtests.c that adds tests for this, both with and without NS triplets enabled. I think this patch should be checked in and closed (along with the bug). If there are further problems, additional reports can be filed. (This is the advantage of "release early, release often", which we should do whenever possible.) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-12 16:22 Message: Logged In: YES user_id=290026 If you go back to 1.95.2, you will see that a similar approach was used, except for the NSTriplets part, of course. Btw, if you find my coding inefficient or simply sub-optimal, please feel free to correct. Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-12 16:18 Message: Logged In: YES user_id=3066 Your description of the problem and proposed solution sounds good, and a quick test of your patch using xmlwf works. I'll see if I can knock out a quick test case for this for the regression suite. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=567035&group_id=10127 From noreply@sourceforge.net Thu Jun 13 06:57:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Jun 13 05:57:01 2002 Subject: [ expat-Patches-567400 ] Patch for cdataSectionProcessor Message-ID: Patches item #567400, was opened at 2002-06-11 09:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=567400&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) Summary: Patch for cdataSectionProcessor Initial Comment: This patch applies to bug # 441449. It seems that doContent() should be called with startTagLevel = 0 for the document entity, and startTagLevel = 1 for external entities. This is how contentProcessor() and externalEntityContentProcessor() are doing it. So, I propose to change cdataSectionProcessor like this: ... if (start) { if (parentParser) { processor = externalEntityContentProcessor; return externalEntityContentProcessor(parser, start, end, endPtr); } else { processor = contentProcessor; return contentProcessor(parser, start, end, endPtr); } } ... This seems to fix at least the bug demo example supplied with bug # 441449. The patch requires that parentParser is always set for external entities, therefore it will only work on newer versions of Expat (1.95.3+). I also found a small bug that needs fixing: In function ExternalEntityparserCreate(), the assignment to parentParser should be pulled out of the conditional section, like this: ... parentParser = oldParser; #ifdef XML_DTD paramEntityParsing = oldParamEntityParsing; prologState.inEntityValue = oldInEntityValue; // parentParser = oldParser; -> move out of here if (context) { #endif /* XML_DTD */ ... Karl ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-13 08:56 Message: Logged In: YES user_id=290026 Patch checked in. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=567400&group_id=10127 From noreply@sourceforge.net Thu Jun 13 06:58:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Jun 13 05:58:02 2002 Subject: [ expat-Bugs-566334 ] Default namespace => wrong element names Message-ID: Bugs item #566334, was opened at 2002-06-08 21:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566334&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 8 Submitted By: Nobody/Anonymous (nobody) Assigned to: Karl Waclawek (kwaclaw) Summary: Default namespace => wrong element names Initial Comment: When a document uses a default namespace and expat is set up to be aware of namespaces the tag names reported in the endElementHandler become incorrect. It seems that the endElementHandler always reports the same thing that was last reported in the startElementHandler. With a document as follows and with the namespace separator char set to '@' Test the start and end element handlers of expat will report start: http://w3.org/SMIL20/@smil start: http://w3.org/SMIL20/@head start: http://w3.org/SMIL20/@title end: http://w3.org/SMIL20/@title end: http://w3.org/SMIL20/@title <-- should be head start: http://w3.org/SMIL20/@body end: http://w3.org/SMIL20/@body end: http://w3.org/SMIL20/@body <-- should be smil This has been observed in the win32 version of 1.95.3 with XML_UNICODE_WCHAR_T defined. I had a quick look at the tag structure and saw that localName had the correct value. If namespace processing is turned off the correct names are reported. /Roland d95-rpe@nada.kth.se ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-13 08:57 Message: Logged In: YES user_id=290026 Patch # 567035 was checked in. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-12 10:42 Message: Logged In: YES user_id=290026 This bug was actually my fault, introduced when I fixed the NSTriplets functionality. I took out a section of code I thought was redundant. :-( My apologies, Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-10 15:57 Message: Logged In: YES user_id=290026 This problems looks as if it could be an old bug that has existed for a long time. It actually happens whenever multiple nested elements use the same prefix. Could anyone please test this with Expat 1.95.2? I have submitted a patch (# 567035). Please review and test. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-08 21:32 Message: Logged In: YES user_id=290026 I can confirm your observation, even for the case of XML_UNICODE_WCHAR_T not defined, and using "^" as namespace separator. Can anybody duplicate this on another platofrm? Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=566334&group_id=10127 From noreply@sourceforge.net Thu Jun 13 07:03:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Jun 13 06:03:02 2002 Subject: [ expat-Bugs-441449 ] problems with parsing external entities Message-ID: Bugs item #441449, was opened at 2001-07-15 11:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=441449&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Works For Me 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: Karl Waclawek (kwaclaw) Date: 2002-06-13 09:02 Message: Logged In: YES user_id=290026 Patch # 567400 checked in. Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-12 22:18 Message: Logged In: YES user_id=3066 Rafael Sevilla: May we have permission to incorporate the test program and sample XML directly into the Expat test suite? This will mean that every copy of (future versions of) Expat will include these files. Prompt response will help us get this fixed and released quickly. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-11 09:49 Message: Logged In: YES user_id=290026 I agree - it seems for external entities, the processor must be set to externalEntityContentProcessor. I have submitted patch # 567400. Please review and test. I hope it doesn't break anything else. Karl ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-04-25 22: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 07: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 15: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 03: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 Jun 13 08:39:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Jun 13 07:39:01 2002 Subject: [ expat-Bugs-422239 ] Bug in XmlUpdatePosition() Message-ID: Bugs item #422239, was opened at 2001-05-08 05:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=422239&group_id=10127 Category: None Group: None >Status: Open Resolution: Works For Me Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Bug in XmlUpdatePosition() Initial Comment: If I call XML_GetCurrentLineNumber() at the end of a document, it appears to double count the lines. Calling XML_GetCurrentLineNumber() on every end element event seems to solve the problem. I have no explanation for this, other than supposing there may be a bug in the call to XmlUpdatePosition(), from XML_Parse(). ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-13 10:38 Message: Logged In: YES user_id=290026 Since *nobody* submitted this, *nobody* will read this. Maybe post to the discussion list? Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-12 23:06 Message: Logged In: YES user_id=3066 Do you still see this in Expat 1.95.3? Does this only occur on long documents? Any other special considerations? I am not able to reproduce this using a short input document: If anyone can provide a failing sample document, please attach it to this bug report, otherwise I'll close it after a short waiting period (say, 2 weeks). I've attached a patch to tests/runtests.c that shows the test I wrote. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-25 17:00 Message: Logged In: YES user_id=3066 Removing the assignment to Clark, since he does not seem to be available, and this doesn't appear to be an XML::Parser specific bug. I need to generate a test case for this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=422239&group_id=10127 From noreply@sourceforge.net Thu Jun 13 08:48:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Jun 13 07:48:01 2002 Subject: [ expat-Bugs-422239 ] Bug in XmlUpdatePosition() Message-ID: Bugs item #422239, was opened at 2001-05-08 05:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=422239&group_id=10127 Category: None Group: None Status: Open Resolution: Works For Me Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Bug in XmlUpdatePosition() Initial Comment: If I call XML_GetCurrentLineNumber() at the end of a document, it appears to double count the lines. Calling XML_GetCurrentLineNumber() on every end element event seems to solve the problem. I have no explanation for this, other than supposing there may be a bug in the call to XmlUpdatePosition(), from XML_Parse(). ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-13 10:47 Message: Logged In: YES user_id=3066 Karl: Not necessarily. The submitter *may* have provided an email address or have requested "monitoring" of the issue, which are not visible in the interface. (I consider this a bug in the SF user interface.) Bringing it up on expat-discuss is not a bad idea. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-13 10:38 Message: Logged In: YES user_id=290026 Since *nobody* submitted this, *nobody* will read this. Maybe post to the discussion list? Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-12 23:06 Message: Logged In: YES user_id=3066 Do you still see this in Expat 1.95.3? Does this only occur on long documents? Any other special considerations? I am not able to reproduce this using a short input document: If anyone can provide a failing sample document, please attach it to this bug report, otherwise I'll close it after a short waiting period (say, 2 weeks). I've attached a patch to tests/runtests.c that shows the test I wrote. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-25 17:00 Message: Logged In: YES user_id=3066 Removing the assignment to Clark, since he does not seem to be available, and this doesn't appear to be an XML::Parser specific bug. I need to generate a test case for this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=422239&group_id=10127 From noreply@sourceforge.net Fri Jun 14 03:03:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Jun 14 02:03:01 2002 Subject: [ expat-Bugs-568904 ] expat sends wrong data to EasySoap ? Message-ID: Bugs item #568904, was opened at 2002-06-14 02:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=568904&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: expat sends wrong data to EasySoap ? Initial Comment: I'm not sure if the following is an expat 1.95.3 bug or an EasySoap 0.6 one. I had to quick-patch it. test This (kind of) structure is parsed by expat for EasySoap. EasySoap knows that the end-tag has been reached because a parameter (uri) given by expat looks like "http://XXX#Envelope" and it's a closing tag. The uri given by expat is correct for the Envelope opening tag "http://XXX#Envelope", correct for the Body opening tag "http://XXX#Body", correct for the Body closing tag "http://XXX#Body" but wrong for the Envelope closing tag "http://XXX#Body". I've traced the code and it's because the tag->uri points to the same address for all the tags. It seems that something is wrong with the "binding" structure in the tag. Here is the diff output, for xmlparse.c 907a908,911 > > if(p->name.str!=NULL) > free(p->name.str) > 2242c2246,2249 < tagNamePtr->str = binding->uri; --- > > // tagNamePtr->str = binding->uri; > tagNamePtr->str = strdup(binding->uri); > Well, since my problem was that raw link, and I didn't had time to know if it was the right thing to do, a strdup/free seemed appropriate. Now I'm not sure it's a misuse from EasySoap or really an expat bug (which had a wrong behaviour anyway since it was while(0==0) {} on empty data because of that). Feedback welcome. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=568904&group_id=10127 From noreply@sourceforge.net Fri Jun 14 03:08:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Jun 14 02:08:01 2002 Subject: [ expat-Bugs-568904 ] expat sends wrong data to EasySoap ? Message-ID: Bugs item #568904, was opened at 2002-06-14 02:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=568904&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: expat sends wrong data to EasySoap ? Initial Comment: I'm not sure if the following is an expat 1.95.3 bug or an EasySoap 0.6 one. I had to quick-patch it. test This (kind of) structure is parsed by expat for EasySoap. EasySoap knows that the end-tag has been reached because a parameter (uri) given by expat looks like "http://XXX#Envelope" and it's a closing tag. The uri given by expat is correct for the Envelope opening tag "http://XXX#Envelope", correct for the Body opening tag "http://XXX#Body", correct for the Body closing tag "http://XXX#Body" but wrong for the Envelope closing tag "http://XXX#Body". I've traced the code and it's because the tag->uri points to the same address for all the tags. It seems that something is wrong with the "binding" structure in the tag. Here is the diff output, for xmlparse.c 907a908,911 > > if(p->name.str!=NULL) > free(p->name.str) > 2242c2246,2249 < tagNamePtr->str = binding->uri; --- > > // tagNamePtr->str = binding->uri; > tagNamePtr->str = strdup(binding->uri); > Well, since my problem was that raw link, and I didn't had time to know if it was the right thing to do, a strdup/free seemed appropriate. Now I'm not sure it's a misuse from EasySoap or really an expat bug (which had a wrong behaviour anyway since it was while(0==0) {} on empty data because of that). Feedback welcome. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-06-14 02:07 Message: Logged In: NO I forgot to mention that _ the bug happens with Linux as with WIN32. The same patch was applied for both of them. _ I used EasySoap 0.6 This was not a problem with an older version of expat and EasySoap 0.5. I was unable to test expat 1.95.3 with EasySoap 0.5 and the older expat I used with EasySoap 0.6. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=568904&group_id=10127 From noreply@sourceforge.net Fri Jun 14 04:10:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Jun 14 03:10:01 2002 Subject: [ expat-Bugs-568904 ] expat sends wrong data to EasySoap ? Message-ID: Bugs item #568904, was opened at 2002-06-14 02:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=568904&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: expat sends wrong data to EasySoap ? Initial Comment: I'm not sure if the following is an expat 1.95.3 bug or an EasySoap 0.6 one. I had to quick-patch it. test This (kind of) structure is parsed by expat for EasySoap. EasySoap knows that the end-tag has been reached because a parameter (uri) given by expat looks like "http://XXX#Envelope" and it's a closing tag. The uri given by expat is correct for the Envelope opening tag "http://XXX#Envelope", correct for the Body opening tag "http://XXX#Body", correct for the Body closing tag "http://XXX#Body" but wrong for the Envelope closing tag "http://XXX#Body". I've traced the code and it's because the tag->uri points to the same address for all the tags. It seems that something is wrong with the "binding" structure in the tag. Here is the diff output, for xmlparse.c 907a908,911 > > if(p->name.str!=NULL) > free(p->name.str) > 2242c2246,2249 < tagNamePtr->str = binding->uri; --- > > // tagNamePtr->str = binding->uri; > tagNamePtr->str = strdup(binding->uri); > Well, since my problem was that raw link, and I didn't had time to know if it was the right thing to do, a strdup/free seemed appropriate. Now I'm not sure it's a misuse from EasySoap or really an expat bug (which had a wrong behaviour anyway since it was while(0==0) {} on empty data because of that). Feedback welcome. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-06-14 03:09 Message: Logged In: NO I though my email would have been put in the report. If you have any question/feedback it's : ediaz@veridis.com ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-06-14 02:07 Message: Logged In: NO I forgot to mention that _ the bug happens with Linux as with WIN32. The same patch was applied for both of them. _ I used EasySoap 0.6 This was not a problem with an older version of expat and EasySoap 0.5. I was unable to test expat 1.95.3 with EasySoap 0.5 and the older expat I used with EasySoap 0.6. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=568904&group_id=10127 From noreply@sourceforge.net Fri Jun 14 05:03:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Jun 14 04:03:03 2002 Subject: [ expat-Bugs-568904 ] expat sends wrong data to EasySoap ? Message-ID: Bugs item #568904, was opened at 2002-06-14 02:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=568904&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: expat sends wrong data to EasySoap ? Initial Comment: I'm not sure if the following is an expat 1.95.3 bug or an EasySoap 0.6 one. I had to quick-patch it. test This (kind of) structure is parsed by expat for EasySoap. EasySoap knows that the end-tag has been reached because a parameter (uri) given by expat looks like "http://XXX#Envelope" and it's a closing tag. The uri given by expat is correct for the Envelope opening tag "http://XXX#Envelope", correct for the Body opening tag "http://XXX#Body", correct for the Body closing tag "http://XXX#Body" but wrong for the Envelope closing tag "http://XXX#Body". I've traced the code and it's because the tag->uri points to the same address for all the tags. It seems that something is wrong with the "binding" structure in the tag. Here is the diff output, for xmlparse.c 907a908,911 > > if(p->name.str!=NULL) > free(p->name.str) > 2242c2246,2249 < tagNamePtr->str = binding->uri; --- > > // tagNamePtr->str = binding->uri; > tagNamePtr->str = strdup(binding->uri); > Well, since my problem was that raw link, and I didn't had time to know if it was the right thing to do, a strdup/free seemed appropriate. Now I'm not sure it's a misuse from EasySoap or really an expat bug (which had a wrong behaviour anyway since it was while(0==0) {} on empty data because of that). Feedback welcome. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-06-14 04:02 Message: Logged In: NO I've tested expat 1.95.3 with EasySoap 0.5 The bug occured. An older version of expat with EasySoap 0.5 runs fine. I guess it's from expat's side then. ediaz@veridis.com ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-06-14 03:09 Message: Logged In: NO I though my email would have been put in the report. If you have any question/feedback it's : ediaz@veridis.com ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-06-14 02:07 Message: Logged In: NO I forgot to mention that _ the bug happens with Linux as with WIN32. The same patch was applied for both of them. _ I used EasySoap 0.6 This was not a problem with an older version of expat and EasySoap 0.5. I was unable to test expat 1.95.3 with EasySoap 0.5 and the older expat I used with EasySoap 0.6. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=568904&group_id=10127 From noreply@sourceforge.net Fri Jun 14 05:50:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Jun 14 04:50:02 2002 Subject: [ expat-Bugs-568904 ] expat sends wrong data to EasySoap ? Message-ID: Bugs item #568904, was opened at 2002-06-14 02:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=568904&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: expat sends wrong data to EasySoap ? Initial Comment: I'm not sure if the following is an expat 1.95.3 bug or an EasySoap 0.6 one. I had to quick-patch it. test This (kind of) structure is parsed by expat for EasySoap. EasySoap knows that the end-tag has been reached because a parameter (uri) given by expat looks like "http://XXX#Envelope" and it's a closing tag. The uri given by expat is correct for the Envelope opening tag "http://XXX#Envelope", correct for the Body opening tag "http://XXX#Body", correct for the Body closing tag "http://XXX#Body" but wrong for the Envelope closing tag "http://XXX#Body". I've traced the code and it's because the tag->uri points to the same address for all the tags. It seems that something is wrong with the "binding" structure in the tag. Here is the diff output, for xmlparse.c 907a908,911 > > if(p->name.str!=NULL) > free(p->name.str) > 2242c2246,2249 < tagNamePtr->str = binding->uri; --- > > // tagNamePtr->str = binding->uri; > tagNamePtr->str = strdup(binding->uri); > Well, since my problem was that raw link, and I didn't had time to know if it was the right thing to do, a strdup/free seemed appropriate. Now I'm not sure it's a misuse from EasySoap or really an expat bug (which had a wrong behaviour anyway since it was while(0==0) {} on empty data because of that). Feedback welcome. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-06-14 04:49 Message: Logged In: NO With a few more checks : the bug doesn't happens with expat 1.95.2 ediaz@veridis.com ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-06-14 04:02 Message: Logged In: NO I've tested expat 1.95.3 with EasySoap 0.5 The bug occured. An older version of expat with EasySoap 0.5 runs fine. I guess it's from expat's side then. ediaz@veridis.com ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-06-14 03:09 Message: Logged In: NO I though my email would have been put in the report. If you have any question/feedback it's : ediaz@veridis.com ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-06-14 02:07 Message: Logged In: NO I forgot to mention that _ the bug happens with Linux as with WIN32. The same patch was applied for both of them. _ I used EasySoap 0.6 This was not a problem with an older version of expat and EasySoap 0.5. I was unable to test expat 1.95.3 with EasySoap 0.5 and the older expat I used with EasySoap 0.6. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=568904&group_id=10127 From noreply@sourceforge.net Fri Jun 14 07:07:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Jun 14 06:07:01 2002 Subject: [ expat-Bugs-568904 ] expat sends wrong data to EasySoap ? Message-ID: Bugs item #568904, was opened at 2002-06-14 05:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=568904&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: expat sends wrong data to EasySoap ? Initial Comment: I'm not sure if the following is an expat 1.95.3 bug or an EasySoap 0.6 one. I had to quick-patch it. test This (kind of) structure is parsed by expat for EasySoap. EasySoap knows that the end-tag has been reached because a parameter (uri) given by expat looks like "http://XXX#Envelope" and it's a closing tag. The uri given by expat is correct for the Envelope opening tag "http://XXX#Envelope", correct for the Body opening tag "http://XXX#Body", correct for the Body closing tag "http://XXX#Body" but wrong for the Envelope closing tag "http://XXX#Body". I've traced the code and it's because the tag->uri points to the same address for all the tags. It seems that something is wrong with the "binding" structure in the tag. Here is the diff output, for xmlparse.c 907a908,911 > > if(p->name.str!=NULL) > free(p->name.str) > 2242c2246,2249 < tagNamePtr->str = binding->uri; --- > > // tagNamePtr->str = binding->uri; > tagNamePtr->str = strdup(binding->uri); > Well, since my problem was that raw link, and I didn't had time to know if it was the right thing to do, a strdup/free seemed appropriate. Now I'm not sure it's a misuse from EasySoap or really an expat bug (which had a wrong behaviour anyway since it was while(0==0) {} on empty data because of that). Feedback welcome. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-14 09:06 Message: Logged In: YES user_id=290026 This is a bug in Expat 1.95.3 (# 566334) and has been fixed. Please check out the current HEAD from CVS. Karl ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-06-14 07:49 Message: Logged In: NO With a few more checks : the bug doesn't happens with expat 1.95.2 ediaz@veridis.com ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-06-14 07:02 Message: Logged In: NO I've tested expat 1.95.3 with EasySoap 0.5 The bug occured. An older version of expat with EasySoap 0.5 runs fine. I guess it's from expat's side then. ediaz@veridis.com ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-06-14 06:09 Message: Logged In: NO I though my email would have been put in the report. If you have any question/feedback it's : ediaz@veridis.com ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-06-14 05:07 Message: Logged In: NO I forgot to mention that _ the bug happens with Linux as with WIN32. The same patch was applied for both of them. _ I used EasySoap 0.6 This was not a problem with an older version of expat and EasySoap 0.5. I was unable to test expat 1.95.3 with EasySoap 0.5 and the older expat I used with EasySoap 0.6. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=568904&group_id=10127 From noreply@sourceforge.net Sat Jun 15 13:35:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat Jun 15 12:35:05 2002 Subject: [ expat-Bugs-569461 ] 1.95.3 and new OASIS xml test suite Message-ID: Bugs item #569461, was opened at 2002-06-15 19:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=569461&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Nobody/Anonymous (nobody) Summary: 1.95.3 and new OASIS xml test suite Initial Comment: I've tested expat-1.95.3 (with xmltok.c updated to rev. 1.17, becase of bug 566240, all other files are the original 1.95.3) against the recently updated OASIS xml test suite (XML 1.0 (Second Edition) errata 20020320, W3C Conformance Test Suite 20020606), avaliable via http://www.w3.org/XML/Test/ and found a few new problems, that are not triggered by older versions of this test suite. As in previous reports, I checked all not-wellformedness tests (should all raise error) and all valid tests (should all pass) of the test-suites xmltest, ibm, sun and oasis with xmlwf -p. Especially for the well-formedness tests, I have _not_ throughout checked if the error reason, reported by expat is the expected error, but checked only mechanical, if the test has raised an error, regardless of the exact error reason. This method is clearly not perfect, and this time we have an example, that underlines this. ibm/not-wf/P32/ibm32n09.xml This is a new test, not included in previous versions. Problem is, that the standalone document declaration has the value "yes" and there is an external markup declaration of an entity (other than amp, lt, gt, apos, quot). xmlwf -p doesn't report an error. The not well-formedness problem is, that standalone="yes" means, that all informations needed to build the XML infoset must be found in the document entity (standalone="yes" doesn't mean, that the document must not have an external subset or external PE's, only that this external entities doesn't change - per attribute defaults or as in this case, entity declarations - change the info in the document entity. See the last sentence of "Well-Formedness Constraint: Entity Declared" (P68). ibm/not-wf/P68/ibm68n06.xml Same reason as the test befor. This test _was_ present in previous versions of the test suite. But with the previous version of the external subset of this test, xmlwf claimed a "syntax error" error in the external subset, which I plain can't understand (eventually an other expat bug?), but is clearly not the expected error. In the new version of the test suite, this external subset now has an XML declaration with explicite encoding (the older version had only an XML declaration without encoding) and is accepted by expat. xmltest/not-wf/not-sa/010.xml xmltest/not-wf/not-sa/011.xml This tests are new in this edition of the test suite. Unfortunately, this both tests seems to be not documented, either in the test files isself nor in the documentation file xmlconf-20020606.htm. As far as I see, this tests test "Validity Constraint: Proper Declaration/PE Nesting" (P29). xmltest/not-wf/not-sa/005.xml This test raised error with previous expat versions, but does not anymore due to the changes, discussed in bug 548690. This is intentional, according to the 548690 discussion. This test is now listed under "XML Documents with Optional Errors". The test suite documentation says: "Conforming XML 1.0 Processors are permitted to ignore certain errors, or to report them at user option. In this section of this test report are found descriptions of test cases which fit into this category. Processor behavior on such test cases does not affect conformance to the XML 1.0 (Second Edition) Recommendation, except as noted." So, according to this, it's OK, that expat doesn't report an error for this case. Since both reporting error and not reporting error are OK, it may be debatably, which behavior is more convenient for the expat user. (Karl: ;-)) sun/not-wf/not-sa03.xml This is a new test in this edition of the test suite. Unfortunately, this test seems not to be documented. As far as I see, it tests the same as xmltest/not-wf/not-sa/005.xml Tests, that still are wrong, as in previous versions are ibm/not-wf/misc/432gewf.xml sun/not-wf/uri01.xml These are already discussed in the past. Well, that's all. rolf ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=569461&group_id=10127 From noreply@sourceforge.net Mon Jun 17 13:06:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon Jun 17 12:06:03 2002 Subject: [ expat-Bugs-569461 ] 1.95.3 and new OASIS xml test suite Message-ID: Bugs item #569461, was opened at 2002-06-15 15:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=569461&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Nobody/Anonymous (nobody) Summary: 1.95.3 and new OASIS xml test suite Initial Comment: I've tested expat-1.95.3 (with xmltok.c updated to rev. 1.17, becase of bug 566240, all other files are the original 1.95.3) against the recently updated OASIS xml test suite (XML 1.0 (Second Edition) errata 20020320, W3C Conformance Test Suite 20020606), avaliable via http://www.w3.org/XML/Test/ and found a few new problems, that are not triggered by older versions of this test suite. As in previous reports, I checked all not-wellformedness tests (should all raise error) and all valid tests (should all pass) of the test-suites xmltest, ibm, sun and oasis with xmlwf -p. Especially for the well-formedness tests, I have _not_ throughout checked if the error reason, reported by expat is the expected error, but checked only mechanical, if the test has raised an error, regardless of the exact error reason. This method is clearly not perfect, and this time we have an example, that underlines this. ibm/not-wf/P32/ibm32n09.xml This is a new test, not included in previous versions. Problem is, that the standalone document declaration has the value "yes" and there is an external markup declaration of an entity (other than amp, lt, gt, apos, quot). xmlwf -p doesn't report an error. The not well-formedness problem is, that standalone="yes" means, that all informations needed to build the XML infoset must be found in the document entity (standalone="yes" doesn't mean, that the document must not have an external subset or external PE's, only that this external entities doesn't change - per attribute defaults or as in this case, entity declarations - change the info in the document entity. See the last sentence of "Well-Formedness Constraint: Entity Declared" (P68). ibm/not-wf/P68/ibm68n06.xml Same reason as the test befor. This test _was_ present in previous versions of the test suite. But with the previous version of the external subset of this test, xmlwf claimed a "syntax error" error in the external subset, which I plain can't understand (eventually an other expat bug?), but is clearly not the expected error. In the new version of the test suite, this external subset now has an XML declaration with explicite encoding (the older version had only an XML declaration without encoding) and is accepted by expat. xmltest/not-wf/not-sa/010.xml xmltest/not-wf/not-sa/011.xml This tests are new in this edition of the test suite. Unfortunately, this both tests seems to be not documented, either in the test files isself nor in the documentation file xmlconf-20020606.htm. As far as I see, this tests test "Validity Constraint: Proper Declaration/PE Nesting" (P29). xmltest/not-wf/not-sa/005.xml This test raised error with previous expat versions, but does not anymore due to the changes, discussed in bug 548690. This is intentional, according to the 548690 discussion. This test is now listed under "XML Documents with Optional Errors". The test suite documentation says: "Conforming XML 1.0 Processors are permitted to ignore certain errors, or to report them at user option. In this section of this test report are found descriptions of test cases which fit into this category. Processor behavior on such test cases does not affect conformance to the XML 1.0 (Second Edition) Recommendation, except as noted." So, according to this, it's OK, that expat doesn't report an error for this case. Since both reporting error and not reporting error are OK, it may be debatably, which behavior is more convenient for the expat user. (Karl: ;-)) sun/not-wf/not-sa03.xml This is a new test in this edition of the test suite. Unfortunately, this test seems not to be documented. As far as I see, it tests the same as xmltest/not-wf/not-sa/005.xml Tests, that still are wrong, as in previous versions are ibm/not-wf/misc/432gewf.xml sun/not-wf/uri01.xml These are already discussed in the past. Well, that's all. rolf ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-17 15:05 Message: Logged In: YES user_id=290026 Given an improved understanding of section 4.1 in the XML spec, I will try to fix the following test cases in the next Expat release: ibm/not-wf/P32/ibm32n09.xml, ibm/not-wf/P68/ibm68n06.xml and sun/not-wf/not-sa03.xml In my opinion, the third one is not the same type as xmltest/not-wf/not-sa/005.xml, but the same type as the other two. About the test cases xmltest/not-wf/not-sa/010.xml and xmltest/not-wf/not-sa/011.xml: If they really check validity constraint P29, as Rolf has suggested, then it is OK that Expat does not report an error. So, If I am successful, we would be left with only: ibm/not-wf/misc/432gewf.xml and sun/not-wf/uri01.xml, conformance with which does not seem a 100% necessity, as previously discussed. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=569461&group_id=10127 From noreply@sourceforge.net Mon Jun 17 17:17:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon Jun 17 16:17:03 2002 Subject: [ expat-Bugs-570263 ] Bug with attr defaults and external PE's Message-ID: Bugs item #570263, was opened at 2002-06-17 23:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=570263&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Nobody/Anonymous (nobody) Summary: Bug with attr defaults and external PE's Initial Comment: Take a look at this document: %x; ]> Hello. If you process this with expat 1.95.3 and without processing the external entity %x; expat reports the element doc with two attributes: a="D4A" b="D4B". You could easily check this with the xmlwf tool, using the -d option. This is wrong. See the last paragraph of the XML rec Second Editoin 5.1: "[...][T]hey must not process entity declarations or attribute-list declarations encountered after a reference to a parameter entity that is not read, since the entity may have contained overriding declarations." As far as I see, this bug was already in 1.95.1, then fixed in 1.95.2 and showed up again in 1.95.3 rolf ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=570263&group_id=10127 From noreply@sourceforge.net Mon Jun 17 17:22:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon Jun 17 16:22:02 2002 Subject: [ expat-Bugs-569461 ] 1.95.3 and new OASIS xml test suite Message-ID: Bugs item #569461, was opened at 2002-06-15 19:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=569461&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Nobody/Anonymous (nobody) Summary: 1.95.3 and new OASIS xml test suite Initial Comment: I've tested expat-1.95.3 (with xmltok.c updated to rev. 1.17, becase of bug 566240, all other files are the original 1.95.3) against the recently updated OASIS xml test suite (XML 1.0 (Second Edition) errata 20020320, W3C Conformance Test Suite 20020606), avaliable via http://www.w3.org/XML/Test/ and found a few new problems, that are not triggered by older versions of this test suite. As in previous reports, I checked all not-wellformedness tests (should all raise error) and all valid tests (should all pass) of the test-suites xmltest, ibm, sun and oasis with xmlwf -p. Especially for the well-formedness tests, I have _not_ throughout checked if the error reason, reported by expat is the expected error, but checked only mechanical, if the test has raised an error, regardless of the exact error reason. This method is clearly not perfect, and this time we have an example, that underlines this. ibm/not-wf/P32/ibm32n09.xml This is a new test, not included in previous versions. Problem is, that the standalone document declaration has the value "yes" and there is an external markup declaration of an entity (other than amp, lt, gt, apos, quot). xmlwf -p doesn't report an error. The not well-formedness problem is, that standalone="yes" means, that all informations needed to build the XML infoset must be found in the document entity (standalone="yes" doesn't mean, that the document must not have an external subset or external PE's, only that this external entities doesn't change - per attribute defaults or as in this case, entity declarations - change the info in the document entity. See the last sentence of "Well-Formedness Constraint: Entity Declared" (P68). ibm/not-wf/P68/ibm68n06.xml Same reason as the test befor. This test _was_ present in previous versions of the test suite. But with the previous version of the external subset of this test, xmlwf claimed a "syntax error" error in the external subset, which I plain can't understand (eventually an other expat bug?), but is clearly not the expected error. In the new version of the test suite, this external subset now has an XML declaration with explicite encoding (the older version had only an XML declaration without encoding) and is accepted by expat. xmltest/not-wf/not-sa/010.xml xmltest/not-wf/not-sa/011.xml This tests are new in this edition of the test suite. Unfortunately, this both tests seems to be not documented, either in the test files isself nor in the documentation file xmlconf-20020606.htm. As far as I see, this tests test "Validity Constraint: Proper Declaration/PE Nesting" (P29). xmltest/not-wf/not-sa/005.xml This test raised error with previous expat versions, but does not anymore due to the changes, discussed in bug 548690. This is intentional, according to the 548690 discussion. This test is now listed under "XML Documents with Optional Errors". The test suite documentation says: "Conforming XML 1.0 Processors are permitted to ignore certain errors, or to report them at user option. In this section of this test report are found descriptions of test cases which fit into this category. Processor behavior on such test cases does not affect conformance to the XML 1.0 (Second Edition) Recommendation, except as noted." So, according to this, it's OK, that expat doesn't report an error for this case. Since both reporting error and not reporting error are OK, it may be debatably, which behavior is more convenient for the expat user. (Karl: ;-)) sun/not-wf/not-sa03.xml This is a new test in this edition of the test suite. Unfortunately, this test seems not to be documented. As far as I see, it tests the same as xmltest/not-wf/not-sa/005.xml Tests, that still are wrong, as in previous versions are ibm/not-wf/misc/432gewf.xml sun/not-wf/uri01.xml These are already discussed in the past. Well, that's all. rolf ---------------------------------------------------------------------- >Comment By: Rolf Ade (pointsman) Date: 2002-06-17 23:21 Message: Logged In: YES user_id=13222 Agreed ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-17 19:05 Message: Logged In: YES user_id=290026 Given an improved understanding of section 4.1 in the XML spec, I will try to fix the following test cases in the next Expat release: ibm/not-wf/P32/ibm32n09.xml, ibm/not-wf/P68/ibm68n06.xml and sun/not-wf/not-sa03.xml In my opinion, the third one is not the same type as xmltest/not-wf/not-sa/005.xml, but the same type as the other two. About the test cases xmltest/not-wf/not-sa/010.xml and xmltest/not-wf/not-sa/011.xml: If they really check validity constraint P29, as Rolf has suggested, then it is OK that Expat does not report an error. So, If I am successful, we would be left with only: ibm/not-wf/misc/432gewf.xml and sun/not-wf/uri01.xml, conformance with which does not seem a 100% necessity, as previously discussed. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=569461&group_id=10127 From noreply@sourceforge.net Mon Jun 17 21:14:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon Jun 17 20:14:05 2002 Subject: [ expat-Bugs-570263 ] Bug with attr defaults and external PE's Message-ID: Bugs item #570263, was opened at 2002-06-17 19:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=570263&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rolf Ade (pointsman) >Assigned to: Karl Waclawek (kwaclaw) Summary: Bug with attr defaults and external PE's Initial Comment: Take a look at this document: %x; ]> Hello. If you process this with expat 1.95.3 and without processing the external entity %x; expat reports the element doc with two attributes: a="D4A" b="D4B". You could easily check this with the xmlwf tool, using the -d option. This is wrong. See the last paragraph of the XML rec Second Editoin 5.1: "[...][T]hey must not process entity declarations or attribute-list declarations encountered after a reference to a parameter entity that is not read, since the entity may have contained overriding declarations." As far as I see, this bug was already in 1.95.1, then fixed in 1.95.2 and showed up again in 1.95.3 rolf ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-17 23:13 Message: Logged In: YES user_id=290026 Yes, this is a bug, and was probably introduced by me. Now I finally beging to understand why the dtd.complete flag was used in such strange ways... :-( So, I guess this one is for me, Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=570263&group_id=10127 From noreply@sourceforge.net Mon Jun 17 21:15:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon Jun 17 20:15:04 2002 Subject: [ expat-Bugs-569461 ] 1.95.3 and new OASIS xml test suite Message-ID: Bugs item #569461, was opened at 2002-06-15 15:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=569461&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rolf Ade (pointsman) >Assigned to: Karl Waclawek (kwaclaw) Summary: 1.95.3 and new OASIS xml test suite Initial Comment: I've tested expat-1.95.3 (with xmltok.c updated to rev. 1.17, becase of bug 566240, all other files are the original 1.95.3) against the recently updated OASIS xml test suite (XML 1.0 (Second Edition) errata 20020320, W3C Conformance Test Suite 20020606), avaliable via http://www.w3.org/XML/Test/ and found a few new problems, that are not triggered by older versions of this test suite. As in previous reports, I checked all not-wellformedness tests (should all raise error) and all valid tests (should all pass) of the test-suites xmltest, ibm, sun and oasis with xmlwf -p. Especially for the well-formedness tests, I have _not_ throughout checked if the error reason, reported by expat is the expected error, but checked only mechanical, if the test has raised an error, regardless of the exact error reason. This method is clearly not perfect, and this time we have an example, that underlines this. ibm/not-wf/P32/ibm32n09.xml This is a new test, not included in previous versions. Problem is, that the standalone document declaration has the value "yes" and there is an external markup declaration of an entity (other than amp, lt, gt, apos, quot). xmlwf -p doesn't report an error. The not well-formedness problem is, that standalone="yes" means, that all informations needed to build the XML infoset must be found in the document entity (standalone="yes" doesn't mean, that the document must not have an external subset or external PE's, only that this external entities doesn't change - per attribute defaults or as in this case, entity declarations - change the info in the document entity. See the last sentence of "Well-Formedness Constraint: Entity Declared" (P68). ibm/not-wf/P68/ibm68n06.xml Same reason as the test befor. This test _was_ present in previous versions of the test suite. But with the previous version of the external subset of this test, xmlwf claimed a "syntax error" error in the external subset, which I plain can't understand (eventually an other expat bug?), but is clearly not the expected error. In the new version of the test suite, this external subset now has an XML declaration with explicite encoding (the older version had only an XML declaration without encoding) and is accepted by expat. xmltest/not-wf/not-sa/010.xml xmltest/not-wf/not-sa/011.xml This tests are new in this edition of the test suite. Unfortunately, this both tests seems to be not documented, either in the test files isself nor in the documentation file xmlconf-20020606.htm. As far as I see, this tests test "Validity Constraint: Proper Declaration/PE Nesting" (P29). xmltest/not-wf/not-sa/005.xml This test raised error with previous expat versions, but does not anymore due to the changes, discussed in bug 548690. This is intentional, according to the 548690 discussion. This test is now listed under "XML Documents with Optional Errors". The test suite documentation says: "Conforming XML 1.0 Processors are permitted to ignore certain errors, or to report them at user option. In this section of this test report are found descriptions of test cases which fit into this category. Processor behavior on such test cases does not affect conformance to the XML 1.0 (Second Edition) Recommendation, except as noted." So, according to this, it's OK, that expat doesn't report an error for this case. Since both reporting error and not reporting error are OK, it may be debatably, which behavior is more convenient for the expat user. (Karl: ;-)) sun/not-wf/not-sa03.xml This is a new test in this edition of the test suite. Unfortunately, this test seems not to be documented. As far as I see, it tests the same as xmltest/not-wf/not-sa/005.xml Tests, that still are wrong, as in previous versions are ibm/not-wf/misc/432gewf.xml sun/not-wf/uri01.xml These are already discussed in the past. Well, that's all. rolf ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-17 23:15 Message: Logged In: YES user_id=290026 Assigned to me, but only for the three test cases described in my last message. Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-06-17 19:21 Message: Logged In: YES user_id=13222 Agreed ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-17 15:05 Message: Logged In: YES user_id=290026 Given an improved understanding of section 4.1 in the XML spec, I will try to fix the following test cases in the next Expat release: ibm/not-wf/P32/ibm32n09.xml, ibm/not-wf/P68/ibm68n06.xml and sun/not-wf/not-sa03.xml In my opinion, the third one is not the same type as xmltest/not-wf/not-sa/005.xml, but the same type as the other two. About the test cases xmltest/not-wf/not-sa/010.xml and xmltest/not-wf/not-sa/011.xml: If they really check validity constraint P29, as Rolf has suggested, then it is OK that Expat does not report an error. So, If I am successful, we would be left with only: ibm/not-wf/misc/432gewf.xml and sun/not-wf/uri01.xml, conformance with which does not seem a 100% necessity, as previously discussed. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=569461&group_id=10127 From noreply@sourceforge.net Tue Jun 18 20:23:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Jun 18 19:23:02 2002 Subject: [ expat-Bugs-570903 ] Remove tabs in sources Message-ID: Bugs item #570903, was opened at 2002-06-18 22:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=570903&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 7 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Remove tabs in sources Initial Comment: All hard tabs should be removed from the source files. This is a release requirement for Expat 1.95.4; the changes will be made while preparing for the final release. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=570903&group_id=10127 From noreply@sourceforge.net Wed Jun 19 15:00:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed Jun 19 14:00:09 2002 Subject: [ expat-Bugs-571324 ] Can't install XML::Parser via CPAN Message-ID: Bugs item #571324, was opened at 2002-06-19 13:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=571324&group_id=10127 Category: XML::Parser (Perl module) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Clark Cooper (coopercc) Summary: Can't install XML::Parser via CPAN Initial Comment: I just installed/updated PERL on my system from 5.00 to 5.61 so that may (probably) has something to do with it, but here's the dump of errors from the install of XML::Parser via CPAN: CPAN.pm: Going to build C/CO/COOPERCL/XML- Parser-2.31.tar.gz Checking if your kit is complete... Looks good Writing Makefile for XML::Parser::Expat Writing Makefile for XML::Parser cp Parser/Encodings/README blib/lib/XML/Parser/Encodings/README cp Parser/Encodings/x-sjis-cp932.enc blib/lib/XML/Parser/Encodings/x-sjis-cp932.enc cp Parser/Encodings/iso-8859-7.enc blib/lib/XML/Parser/Encodings/iso-8859-7.enc cp Parser/Encodings/big5.enc blib/lib/XML/Parser/Encodings/big5.enc cp Parser/Encodings/windows-1250.enc blib/lib/XML/Parser/Encodings/windows-1250.enc cp Parser/Encodings/iso-8859-8.enc blib/lib/XML/Parser/Encodings/iso-8859-8.enc cp Parser/Encodings/iso-8859-2.enc blib/lib/XML/Parser/Encodings/iso-8859-2.enc cp Parser/Encodings/x-euc-jp-jisx0221.enc blib/lib/XML/Parser/Encodings/x-euc-jp-jisx0221.enc cp Parser/Encodings/iso-8859-9.enc blib/lib/XML/Parser/Encodings/iso-8859-9.enc cp Parser/Encodings/x-sjis-unicode.enc blib/lib/XML/Parser/Encodings/x-sjis-unicode.enc cp Parser/Encodings/iso-8859-3.enc blib/lib/XML/Parser/Encodings/iso-8859-3.enc cp Parser/Encodings/x-sjis-jdk117.enc blib/lib/XML/Parser/Encodings/x-sjis-jdk117.enc cp Parser/Encodings/euc-kr.enc blib/lib/XML/Parser/Encodings/euc-kr.enc cp Parser/Encodings/iso-8859-4.enc blib/lib/XML/Parser/Encodings/iso-8859-4.enc cp Parser/Encodings/Japanese_Encodings.msg blib/lib/XML/Parser/Encodings/Japanese_Encodings.msg cp Parser/Encodings/x-sjis-jisx0221.enc blib/lib/XML/Parser/Encodings/x-sjis-jisx0221.enc cp Parser.pm blib/lib/XML/Parser.pm cp Parser/Encodings/iso-8859-5.enc blib/lib/XML/Parser/Encodings/iso-8859-5.enc cp Parser/Encodings/x-euc-jp-unicode.enc blib/lib/XML/Parser/Encodings/x-euc-jp-unicode.enc cp Parser/LWPExternEnt.pl blib/lib/XML/Parser/LWPExternEnt.pl cp Expat.pm ../blib/lib/XML/Parser/Expat.pm /usr/bin/perl -I/usr/local/lib/perl5/5.6.1/i386-freebsd - I/usr/local/lib/perl5/5.6.1 /usr/local/lib/perl 5/5.6.1/ExtUtils/xsubpp -noprototypes - typemap /usr/local/lib/perl5/5.6.1/ExtUtils/typemap - typemap type map Expat.xs > Expat.xsc && mv Expat.xsc Expat.c cc -c -fno-strict-aliasing -I/usr/local/include -O - DVERSION=\2.31\ -DXS_VERSION=\2.31\ -DPIC - fpic -I/usr/local/lib/perl5/5.6.1/i386-freebsd/CORE Expat.c Expat.xs:140: warning: `ERRSV' redefined /usr/local/lib/perl5/5.6.1/i386-freebsd/CORE/perl.h:768: warning: this is the location of the previous d efinition Expat.xs:132: conflicting types for `Perl_newSVpvn' /usr/local/lib/perl5/5.6.1/i386-freebsd/CORE/proto.h:551: previous declaration of `Perl_newSVpvn' Expat.xs: In function `nsStart': Expat.xs:678: `sv_undef' undeclared (first use in this function) Expat.xs:678: (Each undeclared identifier is reported only once Expat.xs:678: for each function it appears in.) Expat.xs: In function `nsEnd': Expat.xs:698: `sv_undef' undeclared (first use in this function) Expat.xs: In function `attributeDecl': Expat.xs:783: `sv_yes' undeclared (first use in this function) Expat.xs: In function `entityDecl': Expat.xs:811: `sv_undef' undeclared (first use in this function) Expat.xs:816: `sv_yes' undeclared (first use in this function) Expat.xs: In function `doctypeStart': Expat.xs:840: `sv_undef' undeclared (first use in this function) Expat.xs:842: `sv_yes' undeclared (first use in this function) Expat.xs:842: `sv_no' undeclared (first use in this function) Expat.xs: In function `xmlDecl': Expat.xs:881: `sv_undef' undeclared (first use in this function) Expat.xs:885: `sv_yes' undeclared (first use in this function) Expat.xs:885: `sv_no' undeclared (first use in this function) Expat.xs: In function `unparsedEntityDecl': Expat.xs:910: `sv_undef' undeclared (first use in this function) Expat.xs: In function `notationDecl': Expat.xs:940: `sv_undef' undeclared (first use in this function) Expat.xs: In function `externalEntityRef': Expat.xs:985: `sv_undef' undeclared (first use in this function) Expat.xs:1024: `errgv' undeclared (first use in this function) Expat.xs:1055: `na' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_ParserCreate': Expat.xs:1281: `na' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetStartElementHandler': Expat.xs:1519: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetEndElementHandler': Expat.xs:1530: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetCharacterDataHandler': Expat.xs:1543: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetProcessingInstructionHan dler': Expat.xs:1561: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetCommentHandler': Expat.xs:1578: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetDefaultHandler': Expat.xs:1595: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetUnparsedEntityDeclHandl er': Expat.xs:1617: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetNotationDeclHandler': Expat.xs:1634: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetExternalEntityRefHandler': Expat.xs:1652: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetExtEntFinishHandler': Expat.xs:1672: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetEntityDeclHandler': Expat.xs:1687: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetElementDeclHandler': Expat.xs:1705: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetAttListDeclHandler': Expat.xs:1723: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetDoctypeHandler': Expat.xs:1742: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetEndDoctypeHandler': Expat.xs:1760: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetXMLDeclHandler': Expat.xs:1779: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetBase': Expat.xs:1800: `na' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_GetBase': Expat.xs:1818: `sv_undef' undeclared (first use in this function) Expat.c: In function `XS_XML__Parser__Expat_LoadEncoding': Expat.c:2324: `na' undeclared (first use in this function) Expat.xs:1998: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetStartCdataHandler': Expat.xs:2113: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetEndCdataHandler': Expat.xs:2131: `sv_undef' undeclared (first use in this function) Expat.c: In function `boot_XML__Parser__Expat': Expat.c:2684: `sv_yes' undeclared (first use in this function) *** Error code 1 Stop in /root/.cpan/build/XML-Parser-2.31/Expat. *** Error code 1 Stop in /root/.cpan/build/XML-Parser-2.31. /usr/bin/make -- NOT OK Running make test Can't test without successful make Running make install make had returned bad status, install seems impossible ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=571324&group_id=10127 From noreply@sourceforge.net Wed Jun 19 15:59:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed Jun 19 14:59:02 2002 Subject: [ expat-Bugs-571346 ] Can't install XML::Parser via CPAN Message-ID: Bugs item #571346, was opened at 2002-06-19 14:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=571346&group_id=10127 Category: XML::Parser (Perl module) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Clark Cooper (coopercc) Summary: Can't install XML::Parser via CPAN Initial Comment: I just installed/updated PERL on my system from 5.00 to 5.61 so that may (probably) has something to do with it, but here's the dump of errors from the install of XML::Parser via CPAN: CPAN.pm: Going to build C/CO/COOPERCL/XML- Parser-2.31.tar.gz Checking if your kit is complete... Looks good Writing Makefile for XML::Parser::Expat Writing Makefile for XML::Parser cp Parser/Encodings/README blib/lib/XML/Parser/Encodings/README cp Parser/Encodings/x-sjis-cp932.enc blib/lib/XML/Parser/Encodings/x-sjis-cp932.enc cp Parser/Encodings/iso-8859-7.enc blib/lib/XML/Parser/Encodings/iso-8859-7.enc cp Parser/Encodings/big5.enc blib/lib/XML/Parser/Encodings/big5.enc cp Parser/Encodings/windows-1250.enc blib/lib/XML/Parser/Encodings/windows-1250.enc cp Parser/Encodings/iso-8859-8.enc blib/lib/XML/Parser/Encodings/iso-8859-8.enc cp Parser/Encodings/iso-8859-2.enc blib/lib/XML/Parser/Encodings/iso-8859-2.enc cp Parser/Encodings/x-euc-jp-jisx0221.enc blib/lib/XML/Parser/Encodings/x-euc-jp-jisx0221.enc cp Parser/Encodings/iso-8859-9.enc blib/lib/XML/Parser/Encodings/iso-8859-9.enc cp Parser/Encodings/x-sjis-unicode.enc blib/lib/XML/Parser/Encodings/x-sjis-unicode.enc cp Parser/Encodings/iso-8859-3.enc blib/lib/XML/Parser/Encodings/iso-8859-3.enc cp Parser/Encodings/x-sjis-jdk117.enc blib/lib/XML/Parser/Encodings/x-sjis-jdk117.enc cp Parser/Encodings/euc-kr.enc blib/lib/XML/Parser/Encodings/euc-kr.enc cp Parser/Encodings/iso-8859-4.enc blib/lib/XML/Parser/Encodings/iso-8859-4.enc cp Parser/Encodings/Japanese_Encodings.msg blib/lib/XML/Parser/Encodings/Japanese_Encodings.msg cp Parser/Encodings/x-sjis-jisx0221.enc blib/lib/XML/Parser/Encodings/x-sjis-jisx0221.enc cp Parser.pm blib/lib/XML/Parser.pm cp Parser/Encodings/iso-8859-5.enc blib/lib/XML/Parser/Encodings/iso-8859-5.enc cp Parser/Encodings/x-euc-jp-unicode.enc blib/lib/XML/Parser/Encodings/x-euc-jp-unicode.enc cp Parser/LWPExternEnt.pl blib/lib/XML/Parser/LWPExternEnt.pl cp Expat.pm ../blib/lib/XML/Parser/Expat.pm /usr/bin/perl -I/usr/local/lib/perl5/5.6.1/i386-freebsd - I/usr/local/lib/perl5/5.6.1 /usr/local/lib/perl 5/5.6.1/ExtUtils/xsubpp -noprototypes - typemap /usr/local/lib/perl5/5.6.1/ExtUtils/typemap - typemap type map Expat.xs > Expat.xsc && mv Expat.xsc Expat.c cc -c -fno-strict-aliasing -I/usr/local/include -O - DVERSION=\2.31\ -DXS_VERSION=\2.31\ -DPIC - fpic -I/usr/local/lib/perl5/5.6.1/i386-freebsd/CORE Expat.c Expat.xs:140: warning: `ERRSV' redefined /usr/local/lib/perl5/5.6.1/i386-freebsd/CORE/perl.h:768: warning: this is the location of the previous d efinition Expat.xs:132: conflicting types for `Perl_newSVpvn' /usr/local/lib/perl5/5.6.1/i386-freebsd/CORE/proto.h:551: previous declaration of `Perl_newSVpvn' Expat.xs: In function `nsStart': Expat.xs:678: `sv_undef' undeclared (first use in this function) Expat.xs:678: (Each undeclared identifier is reported only once Expat.xs:678: for each function it appears in.) Expat.xs: In function `nsEnd': Expat.xs:698: `sv_undef' undeclared (first use in this function) Expat.xs: In function `attributeDecl': Expat.xs:783: `sv_yes' undeclared (first use in this function) Expat.xs: In function `entityDecl': Expat.xs:811: `sv_undef' undeclared (first use in this function) Expat.xs:816: `sv_yes' undeclared (first use in this function) Expat.xs: In function `doctypeStart': Expat.xs:840: `sv_undef' undeclared (first use in this function) Expat.xs:842: `sv_yes' undeclared (first use in this function) Expat.xs:842: `sv_no' undeclared (first use in this function) Expat.xs: In function `xmlDecl': Expat.xs:881: `sv_undef' undeclared (first use in this function) Expat.xs:885: `sv_yes' undeclared (first use in this function) Expat.xs:885: `sv_no' undeclared (first use in this function) Expat.xs: In function `unparsedEntityDecl': Expat.xs:910: `sv_undef' undeclared (first use in this function) Expat.xs: In function `notationDecl': Expat.xs:940: `sv_undef' undeclared (first use in this function) Expat.xs: In function `externalEntityRef': Expat.xs:985: `sv_undef' undeclared (first use in this function) Expat.xs:1024: `errgv' undeclared (first use in this function) Expat.xs:1055: `na' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_ParserCreate': Expat.xs:1281: `na' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetStartElementHandler': Expat.xs:1519: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetEndElementHandler': Expat.xs:1530: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetCharacterDataHandler': Expat.xs:1543: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetProcessingInstructionHan dler': Expat.xs:1561: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetCommentHandler': Expat.xs:1578: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetDefaultHandler': Expat.xs:1595: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetUnparsedEntityDeclHandl er': Expat.xs:1617: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetNotationDeclHandler': Expat.xs:1634: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetExternalEntityRefHandler': Expat.xs:1652: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetExtEntFinishHandler': Expat.xs:1672: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetEntityDeclHandler': Expat.xs:1687: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetElementDeclHandler': Expat.xs:1705: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetAttListDeclHandler': Expat.xs:1723: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetDoctypeHandler': Expat.xs:1742: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetEndDoctypeHandler': Expat.xs:1760: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetXMLDeclHandler': Expat.xs:1779: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetBase': Expat.xs:1800: `na' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_GetBase': Expat.xs:1818: `sv_undef' undeclared (first use in this function) Expat.c: In function `XS_XML__Parser__Expat_LoadEncoding': Expat.c:2324: `na' undeclared (first use in this function) Expat.xs:1998: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetStartCdataHandler': Expat.xs:2113: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetEndCdataHandler': Expat.xs:2131: `sv_undef' undeclared (first use in this function) Expat.c: In function `boot_XML__Parser__Expat': Expat.c:2684: `sv_yes' undeclared (first use in this function) *** Error code 1 Stop in /root/.cpan/build/XML-Parser-2.31/Expat. *** Error code 1 Stop in /root/.cpan/build/XML-Parser-2.31. /usr/bin/make -- NOT OK Running make test Can't test without successful make Running make install make had returned bad status, install seems impossible ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=571346&group_id=10127 From noreply@sourceforge.net Fri Jun 21 08:09:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Jun 21 07:09:02 2002 Subject: [ expat-Bugs-571324 ] Can't install XML::Parser via CPAN Message-ID: Bugs item #571324, was opened at 2002-06-19 16:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=571324&group_id=10127 Category: XML::Parser (Perl module) Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Nobody/Anonymous (nobody) Summary: Can't install XML::Parser via CPAN Initial Comment: I just installed/updated PERL on my system from 5.00 to 5.61 so that may (probably) has something to do with it, but here's the dump of errors from the install of XML::Parser via CPAN: CPAN.pm: Going to build C/CO/COOPERCL/XML- Parser-2.31.tar.gz Checking if your kit is complete... Looks good Writing Makefile for XML::Parser::Expat Writing Makefile for XML::Parser cp Parser/Encodings/README blib/lib/XML/Parser/Encodings/README cp Parser/Encodings/x-sjis-cp932.enc blib/lib/XML/Parser/Encodings/x-sjis-cp932.enc cp Parser/Encodings/iso-8859-7.enc blib/lib/XML/Parser/Encodings/iso-8859-7.enc cp Parser/Encodings/big5.enc blib/lib/XML/Parser/Encodings/big5.enc cp Parser/Encodings/windows-1250.enc blib/lib/XML/Parser/Encodings/windows-1250.enc cp Parser/Encodings/iso-8859-8.enc blib/lib/XML/Parser/Encodings/iso-8859-8.enc cp Parser/Encodings/iso-8859-2.enc blib/lib/XML/Parser/Encodings/iso-8859-2.enc cp Parser/Encodings/x-euc-jp-jisx0221.enc blib/lib/XML/Parser/Encodings/x-euc-jp-jisx0221.enc cp Parser/Encodings/iso-8859-9.enc blib/lib/XML/Parser/Encodings/iso-8859-9.enc cp Parser/Encodings/x-sjis-unicode.enc blib/lib/XML/Parser/Encodings/x-sjis-unicode.enc cp Parser/Encodings/iso-8859-3.enc blib/lib/XML/Parser/Encodings/iso-8859-3.enc cp Parser/Encodings/x-sjis-jdk117.enc blib/lib/XML/Parser/Encodings/x-sjis-jdk117.enc cp Parser/Encodings/euc-kr.enc blib/lib/XML/Parser/Encodings/euc-kr.enc cp Parser/Encodings/iso-8859-4.enc blib/lib/XML/Parser/Encodings/iso-8859-4.enc cp Parser/Encodings/Japanese_Encodings.msg blib/lib/XML/Parser/Encodings/Japanese_Encodings.msg cp Parser/Encodings/x-sjis-jisx0221.enc blib/lib/XML/Parser/Encodings/x-sjis-jisx0221.enc cp Parser.pm blib/lib/XML/Parser.pm cp Parser/Encodings/iso-8859-5.enc blib/lib/XML/Parser/Encodings/iso-8859-5.enc cp Parser/Encodings/x-euc-jp-unicode.enc blib/lib/XML/Parser/Encodings/x-euc-jp-unicode.enc cp Parser/LWPExternEnt.pl blib/lib/XML/Parser/LWPExternEnt.pl cp Expat.pm ../blib/lib/XML/Parser/Expat.pm /usr/bin/perl -I/usr/local/lib/perl5/5.6.1/i386-freebsd - I/usr/local/lib/perl5/5.6.1 /usr/local/lib/perl 5/5.6.1/ExtUtils/xsubpp -noprototypes - typemap /usr/local/lib/perl5/5.6.1/ExtUtils/typemap - typemap type map Expat.xs > Expat.xsc && mv Expat.xsc Expat.c cc -c -fno-strict-aliasing -I/usr/local/include -O - DVERSION=\2.31\ -DXS_VERSION=\2.31\ -DPIC - fpic -I/usr/local/lib/perl5/5.6.1/i386-freebsd/CORE Expat.c Expat.xs:140: warning: `ERRSV' redefined /usr/local/lib/perl5/5.6.1/i386-freebsd/CORE/perl.h:768: warning: this is the location of the previous d efinition Expat.xs:132: conflicting types for `Perl_newSVpvn' /usr/local/lib/perl5/5.6.1/i386-freebsd/CORE/proto.h:551: previous declaration of `Perl_newSVpvn' Expat.xs: In function `nsStart': Expat.xs:678: `sv_undef' undeclared (first use in this function) Expat.xs:678: (Each undeclared identifier is reported only once Expat.xs:678: for each function it appears in.) Expat.xs: In function `nsEnd': Expat.xs:698: `sv_undef' undeclared (first use in this function) Expat.xs: In function `attributeDecl': Expat.xs:783: `sv_yes' undeclared (first use in this function) Expat.xs: In function `entityDecl': Expat.xs:811: `sv_undef' undeclared (first use in this function) Expat.xs:816: `sv_yes' undeclared (first use in this function) Expat.xs: In function `doctypeStart': Expat.xs:840: `sv_undef' undeclared (first use in this function) Expat.xs:842: `sv_yes' undeclared (first use in this function) Expat.xs:842: `sv_no' undeclared (first use in this function) Expat.xs: In function `xmlDecl': Expat.xs:881: `sv_undef' undeclared (first use in this function) Expat.xs:885: `sv_yes' undeclared (first use in this function) Expat.xs:885: `sv_no' undeclared (first use in this function) Expat.xs: In function `unparsedEntityDecl': Expat.xs:910: `sv_undef' undeclared (first use in this function) Expat.xs: In function `notationDecl': Expat.xs:940: `sv_undef' undeclared (first use in this function) Expat.xs: In function `externalEntityRef': Expat.xs:985: `sv_undef' undeclared (first use in this function) Expat.xs:1024: `errgv' undeclared (first use in this function) Expat.xs:1055: `na' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_ParserCreate': Expat.xs:1281: `na' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetStartElementHandler': Expat.xs:1519: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetEndElementHandler': Expat.xs:1530: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetCharacterDataHandler': Expat.xs:1543: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetProcessingInstructionHan dler': Expat.xs:1561: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetCommentHandler': Expat.xs:1578: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetDefaultHandler': Expat.xs:1595: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetUnparsedEntityDeclHandl er': Expat.xs:1617: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetNotationDeclHandler': Expat.xs:1634: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetExternalEntityRefHandler': Expat.xs:1652: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetExtEntFinishHandler': Expat.xs:1672: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetEntityDeclHandler': Expat.xs:1687: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetElementDeclHandler': Expat.xs:1705: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetAttListDeclHandler': Expat.xs:1723: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetDoctypeHandler': Expat.xs:1742: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetEndDoctypeHandler': Expat.xs:1760: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetXMLDeclHandler': Expat.xs:1779: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetBase': Expat.xs:1800: `na' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_GetBase': Expat.xs:1818: `sv_undef' undeclared (first use in this function) Expat.c: In function `XS_XML__Parser__Expat_LoadEncoding': Expat.c:2324: `na' undeclared (first use in this function) Expat.xs:1998: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetStartCdataHandler': Expat.xs:2113: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetEndCdataHandler': Expat.xs:2131: `sv_undef' undeclared (first use in this function) Expat.c: In function `boot_XML__Parser__Expat': Expat.c:2684: `sv_yes' undeclared (first use in this function) *** Error code 1 Stop in /root/.cpan/build/XML-Parser-2.31/Expat. *** Error code 1 Stop in /root/.cpan/build/XML-Parser-2.31. /usr/bin/make -- NOT OK Running make test Can't test without successful make Running make install make had returned bad status, install seems impossible ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-21 10:08 Message: Logged In: YES user_id=3066 Duplicate of SF bug #571346. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=571324&group_id=10127 From noreply@sourceforge.net Fri Jun 21 08:13:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Jun 21 07:13:04 2002 Subject: [ expat-Bugs-571346 ] Can't install XML::Parser via CPAN Message-ID: Bugs item #571346, was opened at 2002-06-19 17:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=571346&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: Nobody/Anonymous (nobody) Summary: Can't install XML::Parser via CPAN Initial Comment: I just installed/updated PERL on my system from 5.00 to 5.61 so that may (probably) has something to do with it, but here's the dump of errors from the install of XML::Parser via CPAN: CPAN.pm: Going to build C/CO/COOPERCL/XML- Parser-2.31.tar.gz Checking if your kit is complete... Looks good Writing Makefile for XML::Parser::Expat Writing Makefile for XML::Parser cp Parser/Encodings/README blib/lib/XML/Parser/Encodings/README cp Parser/Encodings/x-sjis-cp932.enc blib/lib/XML/Parser/Encodings/x-sjis-cp932.enc cp Parser/Encodings/iso-8859-7.enc blib/lib/XML/Parser/Encodings/iso-8859-7.enc cp Parser/Encodings/big5.enc blib/lib/XML/Parser/Encodings/big5.enc cp Parser/Encodings/windows-1250.enc blib/lib/XML/Parser/Encodings/windows-1250.enc cp Parser/Encodings/iso-8859-8.enc blib/lib/XML/Parser/Encodings/iso-8859-8.enc cp Parser/Encodings/iso-8859-2.enc blib/lib/XML/Parser/Encodings/iso-8859-2.enc cp Parser/Encodings/x-euc-jp-jisx0221.enc blib/lib/XML/Parser/Encodings/x-euc-jp-jisx0221.enc cp Parser/Encodings/iso-8859-9.enc blib/lib/XML/Parser/Encodings/iso-8859-9.enc cp Parser/Encodings/x-sjis-unicode.enc blib/lib/XML/Parser/Encodings/x-sjis-unicode.enc cp Parser/Encodings/iso-8859-3.enc blib/lib/XML/Parser/Encodings/iso-8859-3.enc cp Parser/Encodings/x-sjis-jdk117.enc blib/lib/XML/Parser/Encodings/x-sjis-jdk117.enc cp Parser/Encodings/euc-kr.enc blib/lib/XML/Parser/Encodings/euc-kr.enc cp Parser/Encodings/iso-8859-4.enc blib/lib/XML/Parser/Encodings/iso-8859-4.enc cp Parser/Encodings/Japanese_Encodings.msg blib/lib/XML/Parser/Encodings/Japanese_Encodings.msg cp Parser/Encodings/x-sjis-jisx0221.enc blib/lib/XML/Parser/Encodings/x-sjis-jisx0221.enc cp Parser.pm blib/lib/XML/Parser.pm cp Parser/Encodings/iso-8859-5.enc blib/lib/XML/Parser/Encodings/iso-8859-5.enc cp Parser/Encodings/x-euc-jp-unicode.enc blib/lib/XML/Parser/Encodings/x-euc-jp-unicode.enc cp Parser/LWPExternEnt.pl blib/lib/XML/Parser/LWPExternEnt.pl cp Expat.pm ../blib/lib/XML/Parser/Expat.pm /usr/bin/perl -I/usr/local/lib/perl5/5.6.1/i386-freebsd - I/usr/local/lib/perl5/5.6.1 /usr/local/lib/perl 5/5.6.1/ExtUtils/xsubpp -noprototypes - typemap /usr/local/lib/perl5/5.6.1/ExtUtils/typemap - typemap type map Expat.xs > Expat.xsc && mv Expat.xsc Expat.c cc -c -fno-strict-aliasing -I/usr/local/include -O - DVERSION=\2.31\ -DXS_VERSION=\2.31\ -DPIC - fpic -I/usr/local/lib/perl5/5.6.1/i386-freebsd/CORE Expat.c Expat.xs:140: warning: `ERRSV' redefined /usr/local/lib/perl5/5.6.1/i386-freebsd/CORE/perl.h:768: warning: this is the location of the previous d efinition Expat.xs:132: conflicting types for `Perl_newSVpvn' /usr/local/lib/perl5/5.6.1/i386-freebsd/CORE/proto.h:551: previous declaration of `Perl_newSVpvn' Expat.xs: In function `nsStart': Expat.xs:678: `sv_undef' undeclared (first use in this function) Expat.xs:678: (Each undeclared identifier is reported only once Expat.xs:678: for each function it appears in.) Expat.xs: In function `nsEnd': Expat.xs:698: `sv_undef' undeclared (first use in this function) Expat.xs: In function `attributeDecl': Expat.xs:783: `sv_yes' undeclared (first use in this function) Expat.xs: In function `entityDecl': Expat.xs:811: `sv_undef' undeclared (first use in this function) Expat.xs:816: `sv_yes' undeclared (first use in this function) Expat.xs: In function `doctypeStart': Expat.xs:840: `sv_undef' undeclared (first use in this function) Expat.xs:842: `sv_yes' undeclared (first use in this function) Expat.xs:842: `sv_no' undeclared (first use in this function) Expat.xs: In function `xmlDecl': Expat.xs:881: `sv_undef' undeclared (first use in this function) Expat.xs:885: `sv_yes' undeclared (first use in this function) Expat.xs:885: `sv_no' undeclared (first use in this function) Expat.xs: In function `unparsedEntityDecl': Expat.xs:910: `sv_undef' undeclared (first use in this function) Expat.xs: In function `notationDecl': Expat.xs:940: `sv_undef' undeclared (first use in this function) Expat.xs: In function `externalEntityRef': Expat.xs:985: `sv_undef' undeclared (first use in this function) Expat.xs:1024: `errgv' undeclared (first use in this function) Expat.xs:1055: `na' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_ParserCreate': Expat.xs:1281: `na' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetStartElementHandler': Expat.xs:1519: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetEndElementHandler': Expat.xs:1530: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetCharacterDataHandler': Expat.xs:1543: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetProcessingInstructionHan dler': Expat.xs:1561: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetCommentHandler': Expat.xs:1578: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetDefaultHandler': Expat.xs:1595: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetUnparsedEntityDeclHandl er': Expat.xs:1617: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetNotationDeclHandler': Expat.xs:1634: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetExternalEntityRefHandler': Expat.xs:1652: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetExtEntFinishHandler': Expat.xs:1672: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetEntityDeclHandler': Expat.xs:1687: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetElementDeclHandler': Expat.xs:1705: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetAttListDeclHandler': Expat.xs:1723: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetDoctypeHandler': Expat.xs:1742: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetEndDoctypeHandler': Expat.xs:1760: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetXMLDeclHandler': Expat.xs:1779: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetBase': Expat.xs:1800: `na' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_GetBase': Expat.xs:1818: `sv_undef' undeclared (first use in this function) Expat.c: In function `XS_XML__Parser__Expat_LoadEncoding': Expat.c:2324: `na' undeclared (first use in this function) Expat.xs:1998: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetStartCdataHandler': Expat.xs:2113: `sv_undef' undeclared (first use in this function) Expat.xs: In function `XS_XML__Parser__Expat_SetEndCdataHandler': Expat.xs:2131: `sv_undef' undeclared (first use in this function) Expat.c: In function `boot_XML__Parser__Expat': Expat.c:2684: `sv_yes' undeclared (first use in this function) *** Error code 1 Stop in /root/.cpan/build/XML-Parser-2.31/Expat. *** Error code 1 Stop in /root/.cpan/build/XML-Parser-2.31. /usr/bin/make -- NOT OK Running make test Can't test without successful make Running make install make had returned bad status, install seems impossible ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-21 10:12 Message: Logged In: YES user_id=3066 Can't auto-assign XML::Parser reports to Clark Cooper anymore, since he seems to have disappeared. This problem is related to XML::Parser and the building of Perl extension modules and does not indicate a problem with Expat. Closing as a third-party bug. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=571346&group_id=10127 From noreply@sourceforge.net Fri Jun 21 08:15:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Jun 21 07:15:05 2002 Subject: [ expat-Bugs-564275 ] Test 11 in stream.t fails Message-ID: Bugs item #564275, was opened at 2002-06-04 05:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=564275&group_id=10127 Category: XML::Parser (Perl module) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Nobody/Anonymous (nobody) Summary: Test 11 in stream.t fails Initial Comment: System: Linux 2.4.10-4GB i686 Expat-Version: 1.95.3 Perl-Version: 5.6.1 in stream.t, problem with encoding: $string differs from $expected at index 333: $string is result of parsing a document in ISO-8859-1 encoding, input contains character chr(160) which sneaks into output (UTF-8 encoding) unchanged, instead of being converted to chr(192)chr(160). ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-21 10:14 Message: Logged In: YES user_id=3066 This report can't be assigned to Clark Cooper since he's no longer active on this project. I'll see if I can round up someone to help respond to XML::Parser issue reports -- I don't know that anyone currently on this project knows much about the Perl bindings. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-06-07 02:13 Message: Logged In: NO Sorry, was a typo indeed. After parsing the test string (in stream.t) following expressions evaluate to true: ord( substr($string, 332, 1) ) == 160; ord( substr($expected, 332, 1) ) == 194; ord( substr($expected, 333, 1) ) == 160; The test failed yesterday on my freshly installed Suse 8.0 System at home, the expat-library was compiled on Suse 7.3 here at work, though. Some ideas, what's responsible for this test failing? Thank you. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-06 13:59 Message: Logged In: YES user_id=290026 Works for me. Expat 1.95.3 returns 0xC2 0xA0 which corresponds to chr(194) chr(160). I assume you made a typo, since chr(192) = 0xC0 is not valid for the first byte in a UTF-8 sequence. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=564275&group_id=10127 From noreply@sourceforge.net Tue Jun 25 12:18:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Jun 25 11:18:03 2002 Subject: [ expat-Bugs-573754 ] Parse in C Message-ID: Bugs item #573754, was opened at 2002-06-25 13:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=573754&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: angelo (acjets) Assigned to: Nobody/Anonymous (nobody) Summary: Parse in C Initial Comment: I would like to report a link that is no longer working http://www.jclark.com/xml/expat.html could you please recommend another link that will parse C for me thanks Angelo angelo_carducci@neimanmarcus.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=573754&group_id=10127 From noreply@sourceforge.net Tue Jun 25 20:38:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Jun 25 19:38:07 2002 Subject: [ expat-Bugs-422239 ] Bug in XmlUpdatePosition() Message-ID: Bugs item #422239, was opened at 2001-05-08 05:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=422239&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Bug in XmlUpdatePosition() Initial Comment: If I call XML_GetCurrentLineNumber() at the end of a document, it appears to double count the lines. Calling XML_GetCurrentLineNumber() on every end element event seems to solve the problem. I have no explanation for this, other than supposing there may be a bug in the call to XmlUpdatePosition(), from XML_Parse(). ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-25 22:37 Message: Logged In: YES user_id=3066 Closing due to non-response from submitter or other party able to reproduce this. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-13 10:47 Message: Logged In: YES user_id=3066 Karl: Not necessarily. The submitter *may* have provided an email address or have requested "monitoring" of the issue, which are not visible in the interface. (I consider this a bug in the SF user interface.) Bringing it up on expat-discuss is not a bad idea. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-13 10:38 Message: Logged In: YES user_id=290026 Since *nobody* submitted this, *nobody* will read this. Maybe post to the discussion list? Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-12 23:06 Message: Logged In: YES user_id=3066 Do you still see this in Expat 1.95.3? Does this only occur on long documents? Any other special considerations? I am not able to reproduce this using a short input document: If anyone can provide a failing sample document, please attach it to this bug report, otherwise I'll close it after a short waiting period (say, 2 weeks). I've attached a patch to tests/runtests.c that shows the test I wrote. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-25 17:00 Message: Logged In: YES user_id=3066 Removing the assignment to Clark, since he does not seem to be available, and this doesn't appear to be an XML::Parser specific bug. I need to generate a test case for this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=422239&group_id=10127 From noreply@sourceforge.net Tue Jun 25 20:42:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Jun 25 19:42:04 2002 Subject: [ expat-Bugs-568904 ] expat sends wrong data to EasySoap ? Message-ID: Bugs item #568904, was opened at 2002-06-14 05:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=568904&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: expat sends wrong data to EasySoap ? Initial Comment: I'm not sure if the following is an expat 1.95.3 bug or an EasySoap 0.6 one. I had to quick-patch it. test This (kind of) structure is parsed by expat for EasySoap. EasySoap knows that the end-tag has been reached because a parameter (uri) given by expat looks like "http://XXX#Envelope" and it's a closing tag. The uri given by expat is correct for the Envelope opening tag "http://XXX#Envelope", correct for the Body opening tag "http://XXX#Body", correct for the Body closing tag "http://XXX#Body" but wrong for the Envelope closing tag "http://XXX#Body". I've traced the code and it's because the tag->uri points to the same address for all the tags. It seems that something is wrong with the "binding" structure in the tag. Here is the diff output, for xmlparse.c 907a908,911 > > if(p->name.str!=NULL) > free(p->name.str) > 2242c2246,2249 < tagNamePtr->str = binding->uri; --- > > // tagNamePtr->str = binding->uri; > tagNamePtr->str = strdup(binding->uri); > Well, since my problem was that raw link, and I didn't had time to know if it was the right thing to do, a strdup/free seemed appropriate. Now I'm not sure it's a misuse from EasySoap or really an expat bug (which had a wrong behaviour anyway since it was while(0==0) {} on empty data because of that). Feedback welcome. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-25 22:41 Message: Logged In: YES user_id=3066 As Karl mentioned, this has already been fixed in CVS Expat. This can be closed. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-14 09:06 Message: Logged In: YES user_id=290026 This is a bug in Expat 1.95.3 (# 566334) and has been fixed. Please check out the current HEAD from CVS. Karl ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-06-14 07:49 Message: Logged In: NO With a few more checks : the bug doesn't happens with expat 1.95.2 ediaz@veridis.com ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-06-14 07:02 Message: Logged In: NO I've tested expat 1.95.3 with EasySoap 0.5 The bug occured. An older version of expat with EasySoap 0.5 runs fine. I guess it's from expat's side then. ediaz@veridis.com ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-06-14 06:09 Message: Logged In: NO I though my email would have been put in the report. If you have any question/feedback it's : ediaz@veridis.com ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-06-14 05:07 Message: Logged In: NO I forgot to mention that _ the bug happens with Linux as with WIN32. The same patch was applied for both of them. _ I used EasySoap 0.6 This was not a problem with an older version of expat and EasySoap 0.5. I was unable to test expat 1.95.3 with EasySoap 0.5 and the older expat I used with EasySoap 0.6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=568904&group_id=10127 From noreply@sourceforge.net Tue Jun 25 21:10:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Jun 25 20:10:02 2002 Subject: [ expat-Bugs-453546 ] memmove() segv inside XML_GetBuffer (mod_perl) Message-ID: Bugs item #453546, was opened at 2001-08-20 19:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=453546&group_id=10127 Category: XML::Parser (Perl module) >Group: Third-party Bug >Status: Closed >Resolution: Out of Date Priority: 2 Submitted By: Bart Schaefer (barts) Assigned to: Nobody/Anonymous (nobody) Summary: memmove() segv inside XML_GetBuffer (mod_perl) Initial Comment: I do not believe this to be the same bug as 434665. I'm using XML::Parser::EasyTree. I wrote a module that, when perl is run from the shell command line, successfully parses an XML file and interprets the resulting tree. When I use the same module as a mod_perl handler for an upload of exactly the same file, I get a segmentation fault. GDB on a single-threaded httpd shows this to be happening on a memmove() call with dest=0x0, *inside* XML_GetBuffer(). The fix in xmlparse.c rev 1.22 only helps after XML_GetBuffer() returns 0, and I don't get that far. I'm using the 1.95.2-1 RPM on RedHat 6.2 linux, with perl 5.6.0 and XML::Parser both installed using the CPAN shell. I've tried it on two different machines with Apache 1.3.14/ mod_perl 1.24_01 and Apache 1.3.19/mod_perl 1.25, with the same results. If I can come up with a minimal file that reproduces this, I'll attach it to this bug report later. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-25 23:09 Message: Logged In: YES user_id=3066 Closed due to non-response of the submitter. This appears to be the classic Apache/mod_perl problem of two library instances being loaded. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-16 22:18 Message: Logged In: YES user_id=3066 Is it possible that two copies of Expat are getting loaded? This sounds like a classic problem with Apache and mod_perl; using XML::Parser from mod_perl causes a new copy of Expat to be loaded, even though there's already a copy provided as part of Apache. This situation has been improved in more recent Apache versions (1.3.21 and newer). Does the problem go away with more recent versions of Apache? ---------------------------------------------------------------------- Comment By: Bart Schaefer (barts) Date: 2001-08-20 21:11 Message: Logged In: YES user_id=22647 This appears to be a problem with use of global data that is getting messed up by mod_perl. I converted to a CGI script and it works fine now. I reduced the priority and mentioned mod_perl in the summary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=453546&group_id=10127 From noreply@sourceforge.net Tue Jun 25 22:49:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Jun 25 21:49:05 2002 Subject: [ expat-Bugs-561575 ] "configure" fails Message-ID: Bugs item #561575, was opened at 2002-05-28 11:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=561575&group_id=10127 Category: Build control Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) >Summary: "configure" fails Initial Comment: When installing expat, the command "./configure" fails. Here's what appears a the end of the log: creating Makefile creating lib/Makefile sed: Cannot find or open file ./lib/Makefile.in. creating lib/expat.h sed: Cannot find or open file ./lib/expat.h.in. creating config.h config.h is unchanged Neither lib/Makefile.in, nor lib/expat.h.in exists; however lib/Makefile and lib/expat.h do. The value of variable CONFIG_FILES is "Makefile lib/Makefile lib/expat.h". ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-26 00:48 Message: Logged In: YES user_id=3066 Closing due to non-responsiveness of the submitter; there isn't enough information here to work from. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-31 15:37 Message: Logged In: YES user_id=3066 What version of Expat are you using? The build process has changed a lot over each of the last several releases, and the process for the upcoming 1.95.3 release continues this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=561575&group_id=10127 From noreply@sourceforge.net Tue Jun 25 22:53:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Jun 25 21:53:02 2002 Subject: [ expat-Bugs-511175 ] efence catches freeing freed Message-ID: Bugs item #511175, was opened at 2002-01-31 07:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=511175&group_id=10127 Category: XML::Parser (Perl module) Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Daniel Horn (hellcatv) Assigned to: Nobody/Anonymous (nobody) Summary: efence catches freeing freed Initial Comment: I am on an intel pentium III 550 i use expat numerous times in my application vegastrike.sourceforge.net it seems randomly in 10,000 parses of different, short documents I get an error when running efence with set environment EF_PROTECT_FREE 1 no stack is left and it took me about 25 hours to figure out where it was happening I added printf's to almost every line of my code to find this..... but here is what XML_FreeBuffer said your memory management routines are kinda funky though...could it be playing tricks on efence?? anyhow here's the trace of what happens: parser 59358d8 bufget59b61000 parsing.... 59358d8cxml_freefor if (tagstack0==0) TagSTack= freeTagList5935efdc p = tagStack5935efdc Free p->buf59b66fe0 Destroy p->bindings59b66fe0 FREE (p5935ef "`G\021\b\200:\021\b0\035\021\b`T\021\bàP\021\b\220R\021\bp]\021\b°^\021\b\020_\021\b\220_\021\b\220W\021\b\020[\021\b0\\021\bà_\021\bÐV\021\bÀ`\021\b`a\021\b\001", 0x8122ad0 "U\211å\203ì\b\203ì\bÿu\024ÿu\020ÿu\fj", 0x8122b00 "U\211å\203ì\b\203ì\bÿu\024ÿu\020ÿu\fj\001ÿu\bh¬¯\030\bè\037üÿÿ\203Ä \211À\211À\211ì]Ã\215t&", 0x0 , 0x8121560 "U\211å\203ì\bÿu\024ÿu\020ÿu\fh`^\030\bègJÿÿ\203Ä\020\211ì]ÃU\211å\203ì\b\215Eÿ\211Eø\203ì\f\213U\b\213Eø@P\215EøPÿu\020\215E\fPÿu\b\213B<ÿÐ\203Ä \2---Type to continue, or q to quit--- 15Eÿ9Eøu\013¸ÿÿÿÿë\n\215t&", 0x0, 0x0, 0x0, 0x0, 0x600
, 0x56e98e18 "`^\030\bÐ*\022\b", 0x8186160 "`G\021\b\200:\021\dc) for p = tagStack59b6efdc Free p->buf59b70fe0 Destroy p->bindings59b70fe0 FREE (p59b6efdc) for if (tagstack0==0) poolDest (tempPool0) poolDest (temp2Pool0) free (atts5935af00) free (buffer59b61000) ElectricFence Aborting: free(59b61000): freeing free memory. Program received signal SIGILL, Illegal instruction. [Switching to Thread 1024 (LWP 3627)] 0x4018a971 in kill () from /lib/libc.so.6 Current language: auto; currently c (gdb) bt #0 0x4018a971 in kill () from /lib/libc.so.6 #1 0x400ed953 in EF_Abort () from /usr/lib/libefence.so.0 #2 0x40829000 in ?? () this happens very consistently an earlier run (takes about 1 hour of continuous parsing of small files) parscreated at 56e98d8c bufget58c41000ebufget xml_free(56e98d8c) ElectricFence Aborting: free(58c41000): freeing free memory. Program received signal SIGILL, Illegal instruction. 0x4018a971 in ?? () (gdb) (gdb) up #1 0x40829000 in ?? () (gdb) Initial frame selected; you cannot go up. (gdb) down #0 0x4018a971 in ?? () (gdb) Bottom (i.e., innermost) frame selected; you cannot go down. (gdb) print 56e98d8c Invalid number "56e98d8c". (gdb) print 0x56e98d8c $1 = 1458146700 (gdb) print (char *[10])((XML_Parser)0x56e98d8c) Invalid cast. (gdb) print (char *[10])*(char **)((XML_Parser)0x56e98d8c) $9 = {0x56e09fc8 "¤\235#[\003", 0x56e09fc8 "¤\235#[\003", 0x58c41000 "\n", 0x804dd84 "ÿ%\210ê\035\bh`\001", 0x804e244 "ÿ%¸ë\035\bhÀ\003", 0x804e9a4 "ÿ%\220í\035\bhp\a", 0x58c41000 "\n", 0x58c410a5 "", 0x58c45000
, 0xa5
} (gdb) print (char *[100])*(char **)((XML_Parser)0x56e98d8c) $10 = {0x56e09fc8 "¤\235#[\003", 0x56e09fc8 "¤\235#[\003", 0x58c41000 "\n", 0x804dd84 "ÿ%\210ê\035\bh`\001", 0x804e244 "ÿ%¸ë\035\bhÀ\003", 0x804e9a4 "ÿ%\220í\035\bhp\a", 0x58c41000 "\n", 0x58c410a5 "", 0x58c45000
, 0xa5
, 0x58c410a5 "", 0x56e9cc00 "", 0x56e9d000
, 0x8093c00 "U\211å\203ì(\203ì\004ÿu\fhò\215\027\bÿ5ðî\035\bèÈ ûÿ\203Ä\020\203ì\004\203ì\004ÿu\020\215EèPè\237¡üÿ\203Ä\f\215EèPÿu\f\215EØPè,\016\t", 0x8093ce0 "U\211å\203ì\030\203ì\004ÿu\fhú\215\027\bÿ5ðî\035\bèè\237ûÿ\203Ä\020\203ì\bÿu\f\215EèPèb\r\t", 0x0 , 0x56e98d8c "È\237àVÈ\237àV", 0x0, 0x0, 0x0, 0x0, 0x0, 0x8185e60 ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-26 00:52 Message: Logged In: YES user_id=3066 This was an older version of Expat (based on the submission date, much has changed). If you can reproduce this with 1.95.3 or newer (CVS), please add a comment to this report or file a new report. Please always tell what version of Expat you're using. (This also may have been an XML::Parser-specific bug, so not relevant to the Expat project.) ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-16 22:22 Message: Logged In: YES user_id=3066 Removed assignment to Clark since he's not longer working on Expat. What version of Expat was being used in the application? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=511175&group_id=10127 From noreply@sourceforge.net Tue Jun 25 22:59:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Jun 25 21:59:02 2002 Subject: [ expat-Bugs-566238 ] 1.95.3: xmlwf startup time much longer Message-ID: Bugs item #566238, was opened at 2002-06-08 13:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=566238&group_id=10127 >Category: Build control Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Rolf Ade (pointsman) >Assigned to: Greg Stein (gstein) Summary: 1.95.3: xmlwf startup time much longer Initial Comment: At least at my linux box, I seems that the new way of starting xmlwf - with a shell wrapper - heavily increases the startup time of xmlwf. For most people, this may be a really minor problem (it isn't even a big one for me, though). But if you check a lot of really small xml files with xmlwf in one commandline or a shell script, this is very notable. I've noticed it, while checking the (very small) test files of the OASIS test suite. My shell scripts, that does this, needed up to 10 times (!) longer, to finished. To be sure, it's really the startup time, I checked xmlwf against some bigger XML files (around 30 Mbyte) and found only minor speed differences between 1.95.2 and 1.95.3. It seems, 1.95.3 is around 6 or 7 percent slower than 1.95.2 (I've substracted the mesured longer startup time of the 1.95.3 xmlwf from the running time, befor calculation.) rolf ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-26 00:58 Message: Logged In: YES user_id=3066 Ugh! This is heinous! The crufty libtool wrapper should never be installed, and even says so itself. Greg, can you fix this soon? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=566238&group_id=10127 From noreply@sourceforge.net Tue Jun 25 23:02:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Jun 25 22:02:03 2002 Subject: [ expat-Bugs-573754 ] Parse in C Message-ID: Bugs item #573754, was opened at 2002-06-25 14:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=573754&group_id=10127 >Category: Documentation Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: angelo (acjets) Assigned to: Nobody/Anonymous (nobody) Summary: Parse in C Initial Comment: I would like to report a link that is no longer working http://www.jclark.com/xml/expat.html could you please recommend another link that will parse C for me thanks Angelo angelo_carducci@neimanmarcus.com ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-26 01:01 Message: Logged In: YES user_id=3066 The cited link works for me. Current information about expat is available at http://www.libexpat.org/. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=573754&group_id=10127 From noreply@sourceforge.net Thu Jun 27 06:13:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Jun 27 05:13:02 2002 Subject: [ expat-Bugs-574542 ] how to set the parser env -- (HELP) Message-ID: Bugs item #574542, was opened at 2002-06-27 05:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=574542&group_id=10127 Category: XML::Parser (Perl module) Group: Test Required Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: how to set the parser env -- (HELP) Initial Comment: we are using sun OS 5.8. we want to convert a xml data into csv file format using perl.We don't know how to start.we want to know what are the steps to be followed to install the parser.which parser is recommended and where can i get it. ( Actually we did something like this we have installed a expat parser from CPAN and try to "USE XML:DOM" but it is giving error like Can't locate XML/DOM.pm in @INC (@INC contains: /usr/perl5/5.00503/sun4- solaris /usr/perl5/5.00503 /usr/perl5/site_perl/5.005/sun4- solaris /usr/perl5/site_perl/5.005 .) at test.pl line 2. BEGIN failed--compilation aborted at test.pl line 2. .) for example consider the file address.xml Sriman No140 marshalls road chennai Kannan No 10 evc road chennai 5 This data from xml file should be written into Address.csv as Sriman | No140 marshalls road | chennai Kannan | No 10 evc road | chennai 5 Please advice govind ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=574542&group_id=10127 From noreply@sourceforge.net Thu Jun 27 21:57:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Jun 27 20:57:02 2002 Subject: [ expat-Bugs-574931 ] How to set the environment for expat Message-ID: Bugs item #574931, was opened at 2002-06-27 20:56 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=574931&group_id=10127 Category: XML::Parser (inactive) Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: How to set the environment for expat Initial Comment: Please forgive me if this Query is stupid we are using sun OS 5.8. we want to convert a xml data into csv file format using perl. ( Actually we did something like this we have installed a expat-1.95.3 libs and try to "USE XML::DOM" but it is giving error like Can't locate XML/DOM.pm in @INC (@INC contains: /usr/perl5/5.00503/sun4- solaris /usr/perl5/5.00503 /usr/perl5/site_perl/5.005/sun4- solaris /usr/perl5/site_perl/5.005 .) at test.pl line 2. BEGIN failed--compilation aborted at test.pl line 2. .) we want to know what are the steps to be followed to install the parser. And which parser will be suitable for my requirement. We don't know how to fix this problem Please advice thanks govind ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=574931&group_id=10127 From noreply@sourceforge.net Thu Jun 27 22:00:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Jun 27 21:00:01 2002 Subject: [ expat-Bugs-574933 ] How to set the environment for expat1.95 Message-ID: Bugs item #574933, was opened at 2002-06-27 20:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=574933&group_id=10127 Category: XML::Parser (inactive) Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: How to set the environment for expat1.95 Initial Comment: Please forgive me if this Query is stupid we are using sun OS 5.8. we want to convert a xml data into csv file format using perl. ( Actually we did something like this we have installed a expat-1.95.3 libs and try to "USE XML::DOM" but it is giving error like Can't locate XML/DOM.pm in @INC (@INC contains: /usr/perl5/5.00503/sun4- solaris /usr/perl5/5.00503 /usr/perl5/site_perl/5.005/sun4- solaris /usr/perl5/site_perl/5.005 .) at test.pl line 2. BEGIN failed--compilation aborted at test.pl line 2. .) we want to know what are the steps to be followed to install the parser. And which parser will be suitable for my requirement. We don't know how to fix this problem Please advice thanks govind ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=574933&group_id=10127 From noreply@sourceforge.net Fri Jun 28 13:15:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Jun 28 12:15:04 2002 Subject: [ expat-Bugs-574542 ] how to set the parser env -- (HELP) Message-ID: Bugs item #574542, was opened at 2002-06-27 08:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=574542&group_id=10127 Category: XML::Parser (inactive) >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: how to set the parser env -- (HELP) Initial Comment: we are using sun OS 5.8. we want to convert a xml data into csv file format using perl.We don't know how to start.we want to know what are the steps to be followed to install the parser.which parser is recommended and where can i get it. ( Actually we did something like this we have installed a expat parser from CPAN and try to "USE XML:DOM" but it is giving error like Can't locate XML/DOM.pm in @INC (@INC contains: /usr/perl5/5.00503/sun4- solaris /usr/perl5/5.00503 /usr/perl5/site_perl/5.005/sun4- solaris /usr/perl5/site_perl/5.005 .) at test.pl line 2. BEGIN failed--compilation aborted at test.pl line 2. .) for example consider the file address.xml Sriman No140 marshalls road chennai Kannan No 10 evc road chennai 5 This data from xml file should be written into Address.csv as Sriman | No140 marshalls road | chennai Kannan | No 10 evc road | chennai 5 Please advice govind ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-28 15:14 Message: Logged In: YES user_id=3066 This is an application question and not a bug in expat. Please post questions like this, related to the Perl XML modules, to the perl-xml list hosted by ActiveState. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=574542&group_id=10127 From noreply@sourceforge.net Fri Jun 28 13:16:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Jun 28 12:16:06 2002 Subject: [ expat-Bugs-574931 ] How to set the environment for expat Message-ID: Bugs item #574931, was opened at 2002-06-27 23:56 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=574931&group_id=10127 Category: XML::Parser (inactive) Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: How to set the environment for expat Initial Comment: Please forgive me if this Query is stupid we are using sun OS 5.8. we want to convert a xml data into csv file format using perl. ( Actually we did something like this we have installed a expat-1.95.3 libs and try to "USE XML::DOM" but it is giving error like Can't locate XML/DOM.pm in @INC (@INC contains: /usr/perl5/5.00503/sun4- solaris /usr/perl5/5.00503 /usr/perl5/site_perl/5.005/sun4- solaris /usr/perl5/site_perl/5.005 .) at test.pl line 2. BEGIN failed--compilation aborted at test.pl line 2. .) we want to know what are the steps to be followed to install the parser. And which parser will be suitable for my requirement. We don't know how to fix this problem Please advice thanks govind ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-28 15:15 Message: Logged In: YES user_id=3066 Duplicate of SF bug #574542 -- not a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=574931&group_id=10127 From noreply@sourceforge.net Fri Jun 28 13:16:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Jun 28 12:16:14 2002 Subject: [ expat-Bugs-574933 ] How to set the environment for expat1.95 Message-ID: Bugs item #574933, was opened at 2002-06-27 23:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=574933&group_id=10127 Category: XML::Parser (inactive) Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: How to set the environment for expat1.95 Initial Comment: Please forgive me if this Query is stupid we are using sun OS 5.8. we want to convert a xml data into csv file format using perl. ( Actually we did something like this we have installed a expat-1.95.3 libs and try to "USE XML::DOM" but it is giving error like Can't locate XML/DOM.pm in @INC (@INC contains: /usr/perl5/5.00503/sun4- solaris /usr/perl5/5.00503 /usr/perl5/site_perl/5.005/sun4- solaris /usr/perl5/site_perl/5.005 .) at test.pl line 2. BEGIN failed--compilation aborted at test.pl line 2. .) we want to know what are the steps to be followed to install the parser. And which parser will be suitable for my requirement. We don't know how to fix this problem Please advice thanks govind ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-28 15:15 Message: Logged In: YES user_id=3066 Duplicate of SF bug #574542 -- not a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=574933&group_id=10127 From noreply@sourceforge.net Fri Jun 28 13:35:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Jun 28 12:35:02 2002 Subject: [ expat-Bugs-575168 ] Missing events for end-element Message-ID: Bugs item #575168, was opened at 2002-06-28 15:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=575168&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Missing events for end-element Initial Comment: When the end-element handler is set but not the start-element handler, the end-element events for end tags are not reported; events are reported for empty elements. I've attached a test case that demonstrates this problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=575168&group_id=10127 From noreply@sourceforge.net Fri Jun 28 15:20:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Jun 28 14:20:03 2002 Subject: [ expat-Bugs-575168 ] Missing events for end-element Message-ID: Bugs item #575168, was opened at 2002-06-28 15:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=575168&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Missing events for end-element Initial Comment: When the end-element handler is set but not the start-element handler, the end-element events for end tags are not reported; events are reported for empty elements. I've attached a test case that demonstrates this problem. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-28 17:19 Message: Logged In: YES user_id=3066 I've attached a minimal patch to make Expat generate the required events. The attached test passes when this patch has been applied as well. The tests of the Python bindings that originally uncovered this bug also pass with this change to xmlparse.c. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=575168&group_id=10127 From noreply@sourceforge.net Fri Jun 28 17:07:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Jun 28 16:07:03 2002 Subject: [ expat-Bugs-575168 ] Missing events for end-element Message-ID: Bugs item #575168, was opened at 2002-06-28 15:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=575168&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Missing events for end-element Initial Comment: When the end-element handler is set but not the start-element handler, the end-element events for end tags are not reported; events are reported for empty elements. I've attached a test case that demonstrates this problem. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-28 19:06 Message: Logged In: YES user_id=3066 I've gone ahead and checked in the patches as lib/xmlparse.c 1.46 and tests/runtests.c 1.23. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-28 17:19 Message: Logged In: YES user_id=3066 I've attached a minimal patch to make Expat generate the required events. The attached test passes when this patch has been applied as well. The tests of the Python bindings that originally uncovered this bug also pass with this change to xmlparse.c. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=575168&group_id=10127 From noreply@sourceforge.net Fri Jun 28 17:52:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Jun 28 16:52:02 2002 Subject: [ expat-Bugs-575168 ] Missing events for end-element Message-ID: Bugs item #575168, was opened at 2002-06-28 15:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=575168&group_id=10127 Category: None Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Missing events for end-element Initial Comment: When the end-element handler is set but not the start-element handler, the end-element events for end tags are not reported; events are reported for empty elements. I've attached a test case that demonstrates this problem. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-28 19:51 Message: Logged In: YES user_id=290026 Should it not now be possible to change ... if (endElementHandler && tag->name.str) { ... to ... if (endElementHandler) { ... since the code should guarantee that the correct tag is accessed, which means that tag->name.str != NULL? Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-28 19:06 Message: Logged In: YES user_id=3066 I've gone ahead and checked in the patches as lib/xmlparse.c 1.46 and tests/runtests.c 1.23. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-28 17:19 Message: Logged In: YES user_id=3066 I've attached a minimal patch to make Expat generate the required events. The attached test passes when this patch has been applied as well. The tests of the Python bindings that originally uncovered this bug also pass with this change to xmlparse.c. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=575168&group_id=10127 From noreply@sourceforge.net Sat Jun 29 09:18:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat Jun 29 08:18:05 2002 Subject: [ expat-Bugs-575168 ] Missing events for end-element Message-ID: Bugs item #575168, was opened at 2002-06-28 15:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=575168&group_id=10127 Category: None Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Missing events for end-element Initial Comment: When the end-element handler is set but not the start-element handler, the end-element events for end tags are not reported; events are reported for empty elements. I've attached a test case that demonstrates this problem. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-29 11:17 Message: Logged In: YES user_id=3066 Ok, I've thought about that a bit, and the tests pass with that change, but I think that means we're missing a test. I suspect the current implementation largely assumes that once we start parsing, the set of handlers will not grow; while this may be reasonable application behavior, this is a bad assumption to make in library code. Consider this: some processor watches for a processing instruction, and *adds* handlers based on that. Suppose that it adds start/end element handlers where it had none before, and the document looks like this: If we make the change you suggest, we could be passing bad data (NULL for the tagName) to the endElementHandler for the doc element, though all will be fine for the inner element. With the extra check in there, it means we don't call the endElementHandler for the doc element, which, while a bug, means we're preserving existing behavior instead of passing NULL (not documented as a valid value for the tagName). I think we should leave the extra check in for now, but should consider always setting up the TAG structure, even though it means extra work for the rare application that doesn't use either the start or end element handler. The data is still potentially needed for any application that add an endElementHandler after processing starts. There are probably similar cases for paired handlers elsewhere in the code as well. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-28 19:51 Message: Logged In: YES user_id=290026 Should it not now be possible to change ... if (endElementHandler && tag->name.str) { ... to ... if (endElementHandler) { ... since the code should guarantee that the correct tag is accessed, which means that tag->name.str != NULL? Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-28 19:06 Message: Logged In: YES user_id=3066 I've gone ahead and checked in the patches as lib/xmlparse.c 1.46 and tests/runtests.c 1.23. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-28 17:19 Message: Logged In: YES user_id=3066 I've attached a minimal patch to make Expat generate the required events. The attached test passes when this patch has been applied as well. The tests of the Python bindings that originally uncovered this bug also pass with this change to xmlparse.c. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=575168&group_id=10127 From noreply@sourceforge.net Sat Jun 29 09:29:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat Jun 29 08:29:05 2002 Subject: [ expat-Bugs-566238 ] 1.95.3: xmlwf startup time much longer Message-ID: Bugs item #566238, was opened at 2002-06-08 13:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=566238&group_id=10127 Category: Build control Group: None Status: Open Resolution: None >Priority: 6 Submitted By: Rolf Ade (pointsman) Assigned to: Greg Stein (gstein) Summary: 1.95.3: xmlwf startup time much longer Initial Comment: At least at my linux box, I seems that the new way of starting xmlwf - with a shell wrapper - heavily increases the startup time of xmlwf. For most people, this may be a really minor problem (it isn't even a big one for me, though). But if you check a lot of really small xml files with xmlwf in one commandline or a shell script, this is very notable. I've noticed it, while checking the (very small) test files of the OASIS test suite. My shell scripts, that does this, needed up to 10 times (!) longer, to finished. To be sure, it's really the startup time, I checked xmlwf against some bigger XML files (around 30 Mbyte) and found only minor speed differences between 1.95.2 and 1.95.3. It seems, 1.95.3 is around 6 or 7 percent slower than 1.95.2 (I've substracted the mesured longer startup time of the 1.95.3 xmlwf from the running time, befor calculation.) rolf ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-29 11:28 Message: Logged In: YES user_id=3066 This is painful, but not enough to hold up a bugfix release. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-26 00:58 Message: Logged In: YES user_id=3066 Ugh! This is heinous! The crufty libtool wrapper should never be installed, and even says so itself. Greg, can you fix this soon? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=566238&group_id=10127 From noreply@sourceforge.net Sat Jun 29 10:27:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat Jun 29 09:27:02 2002 Subject: [ expat-Bugs-575168 ] Missing events for end-element Message-ID: Bugs item #575168, was opened at 2002-06-28 15:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=575168&group_id=10127 Category: None Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Missing events for end-element Initial Comment: When the end-element handler is set but not the start-element handler, the end-element events for end tags are not reported; events are reported for empty elements. I've attached a test case that demonstrates this problem. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-29 12:26 Message: Logged In: YES user_id=290026 I agree with your analysis, also with the need for checking other handler pairs. One quick idea, without looking at the source: If we remove this check: ... if (startElementHandler || endElementHandler) { ... then the tag structure gets always set up and we would not need the extra check for endElementHandler. At the cost of extra processing time, but how often does one *not* set any of the element handlers? Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-29 11:17 Message: Logged In: YES user_id=3066 Ok, I've thought about that a bit, and the tests pass with that change, but I think that means we're missing a test. I suspect the current implementation largely assumes that once we start parsing, the set of handlers will not grow; while this may be reasonable application behavior, this is a bad assumption to make in library code. Consider this: some processor watches for a processing instruction, and *adds* handlers based on that. Suppose that it adds start/end element handlers where it had none before, and the document looks like this: If we make the change you suggest, we could be passing bad data (NULL for the tagName) to the endElementHandler for the doc element, though all will be fine for the inner element. With the extra check in there, it means we don't call the endElementHandler for the doc element, which, while a bug, means we're preserving existing behavior instead of passing NULL (not documented as a valid value for the tagName). I think we should leave the extra check in for now, but should consider always setting up the TAG structure, even though it means extra work for the rare application that doesn't use either the start or end element handler. The data is still potentially needed for any application that add an endElementHandler after processing starts. There are probably similar cases for paired handlers elsewhere in the code as well. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-28 19:51 Message: Logged In: YES user_id=290026 Should it not now be possible to change ... if (endElementHandler && tag->name.str) { ... to ... if (endElementHandler) { ... since the code should guarantee that the correct tag is accessed, which means that tag->name.str != NULL? Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-28 19:06 Message: Logged In: YES user_id=3066 I've gone ahead and checked in the patches as lib/xmlparse.c 1.46 and tests/runtests.c 1.23. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-28 17:19 Message: Logged In: YES user_id=3066 I've attached a minimal patch to make Expat generate the required events. The attached test passes when this patch has been applied as well. The tests of the Python bindings that originally uncovered this bug also pass with this change to xmlparse.c. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=575168&group_id=10127 From noreply@sourceforge.net Sat Jun 29 21:47:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat Jun 29 20:47:02 2002 Subject: [ expat-Bugs-575168 ] Missing events for end-element Message-ID: Bugs item #575168, was opened at 2002-06-28 15:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=575168&group_id=10127 Category: None Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Missing events for end-element Initial Comment: When the end-element handler is set but not the start-element handler, the end-element events for end tags are not reported; events are reported for empty elements. I've attached a test case that demonstrates this problem. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-29 23:46 Message: Logged In: YES user_id=290026 I attached a patch (based on your patch - xmlparse.c 1.46), that always sets up the tag structure, as suggested. Additionally, I made sure that storeAtts doesn't get called twice - I moved it under if (startElementHandler) ... That way we should have correct behaviour, even if the endElementHandler gets set after the startElementHandler was called. Since tag->name.str should now always be non-NULL, I removed the corresponding check. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-29 12:26 Message: Logged In: YES user_id=290026 I agree with your analysis, also with the need for checking other handler pairs. One quick idea, without looking at the source: If we remove this check: ... if (startElementHandler || endElementHandler) { ... then the tag structure gets always set up and we would not need the extra check for endElementHandler. At the cost of extra processing time, but how often does one *not* set any of the element handlers? Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-29 11:17 Message: Logged In: YES user_id=3066 Ok, I've thought about that a bit, and the tests pass with that change, but I think that means we're missing a test. I suspect the current implementation largely assumes that once we start parsing, the set of handlers will not grow; while this may be reasonable application behavior, this is a bad assumption to make in library code. Consider this: some processor watches for a processing instruction, and *adds* handlers based on that. Suppose that it adds start/end element handlers where it had none before, and the document looks like this: If we make the change you suggest, we could be passing bad data (NULL for the tagName) to the endElementHandler for the doc element, though all will be fine for the inner element. With the extra check in there, it means we don't call the endElementHandler for the doc element, which, while a bug, means we're preserving existing behavior instead of passing NULL (not documented as a valid value for the tagName). I think we should leave the extra check in for now, but should consider always setting up the TAG structure, even though it means extra work for the rare application that doesn't use either the start or end element handler. The data is still potentially needed for any application that add an endElementHandler after processing starts. There are probably similar cases for paired handlers elsewhere in the code as well. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-28 19:51 Message: Logged In: YES user_id=290026 Should it not now be possible to change ... if (endElementHandler && tag->name.str) { ... to ... if (endElementHandler) { ... since the code should guarantee that the correct tag is accessed, which means that tag->name.str != NULL? Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-28 19:06 Message: Logged In: YES user_id=3066 I've gone ahead and checked in the patches as lib/xmlparse.c 1.46 and tests/runtests.c 1.23. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-28 17:19 Message: Logged In: YES user_id=3066 I've attached a minimal patch to make Expat generate the required events. The attached test passes when this patch has been applied as well. The tests of the Python bindings that originally uncovered this bug also pass with this change to xmlparse.c. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=575168&group_id=10127 From we_gowind@yahoo.co.in Sun Jun 30 01:11:01 2002 From: we_gowind@yahoo.co.in (=?iso-8859-1?q?govindarajan=20varadharajulu?=) Date: Sun Jun 30 00:11:01 2002 Subject: help : how to use the expat-1.95.3 Message-ID: <20020630071023.98156.qmail@web8004.mail.in.yahoo.com> i am installed expat-1.95.3 in my sunOS5.8 but the path for expat-1.95.3/lib and expat-1.95.3/bin is not set.whenever i try to run my parser perl program is not at all Identifying the parser methods. these are the septs i have followed. 1) down loaded expat-1.95.3 from sourceforge.net 2) put into my home directory(/misc/home/john/) 3) gunzip and tar the .gz file(it's created a file expat-1.95.3) 4) ./configure -PREFIX=/misc/home/john/expat-1.95.3 5) ./configure CPPFLAGS=-DXML_UNICODE 6) ./configure CFLAGS="-g -O2 -fshort-wchar" PPFLAGS=- DXML_UNICODE_WCHAR_T It's trowing error(./configure CFLAGS="-g -O2 -fshort-wchar" PPFLAGS=-DXML_UNICO> checking build system type... sparc-sun-solaris2.8 checking host system type... sparc-sun-solaris2.8 checking for gcc... gcc checking for C compiler default output... configure: error: C compiler cannot create executables) 7) make buildlib 8) make installlib 9) PATH=/usr/ccs/bin:$PATH make throwing error( cc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DXML_UNICODE -Ilib -I. -o xmlwf/xmlwf.o -c xmlwf/xmlwf.c /usr/ucb/cc: language optional software package not installed *** Error code 1 make: Fatal error: Command failed for target `xmlwf/xmlwf.o' ) 10) LD_LIBRARY_PATH = {$LD_LIBRARY_PATH }:/misc/home/john/expat-1.95.3 After this if i run any perl file having lib function like XML_Parser XML_LChar * XML_ExpatVersion(); throwing error ( syntax error at test.pl line 3, near "* XML_ExpatVersion(" Execution of test.pl aborted due to compilation errors. ) Please advice what i want to do get this work well govind ________________________________________________________________________ Want to sell your car? advertise on Yahoo Autos Classifieds. It's Free!! visit http://in.autos.yahoo.com