From noreply at sourceforge.net Sat Mar 1 06:25:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Mar 1 09:15:54 2003 Subject: [Expat-bugs] [ expat-Bugs-692878 ] FASTCALL problem with Solars/gcc Message-ID: Bugs item #692878, was opened at 2003-02-25 08:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=692878&group_id=10127 Category: None Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: FASTCALL problem with Solars/gcc Initial Comment: Talking about 1.95.6 (of course, prior to that, the FASTCALL macro was a noop, if I recall right). I got two independend reports about compiler warnings, while compiling expat with gcc under Solaris. The one specified his gcc version (2.7.2.3) without saying the exact Solaris Version, the other uses Solaris 2.6 and a not specified gcc version. Both get plenty of similar warning like this: In file included from ../expat/xmlrole.h:14, from ../expat/xmlrole.c:14: ../expat/xmltok.h:143: warning: `regparm' attribute directive ignored ../expat/xmltok.h:144: warning: `regparm' attribute directive ignored ../expat/xmltok.h:149: warning: `regparm' attribute directive ignored .... It seems, the FASTCALL macro in internal.h is the source of the trouble. rolf ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-01 09:25 Message: Logged In: YES user_id=290026 Rolf, In theory regparm(2 or 3) should improve speed since it allows the compiler to choose passing parameters in registers instead of on the stack. The reason why this doesn't work on Windows is that the MS compiler allows register passing to be combined with stdcall only, not with cdecl. And for Expat purposes it seems cdecl is way faster, so this overcompensates any gain register passing with stdcall could give you. However, with gcc it seems that regparm can be combined with cdecl, or rather must be, since AFAIK stdcall doesn't really exist on Linux. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2003-02-25 16:41 Message: Logged In: YES user_id=13222 Freds patch fixed the problem for both reporters: "Works fine now { uname -a SunOS Develop 5.6 Generic_105181-32 sun4u sparc gcc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.7.2.3/specs gcc version 2.7.2.3 }" and "Works for me now as well (gcc v 2.8.1)" Thanks! rolf ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2003-02-25 11:26 Message: Logged In: YES user_id=13222 I've handed the patched version to the original reporters. Will report about the results (if I get answer). Re regparm(2) instead of regparm(3). There isn't a value in using regparm by itself. I think it only makes sense, to use this, if it in deed speeds up things at least a little bit (this seems not guaranteed, as Karls result on w32 shows). If I recall right, Fred had measured a little speed up on linux. I guess, it would be better, to find a volunteer, which checks, if this compiler hints in fact makes a measurable difference, before we try to play advanced tricks. rolf ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-25 10:34 Message: Logged In: YES user_id=290026 This seems to affect older compilers? Maybe a task for the build (autoconf?). One could also try regparm(2) instead of regparm(3). Assuming these compilers recognize regparm at all. Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-02-25 10:24 Message: Logged In: YES user_id=3066 I've attached a patch, but I can't test on an equivalent environment to where you found the problem. It doesn't break the build for Linux. ;-) If you could test this patch to the lib/internal.h file from the CVS version of Expat in the target environments, I'd appreciate knowing if this fixes the problem. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=692878&group_id=10127 From noreply at sourceforge.net Sat Mar 1 08:47:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Mar 1 11:37:51 2003 Subject: [Expat-bugs] [ expat-Bugs-692964 ] Case where expat 1.95.6 doesn't report duplicate attributes. Message-ID: Bugs item #692964, was opened at 2003-02-25 10:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=692964&group_id=10127 Category: None Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Mark E. (snowballville) Assigned to: Karl Waclawek (kwaclaw) Summary: Case where expat 1.95.6 doesn't report duplicate attributes. Initial Comment: I believe I found a bug in the Expat parser in detecting duplicate attributes when using namespaces. I'm using Expat 1.95.6 with PyXML 0.8.2. Section 6.3 of the Namespaces 1.1 recommendation requires that no element have two attributes with the same expanded name. Expat 1.95.6 does indeed report a duplicate attribute error with the example given in that section of the document: I've attached a file with the first element removed. Expat doesn't report a duplicate attribute error when processing this file as I believe the recommendation requires. ---------------------------------------------------------------------- >Comment By: Mark E. (snowballville) Date: 2003-03-01 11:47 Message: Logged In: YES user_id=684927 I checked out the source and built it with DJGPP after applying the patch. I used xmlwf to test the "bad" example I provided and it is flagged as a duplicate error now. Whether the solution is good or not I'll leave to those who know the source. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-28 14:01 Message: Logged In: YES user_id=290026 It turned out that Expat is very resilient against patching this properly without having to re-write major portions of the code that handles attributes and their declarations. I finally decided on a patch that simply hooks into the loop in storeAtts() were prefixed attribute names are expanded. The basic approach is to progressively store the attributes' local names and uris in an array (nsAtts) as they are iterated over, and each time a new attribute name is expanded, it is compared to all previous local names and uris (for the same element). I tried to do this efficiently, but one can expect a slight impact on performance. Feel free to come up with a better solution. Please test the attached patch (file NSAttFix.diff) for both functional correctness and performance (the patch includes a few cosmetic changes - not to be confused). ---------------------------------------------------------------------- Comment By: Mark E. (snowballville) Date: 2003-02-25 17:33 Message: Logged In: YES user_id=684927 I tried expat 1.95.5 with the same result. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-25 14:02 Message: Logged In: YES user_id=290026 Well, if it is not too much effort, it certainly would be useful information. Thanks, Karl ---------------------------------------------------------------------- Comment By: Mark E. (snowballville) Date: 2003-02-25 13:24 Message: Logged In: YES user_id=684927 Correction: I have used expat 1.95.5 (with pyxml 0.8.1), but I haven't tested this case with it. I will if you want me to. I would expect the same result though. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-25 13:23 Message: Logged In: YES user_id=290026 It looks to me as if this error has always been there, since the modifications required would be significant. No need to test 1.95.5. Karl ---------------------------------------------------------------------- Comment By: Mark E. (snowballville) Date: 2003-02-25 13:21 Message: Logged In: YES user_id=684927 I just got started with using xml with python, so expat 1.95.6 (installed with pyxml 0.8.2) is the only version I've used. I could temporarily download to pyxml 0.8.1 (which includes expat 1.95.5) if you think it informative. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-25 11:35 Message: Logged In: YES user_id=290026 Had a look. Won't be a quick fix. The problem function is StoreAtts(). The solution might be to have a separate function getAttributeIdNS() that looks up attribute id structs by expanded instead of prefixed name. But that may require adjustments to other parts of the code. Hope I have time soon, unless someone else is quicker. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-25 10:44 Message: Logged In: YES user_id=290026 Expat only supports XML Namespaces 1.0, but the bug still applies (section 5.3 of the spec). Will look into it. Does this happen with previous versions of Expat? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=692964&group_id=10127 From noreply at sourceforge.net Mon Mar 3 11:36:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Mar 3 14:27:00 2003 Subject: [Expat-bugs] [ expat-Bugs-692964 ] Case where expat 1.95.6 doesn't report duplicate attributes. Message-ID: Bugs item #692964, was opened at 2003-02-25 10:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=692964&group_id=10127 Category: None Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Mark E. (snowballville) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Case where expat 1.95.6 doesn't report duplicate attributes. Initial Comment: I believe I found a bug in the Expat parser in detecting duplicate attributes when using namespaces. I'm using Expat 1.95.6 with PyXML 0.8.2. Section 6.3 of the Namespaces 1.1 recommendation requires that no element have two attributes with the same expanded name. Expat 1.95.6 does indeed report a duplicate attribute error with the example given in that section of the document: I've attached a file with the first element removed. Expat doesn't report a duplicate attribute error when processing this file as I believe the recommendation requires. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-03 14:36 Message: Logged In: YES user_id=290026 The submitted fix - NSAttFix1.diff - seems to work, but has a bad worst case behaviur. For example: assuming 20 attributes in an element, checking for duplicates will require n*(n-1)/2 = 190 string comparisons. I have therefore replaced this with a simplified hash table approach. See the attached file NSAttFix3.diff. In addition, this new patch also fixes bug #695401: "Unbound prefixes not rejected". Several cosmetic changes and some cleanup (removed non-NULL checks when releasing memory) are also included. This requires some more testing. Currently it passes the OASIS xml test suite the same as version 1.95.6. Assigned to Fred for writing the regression tests. ---------------------------------------------------------------------- Comment By: Mark E. (snowballville) Date: 2003-03-01 11:47 Message: Logged In: YES user_id=684927 I checked out the source and built it with DJGPP after applying the patch. I used xmlwf to test the "bad" example I provided and it is flagged as a duplicate error now. Whether the solution is good or not I'll leave to those who know the source. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-28 14:01 Message: Logged In: YES user_id=290026 It turned out that Expat is very resilient against patching this properly without having to re-write major portions of the code that handles attributes and their declarations. I finally decided on a patch that simply hooks into the loop in storeAtts() were prefixed attribute names are expanded. The basic approach is to progressively store the attributes' local names and uris in an array (nsAtts) as they are iterated over, and each time a new attribute name is expanded, it is compared to all previous local names and uris (for the same element). I tried to do this efficiently, but one can expect a slight impact on performance. Feel free to come up with a better solution. Please test the attached patch (file NSAttFix.diff) for both functional correctness and performance (the patch includes a few cosmetic changes - not to be confused). ---------------------------------------------------------------------- Comment By: Mark E. (snowballville) Date: 2003-02-25 17:33 Message: Logged In: YES user_id=684927 I tried expat 1.95.5 with the same result. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-25 14:02 Message: Logged In: YES user_id=290026 Well, if it is not too much effort, it certainly would be useful information. Thanks, Karl ---------------------------------------------------------------------- Comment By: Mark E. (snowballville) Date: 2003-02-25 13:24 Message: Logged In: YES user_id=684927 Correction: I have used expat 1.95.5 (with pyxml 0.8.1), but I haven't tested this case with it. I will if you want me to. I would expect the same result though. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-25 13:23 Message: Logged In: YES user_id=290026 It looks to me as if this error has always been there, since the modifications required would be significant. No need to test 1.95.5. Karl ---------------------------------------------------------------------- Comment By: Mark E. (snowballville) Date: 2003-02-25 13:21 Message: Logged In: YES user_id=684927 I just got started with using xml with python, so expat 1.95.6 (installed with pyxml 0.8.2) is the only version I've used. I could temporarily download to pyxml 0.8.1 (which includes expat 1.95.5) if you think it informative. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-25 11:35 Message: Logged In: YES user_id=290026 Had a look. Won't be a quick fix. The problem function is StoreAtts(). The solution might be to have a separate function getAttributeIdNS() that looks up attribute id structs by expanded instead of prefixed name. But that may require adjustments to other parts of the code. Hope I have time soon, unless someone else is quicker. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-25 10:44 Message: Logged In: YES user_id=290026 Expat only supports XML Namespaces 1.0, but the bug still applies (section 5.3 of the spec). Will look into it. Does this happen with previous versions of Expat? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=692964&group_id=10127 From noreply at sourceforge.net Mon Mar 3 11:38:44 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Mar 3 14:29:02 2003 Subject: [Expat-bugs] [ expat-Bugs-695401 ] Unbound prefixes not rejected Message-ID: Bugs item #695401, was opened at 2003-02-28 20:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=695401&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Unbound prefixes not rejected Initial Comment: When namespace processing is turned on then unbound prefixes are illegal according to the Namespaces for XML 1.0 specification, section 4, paragraph "Namespace Constraint: Prefix Declared". However, Expat does not reject the following two documents: ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-03 14:38 Message: Logged In: YES user_id=290026 There is a fix for bug #692964 - attachment NSAttFix3.diff - that also includes a fix for this bug. Assigned to Fred for regression tests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=695401&group_id=10127 From noreply at sourceforge.net Fri Mar 7 03:20:36 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 7 06:10:20 2003 Subject: [Expat-bugs] [ expat-Bugs-676844 ] expat.h compile error: enum XML_Status Message-ID: Bugs item #676844, was opened at 2003-01-29 07:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=676844&group_id=10127 Category: Build control Group: None Status: Open Resolution: Fixed Priority: 3 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: expat.h compile error: enum XML_Status Initial Comment: c++ -DHAVE_CONFIG_H -I. -I. -I../../autocfg -g -O2 -c context.cpp -fPIC -DPIC -o .libs/context.lo In file included from parser.h:45, from guard.h:143, from context.cpp:45: /usr/include/expat.h:657: use of enum `XML_Status' without previous declaration /usr/include/expat.h:736: multiple definition of `enum XML_Status' when building sablotron. Hand editing the file to place the def of enum XML_Status before any references to it fixes the problem. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-03-07 03:20 Message: Logged In: NO same problem, same fix when building 1.95.6 on vms (just downloaded .tar.gz & processed - got the rpm, but don't know what to do with it - not an archive type I know how to handle on vms, or windows either) - chris.sharman@ccagroup.co.uk ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-28 18:03 Message: Logged In: YES user_id=290026 Strange - I had no problems with MS VC++ 6.0. Which service pack level have you applied? ---------------------------------------------------------------------- Comment By: Jacob Levy (jyljyljyl) Date: 2003-02-28 17:35 Message: Logged In: YES user_id=63723 This makes Expat 1.95.6 unusable for people who create libraries that depend on Expat but don't include their own copy of Expat. Sure, I can edit expat.h and fix it, but my users should not be expected to do that. For that reason I'm staying with Expat 1.95.5 until this problem is fixed. It'd be really nice if you could make Expat 1.95.7 soon.. In my case GCC 2.95.2 and VC++ 6.0 are complaining. ---------------------------------------------------------------------- Comment By: Melvyn Sopacua (nyvlem) Date: 2003-02-13 23:56 Message: Logged In: YES user_id=212431 Yes, that works. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-06 12:47 Message: Logged In: YES user_id=290026 But current CVS works for you, right? ---------------------------------------------------------------------- Comment By: Melvyn Sopacua (nyvlem) Date: 2003-02-06 12:17 Message: Logged In: YES user_id=212431 > So far only gcc3.2 has complained. Nope: /usr/local/include/expat.h:657: use of enum `XML_Status' without previous declaration /usr/local/include/expat.h:736: multiple definition of `enum XML_Status' gmake[2]: *** [context.lo] Error 1 gmake[2]: Leaving directory `/home/mdev/cvs/sablot/src/engine' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/mdev/cvs/sablot/src' gmake: *** [all-recursive] Error 1 $ gcc --version 2.95.3 ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-01-31 06:43 Message: Logged In: YES user_id=290026 It *is* fixed in CVS. Are you sure you checked out the right version, which is expat.h 1.51? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-01-31 02:34 Message: Logged In: NO I just got the same error, already fixed it. But don't understand why it isn't fixed in CVS ? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-01-29 10:44 Message: Logged In: YES user_id=3066 I've not checked the C89 standard yet, but Expat 1.95.6 is certainly dodgy in this case. ;-( The first draft of the C spec I found online certainly seemed to imply that any use of an incomplete enum is not allowed; I'm not likely to go out and buy a copy of the final spec to check further. ;-) As noted, this has been fixed in CVS. Fixed the summary to better indicate what this report is about, and lowered the priority to get it out of the way for maintainers. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-01-29 07:51 Message: Logged In: YES user_id=290026 So far only gcc3.2 has complained. Not sure if this is a bug, since most compilers accept it, but it has been fixed in CVS already anyway. Set resolution status to fixed, but leave open. There may be other users who would report this as a bug and I want them to see the open report instead of having duplicates created. Assigned to Fred - since he may know more about whether this truly is a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=676844&group_id=10127 From noreply at sourceforge.net Fri Mar 7 03:24:11 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 7 06:13:32 2003 Subject: [Expat-bugs] [ expat-Bugs-692878 ] FASTCALL problem with Solars/gcc Message-ID: Bugs item #692878, was opened at 2003-02-25 13:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=692878&group_id=10127 Category: None Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: FASTCALL problem with Solars/gcc Initial Comment: Talking about 1.95.6 (of course, prior to that, the FASTCALL macro was a noop, if I recall right). I got two independend reports about compiler warnings, while compiling expat with gcc under Solaris. The one specified his gcc version (2.7.2.3) without saying the exact Solaris Version, the other uses Solaris 2.6 and a not specified gcc version. Both get plenty of similar warning like this: In file included from ../expat/xmlrole.h:14, from ../expat/xmlrole.c:14: ../expat/xmltok.h:143: warning: `regparm' attribute directive ignored ../expat/xmltok.h:144: warning: `regparm' attribute directive ignored ../expat/xmltok.h:149: warning: `regparm' attribute directive ignored .... It seems, the FASTCALL macro in internal.h is the source of the trouble. rolf ---------------------------------------------------------------------- >Comment By: Rolf Ade (pointsman) Date: 2003-03-07 11:24 Message: Logged In: YES user_id=13222 More regparm fun. gcc 3.1 on Mac OSX: ../expat/xmltok.h:143: syntax error, found `*' ../expat/xmltok.h:143: illegal member declaration, missing name, found `)' ../expat/xmltok.h:144: syntax error, found `*' ../expat/xmltok.h:144: illegal member declaration, missing name, found `)' ../expat/xmltok.h:149: syntax error, found `*' ../expat/xmltok.h:149: illegal member declaration, missing name, found `)' cpp-precomp: warning: errors during smart preprocessing, retrying in basic mode In file included from ../expat/xmlrole.h:14, from ../expat/xmlrole.c:14: ../expat/xmltok.h:143: warning: `regparm' attribute directive ignored ../expat/xmltok.h:144: warning: `regparm' attribute directive ignored ../expat/xmltok.h:149: warning: `regparm' attribute directive ignored ../expat/xmltok.h:280: warning: `regparm' attribute directive ignored . etc. rolf ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-01 14:25 Message: Logged In: YES user_id=290026 Rolf, In theory regparm(2 or 3) should improve speed since it allows the compiler to choose passing parameters in registers instead of on the stack. The reason why this doesn't work on Windows is that the MS compiler allows register passing to be combined with stdcall only, not with cdecl. And for Expat purposes it seems cdecl is way faster, so this overcompensates any gain register passing with stdcall could give you. However, with gcc it seems that regparm can be combined with cdecl, or rather must be, since AFAIK stdcall doesn't really exist on Linux. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2003-02-25 21:41 Message: Logged In: YES user_id=13222 Freds patch fixed the problem for both reporters: "Works fine now { uname -a SunOS Develop 5.6 Generic_105181-32 sun4u sparc gcc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.7.2.3/specs gcc version 2.7.2.3 }" and "Works for me now as well (gcc v 2.8.1)" Thanks! rolf ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2003-02-25 16:26 Message: Logged In: YES user_id=13222 I've handed the patched version to the original reporters. Will report about the results (if I get answer). Re regparm(2) instead of regparm(3). There isn't a value in using regparm by itself. I think it only makes sense, to use this, if it in deed speeds up things at least a little bit (this seems not guaranteed, as Karls result on w32 shows). If I recall right, Fred had measured a little speed up on linux. I guess, it would be better, to find a volunteer, which checks, if this compiler hints in fact makes a measurable difference, before we try to play advanced tricks. rolf ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-25 15:34 Message: Logged In: YES user_id=290026 This seems to affect older compilers? Maybe a task for the build (autoconf?). One could also try regparm(2) instead of regparm(3). Assuming these compilers recognize regparm at all. Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-02-25 15:24 Message: Logged In: YES user_id=3066 I've attached a patch, but I can't test on an equivalent environment to where you found the problem. It doesn't break the build for Linux. ;-) If you could test this patch to the lib/internal.h file from the CVS version of Expat in the target environments, I'd appreciate knowing if this fixes the problem. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=692878&group_id=10127 From noreply at sourceforge.net Fri Mar 7 03:36:17 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 7 06:25:57 2003 Subject: [Expat-bugs] [ expat-Bugs-699323 ] VMS: descrip.mms incomplete (1.95.6 et al) Message-ID: Bugs item #699323, was opened at 2003-03-07 03:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=699323&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: VMS: descrip.mms incomplete (1.95.6 et al) Initial Comment: MMS fails after updating library with: %MMS-F-GWKNOACTS, Actions to update ALL are unknown. Fix: replace the "all : $(library)" line with: "all : sys$common:[syslib]$(LIBRARY), sys$common:[syslib]expat.h @ ! sys$common:[syslib]$(library) : $(library) copy/log $(mms$source) $(mms$target) sys$common:[syslib]expat.h : $(apiheader) copy/log $(mms$source) $(mms$target) " NB: it's important that each rule consists of a 1-line 'dependency' followed by a 1-line 'action' followed by a blank line. The spaces are important too. (Yes, MMS *is* very picky) - chris.sharman@ccagroup.co.uk ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=699323&group_id=10127 From noreply at sourceforge.net Fri Mar 7 06:08:57 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 7 08:58:01 2003 Subject: [Expat-bugs] [ expat-Bugs-692878 ] FASTCALL problem with Solars/gcc Message-ID: Bugs item #692878, was opened at 2003-02-25 08:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=692878&group_id=10127 Category: None Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: FASTCALL problem with Solars/gcc Initial Comment: Talking about 1.95.6 (of course, prior to that, the FASTCALL macro was a noop, if I recall right). I got two independend reports about compiler warnings, while compiling expat with gcc under Solaris. The one specified his gcc version (2.7.2.3) without saying the exact Solaris Version, the other uses Solaris 2.6 and a not specified gcc version. Both get plenty of similar warning like this: In file included from ../expat/xmlrole.h:14, from ../expat/xmlrole.c:14: ../expat/xmltok.h:143: warning: `regparm' attribute directive ignored ../expat/xmltok.h:144: warning: `regparm' attribute directive ignored ../expat/xmltok.h:149: warning: `regparm' attribute directive ignored .... It seems, the FASTCALL macro in internal.h is the source of the trouble. rolf ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-07 09:08 Message: Logged In: YES user_id=290026 It would be nice if the different versions of gcc could agree on what syntax is legal! ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2003-03-07 06:24 Message: Logged In: YES user_id=13222 More regparm fun. gcc 3.1 on Mac OSX: ../expat/xmltok.h:143: syntax error, found `*' ../expat/xmltok.h:143: illegal member declaration, missing name, found `)' ../expat/xmltok.h:144: syntax error, found `*' ../expat/xmltok.h:144: illegal member declaration, missing name, found `)' ../expat/xmltok.h:149: syntax error, found `*' ../expat/xmltok.h:149: illegal member declaration, missing name, found `)' cpp-precomp: warning: errors during smart preprocessing, retrying in basic mode In file included from ../expat/xmlrole.h:14, from ../expat/xmlrole.c:14: ../expat/xmltok.h:143: warning: `regparm' attribute directive ignored ../expat/xmltok.h:144: warning: `regparm' attribute directive ignored ../expat/xmltok.h:149: warning: `regparm' attribute directive ignored ../expat/xmltok.h:280: warning: `regparm' attribute directive ignored . etc. rolf ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-01 09:25 Message: Logged In: YES user_id=290026 Rolf, In theory regparm(2 or 3) should improve speed since it allows the compiler to choose passing parameters in registers instead of on the stack. The reason why this doesn't work on Windows is that the MS compiler allows register passing to be combined with stdcall only, not with cdecl. And for Expat purposes it seems cdecl is way faster, so this overcompensates any gain register passing with stdcall could give you. However, with gcc it seems that regparm can be combined with cdecl, or rather must be, since AFAIK stdcall doesn't really exist on Linux. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2003-02-25 16:41 Message: Logged In: YES user_id=13222 Freds patch fixed the problem for both reporters: "Works fine now { uname -a SunOS Develop 5.6 Generic_105181-32 sun4u sparc gcc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.7.2.3/specs gcc version 2.7.2.3 }" and "Works for me now as well (gcc v 2.8.1)" Thanks! rolf ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2003-02-25 11:26 Message: Logged In: YES user_id=13222 I've handed the patched version to the original reporters. Will report about the results (if I get answer). Re regparm(2) instead of regparm(3). There isn't a value in using regparm by itself. I think it only makes sense, to use this, if it in deed speeds up things at least a little bit (this seems not guaranteed, as Karls result on w32 shows). If I recall right, Fred had measured a little speed up on linux. I guess, it would be better, to find a volunteer, which checks, if this compiler hints in fact makes a measurable difference, before we try to play advanced tricks. rolf ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-25 10:34 Message: Logged In: YES user_id=290026 This seems to affect older compilers? Maybe a task for the build (autoconf?). One could also try regparm(2) instead of regparm(3). Assuming these compilers recognize regparm at all. Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-02-25 10:24 Message: Logged In: YES user_id=3066 I've attached a patch, but I can't test on an equivalent environment to where you found the problem. It doesn't break the build for Linux. ;-) If you could test this patch to the lib/internal.h file from the CVS version of Expat in the target environments, I'd appreciate knowing if this fixes the problem. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=692878&group_id=10127 From noreply at sourceforge.net Fri Mar 7 06:28:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 7 09:17:51 2003 Subject: [Expat-bugs] [ expat-Bugs-692878 ] FASTCALL problem with Solars/gcc Message-ID: Bugs item #692878, was opened at 2003-02-25 08:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=692878&group_id=10127 Category: None Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: FASTCALL problem with Solars/gcc Initial Comment: Talking about 1.95.6 (of course, prior to that, the FASTCALL macro was a noop, if I recall right). I got two independend reports about compiler warnings, while compiling expat with gcc under Solaris. The one specified his gcc version (2.7.2.3) without saying the exact Solaris Version, the other uses Solaris 2.6 and a not specified gcc version. Both get plenty of similar warning like this: In file included from ../expat/xmlrole.h:14, from ../expat/xmlrole.c:14: ../expat/xmltok.h:143: warning: `regparm' attribute directive ignored ../expat/xmltok.h:144: warning: `regparm' attribute directive ignored ../expat/xmltok.h:149: warning: `regparm' attribute directive ignored .... It seems, the FASTCALL macro in internal.h is the source of the trouble. rolf ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-07 09:28 Message: Logged In: YES user_id=290026 It seems "__attribute__ (regparm(3))" is legal in gcc 3.1. The problem is rather that the function pointer declaration syntax used on line 143 in xmltok.h is not accepted by gcc 3.1. Could you try: 1) define the PTRFASTCALL macro with extra parentheses around or 2) instead of the existing declaration, try this: int PTRFASTCALL(*nameLength)(const ENCODING *, const char *); Itf that works, then I bet it won't work under other versions of gcc, as luck will have it. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-07 09:08 Message: Logged In: YES user_id=290026 It would be nice if the different versions of gcc could agree on what syntax is legal! ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2003-03-07 06:24 Message: Logged In: YES user_id=13222 More regparm fun. gcc 3.1 on Mac OSX: ../expat/xmltok.h:143: syntax error, found `*' ../expat/xmltok.h:143: illegal member declaration, missing name, found `)' ../expat/xmltok.h:144: syntax error, found `*' ../expat/xmltok.h:144: illegal member declaration, missing name, found `)' ../expat/xmltok.h:149: syntax error, found `*' ../expat/xmltok.h:149: illegal member declaration, missing name, found `)' cpp-precomp: warning: errors during smart preprocessing, retrying in basic mode In file included from ../expat/xmlrole.h:14, from ../expat/xmlrole.c:14: ../expat/xmltok.h:143: warning: `regparm' attribute directive ignored ../expat/xmltok.h:144: warning: `regparm' attribute directive ignored ../expat/xmltok.h:149: warning: `regparm' attribute directive ignored ../expat/xmltok.h:280: warning: `regparm' attribute directive ignored . etc. rolf ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-01 09:25 Message: Logged In: YES user_id=290026 Rolf, In theory regparm(2 or 3) should improve speed since it allows the compiler to choose passing parameters in registers instead of on the stack. The reason why this doesn't work on Windows is that the MS compiler allows register passing to be combined with stdcall only, not with cdecl. And for Expat purposes it seems cdecl is way faster, so this overcompensates any gain register passing with stdcall could give you. However, with gcc it seems that regparm can be combined with cdecl, or rather must be, since AFAIK stdcall doesn't really exist on Linux. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2003-02-25 16:41 Message: Logged In: YES user_id=13222 Freds patch fixed the problem for both reporters: "Works fine now { uname -a SunOS Develop 5.6 Generic_105181-32 sun4u sparc gcc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.7.2.3/specs gcc version 2.7.2.3 }" and "Works for me now as well (gcc v 2.8.1)" Thanks! rolf ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2003-02-25 11:26 Message: Logged In: YES user_id=13222 I've handed the patched version to the original reporters. Will report about the results (if I get answer). Re regparm(2) instead of regparm(3). There isn't a value in using regparm by itself. I think it only makes sense, to use this, if it in deed speeds up things at least a little bit (this seems not guaranteed, as Karls result on w32 shows). If I recall right, Fred had measured a little speed up on linux. I guess, it would be better, to find a volunteer, which checks, if this compiler hints in fact makes a measurable difference, before we try to play advanced tricks. rolf ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-25 10:34 Message: Logged In: YES user_id=290026 This seems to affect older compilers? Maybe a task for the build (autoconf?). One could also try regparm(2) instead of regparm(3). Assuming these compilers recognize regparm at all. Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-02-25 10:24 Message: Logged In: YES user_id=3066 I've attached a patch, but I can't test on an equivalent environment to where you found the problem. It doesn't break the build for Linux. ;-) If you could test this patch to the lib/internal.h file from the CVS version of Expat in the target environments, I'd appreciate knowing if this fixes the problem. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=692878&group_id=10127 From noreply at sourceforge.net Fri Mar 7 08:06:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 7 10:56:28 2003 Subject: [Expat-bugs] [ expat-Bugs-692964 ] Case where expat 1.95.6 doesn't report duplicate attributes. Message-ID: Bugs item #692964, was opened at 2003-02-25 10:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=692964&group_id=10127 Category: None >Group: Test Required Status: Open >Resolution: Fixed Priority: 5 Submitted By: Mark E. (snowballville) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Case where expat 1.95.6 doesn't report duplicate attributes. Initial Comment: I believe I found a bug in the Expat parser in detecting duplicate attributes when using namespaces. I'm using Expat 1.95.6 with PyXML 0.8.2. Section 6.3 of the Namespaces 1.1 recommendation requires that no element have two attributes with the same expanded name. Expat 1.95.6 does indeed report a duplicate attribute error with the example given in that section of the document: I've attached a file with the first element removed. Expat doesn't report a duplicate attribute error when processing this file as I believe the recommendation requires. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-07 11:06 Message: Logged In: YES user_id=290026 NSAttFix3.diff applied (with minor modification). New revisions: expat.h 1.52, xmlparse.c 1.109. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-03 14:36 Message: Logged In: YES user_id=290026 The submitted fix - NSAttFix1.diff - seems to work, but has a bad worst case behaviur. For example: assuming 20 attributes in an element, checking for duplicates will require n*(n-1)/2 = 190 string comparisons. I have therefore replaced this with a simplified hash table approach. See the attached file NSAttFix3.diff. In addition, this new patch also fixes bug #695401: "Unbound prefixes not rejected". Several cosmetic changes and some cleanup (removed non-NULL checks when releasing memory) are also included. This requires some more testing. Currently it passes the OASIS xml test suite the same as version 1.95.6. Assigned to Fred for writing the regression tests. ---------------------------------------------------------------------- Comment By: Mark E. (snowballville) Date: 2003-03-01 11:47 Message: Logged In: YES user_id=684927 I checked out the source and built it with DJGPP after applying the patch. I used xmlwf to test the "bad" example I provided and it is flagged as a duplicate error now. Whether the solution is good or not I'll leave to those who know the source. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-28 14:01 Message: Logged In: YES user_id=290026 It turned out that Expat is very resilient against patching this properly without having to re-write major portions of the code that handles attributes and their declarations. I finally decided on a patch that simply hooks into the loop in storeAtts() were prefixed attribute names are expanded. The basic approach is to progressively store the attributes' local names and uris in an array (nsAtts) as they are iterated over, and each time a new attribute name is expanded, it is compared to all previous local names and uris (for the same element). I tried to do this efficiently, but one can expect a slight impact on performance. Feel free to come up with a better solution. Please test the attached patch (file NSAttFix.diff) for both functional correctness and performance (the patch includes a few cosmetic changes - not to be confused). ---------------------------------------------------------------------- Comment By: Mark E. (snowballville) Date: 2003-02-25 17:33 Message: Logged In: YES user_id=684927 I tried expat 1.95.5 with the same result. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-25 14:02 Message: Logged In: YES user_id=290026 Well, if it is not too much effort, it certainly would be useful information. Thanks, Karl ---------------------------------------------------------------------- Comment By: Mark E. (snowballville) Date: 2003-02-25 13:24 Message: Logged In: YES user_id=684927 Correction: I have used expat 1.95.5 (with pyxml 0.8.1), but I haven't tested this case with it. I will if you want me to. I would expect the same result though. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-25 13:23 Message: Logged In: YES user_id=290026 It looks to me as if this error has always been there, since the modifications required would be significant. No need to test 1.95.5. Karl ---------------------------------------------------------------------- Comment By: Mark E. (snowballville) Date: 2003-02-25 13:21 Message: Logged In: YES user_id=684927 I just got started with using xml with python, so expat 1.95.6 (installed with pyxml 0.8.2) is the only version I've used. I could temporarily download to pyxml 0.8.1 (which includes expat 1.95.5) if you think it informative. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-25 11:35 Message: Logged In: YES user_id=290026 Had a look. Won't be a quick fix. The problem function is StoreAtts(). The solution might be to have a separate function getAttributeIdNS() that looks up attribute id structs by expanded instead of prefixed name. But that may require adjustments to other parts of the code. Hope I have time soon, unless someone else is quicker. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-25 10:44 Message: Logged In: YES user_id=290026 Expat only supports XML Namespaces 1.0, but the bug still applies (section 5.3 of the spec). Will look into it. Does this happen with previous versions of Expat? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=692964&group_id=10127 From noreply at sourceforge.net Fri Mar 7 08:07:56 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 7 10:57:37 2003 Subject: [Expat-bugs] [ expat-Bugs-695401 ] Unbound prefixes not rejected Message-ID: Bugs item #695401, was opened at 2003-02-28 20:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=695401&group_id=10127 Category: None >Group: Test Required Status: Open >Resolution: Fixed Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Unbound prefixes not rejected Initial Comment: When namespace processing is turned on then unbound prefixes are illegal according to the Namespaces for XML 1.0 specification, section 4, paragraph "Namespace Constraint: Prefix Declared". However, Expat does not reject the following two documents: ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-07 11:07 Message: Logged In: YES user_id=290026 NSAttFix3.diff applied (minor modification). New revisions: expat.h 1.52, xmlparse.c 1.109. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-03 14:38 Message: Logged In: YES user_id=290026 There is a fix for bug #692964 - attachment NSAttFix3.diff - that also includes a fix for this bug. Assigned to Fred for regression tests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=695401&group_id=10127 From noreply at sourceforge.net Fri Mar 7 08:31:51 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 7 11:20:46 2003 Subject: [Expat-bugs] [ expat-Patches-699487 ] Hash table improvement Message-ID: Patches item #699487, was opened at 2003-03-07 11:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=699487&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) Summary: Hash table improvement Initial Comment: This patch addresses two areas: 1) The current hash function ignores the high byte of UTF-16 characters. This is not good. 2) There is a cheap way to switch from the current method of linear probing (to resolve collisions) to the slightly better double hashing. Ad 1) hashing of wide characters: Currently, the algorithm is like this: h = h * 33 + (unsigned char)c; where h is the hash value and c is a character in the string argument (char or wchar_t). It seems this hashing algorithm belongs to a family of algorithms of the type: h = h * + character where is taken froma list of tried and proven values like 31, 33, 37, 41, 65599 which should be (but are not always) prime numbers. I added a wchar_t version (#ifdef XML_UNICODE) of this type: h = h * 65599 + (unsigned short)c; Ad 2) double hashing: Currently the hash table index is calculated from the hash value by masking out the lower bits according to table size. This works because the table size is a power of 2. But this also means that some bits of the hash value are unused. From these we can therefore generate the second hash value with little extra effort. The patch also updates the inlined hash table implementation used for detecting duplicate prefixed attributes (in function storeAtts()). See the attached file hashpatch1.diff (to be applied against xmlparse.c rev. 1.109). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=699487&group_id=10127 From noreply at sourceforge.net Fri Mar 7 21:06:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 7 23:56:19 2003 Subject: [Expat-bugs] [ expat-Bugs-699802 ] expat.h enum XML_Status in wrong position Message-ID: Bugs item #699802, was opened at 2003-03-07 21:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=699802&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.h enum XML_Status in wrong position Initial Comment: in expat.h enum XML_Status was defined in line 73? but it was referred in line 63? already. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=699802&group_id=10127 From noreply at sourceforge.net Fri Mar 7 21:50:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Mar 8 00:39:56 2003 Subject: [Expat-bugs] [ expat-Bugs-699802 ] expat.h enum XML_Status in wrong position Message-ID: Bugs item #699802, was opened at 2003-03-08 00:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=699802&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: expat.h enum XML_Status in wrong position Initial Comment: in expat.h enum XML_Status was defined in line 73? but it was referred in line 63? already. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-08 00:50 Message: Logged In: YES user_id=290026 This is a duplicate of issue #676844. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=699802&group_id=10127 From noreply at sourceforge.net Wed Mar 12 11:30:11 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Mar 12 14:18:44 2003 Subject: [Expat-bugs] [ expat-Bugs-695401 ] Unbound prefixes not rejected Message-ID: Bugs item #695401, was opened at 2003-02-28 20:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=695401&group_id=10127 Category: None Group: Test Required >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Unbound prefixes not rejected Initial Comment: When namespace processing is turned on then unbound prefixes are illegal according to the Namespaces for XML 1.0 specification, section 4, paragraph "Namespace Constraint: Prefix Declared". However, Expat does not reject the following two documents: ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-03-12 14:30 Message: Logged In: YES user_id=3066 Added regression test in tests/runtests.c 1.49. Closing this report. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-07 11:07 Message: Logged In: YES user_id=290026 NSAttFix3.diff applied (minor modification). New revisions: expat.h 1.52, xmlparse.c 1.109. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-03 14:38 Message: Logged In: YES user_id=290026 There is a fix for bug #692964 - attachment NSAttFix3.diff - that also includes a fix for this bug. Assigned to Fred for regression tests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=695401&group_id=10127 From noreply at sourceforge.net Wed Mar 12 11:31:10 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Mar 12 14:19:44 2003 Subject: [Expat-bugs] [ expat-Bugs-692964 ] Case where expat 1.95.6 doesn't report duplicate attributes. Message-ID: Bugs item #692964, was opened at 2003-02-25 10:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=692964&group_id=10127 Category: None Group: Test Required >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Mark E. (snowballville) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Case where expat 1.95.6 doesn't report duplicate attributes. Initial Comment: I believe I found a bug in the Expat parser in detecting duplicate attributes when using namespaces. I'm using Expat 1.95.6 with PyXML 0.8.2. Section 6.3 of the Namespaces 1.1 recommendation requires that no element have two attributes with the same expanded name. Expat 1.95.6 does indeed report a duplicate attribute error with the example given in that section of the document: I've attached a file with the first element removed. Expat doesn't report a duplicate attribute error when processing this file as I believe the recommendation requires. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-03-12 14:31 Message: Logged In: YES user_id=3066 Added regression test in tests/runtests.c 1.49. Closing this report. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-07 11:06 Message: Logged In: YES user_id=290026 NSAttFix3.diff applied (with minor modification). New revisions: expat.h 1.52, xmlparse.c 1.109. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-03 14:36 Message: Logged In: YES user_id=290026 The submitted fix - NSAttFix1.diff - seems to work, but has a bad worst case behaviur. For example: assuming 20 attributes in an element, checking for duplicates will require n*(n-1)/2 = 190 string comparisons. I have therefore replaced this with a simplified hash table approach. See the attached file NSAttFix3.diff. In addition, this new patch also fixes bug #695401: "Unbound prefixes not rejected". Several cosmetic changes and some cleanup (removed non-NULL checks when releasing memory) are also included. This requires some more testing. Currently it passes the OASIS xml test suite the same as version 1.95.6. Assigned to Fred for writing the regression tests. ---------------------------------------------------------------------- Comment By: Mark E. (snowballville) Date: 2003-03-01 11:47 Message: Logged In: YES user_id=684927 I checked out the source and built it with DJGPP after applying the patch. I used xmlwf to test the "bad" example I provided and it is flagged as a duplicate error now. Whether the solution is good or not I'll leave to those who know the source. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-28 14:01 Message: Logged In: YES user_id=290026 It turned out that Expat is very resilient against patching this properly without having to re-write major portions of the code that handles attributes and their declarations. I finally decided on a patch that simply hooks into the loop in storeAtts() were prefixed attribute names are expanded. The basic approach is to progressively store the attributes' local names and uris in an array (nsAtts) as they are iterated over, and each time a new attribute name is expanded, it is compared to all previous local names and uris (for the same element). I tried to do this efficiently, but one can expect a slight impact on performance. Feel free to come up with a better solution. Please test the attached patch (file NSAttFix.diff) for both functional correctness and performance (the patch includes a few cosmetic changes - not to be confused). ---------------------------------------------------------------------- Comment By: Mark E. (snowballville) Date: 2003-02-25 17:33 Message: Logged In: YES user_id=684927 I tried expat 1.95.5 with the same result. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-25 14:02 Message: Logged In: YES user_id=290026 Well, if it is not too much effort, it certainly would be useful information. Thanks, Karl ---------------------------------------------------------------------- Comment By: Mark E. (snowballville) Date: 2003-02-25 13:24 Message: Logged In: YES user_id=684927 Correction: I have used expat 1.95.5 (with pyxml 0.8.1), but I haven't tested this case with it. I will if you want me to. I would expect the same result though. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-25 13:23 Message: Logged In: YES user_id=290026 It looks to me as if this error has always been there, since the modifications required would be significant. No need to test 1.95.5. Karl ---------------------------------------------------------------------- Comment By: Mark E. (snowballville) Date: 2003-02-25 13:21 Message: Logged In: YES user_id=684927 I just got started with using xml with python, so expat 1.95.6 (installed with pyxml 0.8.2) is the only version I've used. I could temporarily download to pyxml 0.8.1 (which includes expat 1.95.5) if you think it informative. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-25 11:35 Message: Logged In: YES user_id=290026 Had a look. Won't be a quick fix. The problem function is StoreAtts(). The solution might be to have a separate function getAttributeIdNS() that looks up attribute id structs by expanded instead of prefixed name. But that may require adjustments to other parts of the code. Hope I have time soon, unless someone else is quicker. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-25 10:44 Message: Logged In: YES user_id=290026 Expat only supports XML Namespaces 1.0, but the bug still applies (section 5.3 of the spec). Will look into it. Does this happen with previous versions of Expat? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=692964&group_id=10127 From noreply at sourceforge.net Wed Mar 12 14:48:17 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Mar 12 17:36:18 2003 Subject: [Expat-bugs] [ expat-Bugs-618199 ] storeRawNames fix for localPart Message-ID: Bugs item #618199, was opened at 2002-10-03 14:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=618199&group_id=10127 Category: None Group: Test Required >Status: Pending >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: storeRawNames fix for localPart Initial Comment: When storing the raw names after processing a buffer, the pointer to the local-name structure is not updated with the rest of the name structures. This leads to segfaults on my machine. Also when run through valgrind, it reports invalid read accesses. Supplied is a tiny fix for this problem. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-03-12 17:48 Message: Logged In: YES user_id=3066 I'm trying to create a test case that exercises this with Expat 1.95.5, but don't see a lot of information that causes me to think I can reasonably do so. Starting with a buffer that gets freed before a second call to XML_Parse() isn't sufficiet on Linux. Has anyone else been able to reproduce this? Perhaps the original submitter is monitoring this report and can provide more information. (The bug is fixed in 1.95.6 and CVS, but a regression test still seems like a good idea, though isn't critical at this point.) ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-07 16:02 Message: Logged In: YES user_id=3066 For the record: This was committed as lib/xmlparse.c 1.91. Converting to a bug report that needs a regression test written for it. Will assign to me. (The "new" bug is the lack of a corresponding test.) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-10-03 15:25 Message: Logged In: YES user_id=290026 Good catch! Will apply your patch. Thanks, Karl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=618199&group_id=10127 From noreply at sourceforge.net Wed Mar 12 14:55:06 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Mar 12 17:43:37 2003 Subject: [Expat-bugs] [ expat-Bugs-620343 ] segfault: bad API/callback interaction Message-ID: Bugs item #620343, was opened at 2002-10-08 12:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=620343&group_id=10127 Category: Documentation Group: Test Required Status: Open Resolution: Fixed Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: segfault: bad API/callback interaction Initial Comment: There is a bad interaction between the call to the start element handler and the Expat API: After the presence of the callback is checked, the addBinding() function can call XML_SetStartElementHandler(parser, NULL), after which doContent() will still attempt to call the start element handler. This results in a call to the NULL address, resulting in a memory fault. This is unlikely to be an issue for applications written entirely in C, but can reasonably happen when a wrapper library clears callbacks when an error condition or exception has been detected. I've attached a patch and a regression test for this case. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-03-12 17:55 Message: Logged In: YES user_id=3066 Removed documentation of the no-longer-present limitations in doc/reference.html 1.43. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-01-28 10:21 Message: Logged In: YES user_id=3066 It probably does. There should be a bug report on the documentation, to which I'll respond "we need more tests to check this", and a year from now we'll decide the lack of thoses tests won't hold up the next bugfix release. Or maybe I'll just write thoses tests. ;-) For now, re-opening this as a documentation bug (regarding documented limitations that should no longer exist), and marked if "Test Required". Still assigned to me. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-01-28 09:05 Message: Logged In: YES user_id=290026 Should my newest fix ("always call storeAtts") not make the handlkers independent? Therefore, should we not remove the documentation item about the "limitation"? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-01-28 00:55 Message: Logged In: YES user_id=3066 Since there have been no objections, this is being closed, and marked as fixed. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-01-21 22:31 Message: Logged In: YES user_id=3066 While I really like the idea that each handler is completely independent, as the API suggests, I'm not aware of any real-world use case that requires the namespace callbacks but not the element boundary callbacks. Without the use cases, I think we can live with documented limitations. As long as limitations are documented, higher-level layers can implement the fully-decoupled callbacks model if needed, by registering "dummy" callbacks as needed to take the place of application-level callbacks. Since I've added notes to the documentation about the limitations relevant to this issue report, I think this is safe to close if there are no objections in the next day or so. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-01-21 14:32 Message: Logged In: YES user_id=290026 The patch passes the OASIS test-suite correctly, but I am not sure it is worth the extra CPU cycles to make the namespace declaration handlers truly independent of the startElementHandler. Any use cases for that? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-01-21 11:59 Message: Logged In: YES user_id=290026 I have attached a patch (ElmHandlers.diff) that calls storeAtts whenever any of the attribute related handlers is called, i.e. : - startElmHandler, - startNamespaceDeclHandler, and - endNamespaceDeclHandler. The default handler calls are adjusted appropriately. This patch should make it possible to have the namespace declaration handlers called even when no startElementHandlers is set. Please review. Not tested yet. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-01-21 11:14 Message: Logged In: YES user_id=3066 Added notes about the limitation in the documentation: doc/reference.html 1.41 ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-01-21 10:55 Message: Logged In: YES user_id=290026 I had another look and this looks trickier than I thought. I suggest we add documentation that states that the start/endNamespaceDeclHandlers will not be called when the startElementHandler is not set. I'll post more details in a follow-up. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-10-08 13:40 Message: Logged In: YES user_id=290026 I am not *that* eager . You take care of it. Thanks! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-08 13:36 Message: Logged In: YES user_id=3066 Original patch checked in as lib/xmlparse.c 1.92 and tests/runtests.c 1.36, before I saw Karl's comments. Karl: Yes, we should probably fix things so the namespace decl handlers can be set independently, as the API suggests. I can take care of this, unless you beat me to it. ;-) Don't know that it warrants a separate issue report, so I'll leave this one as fixed but open for now. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-10-08 13:21 Message: Logged In: YES user_id=290026 Yes, verified. To be precise, addBinding() can call back to startNamespaceDeclHandler() which then allows the application to clear the startElementHandler. One comment: storeAtts() is called like this if (startElementHandler) { result = storeAtts(parser, ...); ... } presumably because the attributes should only be stored if needed for the startElementHandler. However, storeAtts does double duty by also processing namespace declarations and calling startNamespaceDeclHandler(). So, if that handler is set, should then not storeAtts() be called like this: if (startElementHandler || startNamespaceDeclHandler) { result = storeAtts(parser, ...); ... } And, if true, one should then apply this logic to the other occasions when storeAtts() is called. Or does it not make sense to set startNamespaceDeclHandler when startElementHandler is cleared? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=620343&group_id=10127 From noreply at sourceforge.net Wed Mar 12 15:00:34 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Mar 12 17:48:35 2003 Subject: [Expat-bugs] [ expat-Bugs-620343 ] segfault: bad API/callback interaction Message-ID: Bugs item #620343, was opened at 2002-10-08 12:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=620343&group_id=10127 Category: Documentation Group: Test Required >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: segfault: bad API/callback interaction Initial Comment: There is a bad interaction between the call to the start element handler and the Expat API: After the presence of the callback is checked, the addBinding() function can call XML_SetStartElementHandler(parser, NULL), after which doContent() will still attempt to call the start element handler. This results in a call to the NULL address, resulting in a memory fault. This is unlikely to be an issue for applications written entirely in C, but can reasonably happen when a wrapper library clears callbacks when an error condition or exception has been detected. I've attached a patch and a regression test for this case. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-03-12 18:00 Message: Logged In: YES user_id=3066 Looks like the current tests are good enough. Closing this. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-03-12 17:55 Message: Logged In: YES user_id=3066 Removed documentation of the no-longer-present limitations in doc/reference.html 1.43. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-01-28 10:21 Message: Logged In: YES user_id=3066 It probably does. There should be a bug report on the documentation, to which I'll respond "we need more tests to check this", and a year from now we'll decide the lack of thoses tests won't hold up the next bugfix release. Or maybe I'll just write thoses tests. ;-) For now, re-opening this as a documentation bug (regarding documented limitations that should no longer exist), and marked if "Test Required". Still assigned to me. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-01-28 09:05 Message: Logged In: YES user_id=290026 Should my newest fix ("always call storeAtts") not make the handlkers independent? Therefore, should we not remove the documentation item about the "limitation"? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-01-28 00:55 Message: Logged In: YES user_id=3066 Since there have been no objections, this is being closed, and marked as fixed. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-01-21 22:31 Message: Logged In: YES user_id=3066 While I really like the idea that each handler is completely independent, as the API suggests, I'm not aware of any real-world use case that requires the namespace callbacks but not the element boundary callbacks. Without the use cases, I think we can live with documented limitations. As long as limitations are documented, higher-level layers can implement the fully-decoupled callbacks model if needed, by registering "dummy" callbacks as needed to take the place of application-level callbacks. Since I've added notes to the documentation about the limitations relevant to this issue report, I think this is safe to close if there are no objections in the next day or so. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-01-21 14:32 Message: Logged In: YES user_id=290026 The patch passes the OASIS test-suite correctly, but I am not sure it is worth the extra CPU cycles to make the namespace declaration handlers truly independent of the startElementHandler. Any use cases for that? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-01-21 11:59 Message: Logged In: YES user_id=290026 I have attached a patch (ElmHandlers.diff) that calls storeAtts whenever any of the attribute related handlers is called, i.e. : - startElmHandler, - startNamespaceDeclHandler, and - endNamespaceDeclHandler. The default handler calls are adjusted appropriately. This patch should make it possible to have the namespace declaration handlers called even when no startElementHandlers is set. Please review. Not tested yet. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-01-21 11:14 Message: Logged In: YES user_id=3066 Added notes about the limitation in the documentation: doc/reference.html 1.41 ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-01-21 10:55 Message: Logged In: YES user_id=290026 I had another look and this looks trickier than I thought. I suggest we add documentation that states that the start/endNamespaceDeclHandlers will not be called when the startElementHandler is not set. I'll post more details in a follow-up. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-10-08 13:40 Message: Logged In: YES user_id=290026 I am not *that* eager . You take care of it. Thanks! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-08 13:36 Message: Logged In: YES user_id=3066 Original patch checked in as lib/xmlparse.c 1.92 and tests/runtests.c 1.36, before I saw Karl's comments. Karl: Yes, we should probably fix things so the namespace decl handlers can be set independently, as the API suggests. I can take care of this, unless you beat me to it. ;-) Don't know that it warrants a separate issue report, so I'll leave this one as fixed but open for now. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-10-08 13:21 Message: Logged In: YES user_id=290026 Yes, verified. To be precise, addBinding() can call back to startNamespaceDeclHandler() which then allows the application to clear the startElementHandler. One comment: storeAtts() is called like this if (startElementHandler) { result = storeAtts(parser, ...); ... } presumably because the attributes should only be stored if needed for the startElementHandler. However, storeAtts does double duty by also processing namespace declarations and calling startNamespaceDeclHandler(). So, if that handler is set, should then not storeAtts() be called like this: if (startElementHandler || startNamespaceDeclHandler) { result = storeAtts(parser, ...); ... } And, if true, one should then apply this logic to the other occasions when storeAtts() is called. Or does it not make sense to set startNamespaceDeclHandler when startElementHandler is cleared? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=620343&group_id=10127 From noreply at sourceforge.net Wed Mar 12 15:15:07 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Mar 12 18:03:35 2003 Subject: [Expat-bugs] [ expat-Bugs-692878 ] FASTCALL problem with Solars/gcc Message-ID: Bugs item #692878, was opened at 2003-02-25 08:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=692878&group_id=10127 Category: None Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: FASTCALL problem with Solars/gcc Initial Comment: Talking about 1.95.6 (of course, prior to that, the FASTCALL macro was a noop, if I recall right). I got two independend reports about compiler warnings, while compiling expat with gcc under Solaris. The one specified his gcc version (2.7.2.3) without saying the exact Solaris Version, the other uses Solaris 2.6 and a not specified gcc version. Both get plenty of similar warning like this: In file included from ../expat/xmlrole.h:14, from ../expat/xmlrole.c:14: ../expat/xmltok.h:143: warning: `regparm' attribute directive ignored ../expat/xmltok.h:144: warning: `regparm' attribute directive ignored ../expat/xmltok.h:149: warning: `regparm' attribute directive ignored .... It seems, the FASTCALL macro in internal.h is the source of the trouble. rolf ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-03-12 18:15 Message: Logged In: YES user_id=3066 Committed fix for GCC on Solaris as lib/internal.h 1.5. I think we really need to consider removing all this stuff to avoid having constant portability problems. ;-( ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-07 09:28 Message: Logged In: YES user_id=290026 It seems "__attribute__ (regparm(3))" is legal in gcc 3.1. The problem is rather that the function pointer declaration syntax used on line 143 in xmltok.h is not accepted by gcc 3.1. Could you try: 1) define the PTRFASTCALL macro with extra parentheses around or 2) instead of the existing declaration, try this: int PTRFASTCALL(*nameLength)(const ENCODING *, const char *); Itf that works, then I bet it won't work under other versions of gcc, as luck will have it. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-07 09:08 Message: Logged In: YES user_id=290026 It would be nice if the different versions of gcc could agree on what syntax is legal! ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2003-03-07 06:24 Message: Logged In: YES user_id=13222 More regparm fun. gcc 3.1 on Mac OSX: ../expat/xmltok.h:143: syntax error, found `*' ../expat/xmltok.h:143: illegal member declaration, missing name, found `)' ../expat/xmltok.h:144: syntax error, found `*' ../expat/xmltok.h:144: illegal member declaration, missing name, found `)' ../expat/xmltok.h:149: syntax error, found `*' ../expat/xmltok.h:149: illegal member declaration, missing name, found `)' cpp-precomp: warning: errors during smart preprocessing, retrying in basic mode In file included from ../expat/xmlrole.h:14, from ../expat/xmlrole.c:14: ../expat/xmltok.h:143: warning: `regparm' attribute directive ignored ../expat/xmltok.h:144: warning: `regparm' attribute directive ignored ../expat/xmltok.h:149: warning: `regparm' attribute directive ignored ../expat/xmltok.h:280: warning: `regparm' attribute directive ignored . etc. rolf ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-01 09:25 Message: Logged In: YES user_id=290026 Rolf, In theory regparm(2 or 3) should improve speed since it allows the compiler to choose passing parameters in registers instead of on the stack. The reason why this doesn't work on Windows is that the MS compiler allows register passing to be combined with stdcall only, not with cdecl. And for Expat purposes it seems cdecl is way faster, so this overcompensates any gain register passing with stdcall could give you. However, with gcc it seems that regparm can be combined with cdecl, or rather must be, since AFAIK stdcall doesn't really exist on Linux. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2003-02-25 16:41 Message: Logged In: YES user_id=13222 Freds patch fixed the problem for both reporters: "Works fine now { uname -a SunOS Develop 5.6 Generic_105181-32 sun4u sparc gcc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.7.2.3/specs gcc version 2.7.2.3 }" and "Works for me now as well (gcc v 2.8.1)" Thanks! rolf ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2003-02-25 11:26 Message: Logged In: YES user_id=13222 I've handed the patched version to the original reporters. Will report about the results (if I get answer). Re regparm(2) instead of regparm(3). There isn't a value in using regparm by itself. I think it only makes sense, to use this, if it in deed speeds up things at least a little bit (this seems not guaranteed, as Karls result on w32 shows). If I recall right, Fred had measured a little speed up on linux. I guess, it would be better, to find a volunteer, which checks, if this compiler hints in fact makes a measurable difference, before we try to play advanced tricks. rolf ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-25 10:34 Message: Logged In: YES user_id=290026 This seems to affect older compilers? Maybe a task for the build (autoconf?). One could also try regparm(2) instead of regparm(3). Assuming these compilers recognize regparm at all. Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-02-25 10:24 Message: Logged In: YES user_id=3066 I've attached a patch, but I can't test on an equivalent environment to where you found the problem. It doesn't break the build for Linux. ;-) If you could test this patch to the lib/internal.h file from the CVS version of Expat in the target environments, I'd appreciate knowing if this fixes the problem. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=692878&group_id=10127 From noreply at sourceforge.net Wed Mar 12 16:51:25 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Mar 12 19:40:30 2003 Subject: [Expat-bugs] [ expat-Bugs-692878 ] FASTCALL problem with Solars/gcc Message-ID: Bugs item #692878, was opened at 2003-02-25 13:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=692878&group_id=10127 Category: None Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: FASTCALL problem with Solars/gcc Initial Comment: Talking about 1.95.6 (of course, prior to that, the FASTCALL macro was a noop, if I recall right). I got two independend reports about compiler warnings, while compiling expat with gcc under Solaris. The one specified his gcc version (2.7.2.3) without saying the exact Solaris Version, the other uses Solaris 2.6 and a not specified gcc version. Both get plenty of similar warning like this: In file included from ../expat/xmlrole.h:14, from ../expat/xmlrole.c:14: ../expat/xmltok.h:143: warning: `regparm' attribute directive ignored ../expat/xmltok.h:144: warning: `regparm' attribute directive ignored ../expat/xmltok.h:149: warning: `regparm' attribute directive ignored .... It seems, the FASTCALL macro in internal.h is the source of the trouble. rolf ---------------------------------------------------------------------- >Comment By: Rolf Ade (pointsman) Date: 2003-03-13 00:51 Message: Logged In: YES user_id=13222 This will not fix the problem with gcc 3.1 on Mac OS X. I'm sorry, I ball out, for this time. I'm preparing for a release of an expat based package within the next days, and it will come out with 1.95.6 but without the regparm stuff (made it noop, as it was in 1.95.5). Given the bad experience, I see two major ways at the moent: o Revers the method: Instead of enabling this regparm stuff for gcc as default and only disable it for plattforms with know troubles, disable it per default and enable it only for the plattforms, on which it is know to work and make at least a small positiv (speed up) effect. This would be, as far as I know, at the moment only linux (according to some rumor results by Fred). o Remove it. rolf ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-03-12 23:15 Message: Logged In: YES user_id=3066 Committed fix for GCC on Solaris as lib/internal.h 1.5. I think we really need to consider removing all this stuff to avoid having constant portability problems. ;-( ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-07 14:28 Message: Logged In: YES user_id=290026 It seems "__attribute__ (regparm(3))" is legal in gcc 3.1. The problem is rather that the function pointer declaration syntax used on line 143 in xmltok.h is not accepted by gcc 3.1. Could you try: 1) define the PTRFASTCALL macro with extra parentheses around or 2) instead of the existing declaration, try this: int PTRFASTCALL(*nameLength)(const ENCODING *, const char *); Itf that works, then I bet it won't work under other versions of gcc, as luck will have it. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-07 14:08 Message: Logged In: YES user_id=290026 It would be nice if the different versions of gcc could agree on what syntax is legal! ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2003-03-07 11:24 Message: Logged In: YES user_id=13222 More regparm fun. gcc 3.1 on Mac OSX: ../expat/xmltok.h:143: syntax error, found `*' ../expat/xmltok.h:143: illegal member declaration, missing name, found `)' ../expat/xmltok.h:144: syntax error, found `*' ../expat/xmltok.h:144: illegal member declaration, missing name, found `)' ../expat/xmltok.h:149: syntax error, found `*' ../expat/xmltok.h:149: illegal member declaration, missing name, found `)' cpp-precomp: warning: errors during smart preprocessing, retrying in basic mode In file included from ../expat/xmlrole.h:14, from ../expat/xmlrole.c:14: ../expat/xmltok.h:143: warning: `regparm' attribute directive ignored ../expat/xmltok.h:144: warning: `regparm' attribute directive ignored ../expat/xmltok.h:149: warning: `regparm' attribute directive ignored ../expat/xmltok.h:280: warning: `regparm' attribute directive ignored . etc. rolf ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-01 14:25 Message: Logged In: YES user_id=290026 Rolf, In theory regparm(2 or 3) should improve speed since it allows the compiler to choose passing parameters in registers instead of on the stack. The reason why this doesn't work on Windows is that the MS compiler allows register passing to be combined with stdcall only, not with cdecl. And for Expat purposes it seems cdecl is way faster, so this overcompensates any gain register passing with stdcall could give you. However, with gcc it seems that regparm can be combined with cdecl, or rather must be, since AFAIK stdcall doesn't really exist on Linux. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2003-02-25 21:41 Message: Logged In: YES user_id=13222 Freds patch fixed the problem for both reporters: "Works fine now { uname -a SunOS Develop 5.6 Generic_105181-32 sun4u sparc gcc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.7.2.3/specs gcc version 2.7.2.3 }" and "Works for me now as well (gcc v 2.8.1)" Thanks! rolf ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2003-02-25 16:26 Message: Logged In: YES user_id=13222 I've handed the patched version to the original reporters. Will report about the results (if I get answer). Re regparm(2) instead of regparm(3). There isn't a value in using regparm by itself. I think it only makes sense, to use this, if it in deed speeds up things at least a little bit (this seems not guaranteed, as Karls result on w32 shows). If I recall right, Fred had measured a little speed up on linux. I guess, it would be better, to find a volunteer, which checks, if this compiler hints in fact makes a measurable difference, before we try to play advanced tricks. rolf ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-25 15:34 Message: Logged In: YES user_id=290026 This seems to affect older compilers? Maybe a task for the build (autoconf?). One could also try regparm(2) instead of regparm(3). Assuming these compilers recognize regparm at all. Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-02-25 15:24 Message: Logged In: YES user_id=3066 I've attached a patch, but I can't test on an equivalent environment to where you found the problem. It doesn't break the build for Linux. ;-) If you could test this patch to the lib/internal.h file from the CVS version of Expat in the target environments, I'd appreciate knowing if this fixes the problem. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=692878&group_id=10127 From noreply at sourceforge.net Wed Mar 12 17:13:25 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Mar 12 20:01:28 2003 Subject: [Expat-bugs] [ expat-Bugs-692878 ] FASTCALL problem with Solars/gcc Message-ID: Bugs item #692878, was opened at 2003-02-25 08:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=692878&group_id=10127 Category: None Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: FASTCALL problem with Solars/gcc Initial Comment: Talking about 1.95.6 (of course, prior to that, the FASTCALL macro was a noop, if I recall right). I got two independend reports about compiler warnings, while compiling expat with gcc under Solaris. The one specified his gcc version (2.7.2.3) without saying the exact Solaris Version, the other uses Solaris 2.6 and a not specified gcc version. Both get plenty of similar warning like this: In file included from ../expat/xmlrole.h:14, from ../expat/xmlrole.c:14: ../expat/xmltok.h:143: warning: `regparm' attribute directive ignored ../expat/xmltok.h:144: warning: `regparm' attribute directive ignored ../expat/xmltok.h:149: warning: `regparm' attribute directive ignored .... It seems, the FASTCALL macro in internal.h is the source of the trouble. rolf ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-03-12 20:13 Message: Logged In: YES user_id=3066 The Mac OS X issue is why I didn't close this report. I recall seeing a concrete but small speed improvement on Linux, at least for whatever version of GCC I was using at the time. Given that the speedup was small, I'm currently inclined to remove the FASTCALL/PTRCALL/PTRFASTCALL stuff completely. I'll bring it up on expat-discuss and see if there are any real objections; regardless of how careful we are to enable it only where it's known to help, I expect the maintenance nightmare to only get worse. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2003-03-12 19:51 Message: Logged In: YES user_id=13222 This will not fix the problem with gcc 3.1 on Mac OS X. I'm sorry, I ball out, for this time. I'm preparing for a release of an expat based package within the next days, and it will come out with 1.95.6 but without the regparm stuff (made it noop, as it was in 1.95.5). Given the bad experience, I see two major ways at the moent: o Revers the method: Instead of enabling this regparm stuff for gcc as default and only disable it for plattforms with know troubles, disable it per default and enable it only for the plattforms, on which it is know to work and make at least a small positiv (speed up) effect. This would be, as far as I know, at the moment only linux (according to some rumor results by Fred). o Remove it. rolf ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-03-12 18:15 Message: Logged In: YES user_id=3066 Committed fix for GCC on Solaris as lib/internal.h 1.5. I think we really need to consider removing all this stuff to avoid having constant portability problems. ;-( ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-07 09:28 Message: Logged In: YES user_id=290026 It seems "__attribute__ (regparm(3))" is legal in gcc 3.1. The problem is rather that the function pointer declaration syntax used on line 143 in xmltok.h is not accepted by gcc 3.1. Could you try: 1) define the PTRFASTCALL macro with extra parentheses around or 2) instead of the existing declaration, try this: int PTRFASTCALL(*nameLength)(const ENCODING *, const char *); Itf that works, then I bet it won't work under other versions of gcc, as luck will have it. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-07 09:08 Message: Logged In: YES user_id=290026 It would be nice if the different versions of gcc could agree on what syntax is legal! ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2003-03-07 06:24 Message: Logged In: YES user_id=13222 More regparm fun. gcc 3.1 on Mac OSX: ../expat/xmltok.h:143: syntax error, found `*' ../expat/xmltok.h:143: illegal member declaration, missing name, found `)' ../expat/xmltok.h:144: syntax error, found `*' ../expat/xmltok.h:144: illegal member declaration, missing name, found `)' ../expat/xmltok.h:149: syntax error, found `*' ../expat/xmltok.h:149: illegal member declaration, missing name, found `)' cpp-precomp: warning: errors during smart preprocessing, retrying in basic mode In file included from ../expat/xmlrole.h:14, from ../expat/xmlrole.c:14: ../expat/xmltok.h:143: warning: `regparm' attribute directive ignored ../expat/xmltok.h:144: warning: `regparm' attribute directive ignored ../expat/xmltok.h:149: warning: `regparm' attribute directive ignored ../expat/xmltok.h:280: warning: `regparm' attribute directive ignored . etc. rolf ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-01 09:25 Message: Logged In: YES user_id=290026 Rolf, In theory regparm(2 or 3) should improve speed since it allows the compiler to choose passing parameters in registers instead of on the stack. The reason why this doesn't work on Windows is that the MS compiler allows register passing to be combined with stdcall only, not with cdecl. And for Expat purposes it seems cdecl is way faster, so this overcompensates any gain register passing with stdcall could give you. However, with gcc it seems that regparm can be combined with cdecl, or rather must be, since AFAIK stdcall doesn't really exist on Linux. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2003-02-25 16:41 Message: Logged In: YES user_id=13222 Freds patch fixed the problem for both reporters: "Works fine now { uname -a SunOS Develop 5.6 Generic_105181-32 sun4u sparc gcc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.7.2.3/specs gcc version 2.7.2.3 }" and "Works for me now as well (gcc v 2.8.1)" Thanks! rolf ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2003-02-25 11:26 Message: Logged In: YES user_id=13222 I've handed the patched version to the original reporters. Will report about the results (if I get answer). Re regparm(2) instead of regparm(3). There isn't a value in using regparm by itself. I think it only makes sense, to use this, if it in deed speeds up things at least a little bit (this seems not guaranteed, as Karls result on w32 shows). If I recall right, Fred had measured a little speed up on linux. I guess, it would be better, to find a volunteer, which checks, if this compiler hints in fact makes a measurable difference, before we try to play advanced tricks. rolf ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-25 10:34 Message: Logged In: YES user_id=290026 This seems to affect older compilers? Maybe a task for the build (autoconf?). One could also try regparm(2) instead of regparm(3). Assuming these compilers recognize regparm at all. Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-02-25 10:24 Message: Logged In: YES user_id=3066 I've attached a patch, but I can't test on an equivalent environment to where you found the problem. It doesn't break the build for Linux. ;-) If you could test this patch to the lib/internal.h file from the CVS version of Expat in the target environments, I'd appreciate knowing if this fixes the problem. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=692878&group_id=10127 From noreply at sourceforge.net Wed Mar 12 17:20:47 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Mar 12 20:09:22 2003 Subject: [Expat-bugs] [ expat-Bugs-692878 ] FASTCALL problem with Solars/gcc Message-ID: Bugs item #692878, was opened at 2003-02-25 08:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=692878&group_id=10127 Category: None Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: FASTCALL problem with Solars/gcc Initial Comment: Talking about 1.95.6 (of course, prior to that, the FASTCALL macro was a noop, if I recall right). I got two independend reports about compiler warnings, while compiling expat with gcc under Solaris. The one specified his gcc version (2.7.2.3) without saying the exact Solaris Version, the other uses Solaris 2.6 and a not specified gcc version. Both get plenty of similar warning like this: In file included from ../expat/xmlrole.h:14, from ../expat/xmlrole.c:14: ../expat/xmltok.h:143: warning: `regparm' attribute directive ignored ../expat/xmltok.h:144: warning: `regparm' attribute directive ignored ../expat/xmltok.h:149: warning: `regparm' attribute directive ignored .... It seems, the FASTCALL macro in internal.h is the source of the trouble. rolf ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-12 20:20 Message: Logged In: YES user_id=290026 What about making all of these macros noop, but leaving them there in case anyone wants to to tune Expat for their own purposes? It was some effort to put them there in the first place. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-03-12 20:13 Message: Logged In: YES user_id=3066 The Mac OS X issue is why I didn't close this report. I recall seeing a concrete but small speed improvement on Linux, at least for whatever version of GCC I was using at the time. Given that the speedup was small, I'm currently inclined to remove the FASTCALL/PTRCALL/PTRFASTCALL stuff completely. I'll bring it up on expat-discuss and see if there are any real objections; regardless of how careful we are to enable it only where it's known to help, I expect the maintenance nightmare to only get worse. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2003-03-12 19:51 Message: Logged In: YES user_id=13222 This will not fix the problem with gcc 3.1 on Mac OS X. I'm sorry, I ball out, for this time. I'm preparing for a release of an expat based package within the next days, and it will come out with 1.95.6 but without the regparm stuff (made it noop, as it was in 1.95.5). Given the bad experience, I see two major ways at the moent: o Revers the method: Instead of enabling this regparm stuff for gcc as default and only disable it for plattforms with know troubles, disable it per default and enable it only for the plattforms, on which it is know to work and make at least a small positiv (speed up) effect. This would be, as far as I know, at the moment only linux (according to some rumor results by Fred). o Remove it. rolf ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-03-12 18:15 Message: Logged In: YES user_id=3066 Committed fix for GCC on Solaris as lib/internal.h 1.5. I think we really need to consider removing all this stuff to avoid having constant portability problems. ;-( ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-07 09:28 Message: Logged In: YES user_id=290026 It seems "__attribute__ (regparm(3))" is legal in gcc 3.1. The problem is rather that the function pointer declaration syntax used on line 143 in xmltok.h is not accepted by gcc 3.1. Could you try: 1) define the PTRFASTCALL macro with extra parentheses around or 2) instead of the existing declaration, try this: int PTRFASTCALL(*nameLength)(const ENCODING *, const char *); Itf that works, then I bet it won't work under other versions of gcc, as luck will have it. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-07 09:08 Message: Logged In: YES user_id=290026 It would be nice if the different versions of gcc could agree on what syntax is legal! ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2003-03-07 06:24 Message: Logged In: YES user_id=13222 More regparm fun. gcc 3.1 on Mac OSX: ../expat/xmltok.h:143: syntax error, found `*' ../expat/xmltok.h:143: illegal member declaration, missing name, found `)' ../expat/xmltok.h:144: syntax error, found `*' ../expat/xmltok.h:144: illegal member declaration, missing name, found `)' ../expat/xmltok.h:149: syntax error, found `*' ../expat/xmltok.h:149: illegal member declaration, missing name, found `)' cpp-precomp: warning: errors during smart preprocessing, retrying in basic mode In file included from ../expat/xmlrole.h:14, from ../expat/xmlrole.c:14: ../expat/xmltok.h:143: warning: `regparm' attribute directive ignored ../expat/xmltok.h:144: warning: `regparm' attribute directive ignored ../expat/xmltok.h:149: warning: `regparm' attribute directive ignored ../expat/xmltok.h:280: warning: `regparm' attribute directive ignored . etc. rolf ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-01 09:25 Message: Logged In: YES user_id=290026 Rolf, In theory regparm(2 or 3) should improve speed since it allows the compiler to choose passing parameters in registers instead of on the stack. The reason why this doesn't work on Windows is that the MS compiler allows register passing to be combined with stdcall only, not with cdecl. And for Expat purposes it seems cdecl is way faster, so this overcompensates any gain register passing with stdcall could give you. However, with gcc it seems that regparm can be combined with cdecl, or rather must be, since AFAIK stdcall doesn't really exist on Linux. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2003-02-25 16:41 Message: Logged In: YES user_id=13222 Freds patch fixed the problem for both reporters: "Works fine now { uname -a SunOS Develop 5.6 Generic_105181-32 sun4u sparc gcc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.7.2.3/specs gcc version 2.7.2.3 }" and "Works for me now as well (gcc v 2.8.1)" Thanks! rolf ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2003-02-25 11:26 Message: Logged In: YES user_id=13222 I've handed the patched version to the original reporters. Will report about the results (if I get answer). Re regparm(2) instead of regparm(3). There isn't a value in using regparm by itself. I think it only makes sense, to use this, if it in deed speeds up things at least a little bit (this seems not guaranteed, as Karls result on w32 shows). If I recall right, Fred had measured a little speed up on linux. I guess, it would be better, to find a volunteer, which checks, if this compiler hints in fact makes a measurable difference, before we try to play advanced tricks. rolf ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-25 10:34 Message: Logged In: YES user_id=290026 This seems to affect older compilers? Maybe a task for the build (autoconf?). One could also try regparm(2) instead of regparm(3). Assuming these compilers recognize regparm at all. Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-02-25 10:24 Message: Logged In: YES user_id=3066 I've attached a patch, but I can't test on an equivalent environment to where you found the problem. It doesn't break the build for Linux. ;-) If you could test this patch to the lib/internal.h file from the CVS version of Expat in the target environments, I'd appreciate knowing if this fixes the problem. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=692878&group_id=10127 From noreply at sourceforge.net Wed Mar 12 17:42:55 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Mar 12 20:31:27 2003 Subject: [Expat-bugs] [ expat-Bugs-679468 ] Slight error in documentation Message-ID: Bugs item #679468, was opened at 2003-02-03 07:56 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=679468&group_id=10127 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Kenneth Gangsto (sphair) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Slight error in documentation Initial Comment: In the reference documentation of Expat 1.95.6, the following function is listed: const XML_LChar *XML_ErrorString(int code); Return a string describing the error corresponding to code. The code should be one of the enums that can be returned from XML_GetErrorCode. But in the header this is defined as: XML_ErrorString(enum XML_Error code); ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-03-12 20:42 Message: Logged In: YES user_id=3066 Good catch! I've fixed this in doc/reference.html 1.44. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=679468&group_id=10127 From noreply at sourceforge.net Wed Mar 12 18:30:06 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Mar 12 21:18:38 2003 Subject: [Expat-bugs] [ expat-Bugs-683681 ] XML_GetCurrent* functions for doctype declaration/DTD events Message-ID: Bugs item #683681, was opened at 2003-02-09 20:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=683681&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: XML_GetCurrent* functions for doctype declaration/DTD events Initial Comment: I find (1.95.6) the return values of the XML_GetCurrent* functions, if called in a doctype declaration or DTD event handler (XML_StartDoctypeDeclHandler, XML_EndDoctypeDeclHandler, XML_ElementDeclHandler etc.), surprising and at least under documented. The reference.html file is a bit spare about the XML_GetCurrent* functions. For example, the documentation of XML_GetCurrentLineNumber() says only: "Return the line number of the position." What exactly is 'the postion', if the function is called in a event handler? The comments in the expat.h file are more explicit. Especially they mention: They may be called from any callback called to report some parse event; in this case the location is the location of the first of the sequence of characters that generated the event. Now consider for example the following simple xml data: ]> A simple demo program, which calls all the XML_GetCurrent* functions in the XML_StartDoctypeDeclHandler(), XML_EndDoctypeDeclHandler(), XML_ElementDeclHandler() and XML_AttlistDeclHandler() gives the following output: doctypeStart: line 1 column 44 index 44 count 1 elementDecl: line 2 column 18 index 64 count 0 attlistDecl: line 3 column 29 index 100 count 0 doctypeEnd: line 4 column 1 index 111 count 1 elementStart: line 5 column 0 index 113 count 20 If called in an elementStart handler, the XML_GetCurrent* functions return sensible values. Line 5 column 0 is the opening "<" of that tag, as the comment in expat.h says, and the complete markup reported is 20 characters long. Very fine. If called in the doctype declaration start handler, element declaration handler or attlist declaration handler, the results getting stranger. The position, reported by the XML_GetCurrentLine/ColumnNumber is somewhere inside the reported markup and the results of XML_GetCurrentByteCount looks really somewhat wired. At least, the result of XML_GetCurrentByteIndex points always to the same char as XML_GetCurrentLine/ColumnNumber. The current behavior seems to allow me, to do what I want (preserve the internal subset as found in the original XML data, with copying the parts of the input streams as indicated by XML_GetCurrent* function calls in the doctype declaration start/end handler) but all in all, this behavior isn't really considered to be stable or 'the right one' and for sure, it's not documented, so that one could bank on it. rolf ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-03-12 21:30 Message: Logged In: YES user_id=3066 Improved explanations in doc/reference.html 1.45 and lib/expat.h 1.53. Closing this report; the behavior should not be expected to change at this time. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2003-02-10 11:09 Message: Logged In: YES user_id=13222 Ah, right, Karl. I missed that sentences at the start of the chapter "Parse position and error reporting functions", because I jumped from the toc via in page link to XML_GetCurrentLineNumber(). Sorry for that :-(. For my concrete problem the current behaviour seems to be 'just right' - what XML_GetCurrentLine/ColumnNumber return in a doctype declaration start element is exactly the information, I need. But since it isn't documented (or better it is documented as 'bogus information), this may change at any point, and seems nothing, to rely on. Though, this isn't really important to me, at the moment, so there is no action needed (eventually beside a small addition to the related comment in expat.h, to clearify the topic also at this point). Thanks rolf ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-09 21:32 Message: Logged In: YES user_id=290026 This is what reference.html has to say: The position reporting functions are accurate only outside of the DTD. In other words, they usually return bogus information when called from within a DTD declaration handler. I don't know why nothing like that is mentioned in expat.h. Strictly speaking this works as documented and is not a bug. However, it would be nice if it worked as Rolf wanted it to. I haven't had a chance yet to investigate to which degree it would be possible to fix that. Any ideas? Leave open for Fred to comment (here and in expat.h ). Karl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=683681&group_id=10127 From noreply at sourceforge.net Wed Mar 12 18:31:27 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Mar 12 21:20:22 2003 Subject: [Expat-bugs] [ expat-Bugs-679754 ] 1.95.6 - error in compilation, if XML_DTD is not defined Message-ID: Bugs item #679754, was opened at 2003-02-03 14:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=679754&group_id=10127 Category: None Group: None >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Artyom Bolgar (artyom17) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: 1.95.6 - error in compilation, if XML_DTD is not defined Initial Comment: Hi! The new Expat 1.95.6 is uncompilable, if XML_DTD macro is not defined. More exactly, the problem is in the xmlparse.c file, line #616: ------------------ #ifdef XML_DTD #define isParamEntity (parser->m_isParamEntity) #define useForeignDTD (parser->m_useForeignDTD) #define paramEntityParsing (parser- >m_paramEntityParsing) #endif /* XML_DTD */ #define parsing \ (parentParser \ ? \ (isParamEntity \ // <<<<< !AB ? \ (processor != externalParEntInitProcessor) \ : \ (processor != externalEntityInitProcessor)) \ : \ (processor != prologInitProcessor)) -------------------- Look at the line marked as "<<<<< !AB". The isParamEntity macro exists only if XML_DTD is defined, that is why this file can't be compiled in this case. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-03 15:40 Message: Logged In: YES user_id=290026 Yes, that is a bug. Fixed in xmlparse.c rev. 1.108. Leave open for Fred, in case he wants to add a comment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=679754&group_id=10127 From noreply at sourceforge.net Thu Mar 13 05:26:07 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 13 08:14:28 2003 Subject: [Expat-bugs] [ expat-Bugs-695407 ] Reserved prefixes and namespace names Message-ID: Bugs item #695407, was opened at 2003-02-28 20:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=695407&group_id=10127 Category: None Group: None Status: Open Resolution: None >Priority: 3 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) Summary: Reserved prefixes and namespace names Initial Comment: Expat does not reject illegal declarations for reserved prefixes and namespace names. From the errata for the Namespaces in XML 1.0 specs: The prefix xml is by definition bound to the namespace name http://www.w3.org/XML/1998/namespace. It may, but need not, be declared, and must not be bound to any other namespace name. No other prefix may be bound to this namespace name. The prefix xmlns is used only to declare namespace bindings and is by definition bound to the namespace name http://www.w3.org/2000/xmlns/. It must not be declared. No other prefix may be bound to this namespace name. The following four not-well-formed documents are not rejected by Expat: ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-13 08:26 Message: Logged In: YES user_id=290026 Lowered priority to 3. This bug really doesn't have much impact in practical applications, but fixing it may add noticeable overhead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=695407&group_id=10127 From noreply at sourceforge.net Fri Mar 14 09:38:47 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 14 12:27:25 2003 Subject: [Expat-bugs] [ expat-Bugs-692878 ] FASTCALL problem with Solars/gcc Message-ID: Bugs item #692878, was opened at 2003-02-25 08:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=692878&group_id=10127 Category: None Group: Platform Specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: FASTCALL problem with Solars/gcc Initial Comment: Talking about 1.95.6 (of course, prior to that, the FASTCALL macro was a noop, if I recall right). I got two independend reports about compiler warnings, while compiling expat with gcc under Solaris. The one specified his gcc version (2.7.2.3) without saying the exact Solaris Version, the other uses Solaris 2.6 and a not specified gcc version. Both get plenty of similar warning like this: In file included from ../expat/xmlrole.h:14, from ../expat/xmlrole.c:14: ../expat/xmltok.h:143: warning: `regparm' attribute directive ignored ../expat/xmltok.h:144: warning: `regparm' attribute directive ignored ../expat/xmltok.h:149: warning: `regparm' attribute directive ignored .... It seems, the FASTCALL macro in internal.h is the source of the trouble. rolf ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-03-14 12:38 Message: Logged In: YES user_id=3066 Here's the compromise, committed as lib/internal.h 1.6: The *CALL macros are disabled for all platforms other than GCC on Linux, which is the only case where they're known to work and be of some positive value. Everyone else needs to define them if they want them. Closing this report. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-12 20:20 Message: Logged In: YES user_id=290026 What about making all of these macros noop, but leaving them there in case anyone wants to to tune Expat for their own purposes? It was some effort to put them there in the first place. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-03-12 20:13 Message: Logged In: YES user_id=3066 The Mac OS X issue is why I didn't close this report. I recall seeing a concrete but small speed improvement on Linux, at least for whatever version of GCC I was using at the time. Given that the speedup was small, I'm currently inclined to remove the FASTCALL/PTRCALL/PTRFASTCALL stuff completely. I'll bring it up on expat-discuss and see if there are any real objections; regardless of how careful we are to enable it only where it's known to help, I expect the maintenance nightmare to only get worse. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2003-03-12 19:51 Message: Logged In: YES user_id=13222 This will not fix the problem with gcc 3.1 on Mac OS X. I'm sorry, I ball out, for this time. I'm preparing for a release of an expat based package within the next days, and it will come out with 1.95.6 but without the regparm stuff (made it noop, as it was in 1.95.5). Given the bad experience, I see two major ways at the moent: o Revers the method: Instead of enabling this regparm stuff for gcc as default and only disable it for plattforms with know troubles, disable it per default and enable it only for the plattforms, on which it is know to work and make at least a small positiv (speed up) effect. This would be, as far as I know, at the moment only linux (according to some rumor results by Fred). o Remove it. rolf ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-03-12 18:15 Message: Logged In: YES user_id=3066 Committed fix for GCC on Solaris as lib/internal.h 1.5. I think we really need to consider removing all this stuff to avoid having constant portability problems. ;-( ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-07 09:28 Message: Logged In: YES user_id=290026 It seems "__attribute__ (regparm(3))" is legal in gcc 3.1. The problem is rather that the function pointer declaration syntax used on line 143 in xmltok.h is not accepted by gcc 3.1. Could you try: 1) define the PTRFASTCALL macro with extra parentheses around or 2) instead of the existing declaration, try this: int PTRFASTCALL(*nameLength)(const ENCODING *, const char *); Itf that works, then I bet it won't work under other versions of gcc, as luck will have it. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-07 09:08 Message: Logged In: YES user_id=290026 It would be nice if the different versions of gcc could agree on what syntax is legal! ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2003-03-07 06:24 Message: Logged In: YES user_id=13222 More regparm fun. gcc 3.1 on Mac OSX: ../expat/xmltok.h:143: syntax error, found `*' ../expat/xmltok.h:143: illegal member declaration, missing name, found `)' ../expat/xmltok.h:144: syntax error, found `*' ../expat/xmltok.h:144: illegal member declaration, missing name, found `)' ../expat/xmltok.h:149: syntax error, found `*' ../expat/xmltok.h:149: illegal member declaration, missing name, found `)' cpp-precomp: warning: errors during smart preprocessing, retrying in basic mode In file included from ../expat/xmlrole.h:14, from ../expat/xmlrole.c:14: ../expat/xmltok.h:143: warning: `regparm' attribute directive ignored ../expat/xmltok.h:144: warning: `regparm' attribute directive ignored ../expat/xmltok.h:149: warning: `regparm' attribute directive ignored ../expat/xmltok.h:280: warning: `regparm' attribute directive ignored . etc. rolf ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-01 09:25 Message: Logged In: YES user_id=290026 Rolf, In theory regparm(2 or 3) should improve speed since it allows the compiler to choose passing parameters in registers instead of on the stack. The reason why this doesn't work on Windows is that the MS compiler allows register passing to be combined with stdcall only, not with cdecl. And for Expat purposes it seems cdecl is way faster, so this overcompensates any gain register passing with stdcall could give you. However, with gcc it seems that regparm can be combined with cdecl, or rather must be, since AFAIK stdcall doesn't really exist on Linux. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2003-02-25 16:41 Message: Logged In: YES user_id=13222 Freds patch fixed the problem for both reporters: "Works fine now { uname -a SunOS Develop 5.6 Generic_105181-32 sun4u sparc gcc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.7.2.3/specs gcc version 2.7.2.3 }" and "Works for me now as well (gcc v 2.8.1)" Thanks! rolf ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2003-02-25 11:26 Message: Logged In: YES user_id=13222 I've handed the patched version to the original reporters. Will report about the results (if I get answer). Re regparm(2) instead of regparm(3). There isn't a value in using regparm by itself. I think it only makes sense, to use this, if it in deed speeds up things at least a little bit (this seems not guaranteed, as Karls result on w32 shows). If I recall right, Fred had measured a little speed up on linux. I guess, it would be better, to find a volunteer, which checks, if this compiler hints in fact makes a measurable difference, before we try to play advanced tricks. rolf ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-25 10:34 Message: Logged In: YES user_id=290026 This seems to affect older compilers? Maybe a task for the build (autoconf?). One could also try regparm(2) instead of regparm(3). Assuming these compilers recognize regparm at all. Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-02-25 10:24 Message: Logged In: YES user_id=3066 I've attached a patch, but I can't test on an equivalent environment to where you found the problem. It doesn't break the build for Linux. ;-) If you could test this patch to the lib/internal.h file from the CVS version of Expat in the target environments, I'd appreciate knowing if this fixes the problem. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=692878&group_id=10127 From noreply at sourceforge.net Sat Mar 15 13:13:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Mar 15 16:01:41 2003 Subject: [Expat-bugs] [ expat-Bugs-704264 ] Undeclared prefixes and duplicate prefixed attrs Message-ID: Bugs item #704264, was opened at 2003-03-15 14:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=704264&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Kloth (jkloth) Assigned to: Nobody/Anonymous (nobody) Summary: Undeclared prefixes and duplicate prefixed attrs Initial Comment: Per the XML Namespaces 1.0 spec the following documents should not be well-formed. The attached patch against version 1.95.6 fixes these three issues. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=704264&group_id=10127 From noreply at sourceforge.net Sat Mar 15 13:28:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Mar 15 16:15:58 2003 Subject: [Expat-bugs] [ expat-Bugs-618199 ] storeRawNames fix for localPart Message-ID: Bugs item #618199, was opened at 2002-10-03 12:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=618199&group_id=10127 Category: None Group: Test Required Status: Pending Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: storeRawNames fix for localPart Initial Comment: When storing the raw names after processing a buffer, the pointer to the local-name structure is not updated with the rest of the name structures. This leads to segfaults on my machine. Also when run through valgrind, it reports invalid read accesses. Supplied is a tiny fix for this problem. ---------------------------------------------------------------------- Comment By: Jeremy Kloth (jkloth) Date: 2003-03-15 14:28 Message: Logged In: YES user_id=38980 To reproduce the segfault, I think the following steps are needed: 1. A finished call to XML_ParseBuffer with some tags still open, 2. The during next call to XML_ParseBuffer, a tag needs to be closed and then a new tag started that is longer than the previously closed tag (enough to overflow the previous allocation) Or, run the tests through a memory verification tool (valgrind) and the read of free'd (realloc'ed really) memory shows up. Hope this helps. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-03-12 15:48 Message: Logged In: YES user_id=3066 I'm trying to create a test case that exercises this with Expat 1.95.5, but don't see a lot of information that causes me to think I can reasonably do so. Starting with a buffer that gets freed before a second call to XML_Parse() isn't sufficiet on Linux. Has anyone else been able to reproduce this? Perhaps the original submitter is monitoring this report and can provide more information. (The bug is fixed in 1.95.6 and CVS, but a regression test still seems like a good idea, though isn't critical at this point.) ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-07 14:02 Message: Logged In: YES user_id=3066 For the record: This was committed as lib/xmlparse.c 1.91. Converting to a bug report that needs a regression test written for it. Will assign to me. (The "new" bug is the lack of a corresponding test.) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-10-03 13:25 Message: Logged In: YES user_id=290026 Good catch! Will apply your patch. Thanks, Karl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=618199&group_id=10127 From noreply at sourceforge.net Sat Mar 15 15:27:58 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Mar 15 18:15:29 2003 Subject: [Expat-bugs] [ expat-Bugs-704264 ] Undeclared prefixes and duplicate prefixed attrs Message-ID: Bugs item #704264, was opened at 2003-03-15 16:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=704264&group_id=10127 Category: None Group: None Status: Open >Resolution: Duplicate Priority: 5 Submitted By: Jeremy Kloth (jkloth) >Assigned to: Karl Waclawek (kwaclaw) Summary: Undeclared prefixes and duplicate prefixed attrs Initial Comment: Per the XML Namespaces 1.0 spec the following documents should not be well-formed. The attached patch against version 1.95.6 fixes these three issues. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-15 18:27 Message: Logged In: YES user_id=290026 This is a duplicate of bugs #692964 and #695401. A patch has already been applied to CVS. I will review your patch to check if anything is missing in the already applied patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=704264&group_id=10127 From noreply at sourceforge.net Sun Mar 16 13:33:27 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Mar 16 16:20:50 2003 Subject: [Expat-bugs] [ expat-Bugs-699323 ] VMS: descrip.mms incomplete (1.95.6 et al) Message-ID: Bugs item #699323, was opened at 2003-03-07 11:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=699323&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: VMS: descrip.mms incomplete (1.95.6 et al) Initial Comment: MMS fails after updating library with: %MMS-F-GWKNOACTS, Actions to update ALL are unknown. Fix: replace the "all : $(library)" line with: "all : sys$common:[syslib]$(LIBRARY), sys$common:[syslib]expat.h @ ! sys$common:[syslib]$(library) : $(library) copy/log $(mms$source) $(mms$target) sys$common:[syslib]expat.h : $(apiheader) copy/log $(mms$source) $(mms$target) " NB: it's important that each rule consists of a 1-line 'dependency' followed by a 1-line 'action' followed by a blank line. The spaces are important too. (Yes, MMS *is* very picky) - chris.sharman@ccagroup.co.uk ---------------------------------------------------------------------- Comment By: Craig A. Berry (berryc) Date: 2003-03-16 21:33 Message: Logged In: YES user_id=717096 The suggested fix is incorrect because it installs the object library and expat.h in a system directory as part of the build process. It's questionable whether a package should ever put its own files in sys$common:[syslib], and if it does, it should do so as part of a separate install step (not currently implemented) and not as part of the initial make. There is nothing wrong with not having an action line, but it does lead to a less than informative message in the case of the "all" target, which exists solely to drive the other dependencies. The patch below is all that's needed to replace that message with something more informative: --- vms/descrip.mms;-0 Tue Jun 4 23:13:10 2002 +++ vms/descrip.mms Sun Mar 16 14:47:46 2003 @@ -40,2 +40,3 @@ all : $(LIBRARY) + @ write sys$output "All made." [end of patch] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=699323&group_id=10127 From noreply at sourceforge.net Thu Mar 20 09:30:20 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 20 12:17:03 2003 Subject: [Expat-bugs] [ expat-Bugs-707021 ] Improve internal entity reporting Message-ID: Bugs item #707021, was opened at 2003-03-20 12:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=707021&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: Improve internal entity reporting Initial Comment: Currently there are limitations to the reporting of internal entities, which affects DOM building and validation on top of Epat: - When internal entities are expanded, then there is no way to determine when an entity starts or ends. - When they are not expanded (in content) then the entity references are reported through the skippedEntityHandler or the defaultHandler, which is a crude way to detect entity boundaries since it now places the burden of expansion on the call-back code. - PE references in entity values (declarations) and GE references in attribute values are always silently expanded (if possible) and there is no way to detect entity boundaries, even when skipped It would be nice to have a way to report internal entity boundaries in character content, entity values and attribute values in a uniform way, whether the entity is expanded or not. It could be an optional feature, but likely not through setting start/endEntityHandlers, since such handlers would not work for attribute and entity values, as these are not reported in a streaming fashion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=707021&group_id=10127 From noreply at sourceforge.net Fri Mar 21 04:38:50 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 21 07:26:22 2003 Subject: [Expat-bugs] [ expat-Bugs-707464 ] expat 1.95.6 raises "Access violation" on WinXP Message-ID: Bugs item #707464, was opened at 2003-03-21 14:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=707464&group_id=10127 Category: www.libexpat.org Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Dragos Onac (dragos_o) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: expat 1.95.6 raises "Access violation" on WinXP Initial Comment: Running the "elements.c" example on a specific XML file causes the Access Violation message do be displayed, when the code is compiled without debug info. The "Acces violation" issue could also be reproduced using the dll from the win32 package. I don't know how useful this is, but when running the "elements.c" example by compiling all the files with the NuMega Bounds Checker, the following erorr message is shown at line line 1511 of file xmlparse.c: "Expresion uses dangling pointer" The line is: bufferEnd = buffer + (bufferEnd - bufferPtr) + keep; (parser->m_bufferEnd-parser->m_bufferPtr)+keep equals 2048 Stack trace: main()->XML_Parse()->XML_GetBuffer() Input file is attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=707464&group_id=10127 From noreply at sourceforge.net Fri Mar 21 04:51:35 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 21 07:38:40 2003 Subject: [Expat-bugs] [ expat-Bugs-707469 ] external param entities Message-ID: Bugs item #707469, was opened at 2003-03-21 12:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=707469&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pavel Hlavnicka (pavel_hlavnicka) Assigned to: Nobody/Anonymous (nobody) Summary: external param entities Initial Comment: Hi all, perhaps, this is not a bug, perhaps it is. Give me some explanation in the first case, please. 1) look at the example 2) It happens with 1.95.5 and 1.95.4 at least We use expat in sablotron xslt processor. We do support external entity parsing, and in addition we allow users to tell, whether they want to parse public external entities or not. In such a case we just return 1 from our entity reference handler. (No entity parser is created). It results to a strange behavior, if following scenario happens: - the parsed document contains - file.dtd contains the declaration of external public parameter entity - file.dtd references this entity - file dtd defines other entities This is sample file.dtd: %foo; If %foo; is not referenced, all works fine, and &baz; means "somedata". If %foo; is referenced, an error occurs while parsing , it seems, that the entity expansion of %baz; and %bar; is empty. If I replace with paring goes fine, but &baz; points to an empty string. I played with a debugger a bit, and what I found was, that if entity parser is not created in entity ref. handler. dtd.paramEntityRead is not set to true, and dtd.keepProcessing is set to false consequently. I'm not sure, what the mission of dtd.keepProcessing is, but it seems, that it stays valid a bit longer then needed. Or do you really mean, that the whole file.dtd content should be skipped, if the %foo; reference was not resolved? If so, why I can see the compilation error? Thank you very much and thanks for expat. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=707469&group_id=10127 From noreply at sourceforge.net Fri Mar 21 06:25:07 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 21 09:12:44 2003 Subject: [Expat-bugs] [ expat-Bugs-707469 ] external param entities Message-ID: Bugs item #707469, was opened at 2003-03-21 07:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=707469&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pavel Hlavnicka (pavel_hlavnicka) Assigned to: Nobody/Anonymous (nobody) Summary: external param entities Initial Comment: Hi all, perhaps, this is not a bug, perhaps it is. Give me some explanation in the first case, please. 1) look at the example 2) It happens with 1.95.5 and 1.95.4 at least We use expat in sablotron xslt processor. We do support external entity parsing, and in addition we allow users to tell, whether they want to parse public external entities or not. In such a case we just return 1 from our entity reference handler. (No entity parser is created). It results to a strange behavior, if following scenario happens: - the parsed document contains - file.dtd contains the declaration of external public parameter entity - file.dtd references this entity - file dtd defines other entities This is sample file.dtd: %foo; If %foo; is not referenced, all works fine, and &baz; means "somedata". If %foo; is referenced, an error occurs while parsing , it seems, that the entity expansion of %baz; and %bar; is empty. If I replace with paring goes fine, but &baz; points to an empty string. I played with a debugger a bit, and what I found was, that if entity parser is not created in entity ref. handler. dtd.paramEntityRead is not set to true, and dtd.keepProcessing is set to false consequently. I'm not sure, what the mission of dtd.keepProcessing is, but it seems, that it stays valid a bit longer then needed. Or do you really mean, that the whole file.dtd content should be skipped, if the %foo; reference was not resolved? If so, why I can see the compilation error? Thank you very much and thanks for expat. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-21 09:25 Message: Logged In: YES user_id=290026 This has to do with section 5.1 of the spec (http://www.w3.org/TR/REC-xml#proc-types): Except when standalone="yes", they 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. So, once %foo is not resolved/read, Expat must not process any more entity and attribute declarations in file.dtd. Try it again with standalone="yes". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=707469&group_id=10127 From noreply at sourceforge.net Fri Mar 21 06:33:34 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 21 09:20:10 2003 Subject: [Expat-bugs] [ expat-Bugs-707464 ] expat 1.95.6 raises "Access violation" on WinXP Message-ID: Bugs item #707464, was opened at 2003-03-21 07:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=707464&group_id=10127 Category: www.libexpat.org Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Dragos Onac (dragos_o) Assigned to: Fred L. Drake, Jr. (fdrake) >Summary: expat 1.95.6 raises "Access violation" on WinXP Initial Comment: Running the "elements.c" example on a specific XML file causes the Access Violation message do be displayed, when the code is compiled without debug info. The "Acces violation" issue could also be reproduced using the dll from the win32 package. I don't know how useful this is, but when running the "elements.c" example by compiling all the files with the NuMega Bounds Checker, the following erorr message is shown at line line 1511 of file xmlparse.c: "Expresion uses dangling pointer" The line is: bufferEnd = buffer + (bufferEnd - bufferPtr) + keep; (parser->m_bufferEnd-parser->m_bufferPtr)+keep equals 2048 Stack trace: main()->XML_Parse()->XML_GetBuffer() Input file is attached. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-21 09:33 Message: Logged In: YES user_id=290026 I could not reproduce this. How exactly did you trigger the AV? What file did you use? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=707464&group_id=10127 From noreply at sourceforge.net Fri Mar 21 06:36:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 21 09:23:51 2003 Subject: [Expat-bugs] [ expat-Bugs-707469 ] external param entities Message-ID: Bugs item #707469, was opened at 2003-03-21 12:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=707469&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pavel Hlavnicka (pavel_hlavnicka) Assigned to: Nobody/Anonymous (nobody) Summary: external param entities Initial Comment: Hi all, perhaps, this is not a bug, perhaps it is. Give me some explanation in the first case, please. 1) look at the example 2) It happens with 1.95.5 and 1.95.4 at least We use expat in sablotron xslt processor. We do support external entity parsing, and in addition we allow users to tell, whether they want to parse public external entities or not. In such a case we just return 1 from our entity reference handler. (No entity parser is created). It results to a strange behavior, if following scenario happens: - the parsed document contains - file.dtd contains the declaration of external public parameter entity - file.dtd references this entity - file dtd defines other entities This is sample file.dtd: %foo; If %foo; is not referenced, all works fine, and &baz; means "somedata". If %foo; is referenced, an error occurs while parsing , it seems, that the entity expansion of %baz; and %bar; is empty. If I replace with paring goes fine, but &baz; points to an empty string. I played with a debugger a bit, and what I found was, that if entity parser is not created in entity ref. handler. dtd.paramEntityRead is not set to true, and dtd.keepProcessing is set to false consequently. I'm not sure, what the mission of dtd.keepProcessing is, but it seems, that it stays valid a bit longer then needed. Or do you really mean, that the whole file.dtd content should be skipped, if the %foo; reference was not resolved? If so, why I can see the compilation error? Thank you very much and thanks for expat. ---------------------------------------------------------------------- >Comment By: Pavel Hlavnicka (pavel_hlavnicka) Date: 2003-03-21 14:36 Message: Logged In: YES user_id=302801 Ok, makes sense, actually I've get lost reading this parts of XML spec. But anyway... why the error is reported? If I understand well, all following entities should be ignored, but the error is reported. (for ATTLIST is is the same). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-21 14:25 Message: Logged In: YES user_id=290026 This has to do with section 5.1 of the spec (http://www.w3.org/TR/REC-xml#proc-types): Except when standalone="yes", they 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. So, once %foo is not resolved/read, Expat must not process any more entity and attribute declarations in file.dtd. Try it again with standalone="yes". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=707469&group_id=10127 From noreply at sourceforge.net Fri Mar 21 06:51:31 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 21 09:38:07 2003 Subject: [Expat-bugs] [ expat-Bugs-707464 ] expat 1.95.6 raises "Access violation" on WinXP Message-ID: Bugs item #707464, was opened at 2003-03-21 14:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=707464&group_id=10127 Category: www.libexpat.org Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Dragos Onac (dragos_o) Assigned to: Fred L. Drake, Jr. (fdrake) >Summary: expat 1.95.6 raises "Access violation" on WinXP Initial Comment: Running the "elements.c" example on a specific XML file causes the Access Violation message do be displayed, when the code is compiled without debug info. The "Acces violation" issue could also be reproduced using the dll from the win32 package. I don't know how useful this is, but when running the "elements.c" example by compiling all the files with the NuMega Bounds Checker, the following erorr message is shown at line line 1511 of file xmlparse.c: "Expresion uses dangling pointer" The line is: bufferEnd = buffer + (bufferEnd - bufferPtr) + keep; (parser->m_bufferEnd-parser->m_bufferPtr)+keep equals 2048 Stack trace: main()->XML_Parse()->XML_GetBuffer() Input file is attached. ---------------------------------------------------------------------- >Comment By: Dragos Onac (dragos_o) Date: 2003-03-21 16:51 Message: Logged In: YES user_id=270981 The file was something like ]> &cc; Where every entity had about 60 references to the other one (bb1 for exemple had 60*&bb2;). The test was intended to see how much time is needed for a file with a large amount of references. Seems that i've found the source of the problem... When switching the project preferences, the input file was not passed as argument and of course that a fopen() returned NULL and the associated fread() failed, causing AV Sorry for the false alarm :( ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-21 16:33 Message: Logged In: YES user_id=290026 I could not reproduce this. How exactly did you trigger the AV? What file did you use? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=707464&group_id=10127 From noreply at sourceforge.net Fri Mar 21 07:33:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 21 10:20:32 2003 Subject: [Expat-bugs] [ expat-Bugs-707464 ] expat 1.95.6 raises "Access violation" on WinXP Message-ID: Bugs item #707464, was opened at 2003-03-21 07:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=707464&group_id=10127 >Category: None Group: Platform Specific >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Dragos Onac (dragos_o) Assigned to: Fred L. Drake, Jr. (fdrake) >Summary: expat 1.95.6 raises "Access violation" on WinXP Initial Comment: Running the "elements.c" example on a specific XML file causes the Access Violation message do be displayed, when the code is compiled without debug info. The "Acces violation" issue could also be reproduced using the dll from the win32 package. I don't know how useful this is, but when running the "elements.c" example by compiling all the files with the NuMega Bounds Checker, the following erorr message is shown at line line 1511 of file xmlparse.c: "Expresion uses dangling pointer" The line is: bufferEnd = buffer + (bufferEnd - bufferPtr) + keep; (parser->m_bufferEnd-parser->m_bufferPtr)+keep equals 2048 Stack trace: main()->XML_Parse()->XML_GetBuffer() Input file is attached. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-21 10:32 Message: Logged In: YES user_id=290026 Better a false alarm than a real bug. :-) ---------------------------------------------------------------------- Comment By: Dragos Onac (dragos_o) Date: 2003-03-21 09:51 Message: Logged In: YES user_id=270981 The file was something like ]> &cc; Where every entity had about 60 references to the other one (bb1 for exemple had 60*&bb2;). The test was intended to see how much time is needed for a file with a large amount of references. Seems that i've found the source of the problem... When switching the project preferences, the input file was not passed as argument and of course that a fopen() returned NULL and the associated fread() failed, causing AV Sorry for the false alarm :( ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-21 09:33 Message: Logged In: YES user_id=290026 I could not reproduce this. How exactly did you trigger the AV? What file did you use? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=707464&group_id=10127 From noreply at sourceforge.net Fri Mar 21 08:09:20 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 21 10:56:57 2003 Subject: [Expat-bugs] [ expat-Bugs-707469 ] external param entities Message-ID: Bugs item #707469, was opened at 2003-03-21 07:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=707469&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pavel Hlavnicka (pavel_hlavnicka) Assigned to: Nobody/Anonymous (nobody) Summary: external param entities Initial Comment: Hi all, perhaps, this is not a bug, perhaps it is. Give me some explanation in the first case, please. 1) look at the example 2) It happens with 1.95.5 and 1.95.4 at least We use expat in sablotron xslt processor. We do support external entity parsing, and in addition we allow users to tell, whether they want to parse public external entities or not. In such a case we just return 1 from our entity reference handler. (No entity parser is created). It results to a strange behavior, if following scenario happens: - the parsed document contains - file.dtd contains the declaration of external public parameter entity - file.dtd references this entity - file dtd defines other entities This is sample file.dtd: %foo; If %foo; is not referenced, all works fine, and &baz; means "somedata". If %foo; is referenced, an error occurs while parsing , it seems, that the entity expansion of %baz; and %bar; is empty. If I replace with paring goes fine, but &baz; points to an empty string. I played with a debugger a bit, and what I found was, that if entity parser is not created in entity ref. handler. dtd.paramEntityRead is not set to true, and dtd.keepProcessing is set to false consequently. I'm not sure, what the mission of dtd.keepProcessing is, but it seems, that it stays valid a bit longer then needed. Or do you really mean, that the whole file.dtd content should be skipped, if the %foo; reference was not resolved? If so, why I can see the compilation error? Thank you very much and thanks for expat. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-21 11:09 Message: Logged In: YES user_id=290026 As far as I can tell, the last line in data.dtd has a reference to an undeclared entity (since the corresponding declaration was ignored). That alone is legal for non-validating processors - see http://www.w3.org/TR/REC-xml#wf-entdeclared, but the entity declaration itself would then become mal-formed. I think that section 5.1 does not mean that non-processed entities are allowed to be mal-formed. ---------------------------------------------------------------------- Comment By: Pavel Hlavnicka (pavel_hlavnicka) Date: 2003-03-21 09:36 Message: Logged In: YES user_id=302801 Ok, makes sense, actually I've get lost reading this parts of XML spec. But anyway... why the error is reported? If I understand well, all following entities should be ignored, but the error is reported. (for ATTLIST is is the same). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-21 09:25 Message: Logged In: YES user_id=290026 This has to do with section 5.1 of the spec (http://www.w3.org/TR/REC-xml#proc-types): Except when standalone="yes", they 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. So, once %foo is not resolved/read, Expat must not process any more entity and attribute declarations in file.dtd. Try it again with standalone="yes". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=707469&group_id=10127 From noreply at sourceforge.net Fri Mar 21 08:23:44 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 21 11:10:55 2003 Subject: [Expat-bugs] [ expat-Bugs-707469 ] external param entities Message-ID: Bugs item #707469, was opened at 2003-03-21 12:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=707469&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pavel Hlavnicka (pavel_hlavnicka) Assigned to: Nobody/Anonymous (nobody) Summary: external param entities Initial Comment: Hi all, perhaps, this is not a bug, perhaps it is. Give me some explanation in the first case, please. 1) look at the example 2) It happens with 1.95.5 and 1.95.4 at least We use expat in sablotron xslt processor. We do support external entity parsing, and in addition we allow users to tell, whether they want to parse public external entities or not. In such a case we just return 1 from our entity reference handler. (No entity parser is created). It results to a strange behavior, if following scenario happens: - the parsed document contains - file.dtd contains the declaration of external public parameter entity - file.dtd references this entity - file dtd defines other entities This is sample file.dtd: %foo; If %foo; is not referenced, all works fine, and &baz; means "somedata". If %foo; is referenced, an error occurs while parsing , it seems, that the entity expansion of %baz; and %bar; is empty. If I replace with paring goes fine, but &baz; points to an empty string. I played with a debugger a bit, and what I found was, that if entity parser is not created in entity ref. handler. dtd.paramEntityRead is not set to true, and dtd.keepProcessing is set to false consequently. I'm not sure, what the mission of dtd.keepProcessing is, but it seems, that it stays valid a bit longer then needed. Or do you really mean, that the whole file.dtd content should be skipped, if the %foo; reference was not resolved? If so, why I can see the compilation error? Thank you very much and thanks for expat. ---------------------------------------------------------------------- >Comment By: Pavel Hlavnicka (pavel_hlavnicka) Date: 2003-03-21 16:23 Message: Logged In: YES user_id=302801 Hard to tell. Another question is, why the last line (entity declariation) is even processed. It should be skipped at all, or not? I can understand, that it could be a hrad job. As I looked into the expat code, it seems, that the parsing is just ignoring any output, but anything else works as usually. Perhaps if DTD is not processed (dtd.keepProcessing == FALSE) you could expand any entity reference to some fake value. It looks like a dirty solution, indeed. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-21 16:09 Message: Logged In: YES user_id=290026 As far as I can tell, the last line in data.dtd has a reference to an undeclared entity (since the corresponding declaration was ignored). That alone is legal for non-validating processors - see http://www.w3.org/TR/REC-xml#wf-entdeclared, but the entity declaration itself would then become mal-formed. I think that section 5.1 does not mean that non-processed entities are allowed to be mal-formed. ---------------------------------------------------------------------- Comment By: Pavel Hlavnicka (pavel_hlavnicka) Date: 2003-03-21 14:36 Message: Logged In: YES user_id=302801 Ok, makes sense, actually I've get lost reading this parts of XML spec. But anyway... why the error is reported? If I understand well, all following entities should be ignored, but the error is reported. (for ATTLIST is is the same). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-21 14:25 Message: Logged In: YES user_id=290026 This has to do with section 5.1 of the spec (http://www.w3.org/TR/REC-xml#proc-types): Except when standalone="yes", they 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. So, once %foo is not resolved/read, Expat must not process any more entity and attribute declarations in file.dtd. Try it again with standalone="yes". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=707469&group_id=10127 From noreply at sourceforge.net Fri Mar 21 08:34:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 21 11:21:26 2003 Subject: [Expat-bugs] [ expat-Bugs-707469 ] external param entities Message-ID: Bugs item #707469, was opened at 2003-03-21 07:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=707469&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pavel Hlavnicka (pavel_hlavnicka) Assigned to: Nobody/Anonymous (nobody) Summary: external param entities Initial Comment: Hi all, perhaps, this is not a bug, perhaps it is. Give me some explanation in the first case, please. 1) look at the example 2) It happens with 1.95.5 and 1.95.4 at least We use expat in sablotron xslt processor. We do support external entity parsing, and in addition we allow users to tell, whether they want to parse public external entities or not. In such a case we just return 1 from our entity reference handler. (No entity parser is created). It results to a strange behavior, if following scenario happens: - the parsed document contains - file.dtd contains the declaration of external public parameter entity - file.dtd references this entity - file dtd defines other entities This is sample file.dtd: %foo; If %foo; is not referenced, all works fine, and &baz; means "somedata". If %foo; is referenced, an error occurs while parsing , it seems, that the entity expansion of %baz; and %bar; is empty. If I replace with paring goes fine, but &baz; points to an empty string. I played with a debugger a bit, and what I found was, that if entity parser is not created in entity ref. handler. dtd.paramEntityRead is not set to true, and dtd.keepProcessing is set to false consequently. I'm not sure, what the mission of dtd.keepProcessing is, but it seems, that it stays valid a bit longer then needed. Or do you really mean, that the whole file.dtd content should be skipped, if the %foo; reference was not resolved? If so, why I can see the compilation error? Thank you very much and thanks for expat. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-21 11:34 Message: Logged In: YES user_id=290026 The last line is processed because Expat checks it for well-formedness. What "processed" means is defined in section 5.1: Definition: While they are not required to check the document for validity, they are required to process all the declarations they read in the internal DTD subset and in any parameter entity that they read, up to the first reference to a parameter entity that they do not read; that is to say, they must use the information in those declarations to normalize attribute values, include the replacement text of internal entities, and supply default attribute values. Now, check the excerpt from 5.1 that I quoted in my first reply. IMO, this implies that the declaration is read and checked for well-formedness, but its information is *not* used for normalizing attribute values, including the replacement text of internal entities, and supplying default attribute values Maybe you could also ask this question on the xml-dev mailing list. ---------------------------------------------------------------------- Comment By: Pavel Hlavnicka (pavel_hlavnicka) Date: 2003-03-21 11:23 Message: Logged In: YES user_id=302801 Hard to tell. Another question is, why the last line (entity declariation) is even processed. It should be skipped at all, or not? I can understand, that it could be a hrad job. As I looked into the expat code, it seems, that the parsing is just ignoring any output, but anything else works as usually. Perhaps if DTD is not processed (dtd.keepProcessing == FALSE) you could expand any entity reference to some fake value. It looks like a dirty solution, indeed. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-21 11:09 Message: Logged In: YES user_id=290026 As far as I can tell, the last line in data.dtd has a reference to an undeclared entity (since the corresponding declaration was ignored). That alone is legal for non-validating processors - see http://www.w3.org/TR/REC-xml#wf-entdeclared, but the entity declaration itself would then become mal-formed. I think that section 5.1 does not mean that non-processed entities are allowed to be mal-formed. ---------------------------------------------------------------------- Comment By: Pavel Hlavnicka (pavel_hlavnicka) Date: 2003-03-21 09:36 Message: Logged In: YES user_id=302801 Ok, makes sense, actually I've get lost reading this parts of XML spec. But anyway... why the error is reported? If I understand well, all following entities should be ignored, but the error is reported. (for ATTLIST is is the same). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-21 09:25 Message: Logged In: YES user_id=290026 This has to do with section 5.1 of the spec (http://www.w3.org/TR/REC-xml#proc-types): Except when standalone="yes", they 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. So, once %foo is not resolved/read, Expat must not process any more entity and attribute declarations in file.dtd. Try it again with standalone="yes". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=707469&group_id=10127 From noreply at sourceforge.net Mon Mar 24 03:15:43 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Mar 24 06:02:30 2003 Subject: [Expat-bugs] [ expat-Bugs-707469 ] external param entities Message-ID: Bugs item #707469, was opened at 2003-03-21 12:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=707469&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pavel Hlavnicka (pavel_hlavnicka) Assigned to: Nobody/Anonymous (nobody) Summary: external param entities Initial Comment: Hi all, perhaps, this is not a bug, perhaps it is. Give me some explanation in the first case, please. 1) look at the example 2) It happens with 1.95.5 and 1.95.4 at least We use expat in sablotron xslt processor. We do support external entity parsing, and in addition we allow users to tell, whether they want to parse public external entities or not. In such a case we just return 1 from our entity reference handler. (No entity parser is created). It results to a strange behavior, if following scenario happens: - the parsed document contains - file.dtd contains the declaration of external public parameter entity - file.dtd references this entity - file dtd defines other entities This is sample file.dtd: %foo; If %foo; is not referenced, all works fine, and &baz; means "somedata". If %foo; is referenced, an error occurs while parsing , it seems, that the entity expansion of %baz; and %bar; is empty. If I replace with paring goes fine, but &baz; points to an empty string. I played with a debugger a bit, and what I found was, that if entity parser is not created in entity ref. handler. dtd.paramEntityRead is not set to true, and dtd.keepProcessing is set to false consequently. I'm not sure, what the mission of dtd.keepProcessing is, but it seems, that it stays valid a bit longer then needed. Or do you really mean, that the whole file.dtd content should be skipped, if the %foo; reference was not resolved? If so, why I can see the compilation error? Thank you very much and thanks for expat. ---------------------------------------------------------------------- >Comment By: Pavel Hlavnicka (pavel_hlavnicka) Date: 2003-03-24 11:15 Message: Logged In: YES user_id=302801 In the fact, I' don not really depend on this. People using sablotron reported this behavior, and I do not need to solve this problem once knowing it is an expat feature. Just note, that other processors went trough this data smoothly (basically Java parsers). It's your call, whether you tell it's ok or not :) Anyway, thank you very much for all your explanations. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-21 16:34 Message: Logged In: YES user_id=290026 The last line is processed because Expat checks it for well-formedness. What "processed" means is defined in section 5.1: Definition: While they are not required to check the document for validity, they are required to process all the declarations they read in the internal DTD subset and in any parameter entity that they read, up to the first reference to a parameter entity that they do not read; that is to say, they must use the information in those declarations to normalize attribute values, include the replacement text of internal entities, and supply default attribute values. Now, check the excerpt from 5.1 that I quoted in my first reply. IMO, this implies that the declaration is read and checked for well-formedness, but its information is *not* used for normalizing attribute values, including the replacement text of internal entities, and supplying default attribute values Maybe you could also ask this question on the xml-dev mailing list. ---------------------------------------------------------------------- Comment By: Pavel Hlavnicka (pavel_hlavnicka) Date: 2003-03-21 16:23 Message: Logged In: YES user_id=302801 Hard to tell. Another question is, why the last line (entity declariation) is even processed. It should be skipped at all, or not? I can understand, that it could be a hrad job. As I looked into the expat code, it seems, that the parsing is just ignoring any output, but anything else works as usually. Perhaps if DTD is not processed (dtd.keepProcessing == FALSE) you could expand any entity reference to some fake value. It looks like a dirty solution, indeed. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-21 16:09 Message: Logged In: YES user_id=290026 As far as I can tell, the last line in data.dtd has a reference to an undeclared entity (since the corresponding declaration was ignored). That alone is legal for non-validating processors - see http://www.w3.org/TR/REC-xml#wf-entdeclared, but the entity declaration itself would then become mal-formed. I think that section 5.1 does not mean that non-processed entities are allowed to be mal-formed. ---------------------------------------------------------------------- Comment By: Pavel Hlavnicka (pavel_hlavnicka) Date: 2003-03-21 14:36 Message: Logged In: YES user_id=302801 Ok, makes sense, actually I've get lost reading this parts of XML spec. But anyway... why the error is reported? If I understand well, all following entities should be ignored, but the error is reported. (for ATTLIST is is the same). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-21 14:25 Message: Logged In: YES user_id=290026 This has to do with section 5.1 of the spec (http://www.w3.org/TR/REC-xml#proc-types): Except when standalone="yes", they 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. So, once %foo is not resolved/read, Expat must not process any more entity and attribute declarations in file.dtd. Try it again with standalone="yes". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=707469&group_id=10127 From noreply at sourceforge.net Mon Mar 24 06:08:56 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Mar 24 08:55:11 2003 Subject: [Expat-bugs] [ expat-Bugs-707469 ] external param entities Message-ID: Bugs item #707469, was opened at 2003-03-21 07:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=707469&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pavel Hlavnicka (pavel_hlavnicka) Assigned to: Nobody/Anonymous (nobody) Summary: external param entities Initial Comment: Hi all, perhaps, this is not a bug, perhaps it is. Give me some explanation in the first case, please. 1) look at the example 2) It happens with 1.95.5 and 1.95.4 at least We use expat in sablotron xslt processor. We do support external entity parsing, and in addition we allow users to tell, whether they want to parse public external entities or not. In such a case we just return 1 from our entity reference handler. (No entity parser is created). It results to a strange behavior, if following scenario happens: - the parsed document contains - file.dtd contains the declaration of external public parameter entity - file.dtd references this entity - file dtd defines other entities This is sample file.dtd: %foo; If %foo; is not referenced, all works fine, and &baz; means "somedata". If %foo; is referenced, an error occurs while parsing , it seems, that the entity expansion of %baz; and %bar; is empty. If I replace with paring goes fine, but &baz; points to an empty string. I played with a debugger a bit, and what I found was, that if entity parser is not created in entity ref. handler. dtd.paramEntityRead is not set to true, and dtd.keepProcessing is set to false consequently. I'm not sure, what the mission of dtd.keepProcessing is, but it seems, that it stays valid a bit longer then needed. Or do you really mean, that the whole file.dtd content should be skipped, if the %foo; reference was not resolved? If so, why I can see the compilation error? Thank you very much and thanks for expat. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-24 09:08 Message: Logged In: YES user_id=290026 As it currentlyt stands I think Expat is right. We have re-vamped exactly these parts of Expat in the not so distant past, and it behaves as designed. Now, this is not to say we could be wrong, but so far I have not seen any argument or section in the specs that would convince me otherwise. Btw, Expat has a high degree of conformance with the XML-test-suite, which has been one of our goals for the past few releases. There is a dicsussion of the test results in bug #569461. ---------------------------------------------------------------------- Comment By: Pavel Hlavnicka (pavel_hlavnicka) Date: 2003-03-24 06:15 Message: Logged In: YES user_id=302801 In the fact, I' don not really depend on this. People using sablotron reported this behavior, and I do not need to solve this problem once knowing it is an expat feature. Just note, that other processors went trough this data smoothly (basically Java parsers). It's your call, whether you tell it's ok or not :) Anyway, thank you very much for all your explanations. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-21 11:34 Message: Logged In: YES user_id=290026 The last line is processed because Expat checks it for well-formedness. What "processed" means is defined in section 5.1: Definition: While they are not required to check the document for validity, they are required to process all the declarations they read in the internal DTD subset and in any parameter entity that they read, up to the first reference to a parameter entity that they do not read; that is to say, they must use the information in those declarations to normalize attribute values, include the replacement text of internal entities, and supply default attribute values. Now, check the excerpt from 5.1 that I quoted in my first reply. IMO, this implies that the declaration is read and checked for well-formedness, but its information is *not* used for normalizing attribute values, including the replacement text of internal entities, and supplying default attribute values Maybe you could also ask this question on the xml-dev mailing list. ---------------------------------------------------------------------- Comment By: Pavel Hlavnicka (pavel_hlavnicka) Date: 2003-03-21 11:23 Message: Logged In: YES user_id=302801 Hard to tell. Another question is, why the last line (entity declariation) is even processed. It should be skipped at all, or not? I can understand, that it could be a hrad job. As I looked into the expat code, it seems, that the parsing is just ignoring any output, but anything else works as usually. Perhaps if DTD is not processed (dtd.keepProcessing == FALSE) you could expand any entity reference to some fake value. It looks like a dirty solution, indeed. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-21 11:09 Message: Logged In: YES user_id=290026 As far as I can tell, the last line in data.dtd has a reference to an undeclared entity (since the corresponding declaration was ignored). That alone is legal for non-validating processors - see http://www.w3.org/TR/REC-xml#wf-entdeclared, but the entity declaration itself would then become mal-formed. I think that section 5.1 does not mean that non-processed entities are allowed to be mal-formed. ---------------------------------------------------------------------- Comment By: Pavel Hlavnicka (pavel_hlavnicka) Date: 2003-03-21 09:36 Message: Logged In: YES user_id=302801 Ok, makes sense, actually I've get lost reading this parts of XML spec. But anyway... why the error is reported? If I understand well, all following entities should be ignored, but the error is reported. (for ATTLIST is is the same). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-21 09:25 Message: Logged In: YES user_id=290026 This has to do with section 5.1 of the spec (http://www.w3.org/TR/REC-xml#proc-types): Except when standalone="yes", they 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. So, once %foo is not resolved/read, Expat must not process any more entity and attribute declarations in file.dtd. Try it again with standalone="yes". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=707469&group_id=10127 From noreply at sourceforge.net Mon Mar 24 06:20:25 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Mar 24 09:06:59 2003 Subject: [Expat-bugs] [ expat-Bugs-704264 ] Undeclared prefixes and duplicate prefixed attrs Message-ID: Bugs item #704264, was opened at 2003-03-15 16:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=704264&group_id=10127 Category: None Group: None >Status: Closed Resolution: Duplicate Priority: 5 Submitted By: Jeremy Kloth (jkloth) Assigned to: Karl Waclawek (kwaclaw) Summary: Undeclared prefixes and duplicate prefixed attrs Initial Comment: Per the XML Namespaces 1.0 spec the following documents should not be well-formed. The attached patch against version 1.95.6 fixes these three issues. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-15 18:27 Message: Logged In: YES user_id=290026 This is a duplicate of bugs #692964 and #695401. A patch has already been applied to CVS. I will review your patch to check if anything is missing in the already applied patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=704264&group_id=10127 From noreply at sourceforge.net Mon Mar 24 06:20:47 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Mar 24 09:07:54 2003 Subject: [Expat-bugs] [ expat-Bugs-707469 ] external param entities Message-ID: Bugs item #707469, was opened at 2003-03-21 12:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=707469&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pavel Hlavnicka (pavel_hlavnicka) Assigned to: Nobody/Anonymous (nobody) Summary: external param entities Initial Comment: Hi all, perhaps, this is not a bug, perhaps it is. Give me some explanation in the first case, please. 1) look at the example 2) It happens with 1.95.5 and 1.95.4 at least We use expat in sablotron xslt processor. We do support external entity parsing, and in addition we allow users to tell, whether they want to parse public external entities or not. In such a case we just return 1 from our entity reference handler. (No entity parser is created). It results to a strange behavior, if following scenario happens: - the parsed document contains - file.dtd contains the declaration of external public parameter entity - file.dtd references this entity - file dtd defines other entities This is sample file.dtd: %foo; If %foo; is not referenced, all works fine, and &baz; means "somedata". If %foo; is referenced, an error occurs while parsing , it seems, that the entity expansion of %baz; and %bar; is empty. If I replace with paring goes fine, but &baz; points to an empty string. I played with a debugger a bit, and what I found was, that if entity parser is not created in entity ref. handler. dtd.paramEntityRead is not set to true, and dtd.keepProcessing is set to false consequently. I'm not sure, what the mission of dtd.keepProcessing is, but it seems, that it stays valid a bit longer then needed. Or do you really mean, that the whole file.dtd content should be skipped, if the %foo; reference was not resolved? If so, why I can see the compilation error? Thank you very much and thanks for expat. ---------------------------------------------------------------------- >Comment By: Pavel Hlavnicka (pavel_hlavnicka) Date: 2003-03-24 14:20 Message: Logged In: YES user_id=302801 OK, I do believe you :) This issue is too esoteric for me, I hardly can tell you more points. Thanks again. I think, the spec. is pretty confusing on DTD's etc. and the usability is quite another question... but this is farly out of scope... ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-24 14:08 Message: Logged In: YES user_id=290026 As it currentlyt stands I think Expat is right. We have re-vamped exactly these parts of Expat in the not so distant past, and it behaves as designed. Now, this is not to say we could be wrong, but so far I have not seen any argument or section in the specs that would convince me otherwise. Btw, Expat has a high degree of conformance with the XML-test-suite, which has been one of our goals for the past few releases. There is a dicsussion of the test results in bug #569461. ---------------------------------------------------------------------- Comment By: Pavel Hlavnicka (pavel_hlavnicka) Date: 2003-03-24 11:15 Message: Logged In: YES user_id=302801 In the fact, I' don not really depend on this. People using sablotron reported this behavior, and I do not need to solve this problem once knowing it is an expat feature. Just note, that other processors went trough this data smoothly (basically Java parsers). It's your call, whether you tell it's ok or not :) Anyway, thank you very much for all your explanations. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-21 16:34 Message: Logged In: YES user_id=290026 The last line is processed because Expat checks it for well-formedness. What "processed" means is defined in section 5.1: Definition: While they are not required to check the document for validity, they are required to process all the declarations they read in the internal DTD subset and in any parameter entity that they read, up to the first reference to a parameter entity that they do not read; that is to say, they must use the information in those declarations to normalize attribute values, include the replacement text of internal entities, and supply default attribute values. Now, check the excerpt from 5.1 that I quoted in my first reply. IMO, this implies that the declaration is read and checked for well-formedness, but its information is *not* used for normalizing attribute values, including the replacement text of internal entities, and supplying default attribute values Maybe you could also ask this question on the xml-dev mailing list. ---------------------------------------------------------------------- Comment By: Pavel Hlavnicka (pavel_hlavnicka) Date: 2003-03-21 16:23 Message: Logged In: YES user_id=302801 Hard to tell. Another question is, why the last line (entity declariation) is even processed. It should be skipped at all, or not? I can understand, that it could be a hrad job. As I looked into the expat code, it seems, that the parsing is just ignoring any output, but anything else works as usually. Perhaps if DTD is not processed (dtd.keepProcessing == FALSE) you could expand any entity reference to some fake value. It looks like a dirty solution, indeed. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-21 16:09 Message: Logged In: YES user_id=290026 As far as I can tell, the last line in data.dtd has a reference to an undeclared entity (since the corresponding declaration was ignored). That alone is legal for non-validating processors - see http://www.w3.org/TR/REC-xml#wf-entdeclared, but the entity declaration itself would then become mal-formed. I think that section 5.1 does not mean that non-processed entities are allowed to be mal-formed. ---------------------------------------------------------------------- Comment By: Pavel Hlavnicka (pavel_hlavnicka) Date: 2003-03-21 14:36 Message: Logged In: YES user_id=302801 Ok, makes sense, actually I've get lost reading this parts of XML spec. But anyway... why the error is reported? If I understand well, all following entities should be ignored, but the error is reported. (for ATTLIST is is the same). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-21 14:25 Message: Logged In: YES user_id=290026 This has to do with section 5.1 of the spec (http://www.w3.org/TR/REC-xml#proc-types): Except when standalone="yes", they 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. So, once %foo is not resolved/read, Expat must not process any more entity and attribute declarations in file.dtd. Try it again with standalone="yes". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=707469&group_id=10127 From noreply at sourceforge.net Mon Mar 24 10:29:38 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Mar 24 13:16:22 2003 Subject: [Expat-bugs] [ expat-Patches-699487 ] Hash table improvement Message-ID: Patches item #699487, was opened at 2003-03-07 11:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=699487&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) Summary: Hash table improvement Initial Comment: This patch addresses two areas: 1) The current hash function ignores the high byte of UTF-16 characters. This is not good. 2) There is a cheap way to switch from the current method of linear probing (to resolve collisions) to the slightly better double hashing. Ad 1) hashing of wide characters: Currently, the algorithm is like this: h = h * 33 + (unsigned char)c; where h is the hash value and c is a character in the string argument (char or wchar_t). It seems this hashing algorithm belongs to a family of algorithms of the type: h = h * + character where is taken froma list of tried and proven values like 31, 33, 37, 41, 65599 which should be (but are not always) prime numbers. I added a wchar_t version (#ifdef XML_UNICODE) of this type: h = h * 65599 + (unsigned short)c; Ad 2) double hashing: Currently the hash table index is calculated from the hash value by masking out the lower bits according to table size. This works because the table size is a power of 2. But this also means that some bits of the hash value are unused. From these we can therefore generate the second hash value with little extra effort. The patch also updates the inlined hash table implementation used for detecting duplicate prefixed attributes (in function storeAtts()). See the attached file hashpatch1.diff (to be applied against xmlparse.c rev. 1.109). ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-24 13:29 Message: Logged In: YES user_id=290026 Improvement to first patch version (hashpatch1.diff): For calculating second hash, don't overwrite the rightmost bit of the hash value's unused portion. This means: change ">> (power)" to ">> ((power) - 1)": #define PROBE_STEP(hash, mask, power) \ ((unsigned char)((((hash) & ~(mask)) >> ((power) - 1)) & ((mask) >> 2)) \ + | (unsigned char)(1)) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=699487&group_id=10127 From noreply at sourceforge.net Thu Mar 27 02:42:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Mar 27 05:29:19 2003 Subject: [Expat-bugs] [ expat-Bugs-676844 ] expat.h compile error: enum XML_Status Message-ID: Bugs item #676844, was opened at 2003-01-29 07:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=676844&group_id=10127 Category: Build control Group: None Status: Open Resolution: Fixed Priority: 3 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: expat.h compile error: enum XML_Status Initial Comment: c++ -DHAVE_CONFIG_H -I. -I. -I../../autocfg -g -O2 -c context.cpp -fPIC -DPIC -o .libs/context.lo In file included from parser.h:45, from guard.h:143, from context.cpp:45: /usr/include/expat.h:657: use of enum `XML_Status' without previous declaration /usr/include/expat.h:736: multiple definition of `enum XML_Status' when building sablotron. Hand editing the file to place the def of enum XML_Status before any references to it fixes the problem. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-03-27 02:42 Message: Logged In: NO Same problem and the same fix under Linux and gcc 2.95.2. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-03-07 03:20 Message: Logged In: NO same problem, same fix when building 1.95.6 on vms (just downloaded .tar.gz & processed - got the rpm, but don't know what to do with it - not an archive type I know how to handle on vms, or windows either) - chris.sharman@ccagroup.co.uk ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-28 18:03 Message: Logged In: YES user_id=290026 Strange - I had no problems with MS VC++ 6.0. Which service pack level have you applied? ---------------------------------------------------------------------- Comment By: Jacob Levy (jyljyljyl) Date: 2003-02-28 17:35 Message: Logged In: YES user_id=63723 This makes Expat 1.95.6 unusable for people who create libraries that depend on Expat but don't include their own copy of Expat. Sure, I can edit expat.h and fix it, but my users should not be expected to do that. For that reason I'm staying with Expat 1.95.5 until this problem is fixed. It'd be really nice if you could make Expat 1.95.7 soon.. In my case GCC 2.95.2 and VC++ 6.0 are complaining. ---------------------------------------------------------------------- Comment By: Melvyn Sopacua (nyvlem) Date: 2003-02-13 23:56 Message: Logged In: YES user_id=212431 Yes, that works. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-06 12:47 Message: Logged In: YES user_id=290026 But current CVS works for you, right? ---------------------------------------------------------------------- Comment By: Melvyn Sopacua (nyvlem) Date: 2003-02-06 12:17 Message: Logged In: YES user_id=212431 > So far only gcc3.2 has complained. Nope: /usr/local/include/expat.h:657: use of enum `XML_Status' without previous declaration /usr/local/include/expat.h:736: multiple definition of `enum XML_Status' gmake[2]: *** [context.lo] Error 1 gmake[2]: Leaving directory `/home/mdev/cvs/sablot/src/engine' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/mdev/cvs/sablot/src' gmake: *** [all-recursive] Error 1 $ gcc --version 2.95.3 ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-01-31 06:43 Message: Logged In: YES user_id=290026 It *is* fixed in CVS. Are you sure you checked out the right version, which is expat.h 1.51? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-01-31 02:34 Message: Logged In: NO I just got the same error, already fixed it. But don't understand why it isn't fixed in CVS ? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-01-29 10:44 Message: Logged In: YES user_id=3066 I've not checked the C89 standard yet, but Expat 1.95.6 is certainly dodgy in this case. ;-( The first draft of the C spec I found online certainly seemed to imply that any use of an incomplete enum is not allowed; I'm not likely to go out and buy a copy of the final spec to check further. ;-) As noted, this has been fixed in CVS. Fixed the summary to better indicate what this report is about, and lowered the priority to get it out of the way for maintainers. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-01-29 07:51 Message: Logged In: YES user_id=290026 So far only gcc3.2 has complained. Not sure if this is a bug, since most compilers accept it, but it has been fixed in CVS already anyway. Set resolution status to fixed, but leave open. There may be other users who would report this as a bug and I want them to see the open report instead of having duplicates created. Assigned to Fred - since he may know more about whether this truly is a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=676844&group_id=10127 From noreply at sourceforge.net Fri Mar 28 17:40:38 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Mar 28 20:26:32 2003 Subject: [Expat-bugs] [ expat-Patches-699487 ] Hash table improvement Message-ID: Patches item #699487, was opened at 2003-03-07 11:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=699487&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) Summary: Hash table improvement Initial Comment: This patch addresses two areas: 1) The current hash function ignores the high byte of UTF-16 characters. This is not good. 2) There is a cheap way to switch from the current method of linear probing (to resolve collisions) to the slightly better double hashing. Ad 1) hashing of wide characters: Currently, the algorithm is like this: h = h * 33 + (unsigned char)c; where h is the hash value and c is a character in the string argument (char or wchar_t). It seems this hashing algorithm belongs to a family of algorithms of the type: h = h * + character where is taken froma list of tried and proven values like 31, 33, 37, 41, 65599 which should be (but are not always) prime numbers. I added a wchar_t version (#ifdef XML_UNICODE) of this type: h = h * 65599 + (unsigned short)c; Ad 2) double hashing: Currently the hash table index is calculated from the hash value by masking out the lower bits according to table size. This works because the table size is a power of 2. But this also means that some bits of the hash value are unused. From these we can therefore generate the second hash value with little extra effort. The patch also updates the inlined hash table implementation used for detecting duplicate prefixed attributes (in function storeAtts()). See the attached file hashpatch1.diff (to be applied against xmlparse.c rev. 1.109). ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-28 20:40 Message: Logged In: YES user_id=290026 Further change for PROBE_STEP macro: To prevent overflow (the result should fit into one Byte) we replace "& (mask >> 2)" with "& (unsigned long)0xFF": #define BYTE_MASK ((unsigned long)0xFF) #define PROBE_STEP(hash, mask, power) \ ((unsigned char)((((hash) & ~(mask)) >> ((power) - 1)) \ & BYTE_MASK) \ | (unsigned char)(1)) which limits the maxium step size to 0xFF. Large steps are not a good idea anyway, since that might lead to cache misses. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-24 13:29 Message: Logged In: YES user_id=290026 Improvement to first patch version (hashpatch1.diff): For calculating second hash, don't overwrite the rightmost bit of the hash value's unused portion. This means: change ">> (power)" to ">> ((power) - 1)": #define PROBE_STEP(hash, mask, power) \ ((unsigned char)((((hash) & ~(mask)) >> ((power) - 1)) & ((mask) >> 2)) \ + | (unsigned char)(1)) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=699487&group_id=10127 From noreply at sourceforge.net Mon Mar 31 09:21:17 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Mar 31 12:08:04 2003 Subject: [Expat-bugs] [ expat-Bugs-712785 ] expat-1.95.2 (Mac OS X 10.2.4) xmlwf/-lcrt0.o missing Message-ID: Bugs item #712785, was opened at 2003-03-31 12:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=712785&group_id=10127 Category: Build control Group: None Status: Open Resolution: None Priority: 5 Submitted By: José Muñiz (josemuniznyc) Assigned to: Greg Stein (gstein) Summary: expat-1.95.2 (Mac OS X 10.2.4) xmlwf/-lcrt0.o missing Initial Comment: Make fails, giving me this ouput: [imacs-Computer:~/expat-1.95.2] jmuniz% make cd lib && make make[1]: Nothing to be done for `all'. cd xmlwf && make gcc -o xmlwf -static xmlwf.o xmlfile.o codepage.o unixfilemap.o -L../lib/.libs -lexpat ld: can't locate file for: -lcrt0.o make[1]: *** [xmlwf] Error 1 make: *** [xmlwf] Error 2 I believe this might be related to issue: [ 454879 ] Compile of xmlwf fails in cygwin v1.95. However, some of the work arounds seemed local to cygwin and expat 1.95.2 is a specific dependency for the software I'm trying to build. Although I can ask upstream if we can move to a newer version with the patched macro, assuming the naming issue was resolved in a newer version. Thank you for all the work you do, Y ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=712785&group_id=10127