From noreply at sourceforge.net Mon Feb 3 04:56:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 3 07:50:38 2003 Subject: [Expat-bugs] [ expat-Bugs-679468 ] Slight error in documentation Message-ID: Bugs item #679468, was opened at 2003-02-03 13:56 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=679468&group_id=10127 Category: Documentation Group: None Status: Open Resolution: None 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); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=679468&group_id=10127 From noreply at sourceforge.net Mon Feb 3 11:51:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 3 14:45:31 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 22:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=679754&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Artyom Bolgar (artyom17) Assigned to: Nobody/Anonymous (nobody) 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=679754&group_id=10127 From noreply at sourceforge.net Mon Feb 3 12:40:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 3 15:34:44 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: Open >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 Feb 6 12:17:27 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 6 15:11:21 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 16: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: Melvyn Sopacua (nyvlem) Date: 2003-02-06 21: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 15: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 11: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 19: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 16: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 Thu Feb 6 12:47:36 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 6 17:51:55 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 10: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: Karl Waclawek (kwaclaw) Date: 2003-02-06 15:47 Message: Logged In: YES user_id=290026 But current CVS works for you, right? ---------------------------------------------------------------------- Comment By: Melvyn Sopacua (nyvlem) Date: 2003-02-06 15: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 09: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 05: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 13: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 10: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 Sun Feb 9 17:12:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 9 20:05:45 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-10 01:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=683681&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Nobody/Anonymous (nobody) 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=683681&group_id=10127 From noreply at sourceforge.net Sun Feb 9 18:32:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 9 21:25:56 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: Open Resolution: None 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: 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 Mon Feb 10 08:09:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 10 11:02:51 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-10 01:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=683681&group_id=10127 Category: None Group: None Status: Open Resolution: None 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: Rolf Ade (pointsman) Date: 2003-02-10 16: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-10 02: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 key88sf at hotmail.com Thu Feb 13 06:57:01 2003 From: key88sf at hotmail.com (Key88 SF) Date: Thu Feb 13 01:57:35 2003 Subject: [Expat-bugs] Bug parsing embedded xml? Message-ID: I'm wondering if the following is a bug. I am trying to parse an XML file that has, as the value for a tag, another XML string which is encoded via HTML-type >, etc. When expat encounters this tag, it doesn't pass the entire html-encoded text as the value to my XML_SetCharacterDataHandler function. Instead, it passes every encoded '<' character, '>' character, and the text in between. Is this a bug?? The xml I am trying to process looks like below: (NOTE: Also attached as a zip file in case email programs try to re-encode it). <MuseMediaCollection xmlns="http://www.mediacode.com/muse.net/ClientService/MuseMediaUpdate" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><MuseMedia xmlns=""><OldPath>2/Aerosmith%20-%20Dream%20On.mp3</OldPath><Creator xmlns="http://www.mediacode.com/muse.net/ClientService/MuseMediaUpdate">mycreator</Creator><Title xmlns="http://www.mediacode.com/muse.net/ClientService/MuseMediaUpdate">My Title</Title><Audio xmlns="http://www.mediacode.com/muse.net/ClientService/MuseMediaUpdate"><TrackNumber>999</TrackNumber><Album>My Album</Album><Date>2003-03-03</Date><Comment>This is my comment</Comment></Audio></MuseMedia></MuseMediaCollection> _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail -------------- next part -------------- A non-text attachment was scrubbed... Name: pcp.zip Type: application/x-zip-compressed Size: 437 bytes Desc: not available Url : http://mail.libexpat.org/pipermail/expat-bugs/attachments/20030213/23b5f567/pcp.bin From noreply at sourceforge.net Thu Feb 13 23:56:31 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 14 02:49:31 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 16: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: Melvyn Sopacua (nyvlem) Date: 2003-02-14 08:56 Message: Logged In: YES user_id=212431 Yes, that works. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-06 21:47 Message: Logged In: YES user_id=290026 But current CVS works for you, right? ---------------------------------------------------------------------- Comment By: Melvyn Sopacua (nyvlem) Date: 2003-02-06 21: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 15: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 11: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 19: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 16: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 Tue Feb 18 13:59:46 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 18 16:51:49 2003 Subject: [Expat-bugs] [ expat-Bugs-615606 ] Buffer overrun with XML_ParserCreateNS Message-ID: Bugs item #615606, was opened at 2002-09-27 11:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615606&group_id=10127 Category: None Group: Test Required >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Daniel Bowen (daniel_bowen) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Buffer overrun with XML_ParserCreateNS Initial Comment: Expat 1.95.5 on Win32 using MSVC 6, 7 A buffer overrun occurs under the following set of circumstances: * In a test program, create an XML_Parser using XML_ParserCreateNS (instead of XML_ParserCreate) * Parse a file (or stdin) where the number of bytes is greater than the size of your buffer (so that you have to do multiple passes). It seems to happen with both XML_GetBuffer / XML_ParseBuffer as well as allocating your own buffer and calling XML_Parse. To see that an error occurs: * Compile a debug version of expat (DLL or static library) * Compile a debug version of your test program that uses the debug version of expat * You get a dialog similar to the following: --------------------------- Microsoft Visual C++ Debug Library --------------------------- Debug Error! Program: ...\Expat-1.95.5 \Source\examples\Debug\elements.exe DAMAGE: after Normal block (#88) at 0x002F7798. (Press Retry to debug the application) --------------------------- Abort Retry Ignore --------------------------- If you click "Retry", it takes you to the _free_dbg function in dbgheap.c, line 1066 in MSVC 6, as a result of a "CheckBytes" call. The call stack indicates that this is on the "XML_ParserFree" call. In the output window, it lists a handful of addresses where the bytes should be "0xFD", such as: memory check error at 0x002F77BF = 0x69, should be 0xFD. If you view memory at this address, you see parts of the input XML file have been written there. If you set a breakpoint to break when data at this location in memory changes, you break at line 2110 in xmlparse.c in the function doContent, at the line: /* don't need to check for space - already done in storeAtts() */ while (*localPart) *uri++ = *localPart++; If you watch memory changing as you do multiple passes through XML_Parse/XML_ParseBuffer, it seems that instead of reusing the internal buffer starting at the beginning, the internal buffer keeps getting appended to (beyond the size of its allocation). This should be easily reproducable. For example, in the "elements" sample, change the "XML_ParserCreate (NULL)" line on line 32 in elements.c to "XML_ParserCreateNS(NULL, '|')". I haven't tested this scenario in builds other than 1.95.5, so I'm not sure if this is a new bug or a bug that hasn't yet been tripped across. Thanks! -Daniel ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-11-12 12:37 Message: Logged In: YES user_id=3066 Oops, this was marked "Test Required" but wasn't assigned; now assigned to me to add a regression test. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-28 18:15 Message: Logged In: NO Ouch! I've been working for the past two days tracking down this bug. Thanks for the patch! ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-09-28 07:56 Message: Logged In: YES user_id=290026 I could trace this bug to the function storeRawNames. What happens is this: when namespace processing is turned on, tag->name.str does not point to tag->buf, but to the binding->uri buffer of the associated PREFIX structure. Therefore, when tag->buf is reallocated, one should update tag->name.str only when namespace processing is off. This condition was not tested and tag->name.str was wrongly updated in those cases when namespace processing was turned on and the storeRawNames function reallocated tag->buf. Fix is already committed to CVS. Patch attached. I tested with your example and it works fine now. ---------------------------------------------------------------------- Comment By: Daniel Bowen (daniel_bowen) Date: 2002-09-27 12:09 Message: Logged In: YES user_id=619351 I had to re-upload with the compiled elements.exe taken out (it made the file too big to upload). You can just rebuild all in debug mode. ---------------------------------------------------------------------- Comment By: Daniel Bowen (daniel_bowen) Date: 2002-09-27 12:02 Message: Logged In: YES user_id=619351 I've attached a copy of the "elements" project along with the expat (static) that it uses. I compiled both in debug, and included in the upload elements.exe. Also in the examples\Debug directory is an XML file that will trigger the bug. I had tried it with only a couple of input XML files. I've tried it with a few more, and I see that to reproduce the problem is not always as simple as "Parse a file (or stdin) where the number of bytes is greater than the size of your buffer". I'm not sure what characteristics trigger the bug, but from what I could tell, this was at least one symptom. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-09-27 11:30 Message: Logged In: YES user_id=290026 I am using XML_ParserCreateNS with multiple buffers all the time and have never had that problem. Could you please attach a complete but simple test case, so that we can reproduce the error. Thanks, Karl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615606&group_id=10127 From karl at waclawek.net Fri Feb 21 10:54:43 2003 From: karl at waclawek.net (Karl Waclawek) Date: Fri Feb 21 10:53:13 2003 Subject: [Expat-bugs] Bug parsing embedded xml? References: Message-ID: <002c01c2d9c1$8e8f0b90$0207a8c0@karl> > I'm wondering if the following is a bug. I am trying to parse an XML file > that has, as the value for a tag, another XML string which is encoded via > HTML-type >, etc. > > When expat encounters this tag, it doesn't pass the entire html-encoded text > as the value to my XML_SetCharacterDataHandler function. Instead, it passes > every encoded '<' character, '>' character, and the text in between. Is > this a bug?? I am not sure I really understand your problem, but it works as expected for me. The character handler can be called more than once for a chunk of text, btw. Karl From noreply at sourceforge.net Tue Feb 25 05:27:20 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 25 08:17:55 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: None Status: Open Resolution: None Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Nobody/Anonymous (nobody) 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=692878&group_id=10127 From noreply at sourceforge.net Tue Feb 25 07:24:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 25 10:15:23 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-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 Tue Feb 25 07:28:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 25 10:19:12 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: None Priority: 5 Submitted By: Mark E. (snowballville) Assigned to: Nobody/Anonymous (nobody) 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=692964&group_id=10127 From noreply at sourceforge.net Tue Feb 25 07:34:56 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 25 10:26:10 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-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 Tue Feb 25 07:44:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 25 10:35:35 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: 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 Tue Feb 25 08:26:54 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 25 11:17:29 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-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 Tue Feb 25 08:35:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 25 11:25:34 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: 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 Tue Feb 25 10:21:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 25 13:12:21 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-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 Tue Feb 25 10:23:38 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 25 13:14:29 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: 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 Tue Feb 25 10:24:27 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 25 13:15:18 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-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 Tue Feb 25 11:02:25 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 25 13:53:38 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: 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 Tue Feb 25 13:41:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 25 16:33:06 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-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 Tue Feb 25 14:33:05 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 25 17:24:27 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-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 Feb 26 08:47:13 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 26 11:37:37 2003 Subject: [Expat-bugs] [ expat-Bugs-693747 ] complie problem on HP-UX 11 with expat version > 1.95.4 Message-ID: Bugs item #693747, was opened at 2003-02-26 08:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=693747&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: complie problem on HP-UX 11 with expat version > 1.95.4 Initial Comment: complie problem on HP-UX 11 with expat version > 1.95.4 ---------------------------------------- cc -w -O2 -I./lib -I. -o xmlwf/xmlwf.o -c xmlwf/xmlwf.c cc: "xmlwf/xmlwf.c", line 602: error 1000: Unexpected symbol: "*". cc: error 2017: Cannot recover from earlier errors, terminating. make: *** [xmlwf/xmlwf.o] Error 1 ______________________ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=693747&group_id=10127 From noreply at sourceforge.net Fri Feb 28 11:01:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 28 13:52:10 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: 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 Feb 28 17:32:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 28 20:22:28 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: Karl Waclawek (kwaclaw) 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: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=695401&group_id=10127 From noreply at sourceforge.net Fri Feb 28 17:35:51 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 28 20:26:14 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: 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 Feb 28 17:46:57 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 28 20:37:20 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: 5 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: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=695407&group_id=10127 From noreply at sourceforge.net Fri Feb 28 18:03:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 28 20:53:50 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 10: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: Karl Waclawek (kwaclaw) Date: 2003-02-28 21: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 20: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-14 02:56 Message: Logged In: YES user_id=212431 Yes, that works. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-06 15:47 Message: Logged In: YES user_id=290026 But current CVS works for you, right? ---------------------------------------------------------------------- Comment By: Melvyn Sopacua (nyvlem) Date: 2003-02-06 15: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 09: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 05: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 13: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 10: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