From noreply at sourceforge.net Fri Apr 2 04:05:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 2 04:05:27 2004 Subject: [Expat-bugs] [ expat-Bugs-928113 ] XML_SetUnknownEncodingHandler() return values are mixed. Message-ID: Bugs item #928113, was opened at 2004-04-02 13:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=928113&group_id=10127 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Maxim Petrovich Dementiev (maximdementiev) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: XML_SetUnknownEncodingHandler() return values are mixed. Initial Comment: In documentation (reference.html) to expat-1.95.7 wrote: "If the handler knows how to deal with an encoding with the given name, it should fill in the info data structure and return XML_STATUS_ERROR. Otherwise it should return XML_STATUS_OK." In expat.h: enum XML_Status { XML_STATUS_ERROR = 0, // false #define XML_STATUS_ERROR XML_STATUS_ERROR XML_STATUS_OK = 1 // not zero - ture #define XML_STATUS_OK XML_STATUS_OK }; In xmlparse.c: if (unknownEncodingHandler(...)) { // ... handler knows how to deal ... ... return XML_ERROR_NONE; } ... return XML_ERROR_UNKNOWN_ENCODING; So right might be: "If the handler knows how to deal with an encoding ... return XML_STATUS_OK (not zero - ture). Otherwise it should return XML_STATUS_ERROR (zero - false)." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=928113&group_id=10127 From noreply at sourceforge.net Wed Apr 7 20:10:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Apr 7 20:10:54 2004 Subject: [Expat-bugs] [ expat-Bugs-920274 ] xml: namespace not closed after entity Message-ID: Bugs item #920274, was opened at 2004-03-20 18:35 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=920274&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Karl Waclawek (kwaclaw) Summary: xml: namespace not closed after entity Initial Comment: When an external entity is parsed, StartNamespaceDecl is called for xml http://www.w3.org/1998/namespace (from setContext). On exit, EndNamespaceDecl is not called, and the calls become unbalanced. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2004-04-07 20:10 Message: Logged In: YES user_id=290026 Please check if the attached patch - nsDecl.diff - works for you. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-03-22 22:58 Message: Logged In: YES user_id=290026 Assigned to me - would like to have this resolved before releasing 1.95.8. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-03-20 21:52 Message: Logged In: YES user_id=290026 I looked at the code, and I am wondering why startNamespaceDecl() is called at all. Why should Expat call it when starting to parse an external entity? Am I overlooking something? At the moment it appears to me that this call-back is an undesirable side-effect of a child parser inheriting namespace scopes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=920274&group_id=10127 From noreply at sourceforge.net Wed Apr 7 20:17:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Apr 7 20:17:07 2004 Subject: [Expat-bugs] [ expat-Bugs-916718 ] CDATA Sections is not parsed Properly Message-ID: Bugs item #916718, was opened at 2004-03-15 11:14 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=916718&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Karl Waclawek (kwaclaw) Summary: CDATA Sections is not parsed Properly Initial Comment: When Expat encounters CDATA, it should parse it as a CDATA, but it's parsing normally ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2004-04-07 20:17 Message: Logged In: YES user_id=290026 Closed, because the original bug report is too unspecific, and the poster did not follow up on requests for more detail. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-03-15 13:00 Message: Logged In: YES user_id=290026 CDATA sections work fine for me. I have no idea what you mean - can you be more specific? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=916718&group_id=10127 From noreply at sourceforge.net Thu Apr 8 02:45:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 8 02:45:26 2004 Subject: [Expat-bugs] [ expat-Bugs-931546 ] Unixode support for Windows and Unix are not compatible Message-ID: Bugs item #931546, was opened at 2004-04-08 09:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=931546&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Arthur Prosso (turik) Assigned to: Nobody/Anonymous (nobody) Summary: Unixode support for Windows and Unix are not compatible Initial Comment: This bug or "feauture" exists in 1.95.6 and also 1.95.7 versions (I have not tested the previous ones). There is inconsistency between the Unicode support on Unix and on Windows. On windows wchar_t is defined as unsighed short. On most Unix platforms it is defined as unsigned int If expat is compiled with XML_UNICODE_WCHAR_T switch, then XML_Char is defined as wchar_t, but ICHAR type is hardcoded as unsigned short for UNIX (see xmparse.c). As e result, every in XmlConvert() every two unsigned short characters are packed into one wchar_t character. Is it "BY DESIGN" ??? But the OnElementStart(XML_Char*), OnElementEnd (XML_Char*) handlers assume a regular wchar_t character. As a result, the code written on Windows is not UNIX compatible. The same problem occurs, when encoding ("UTF-16") is used. Before Calling XML_Parse on UNIX, the input buffer of type wchar_t* must be manually converted to unsigned short* to make things work Please, explain this behaviour. Is it a "bug" or "by design" ? Thank you ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=931546&group_id=10127 From noreply at sourceforge.net Thu Apr 8 09:03:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 8 10:02:43 2004 Subject: [Expat-bugs] [ expat-Bugs-931546 ] Unixode support for Windows and Unix are not compatible Message-ID: Bugs item #931546, was opened at 2004-04-08 02:45 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=931546&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Arthur Prosso (turik) Assigned to: Nobody/Anonymous (nobody) Summary: Unixode support for Windows and Unix are not compatible Initial Comment: This bug or "feauture" exists in 1.95.6 and also 1.95.7 versions (I have not tested the previous ones). There is inconsistency between the Unicode support on Unix and on Windows. On windows wchar_t is defined as unsighed short. On most Unix platforms it is defined as unsigned int If expat is compiled with XML_UNICODE_WCHAR_T switch, then XML_Char is defined as wchar_t, but ICHAR type is hardcoded as unsigned short for UNIX (see xmparse.c). As e result, every in XmlConvert() every two unsigned short characters are packed into one wchar_t character. Is it "BY DESIGN" ??? But the OnElementStart(XML_Char*), OnElementEnd (XML_Char*) handlers assume a regular wchar_t character. As a result, the code written on Windows is not UNIX compatible. The same problem occurs, when encoding ("UTF-16") is used. Before Calling XML_Parse on UNIX, the input buffer of type wchar_t* must be manually converted to unsigned short* to make things work Please, explain this behaviour. Is it a "bug" or "by design" ? Thank you ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2004-04-08 09:02 Message: Logged In: YES user_id=290026 Expat assumes that wchar_t is defined as two-byte character type. Otherwise UTF-16 output would not be possible. That is why the README file includes the "-fshort_wchar" compiler option in the build instructions for Unix. If a Unix compiler does not support this option, then one has to build Expat with XML_UNICODE defined, but with XML_UNICODE_WCHAR_T undefined. This defines XML_Char as unsigned short instead of wchar_t. In both cases, there is not problem with ICHAR, and Expat works the same on Windows and Unix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=931546&group_id=10127 From noreply at sourceforge.net Thu Apr 8 10:44:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 8 10:44:28 2004 Subject: [Expat-bugs] [ expat-Bugs-931546 ] Unixode support for Windows and Unix are not compatible Message-ID: Bugs item #931546, was opened at 2004-04-07 23:45 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=931546&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Arthur Prosso (turik) Assigned to: Nobody/Anonymous (nobody) Summary: Unixode support for Windows and Unix are not compatible Initial Comment: This bug or "feauture" exists in 1.95.6 and also 1.95.7 versions (I have not tested the previous ones). There is inconsistency between the Unicode support on Unix and on Windows. On windows wchar_t is defined as unsighed short. On most Unix platforms it is defined as unsigned int If expat is compiled with XML_UNICODE_WCHAR_T switch, then XML_Char is defined as wchar_t, but ICHAR type is hardcoded as unsigned short for UNIX (see xmparse.c). As e result, every in XmlConvert() every two unsigned short characters are packed into one wchar_t character. Is it "BY DESIGN" ??? But the OnElementStart(XML_Char*), OnElementEnd (XML_Char*) handlers assume a regular wchar_t character. As a result, the code written on Windows is not UNIX compatible. The same problem occurs, when encoding ("UTF-16") is used. Before Calling XML_Parse on UNIX, the input buffer of type wchar_t* must be manually converted to unsigned short* to make things work Please, explain this behaviour. Is it a "bug" or "by design" ? Thank you ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-04-08 07:44 Message: Logged In: NO Waclav, than you for your answer I think it IS A BUG, because 1) you cannot write platform independent code this way, since wchar_t is a system type and the default is unsigned int on UNIX and unsighned short on Windows 2) wchar_t can't be used as unsigned short in a straightforward way, because if libc functions for wide character support are used in the code, every time one will need converting types from wchar_t to short before calling EXPAT API and back when getting the buffers from the callback functions. 3) If you always assume XML_CHAR is ALWAYS unsigned short, there is no need to have both XML_UNICODE and XML_UNICODE_WCHAR_T switches Will this issue be corrected in the next releases? Thank you. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-04-08 06:02 Message: Logged In: YES user_id=290026 Expat assumes that wchar_t is defined as two-byte character type. Otherwise UTF-16 output would not be possible. That is why the README file includes the "-fshort_wchar" compiler option in the build instructions for Unix. If a Unix compiler does not support this option, then one has to build Expat with XML_UNICODE defined, but with XML_UNICODE_WCHAR_T undefined. This defines XML_Char as unsigned short instead of wchar_t. In both cases, there is not problem with ICHAR, and Expat works the same on Windows and Unix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=931546&group_id=10127 From noreply at sourceforge.net Thu Apr 8 11:05:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 8 11:05:35 2004 Subject: [Expat-bugs] [ expat-Bugs-931546 ] Unixode support for Windows and Unix are not compatible Message-ID: Bugs item #931546, was opened at 2004-04-08 02:45 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=931546&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Arthur Prosso (turik) Assigned to: Nobody/Anonymous (nobody) Summary: Unixode support for Windows and Unix are not compatible Initial Comment: This bug or "feauture" exists in 1.95.6 and also 1.95.7 versions (I have not tested the previous ones). There is inconsistency between the Unicode support on Unix and on Windows. On windows wchar_t is defined as unsighed short. On most Unix platforms it is defined as unsigned int If expat is compiled with XML_UNICODE_WCHAR_T switch, then XML_Char is defined as wchar_t, but ICHAR type is hardcoded as unsigned short for UNIX (see xmparse.c). As e result, every in XmlConvert() every two unsigned short characters are packed into one wchar_t character. Is it "BY DESIGN" ??? But the OnElementStart(XML_Char*), OnElementEnd (XML_Char*) handlers assume a regular wchar_t character. As a result, the code written on Windows is not UNIX compatible. The same problem occurs, when encoding ("UTF-16") is used. Before Calling XML_Parse on UNIX, the input buffer of type wchar_t* must be manually converted to unsigned short* to make things work Please, explain this behaviour. Is it a "bug" or "by design" ? Thank you ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2004-04-08 11:05 Message: Logged In: YES user_id=290026 If you want to use wchar_t in your application as an unsigned int, then you cannot use it for UTF-16 Unicode anyway. So you are better off using UTF-8. One can say: Expat does not support wchar_t unless it is defined as a 16bit type. Which means you cannot write platform independent code using wchar_t if you want to run it on platforms that use unsigned int for it. In that case, use unsigned short and leave XML_UNICODE_WCHAR_T undefined. This is not an Expat isse, but a platform issue with using wchar_t for UTF-16, which works on Windows, but not on some Unixes. I am curious, what would you want to change in Expat? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-04-08 10:44 Message: Logged In: NO Waclav, than you for your answer I think it IS A BUG, because 1) you cannot write platform independent code this way, since wchar_t is a system type and the default is unsigned int on UNIX and unsighned short on Windows 2) wchar_t can't be used as unsigned short in a straightforward way, because if libc functions for wide character support are used in the code, every time one will need converting types from wchar_t to short before calling EXPAT API and back when getting the buffers from the callback functions. 3) If you always assume XML_CHAR is ALWAYS unsigned short, there is no need to have both XML_UNICODE and XML_UNICODE_WCHAR_T switches Will this issue be corrected in the next releases? Thank you. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-04-08 09:02 Message: Logged In: YES user_id=290026 Expat assumes that wchar_t is defined as two-byte character type. Otherwise UTF-16 output would not be possible. That is why the README file includes the "-fshort_wchar" compiler option in the build instructions for Unix. If a Unix compiler does not support this option, then one has to build Expat with XML_UNICODE defined, but with XML_UNICODE_WCHAR_T undefined. This defines XML_Char as unsigned short instead of wchar_t. In both cases, there is not problem with ICHAR, and Expat works the same on Windows and Unix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=931546&group_id=10127 From noreply at sourceforge.net Thu Apr 8 11:26:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 8 11:26:44 2004 Subject: [Expat-bugs] [ expat-Bugs-931546 ] Unixode support for Windows and Unix are not compatible Message-ID: Bugs item #931546, was opened at 2004-04-07 23:45 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=931546&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Arthur Prosso (turik) Assigned to: Nobody/Anonymous (nobody) Summary: Unixode support for Windows and Unix are not compatible Initial Comment: This bug or "feauture" exists in 1.95.6 and also 1.95.7 versions (I have not tested the previous ones). There is inconsistency between the Unicode support on Unix and on Windows. On windows wchar_t is defined as unsighed short. On most Unix platforms it is defined as unsigned int If expat is compiled with XML_UNICODE_WCHAR_T switch, then XML_Char is defined as wchar_t, but ICHAR type is hardcoded as unsigned short for UNIX (see xmparse.c). As e result, every in XmlConvert() every two unsigned short characters are packed into one wchar_t character. Is it "BY DESIGN" ??? But the OnElementStart(XML_Char*), OnElementEnd (XML_Char*) handlers assume a regular wchar_t character. As a result, the code written on Windows is not UNIX compatible. The same problem occurs, when encoding ("UTF-16") is used. Before Calling XML_Parse on UNIX, the input buffer of type wchar_t* must be manually converted to unsigned short* to make things work Please, explain this behaviour. Is it a "bug" or "by design" ? Thank you ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-04-08 08:26 Message: Logged In: NO Waclav, thank you for the answer again. I would like to have an option to use expat on UNIX, using native wchar_t type, without bothering to convert the buffers to unsigned short and back, and all this while being able to use UTF-8 and UTF-16 encoding I suppose that for problem fixing you just should not use hardcoded "unsigned short" in the functions' API, but use wchar_t or any other internal expat's type defined as wchar_t. So the overall number of changes will be minor. I have already compiled the "corrected" version of expat and it works. Using -fshort_wchar is a bad idea, beacause in large projects you will not be able to link against most of the libraries, including libc, which was not compiled with -fshort_wchar Thank you ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-04-08 08:05 Message: Logged In: YES user_id=290026 If you want to use wchar_t in your application as an unsigned int, then you cannot use it for UTF-16 Unicode anyway. So you are better off using UTF-8. One can say: Expat does not support wchar_t unless it is defined as a 16bit type. Which means you cannot write platform independent code using wchar_t if you want to run it on platforms that use unsigned int for it. In that case, use unsigned short and leave XML_UNICODE_WCHAR_T undefined. This is not an Expat isse, but a platform issue with using wchar_t for UTF-16, which works on Windows, but not on some Unixes. I am curious, what would you want to change in Expat? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-04-08 07:44 Message: Logged In: NO Waclav, than you for your answer I think it IS A BUG, because 1) you cannot write platform independent code this way, since wchar_t is a system type and the default is unsigned int on UNIX and unsighned short on Windows 2) wchar_t can't be used as unsigned short in a straightforward way, because if libc functions for wide character support are used in the code, every time one will need converting types from wchar_t to short before calling EXPAT API and back when getting the buffers from the callback functions. 3) If you always assume XML_CHAR is ALWAYS unsigned short, there is no need to have both XML_UNICODE and XML_UNICODE_WCHAR_T switches Will this issue be corrected in the next releases? Thank you. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-04-08 06:02 Message: Logged In: YES user_id=290026 Expat assumes that wchar_t is defined as two-byte character type. Otherwise UTF-16 output would not be possible. That is why the README file includes the "-fshort_wchar" compiler option in the build instructions for Unix. If a Unix compiler does not support this option, then one has to build Expat with XML_UNICODE defined, but with XML_UNICODE_WCHAR_T undefined. This defines XML_Char as unsigned short instead of wchar_t. In both cases, there is not problem with ICHAR, and Expat works the same on Windows and Unix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=931546&group_id=10127 From noreply at sourceforge.net Thu Apr 8 11:32:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 8 11:32:54 2004 Subject: [Expat-bugs] [ expat-Bugs-931546 ] Unicode support for Windows and Unix are not compatible Message-ID: Bugs item #931546, was opened at 2004-04-08 02:45 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=931546&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Arthur Prosso (turik) Assigned to: Nobody/Anonymous (nobody) >Summary: Unicode support for Windows and Unix are not compatible Initial Comment: This bug or "feauture" exists in 1.95.6 and also 1.95.7 versions (I have not tested the previous ones). There is inconsistency between the Unicode support on Unix and on Windows. On windows wchar_t is defined as unsighed short. On most Unix platforms it is defined as unsigned int If expat is compiled with XML_UNICODE_WCHAR_T switch, then XML_Char is defined as wchar_t, but ICHAR type is hardcoded as unsigned short for UNIX (see xmparse.c). As e result, every in XmlConvert() every two unsigned short characters are packed into one wchar_t character. Is it "BY DESIGN" ??? But the OnElementStart(XML_Char*), OnElementEnd (XML_Char*) handlers assume a regular wchar_t character. As a result, the code written on Windows is not UNIX compatible. The same problem occurs, when encoding ("UTF-16") is used. Before Calling XML_Parse on UNIX, the input buffer of type wchar_t* must be manually converted to unsigned short* to make things work Please, explain this behaviour. Is it a "bug" or "by design" ? Thank you ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-04-08 11:26 Message: Logged In: NO Waclav, thank you for the answer again. I would like to have an option to use expat on UNIX, using native wchar_t type, without bothering to convert the buffers to unsigned short and back, and all this while being able to use UTF-8 and UTF-16 encoding I suppose that for problem fixing you just should not use hardcoded "unsigned short" in the functions' API, but use wchar_t or any other internal expat's type defined as wchar_t. So the overall number of changes will be minor. I have already compiled the "corrected" version of expat and it works. Using -fshort_wchar is a bad idea, beacause in large projects you will not be able to link against most of the libraries, including libc, which was not compiled with -fshort_wchar Thank you ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-04-08 11:05 Message: Logged In: YES user_id=290026 If you want to use wchar_t in your application as an unsigned int, then you cannot use it for UTF-16 Unicode anyway. So you are better off using UTF-8. One can say: Expat does not support wchar_t unless it is defined as a 16bit type. Which means you cannot write platform independent code using wchar_t if you want to run it on platforms that use unsigned int for it. In that case, use unsigned short and leave XML_UNICODE_WCHAR_T undefined. This is not an Expat isse, but a platform issue with using wchar_t for UTF-16, which works on Windows, but not on some Unixes. I am curious, what would you want to change in Expat? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-04-08 10:44 Message: Logged In: NO Waclav, than you for your answer I think it IS A BUG, because 1) you cannot write platform independent code this way, since wchar_t is a system type and the default is unsigned int on UNIX and unsighned short on Windows 2) wchar_t can't be used as unsigned short in a straightforward way, because if libc functions for wide character support are used in the code, every time one will need converting types from wchar_t to short before calling EXPAT API and back when getting the buffers from the callback functions. 3) If you always assume XML_CHAR is ALWAYS unsigned short, there is no need to have both XML_UNICODE and XML_UNICODE_WCHAR_T switches Will this issue be corrected in the next releases? Thank you. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-04-08 09:02 Message: Logged In: YES user_id=290026 Expat assumes that wchar_t is defined as two-byte character type. Otherwise UTF-16 output would not be possible. That is why the README file includes the "-fshort_wchar" compiler option in the build instructions for Unix. If a Unix compiler does not support this option, then one has to build Expat with XML_UNICODE defined, but with XML_UNICODE_WCHAR_T undefined. This defines XML_Char as unsigned short instead of wchar_t. In both cases, there is not problem with ICHAR, and Expat works the same on Windows and Unix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=931546&group_id=10127 From noreply at sourceforge.net Thu Apr 8 11:45:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 8 11:45:06 2004 Subject: [Expat-bugs] [ expat-Bugs-931546 ] Unixode support for Windows and Unix are not compatible Message-ID: Bugs item #931546, was opened at 2004-04-08 02:45 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=931546&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Arthur Prosso (turik) Assigned to: Nobody/Anonymous (nobody) >Summary: Unixode support for Windows and Unix are not compatible Initial Comment: This bug or "feauture" exists in 1.95.6 and also 1.95.7 versions (I have not tested the previous ones). There is inconsistency between the Unicode support on Unix and on Windows. On windows wchar_t is defined as unsighed short. On most Unix platforms it is defined as unsigned int If expat is compiled with XML_UNICODE_WCHAR_T switch, then XML_Char is defined as wchar_t, but ICHAR type is hardcoded as unsigned short for UNIX (see xmparse.c). As e result, every in XmlConvert() every two unsigned short characters are packed into one wchar_t character. Is it "BY DESIGN" ??? But the OnElementStart(XML_Char*), OnElementEnd (XML_Char*) handlers assume a regular wchar_t character. As a result, the code written on Windows is not UNIX compatible. The same problem occurs, when encoding ("UTF-16") is used. Before Calling XML_Parse on UNIX, the input buffer of type wchar_t* must be manually converted to unsigned short* to make things work Please, explain this behaviour. Is it a "bug" or "by design" ? Thank you ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2004-04-08 11:45 Message: Logged In: YES user_id=290026 Well, you simply can't use UTF-16 with a 32bit wchar_t type, since it is defined as a 16bit encoding. AFAIK, the libc libraries supporting Unicode for this type of wchar_t implement UTF-32 and not UTF-16. Expat simply is not built to output UTF-32. Sure you can copy a UTF-16 encoded string into an array of 32bit types, but then you don't have UTF-16 anymore, you have a propietary encoding. This should not be an officially distributed configuration of Expat. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-04-08 11:26 Message: Logged In: NO Waclav, thank you for the answer again. I would like to have an option to use expat on UNIX, using native wchar_t type, without bothering to convert the buffers to unsigned short and back, and all this while being able to use UTF-8 and UTF-16 encoding I suppose that for problem fixing you just should not use hardcoded "unsigned short" in the functions' API, but use wchar_t or any other internal expat's type defined as wchar_t. So the overall number of changes will be minor. I have already compiled the "corrected" version of expat and it works. Using -fshort_wchar is a bad idea, beacause in large projects you will not be able to link against most of the libraries, including libc, which was not compiled with -fshort_wchar Thank you ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-04-08 11:05 Message: Logged In: YES user_id=290026 If you want to use wchar_t in your application as an unsigned int, then you cannot use it for UTF-16 Unicode anyway. So you are better off using UTF-8. One can say: Expat does not support wchar_t unless it is defined as a 16bit type. Which means you cannot write platform independent code using wchar_t if you want to run it on platforms that use unsigned int for it. In that case, use unsigned short and leave XML_UNICODE_WCHAR_T undefined. This is not an Expat isse, but a platform issue with using wchar_t for UTF-16, which works on Windows, but not on some Unixes. I am curious, what would you want to change in Expat? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-04-08 10:44 Message: Logged In: NO Waclav, than you for your answer I think it IS A BUG, because 1) you cannot write platform independent code this way, since wchar_t is a system type and the default is unsigned int on UNIX and unsighned short on Windows 2) wchar_t can't be used as unsigned short in a straightforward way, because if libc functions for wide character support are used in the code, every time one will need converting types from wchar_t to short before calling EXPAT API and back when getting the buffers from the callback functions. 3) If you always assume XML_CHAR is ALWAYS unsigned short, there is no need to have both XML_UNICODE and XML_UNICODE_WCHAR_T switches Will this issue be corrected in the next releases? Thank you. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-04-08 09:02 Message: Logged In: YES user_id=290026 Expat assumes that wchar_t is defined as two-byte character type. Otherwise UTF-16 output would not be possible. That is why the README file includes the "-fshort_wchar" compiler option in the build instructions for Unix. If a Unix compiler does not support this option, then one has to build Expat with XML_UNICODE defined, but with XML_UNICODE_WCHAR_T undefined. This defines XML_Char as unsigned short instead of wchar_t. In both cases, there is not problem with ICHAR, and Expat works the same on Windows and Unix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=931546&group_id=10127 From noreply at sourceforge.net Fri Apr 16 23:17:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 16 23:17:29 2004 Subject: [Expat-bugs] [ expat-Bugs-936754 ] Looking for a solution to have carriage return Message-ID: Bugs item #936754, was opened at 2004-04-17 03:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=936754&group_id=10127 Category: XML::Parser (inactive) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Chatelaine (jchatelaine) Assigned to: Nobody/Anonymous (nobody) Summary: Looking for a solution to have carriage return Initial Comment: http://www.w3.org/TR/2004/REC-xml-20040204/#sec- line-ends A shame this doesn't seem to be supported I tried in my xml file: PlayerText="Line1#xD#xALine2" The output I receive is exactly this one and not a string with a carriage return in between line1 and line2 as intended. Any idea, work around, patch for that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=936754&group_id=10127 From noreply at sourceforge.net Fri Apr 16 23:22:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 16 23:22:22 2004 Subject: [Expat-bugs] [ expat-Bugs-936754 ] Looking for a solution to have carriage return Message-ID: Bugs item #936754, was opened at 2004-04-17 03:17 Message generated for change (Settings changed) made by jchatelaine You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=936754&group_id=10127 Category: XML::Parser (inactive) Group: None >Status: Deleted Resolution: None Priority: 5 Submitted By: Jeremy Chatelaine (jchatelaine) Assigned to: Nobody/Anonymous (nobody) Summary: Looking for a solution to have carriage return Initial Comment: http://www.w3.org/TR/2004/REC-xml-20040204/#sec- line-ends A shame this doesn't seem to be supported I tried in my xml file: PlayerText="Line1#xD#xALine2" The output I receive is exactly this one and not a string with a carriage return in between line1 and line2 as intended. Any idea, work around, patch for that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=936754&group_id=10127 From noreply at sourceforge.net Sun Apr 18 13:46:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Apr 18 13:46:46 2004 Subject: [Expat-bugs] [ expat-Bugs-936754 ] Looking for a solution to have carriage return Message-ID: Bugs item #936754, was opened at 2004-04-16 20:17 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=936754&group_id=10127 Category: XML::Parser (inactive) Group: None Status: Deleted Resolution: None Priority: 5 Submitted By: Jeremy Chatelaine (jchatelaine) Assigned to: Nobody/Anonymous (nobody) Summary: Looking for a solution to have carriage return Initial Comment: http://www.w3.org/TR/2004/REC-xml-20040204/#sec- line-ends A shame this doesn't seem to be supported I tried in my xml file: PlayerText="Line1#xD#xALine2" The output I receive is exactly this one and not a string with a carriage return in between line1 and line2 as intended. Any idea, work around, patch for that? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-04-18 10:46 Message: Logged In: NO You should be using "Line1 Line2" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=936754&group_id=10127 From noreply at sourceforge.net Sun Apr 18 18:19:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Apr 18 18:19:36 2004 Subject: [Expat-bugs] [ expat-Bugs-936754 ] Looking for a solution to have carriage return Message-ID: Bugs item #936754, was opened at 2004-04-17 03:17 Message generated for change (Comment added) made by jchatelaine You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=936754&group_id=10127 Category: XML::Parser (inactive) Group: None Status: Deleted Resolution: None Priority: 5 Submitted By: Jeremy Chatelaine (jchatelaine) Assigned to: Nobody/Anonymous (nobody) Summary: Looking for a solution to have carriage return Initial Comment: http://www.w3.org/TR/2004/REC-xml-20040204/#sec- line-ends A shame this doesn't seem to be supported I tried in my xml file: PlayerText="Line1#xD#xALine2" The output I receive is exactly this one and not a string with a carriage return in between line1 and line2 as intended. Any idea, work around, patch for that? ---------------------------------------------------------------------- >Comment By: Jeremy Chatelaine (jchatelaine) Date: 2004-04-18 22:19 Message: Logged In: YES user_id=791446 I know, that's why I closed it. I though it will disappear. I searched one hour without success, enter this bug, then find the solution the next 5 minutes by luck... sometimes... :) Thanks for your answer. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-04-18 17:46 Message: Logged In: NO You should be using "Line1 Line2" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=936754&group_id=10127 From noreply at sourceforge.net Thu Apr 22 12:09:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 22 12:10:02 2004 Subject: [Expat-bugs] [ expat-Bugs-940135 ] Missing Win32 VCPROJ + SLN file Message-ID: Bugs item #940135, was opened at 2004-04-22 09:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=940135&group_id=10127 Category: Documentation Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: D Brown (key88sf) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Missing Win32 VCPROJ + SLN file Initial Comment: You left out the Win32 .vcproj and .sln files, so there is no easy build for Win32 with Visual Studio. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=940135&group_id=10127 From noreply at sourceforge.net Thu Apr 22 12:33:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 22 12:33:33 2004 Subject: [Expat-bugs] [ expat-Bugs-940135 ] Missing Win32 VCPROJ + SLN file Message-ID: Bugs item #940135, was opened at 2004-04-22 12:09 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=940135&group_id=10127 Category: Documentation Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: D Brown (key88sf) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Missing Win32 VCPROJ + SLN file Initial Comment: You left out the Win32 .vcproj and .sln files, so there is no easy build for Win32 with Visual Studio. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2004-04-22 12:33 Message: Logged In: YES user_id=290026 We are not yet supporting VS.NET, only VC++ 6.0. Would you be willing to contribute the files needed to build under VS.NET? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=940135&group_id=10127 From noreply at sourceforge.net Mon Apr 26 12:34:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Apr 26 12:34:43 2004 Subject: [Expat-bugs] [ expat-Bugs-942460 ] how to configure the expat library for cross compilation. Message-ID: Bugs item #942460, was opened at 2004-04-26 09:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=942460&group_id=10127 Category: None Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: how to configure the expat library for cross compilation. Initial Comment: Hi, Iam using i686 architecure.I want to build my application using ppc_405 architecture.I have the gcc,lib,etc..for my ppc_405 architecture. In my application am using the expat library calls.So i have to reconfigure my expat library for PPC architecture.hope am right ? In that regard i want to know how to configure it for PPC architecture. i gave the following option. #./configure --host=ppc --prefix=. CC=ppc_405gcc is thiz fine ?? or else shud i give some more like --build ?? can you mail me direclty to sbabu_psgbits@yahoo.co.in thanks in advance, ~Babu.S ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=942460&group_id=10127 From noreply at sourceforge.net Mon Apr 26 12:37:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Apr 26 12:37:46 2004 Subject: [Expat-bugs] [ expat-Bugs-942465 ] dllimport' attribute directive ignored warning Message-ID: Bugs item #942465, was opened at 2004-04-26 09:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=942465&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: dllimport' attribute directive ignored warning Initial Comment: Hi, am getting so much of warnings when i make the expat library. lib/expat.h:853: warning: `dllimport' attribute directive ignored lib/expat.h:886: warning: `dllimport' attribute directive ignored lib/expat.h:892: warning: `dllimport' attribute directive ignored lib/expat.h:910: warning: `dllimport' attribute directive ignored lib/expat.h:911: warning: `dllimport' attribute directive ignored lib/expat.h:912: warning: `dllimport' attribute directive ignored lib/expat.h:918: warning: `dllimport' attribute directive ignored etc.................. can u help me to resolve it ? thanks ~Babu.S ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=942465&group_id=10127 From fdrake at acm.org Thu Apr 29 23:45:37 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Thu Apr 29 23:45:57 2004 Subject: [Expat-bugs] [PATCH] small include addition to compile 1.95.7 on BeOS In-Reply-To: <20031108233457.12707.4@bepc.home.astercity.net> References: <20031108233457.12707.4@bepc.home.astercity.net> Message-ID: <200404292345.37441.fdrake@acm.org> On Saturday 08 November 2003 05:34 pm, shard@neoni.net wrote: > There is only one more include needed to compile expat on BeOS, it would > be great if it could be applied to official sources :) Sorry it's taken so long to get to this. I've added the patch in CVS, so it'll be included in Expat 1.95.8. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From noreply at sourceforge.net Fri Apr 30 00:13:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 30 00:13:56 2004 Subject: [Expat-bugs] [ expat-Bugs-945042 ] external.h not installed Message-ID: Bugs item #945042, was opened at 2004-04-30 00:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=945042&group_id=10127 Category: Build control Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Greg Stein (gstein) Summary: external.h not installed Initial Comment: Reported by Fr?d?ric L. W. Meunier: When compiling CVS, for some reason external.h doesn't get installed by make install. Since expat.h includes it, everything breaks. BTW, I'm not sure if external.h is a good name for a header that gets installed. What about expat_external.h or something with expat in the name? Or install external.h in an expat directory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=945042&group_id=10127 From noreply at sourceforge.net Fri Apr 30 00:15:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 30 00:15:04 2004 Subject: [Expat-bugs] [ expat-Bugs-942465 ] dllimport' attribute directive ignored warning Message-ID: Bugs item #942465, was opened at 2004-04-26 12:37 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=942465&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: dllimport' attribute directive ignored warning Initial Comment: Hi, am getting so much of warnings when i make the expat library. lib/expat.h:853: warning: `dllimport' attribute directive ignored lib/expat.h:886: warning: `dllimport' attribute directive ignored lib/expat.h:892: warning: `dllimport' attribute directive ignored lib/expat.h:910: warning: `dllimport' attribute directive ignored lib/expat.h:911: warning: `dllimport' attribute directive ignored lib/expat.h:912: warning: `dllimport' attribute directive ignored lib/expat.h:918: warning: `dllimport' attribute directive ignored etc.................. can u help me to resolve it ? thanks ~Babu.S ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2004-04-30 00:15 Message: Logged In: YES user_id=290026 Details please. How do you build, platform, etc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=942465&group_id=10127 From noreply at sourceforge.net Fri Apr 30 00:18:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 30 00:18:39 2004 Subject: [Expat-bugs] [ expat-Bugs-942460 ] how to configure the expat library for cross compilation. Message-ID: Bugs item #942460, was opened at 2004-04-26 12:34 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=942460&group_id=10127 Category: None Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: how to configure the expat library for cross compilation. Initial Comment: Hi, Iam using i686 architecure.I want to build my application using ppc_405 architecture.I have the gcc,lib,etc..for my ppc_405 architecture. In my application am using the expat library calls.So i have to reconfigure my expat library for PPC architecture.hope am right ? In that regard i want to know how to configure it for PPC architecture. i gave the following option. #./configure --host=ppc --prefix=. CC=ppc_405gcc is thiz fine ?? or else shud i give some more like --build ?? can you mail me direclty to sbabu_psgbits@yahoo.co.in thanks in advance, ~Babu.S ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2004-04-30 00:18 Message: Logged In: YES user_id=290026 I don't think our team has anyone with PPC expertise. It would be nice if you could find a solution and submit it back to this project as a patch. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=942460&group_id=10127 From noreply at sourceforge.net Fri Apr 30 00:23:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 30 00:23:13 2004 Subject: [Expat-bugs] [ expat-Bugs-931546 ] Unixode support for Windows and Unix are not compatible Message-ID: Bugs item #931546, was opened at 2004-04-08 02:45 Message generated for change (Settings changed) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=931546&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Arthur Prosso (turik) Assigned to: Nobody/Anonymous (nobody) Summary: Unixode support for Windows and Unix are not compatible Initial Comment: This bug or "feauture" exists in 1.95.6 and also 1.95.7 versions (I have not tested the previous ones). There is inconsistency between the Unicode support on Unix and on Windows. On windows wchar_t is defined as unsighed short. On most Unix platforms it is defined as unsigned int If expat is compiled with XML_UNICODE_WCHAR_T switch, then XML_Char is defined as wchar_t, but ICHAR type is hardcoded as unsigned short for UNIX (see xmparse.c). As e result, every in XmlConvert() every two unsigned short characters are packed into one wchar_t character. Is it "BY DESIGN" ??? But the OnElementStart(XML_Char*), OnElementEnd (XML_Char*) handlers assume a regular wchar_t character. As a result, the code written on Windows is not UNIX compatible. The same problem occurs, when encoding ("UTF-16") is used. Before Calling XML_Parse on UNIX, the input buffer of type wchar_t* must be manually converted to unsigned short* to make things work Please, explain this behaviour. Is it a "bug" or "by design" ? Thank you ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2004-04-30 00:23 Message: Logged In: YES user_id=290026 Closing this issue since I could not be convinced that support of 32bit wchar_t for UTF-16 output makes sense. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-04-08 11:45 Message: Logged In: YES user_id=290026 Well, you simply can't use UTF-16 with a 32bit wchar_t type, since it is defined as a 16bit encoding. AFAIK, the libc libraries supporting Unicode for this type of wchar_t implement UTF-32 and not UTF-16. Expat simply is not built to output UTF-32. Sure you can copy a UTF-16 encoded string into an array of 32bit types, but then you don't have UTF-16 anymore, you have a propietary encoding. This should not be an officially distributed configuration of Expat. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-04-08 11:26 Message: Logged In: NO Waclav, thank you for the answer again. I would like to have an option to use expat on UNIX, using native wchar_t type, without bothering to convert the buffers to unsigned short and back, and all this while being able to use UTF-8 and UTF-16 encoding I suppose that for problem fixing you just should not use hardcoded "unsigned short" in the functions' API, but use wchar_t or any other internal expat's type defined as wchar_t. So the overall number of changes will be minor. I have already compiled the "corrected" version of expat and it works. Using -fshort_wchar is a bad idea, beacause in large projects you will not be able to link against most of the libraries, including libc, which was not compiled with -fshort_wchar Thank you ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-04-08 11:05 Message: Logged In: YES user_id=290026 If you want to use wchar_t in your application as an unsigned int, then you cannot use it for UTF-16 Unicode anyway. So you are better off using UTF-8. One can say: Expat does not support wchar_t unless it is defined as a 16bit type. Which means you cannot write platform independent code using wchar_t if you want to run it on platforms that use unsigned int for it. In that case, use unsigned short and leave XML_UNICODE_WCHAR_T undefined. This is not an Expat isse, but a platform issue with using wchar_t for UTF-16, which works on Windows, but not on some Unixes. I am curious, what would you want to change in Expat? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-04-08 10:44 Message: Logged In: NO Waclav, than you for your answer I think it IS A BUG, because 1) you cannot write platform independent code this way, since wchar_t is a system type and the default is unsigned int on UNIX and unsighned short on Windows 2) wchar_t can't be used as unsigned short in a straightforward way, because if libc functions for wide character support are used in the code, every time one will need converting types from wchar_t to short before calling EXPAT API and back when getting the buffers from the callback functions. 3) If you always assume XML_CHAR is ALWAYS unsigned short, there is no need to have both XML_UNICODE and XML_UNICODE_WCHAR_T switches Will this issue be corrected in the next releases? Thank you. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-04-08 09:02 Message: Logged In: YES user_id=290026 Expat assumes that wchar_t is defined as two-byte character type. Otherwise UTF-16 output would not be possible. That is why the README file includes the "-fshort_wchar" compiler option in the build instructions for Unix. If a Unix compiler does not support this option, then one has to build Expat with XML_UNICODE defined, but with XML_UNICODE_WCHAR_T undefined. This defines XML_Char as unsigned short instead of wchar_t. In both cases, there is not problem with ICHAR, and Expat works the same on Windows and Unix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=931546&group_id=10127 From noreply at sourceforge.net Fri Apr 30 00:25:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 30 00:25:42 2004 Subject: [Expat-bugs] [ expat-Bugs-920274 ] xml: namespace not closed after entity Message-ID: Bugs item #920274, was opened at 2004-03-20 18:35 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=920274&group_id=10127 Category: None >Group: Test Required Status: Open >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: xml: namespace not closed after entity Initial Comment: When an external entity is parsed, StartNamespaceDecl is called for xml http://www.w3.org/1998/namespace (from setContext). On exit, EndNamespaceDecl is not called, and the calls become unbalanced. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2004-04-30 00:25 Message: Logged In: YES user_id=290026 The patch has been committed to xmlparse.c - forgot which revision. Needs testing. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-04-07 20:10 Message: Logged In: YES user_id=290026 Please check if the attached patch - nsDecl.diff - works for you. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-03-22 22:58 Message: Logged In: YES user_id=290026 Assigned to me - would like to have this resolved before releasing 1.95.8. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-03-20 21:52 Message: Logged In: YES user_id=290026 I looked at the code, and I am wondering why startNamespaceDecl() is called at all. Why should Expat call it when starting to parse an external entity? Am I overlooking something? At the moment it appears to me that this call-back is an undesirable side-effect of a child parser inheriting namespace scopes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=920274&group_id=10127 From noreply at sourceforge.net Fri Apr 30 01:57:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 30 01:57:16 2004 Subject: [Expat-bugs] [ expat-Bugs-888329 ] Doesn't print URL for 'check' tool Message-ID: Bugs item #888329, was opened at 2004-01-31 17:07 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=888329&group_id=10127 Category: Build control Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Ed Avis (epaepa) Assigned to: Greg Stein (gstein) Summary: Doesn't print URL for 'check' tool Initial Comment: I downloaded and unpacked expat-1.97.tar.gz, ran './configure --prefix=/home/ed' and then 'make check', which printed gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -I./li\b -I. -o tests/runtests.o -c tests/runtests.c tests/runtests.c:14: #error This test suite requires the 'check' unit test framework (http: make: *** [tests/runtests.o] Error 1 Note that the bit after 'http:' is missing. It should print a URL where the 'check' framework can be downloaded. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-04-30 01:57 Message: Logged In: YES user_id=3066 The "check" library will no longer be required for the regressions tests ("make check") starting with Expat 1.95.8. This has already been fixed in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=888329&group_id=10127 From noreply at sourceforge.net Fri Apr 30 02:00:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 30 02:00:40 2004 Subject: [Expat-bugs] [ expat-Bugs-780087 ] bad gcc flag when linking library in Solaris 2.8 Message-ID: Bugs item #780087, was opened at 2003-07-30 04:44 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=780087&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: bad gcc flag when linking library in Solaris 2.8 Initial Comment: expat 1.95.5, 1.95.6 When libtool links the lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo into libexpat.la on Solaris 2.8 when using gcc(3.3 or 3.1), libgcc(3.1 or 3.3) and binutils (2.11.2) ,from SunFreeware.com, it includes the '-no- undefined' flag which causes the make to always fail with a "main not found in crt1.o" error. This of course is silly 'coz a library has no 'main', see gcc discusion http://www.geocrawler.com/mail/msg.php3? msg_id=2903632&list=28. Looking at libtools "link" case statement I see it sets "allow_undefined=yes" but this does not translate to the make line. Could this be a problem? When I manually edited the "make" line, removing the flag '-no-undefined' the library was built without error. As this stops expat building from source on the above platform can I sugest that this is considered an urgent bug to be fixed? Of course I could be wrong :-) Here's an example (I've used 1.95.5 to avoid all those regparm warning messages you get in 1.95.6 on Solaris with gcc 3.1/3.3) snip--- Script started on Wed Jul 30 09:41:53 2003 sh-2.03$ cd expat-1.95.5 sh-2.03$ make distclean ; ./configure ; make cd lib && rm -f libexpat.la *.o *.lo && rm -rf .libs _libs cd xmlwf && rm -f xmlwf *.o *.lo && rm -rf .libs _libs cd examples && rm -f elements outline *.o *.lo && rm - rf .libs _libs cd tests && rm -rf .libs runtests runtests.o chardata.o rm -rf .libs libexpat.la find . -name core | xargs rm -f rm -f expat_config.h config.status config.log config.cache libtool rm -f Makefile checking build system type... sparc-sun-solaris2.8 checking host system type... sparc-sun-solaris2.8 checking for gcc... /usr/local/bin/gcc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /usr/local/bin/gcc accepts -g... yes checking for ld used by GCC... /usr/local/bin/gcc checking if the linker (/usr/local/bin/gcc) is GNU ld... no checking for /usr/local/bin/gcc option to reload object files... -r checking for BSD-compatible nm... /usr/local/bin/nm -B checking whether ln -s works... yes checking how to recognise dependant libraries... pass_all checking command to parse /usr/local/bin/nm -B output... ok checking how to run the C preprocessor... /usr/local/bin/gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... no checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for ranlib... ranlib checking for strip... strip checking for objdir... .libs checking for /usr/local/bin/gcc option to produce PIC... - fPIC checking if /usr/local/bin/gcc PIC flag -fPIC works... yes checking if /usr/local/bin/gcc static flag -static works... yes checking if /usr/local/bin/gcc supports -c -o file.o... yes checking if /usr/local/bin/gcc supports -c -o file.lo... yes checking if /usr/local/bin/gcc supports -fno-rtti -fno- exceptions... yes checking whether the linker (/usr/local/bin/gcc) supports shared libraries... ye s checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking dynamic linker characteristics... solaris2.8 ld.so checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes creating libtool checking for gcc... (cached) /usr/local/bin/gcc checking whether we are using the GNU C compiler... (cached) yes checking whether /usr/local/bin/gcc accepts -g... (cached) yes checking for a BSD-compatible install... conftools/install- sh -c checking whether gcc accepts -fexceptions... yes checking for ANSI C header files... (cached) yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking whether byte ordering is bigendian... yes checking for /usr/local/bin/gcc option to accept ANSI C... none needed checking for an ANSI C-conforming const... yes checking for off_t... yes checking for size_t... yes checking for working memcmp... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... yes checking for memmove... yes checking for bcopy... yes configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h /bin/bash ./libtool --silent -- mode=compile /usr/local/bin/gcc -g -O2 -Wall -Wmi ssing-prototypes -Wstrict-prototypes -fexceptions - I./lib -I. -o lib/xmlparse. lo -c lib/xmlparse.c /bin/bash ./libtool --silent -- mode=compile /usr/local/bin/gcc -g -O2 -Wall -Wmi ssing-prototypes -Wstrict-prototypes -fexceptions - I./lib -I. -o lib/xmltok.lo -c lib/xmltok.c /bin/bash ./libtool --silent -- mode=compile /usr/local/bin/gcc -g -O2 -Wall -Wmi ssing-prototypes -Wstrict-prototypes -fexceptions - I./lib -I. -o lib/xmlrole.l o -c lib/xmlrole.c /bin/bash ./libtool --silent -- mode=link /usr/local/bin/gcc -g -O2 -Wall -Wmissi ng-prototypes -Wstrict-prototypes -fexceptions - I./lib -I. -no-undefined -vers ion-info 4:0:4 -rpath /usr/local/lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo Undefined first referenced symbol in file main /usr/local/lib/gcc-lib/sparc- sun-solaris2.8/ 3.3/crt1.o ld: fatal: Symbol referencing errors. No output written to .libs/libexpat.so.0.4 .0 collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `libexpat.la' sh-2.03$ exit script done on Wed Jul 30 09:43:53 2003 snip--- ---------------------------------------------------------------------- Comment By: Faye Gibbins (fgibbins) Date: 2003-11-03 08:04 Message: Logged In: YES user_id=837230 I'm still getting this on Solairs 2.8 with expat 1.95.7 snip--- /bin/bash ./libtool --silent --mode=compile /usr/local/bin/gcc - g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes - fexceptions -DHAVE_EXPAT_CONFIG_H -I./lib -I. -o lib/xmltok.lo -c lib/xmltok.c /bin/bash ./libtool --silent --mode=compile /usr/local/bin/gcc - g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes - fexceptions -DHAVE_EXPAT_CONFIG_H -I./lib -I. -o lib/xmlrole.lo -c lib/xmlrole.c /bin/bash ./libtool --silent --mode=link /usr/local/bin/gcc -g - O2 -Wall -Wmissing-prototypes -Wstrict-prototypes - fexceptions -DHAVE_EXPAT_CONFIG_H -I./lib -I. -no- undefined -version-info 5:0:5 - rpath /home/l347283/tmp/expat/lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo Undefined first referenced symbol in file main /usr/local/lib/gcc-lib/sparc-sun- solaris2.8/3.3/crt1.o ld: fatal: Symbol referencing errors. No output written to .libs/libexpat.so.0.5.0 collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `libexpat.la' [l347283@ifperf expat-1.95.7]$ snip--- ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-14 15:47 Message: Logged In: YES user_id=3066 There's a snapshot of the current CVS version at: http://www.libexpat.org/expat-2003-10-11.tar.gz Can anyone reproduce this using this snapshot? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=780087&group_id=10127 From noreply at sourceforge.net Fri Apr 30 02:06:07 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 30 02:06:20 2004 Subject: [Expat-bugs] [ expat-Bugs-918730 ] namespace uri's arent checked for an ending hash Message-ID: Bugs item #918730, was opened at 2004-03-18 08:20 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=918730&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Jasper (jaspervdg) Assigned to: Nobody/Anonymous (nobody) Summary: namespace uri's arent checked for an ending hash Initial Comment: With a document like this (made much shorter): Earth Crisis The element types are resolved as follows (namespace separator is set to a hash): rdf:RDF -> http://www.w3.org/1999/02/22-rdf-syntax-ns##RDF mm:Artist -> http://musicbrainz.org/mm/mm-2.1##Artist dc:title -> http://purl.org/dc/elements/1.1/#title As far as I know that's not how it should be (having two hashes as separator in the first two cases). For my purpose I fixed it by modifying addBinding (in xmlparse.c) to check whether the namespace URI already ends in a hash. I am using version 1.95.7. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-04-30 02:06 Message: Logged In: YES user_id=3066 This is related to RDFs weird combining of namespace URIs and element/attribute names; Expat is doing the right thing, but it's up to the application to remove the separator character before making use of the combined URI+localName. I'm not aware of any non-RDF applications that use the concatenated form of URI+localName. I'm closing this as invalid; it's not Expat's job to cater to mixed up specifications like what RDF requires in this arena. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-03-18 09:17 Message: Logged In: YES user_id=290026 AFAIK, Expat does not check URIs for conformance at all. Maybe it should, but this is not implemented. In the case above I think the XML Namespaces spec allows hash marks, as they are legal in an URI reference. So, if you pick a namespace separator that can occur in your URIs then this is your problem, as the above looks like Expat works as designed. I suggest you try a character as namespace separator that is not a legal XML character. That should always work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=918730&group_id=10127 From noreply at sourceforge.net Fri Apr 30 02:12:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 30 02:12:38 2004 Subject: [Expat-bugs] [ expat-Bugs-926945 ] AMD64 - lib/expat.h: warning: `cdecl' attribute ignored Message-ID: Bugs item #926945, was opened at 2004-03-31 15:25 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=926945&group_id=10127 Category: Build control Group: Platform Specific >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: AMD64 - lib/expat.h: warning: `cdecl' attribute ignored Initial Comment: AMD 64 Opteron (Mandrake 9.2) Expat 1.95.7 when doing a simple ./configure and make, get about 100 of these messages: /bin/sh ./libtool --silent --mode=compile gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -I./lib -I. -o lib/xmlp arse.lo -c lib/xmlparse.c In file included from lib/xmlparse.c:20: lib/expat.h:216: warning: `cdecl' attribute ignored lib/expat.h:220: warning: `cdecl' attribute ignored lib/expat.h:236: warning: `cdecl' attribute ignored ... lib/xmlparse.c:663: warning: `cdecl' attribute ignored lib/xmlparse.c:669: warning: `cdecl' attribute ignored lib/xmlparse.c:686: warning: `cdecl' attribute ignored and In file included from xmlwf/xmlwf.c:10: lib/expat.h:216: warning: `cdecl' attribute ignored ... xmlwf/xmlwf.c:25: warning: `cdecl' attribute ignored ... and In file included from xmlwf/xmlfile.c:17: lib/expat.h:216: warning: `cdecl' attribute ignored ... This does not happen in 1.95.6 asloan@antarctica.net ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-04-30 02:12 Message: Logged In: YES user_id=3066 Duplicate of SF bug #926893. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=926945&group_id=10127 From noreply at sourceforge.net Fri Apr 30 02:13:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 30 02:14:03 2004 Subject: [Expat-bugs] [ expat-Bugs-926893 ] AMD64 - lib/expat.h: warning: `cdecl' attribute ignored Message-ID: Bugs item #926893, was opened at 2004-03-31 14:12 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=926893&group_id=10127 Category: Build control Group: Platform Specific >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: AMD64 - lib/expat.h: warning: `cdecl' attribute ignored Initial Comment: AMD 64 Opteron (Mandrake 9.2) Expat 1.95.7 when doing a simple ./configure and make, get about 100 of these messages: /bin/sh ./libtool --silent --mode=compile gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -I./lib -I. -o lib/xmlp arse.lo -c lib/xmlparse.c In file included from lib/xmlparse.c:20: lib/expat.h:216: warning: `cdecl' attribute ignored lib/expat.h:220: warning: `cdecl' attribute ignored lib/expat.h:236: warning: `cdecl' attribute ignored ... lib/xmlparse.c:663: warning: `cdecl' attribute ignored lib/xmlparse.c:669: warning: `cdecl' attribute ignored lib/xmlparse.c:686: warning: `cdecl' attribute ignored and In file included from xmlwf/xmlwf.c:10: lib/expat.h:216: warning: `cdecl' attribute ignored ... xmlwf/xmlwf.c:25: warning: `cdecl' attribute ignored ... and In file included from xmlwf/xmlfile.c:17: lib/expat.h:216: warning: `cdecl' attribute ignored ... This does not happen in 1.95.6 asloan@antarctica.net ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-04-30 02:13 Message: Logged In: YES user_id=3066 Closed as rejected due to non-reponse from the original poster. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-03-31 14:27 Message: Logged In: YES user_id=290026 Please try with the current CVS version. It might be fixed there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=926893&group_id=10127 From noreply at sourceforge.net Fri Apr 30 02:14:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 30 02:14:57 2004 Subject: [Expat-bugs] [ expat-Bugs-693747 ] compile problem on HP-UX 11 with expat version > 1.95.4 Message-ID: Bugs item #693747, was opened at 2003-02-26 11:47 Message generated for change (Settings changed) made by fdrake 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: compile 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 ______________________ ---------------------------------------------------------------------- Comment By: Chris Liebman (liebman) Date: 2004-01-18 18:09 Message: Logged In: YES user_id=55478 I get the same error when compiling on a system that has an older version of expat.h already installed. In my case I'm adding additional include dirs... they are being placed befor -I./lib and -I. resulting in: gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -I/home/liebman/ats-rt/include -I/home/liebman/ats-rt/ext/include -I./lib -I. -o xmlwf/xmlwf.o -c xmlwf/xmlwf.c In file included from xmlwf/xmlwf.c:10: /home/liebman/ats-rt/ext/include/expat.h:704: warning: function declaration isn't a prototype xmlwf/xmlwf.c: In function `showVersion': xmlwf/xmlwf.c:602: error: syntax error before '*' token xmlwf/xmlwf.c:613: error: `features' undeclared (first use in this function) xmlwf/xmlwf.c:613: error: (Each undeclared identifier is reported only once xmlwf/xmlwf.c:613: error: for each function it appears in.) xmlwf/xmlwf.c:613: error: `XML_FEATURE_END' undeclared (first use in this function) 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 Apr 30 02:38:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 30 02:38:46 2004 Subject: [Expat-bugs] [ expat-Bugs-918730 ] namespace uri's arent checked for an ending hash Message-ID: Bugs item #918730, was opened at 2004-03-18 14:20 Message generated for change (Comment added) made by jaspervdg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=918730&group_id=10127 Category: None Group: None Status: Closed Resolution: Invalid Priority: 5 Submitted By: Jasper (jaspervdg) Assigned to: Nobody/Anonymous (nobody) Summary: namespace uri's arent checked for an ending hash Initial Comment: With a document like this (made much shorter): Earth Crisis The element types are resolved as follows (namespace separator is set to a hash): rdf:RDF -> http://www.w3.org/1999/02/22-rdf-syntax-ns##RDF mm:Artist -> http://musicbrainz.org/mm/mm-2.1##Artist dc:title -> http://purl.org/dc/elements/1.1/#title As far as I know that's not how it should be (having two hashes as separator in the first two cases). For my purpose I fixed it by modifying addBinding (in xmlparse.c) to check whether the namespace URI already ends in a hash. I am using version 1.95.7. ---------------------------------------------------------------------- >Comment By: Jasper (jaspervdg) Date: 2004-04-30 08:38 Message: Logged In: YES user_id=730345 You're right, I only found that out some time after I posted this (it's in the RDF/XML specification for those who are interested). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-04-30 08:06 Message: Logged In: YES user_id=3066 This is related to RDFs weird combining of namespace URIs and element/attribute names; Expat is doing the right thing, but it's up to the application to remove the separator character before making use of the combined URI+localName. I'm not aware of any non-RDF applications that use the concatenated form of URI+localName. I'm closing this as invalid; it's not Expat's job to cater to mixed up specifications like what RDF requires in this arena. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-03-18 15:17 Message: Logged In: YES user_id=290026 AFAIK, Expat does not check URIs for conformance at all. Maybe it should, but this is not implemented. In the case above I think the XML Namespaces spec allows hash marks, as they are legal in an URI reference. So, if you pick a namespace separator that can occur in your URIs then this is your problem, as the above looks like Expat works as designed. I suggest you try a character as namespace separator that is not a legal XML character. That should always work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=918730&group_id=10127 From noreply at sourceforge.net Fri Apr 30 09:35:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 30 09:35:06 2004 Subject: [Expat-bugs] [ expat-Bugs-828485 ] expat_win32 bin built with /MT instead of /MD Message-ID: Bugs item #828485, was opened at 2003-10-22 16:47 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=828485&group_id=10127 Category: Build control Group: None >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Karl Waclawek (kwaclaw) Summary: expat_win32 bin built with /MT instead of /MD Initial Comment: With version 1.95.7, the expat_win32 binaries are built with /MT (multi-threaded libraries linked-in). This is also the default in the expat 1.95.7 Visual Studio project. The README.txt says "By default the Expat Dlls are built to link with the multi-threaded run-time Dll." ... that is /MD, which is also what I'd expect. Bernard bernard@zeroc.com ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2004-04-30 09:35 Message: Logged In: YES user_id=290026 I don't have the full version of BCB5 and cannot correct the project files. Since the build behaviour is documented in the README file, we do not really have a bug but rather an inconsistency and inconvenience. I am closing this report as I don't have the means or time to correct this minor issue. Maybe someone else will submit a patch for this (rather outdated) compiler. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-11-02 09:08 Message: Logged In: YES user_id=290026 There is still an inconsistency on Windows, as the BCB5 make files build with linkage to the Borland runtime Dll. I think I should change that to be consistent with the MS VC++ builds. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-11-02 03:14 Message: Logged In: YES user_id=3066 Anything else to be done here? If not, this issue can be closed. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-23 22:03 Message: Logged In: YES user_id=290026 Corrected documentation - ReadMe files in BCB5 and Win32 directories. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-22 20:26 Message: Logged In: YES user_id=290026 Thanks for pointing out these inconsistencies. As far as default options are concerned: I think we should leave it as /MT as this does not force one to include MSVCRTxx.DLL in the distribution. So what should be fixed is the documentation. In any case, it's easy to change for a custom build. Are there good reasons to do it differently? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=828485&group_id=10127 From noreply at sourceforge.net Fri Apr 30 09:54:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 30 09:54:50 2004 Subject: [Expat-bugs] [ expat-Bugs-221310 ] File missing during install of Expat Message-ID: Bugs item #221310, was opened at 2000-11-03 12:15 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=221310&group_id=10127 Category: None Group: None Status: Closed Resolution: Duplicate Priority: 5 Submitted By: Orbhost Sysadmin (orbhostadmin) Assigned to: Clark Cooper (coopercc) Summary: File missing during install of Expat Initial Comment: Platform is Alpha Tru64 V5.1 CC="cc" MAKE="gmake" ./configure creating cache ./config.cache checking host system type... alphaev56-dec-osf5.1 checking build system type... alphaev56-dec-osf5.1 checking for ranlib... ranlib checking for gcc... cc checking whether the C compiler (cc ) works... yes checking whether the C compiler (cc ) is a cross-compiler... no checking whether we are using GNU C... no checking whether cc accepts -g... yes checking for non-GNU ld... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for BSD-compatible nm... /usr/local/bin/nm -B checking whether ln -s works... yes updating cache ./config.cache loading cache ./config.cache within ltconfig checking whether we are using GNU C... no checking for object suffix... o checking for executable suffix... no checking for cc option to produce PIC... none checking if cc supports -c -o file.o... yes checking if cc supports -c -o file.lo... yes checking if cc static flag -non_shared works... -non_shared checking if the linker (/usr/bin/ld) is GNU ld... no checking whether the linker (/usr/bin/ld) supports shared libraries... yes checking command to parse /usr/local/bin/nm -B output... ok checking how to hardcode library paths into programs... immediate checking for /usr/bin/ld option to reload object files... -r checking dynamic linker characteristics... osf5.1 ld.so checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for objdir... .libs creating libtool updating cache ./config.cache loading cache ./config.cache checking for gcc... (cached) cc checking whether the C compiler (cc -g ) works... yes checking whether the C compiler (cc -g ) is a cross-compiler... no checking whether we are using GNU C... (cached) no checking whether cc accepts -g... (cached) yes checking for a BSD compatible install... /usr/local/bin/install -c checking how to run the C preprocessor... cc -E checking for ANSI C header files... yes checking for fcntl.h... yes checking for unistd.h... yes checking whether byte ordering is bigendian... no checking for working const... yes checking for off_t... yes checking for size_t... yes checking for 8-bit clean memcmp... yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... yes checking for memmove... yes checking for bcopy... yes updating cache ./config.cache creating ./config.status creating Makefile creating lib/Makefile creating xmlwf/Makefile creating examples/Makefile creating config.h gmake cd lib; gmake gmake[1]: Entering directory `/usr/users/dg/work/expat-1.95.1/lib' /bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -DPACKAGE=expat -DVERSION=expat_1.95.1 -I. -I.. -g -c xmlparse.c mkdir .libs cc -DHAVE_CONFIG_H -DPACKAGE=\expat\ -DVERSION=\expat_1.95.1\ -I. -I.. -g -Wp,-MD,.deps/xmlparse.pp -c xmlparse.c -DPIC -o .lib s/xmlparse.lo cc: Severe: No such file or directory ... file is '.deps/xmlparse.pp' gmake[1]: *** [xmlparse.lo] Error 1 gmake[1]: Leaving directory `/usr/users/dg/work/expat-1.95.1/lib' gmake: *** [lib] Error 2 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-04-30 06:54 Message: Logged In: NO Try downloading it from: http://sourceforge.net/projects/expat Dennis.McEnaney@marconi.com ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-03-16 07:08 Message: Logged In: NO Clark, It may indeed be a problem as you indicated in that scenario, however the problem remains: Checking if your kit is complete... Looks good Writing Makefile for XML::Parser::Expat Writing Makefile for XML::Parser cp Parser/Encodings/x-sjis-cp932.enc blib/lib/XML/Parser/Encodings/x-sjis-cp932.enc cp Parser/Encodings/iso-8859-7.enc blib/lib/XML/Parser/Encodings/iso-8859-7.enc cp Parser/Style/Tree.pm blib/lib/XML/Parser/Style/Tree.pm cp Parser/Encodings/iso-8859-9.enc blib/lib/XML/Parser/Encodings/iso-8859-9.enc cp Parser/Encodings/x-euc-jp-unicode.enc blib/lib/XML/Parser/Encodings/x-euc-jp-unicode.enc cp Parser/Encodings/README blib/lib/XML/Parser/Encodings/README cp Parser/Encodings/euc-kr.enc blib/lib/XML/Parser/Encodings/euc-kr.enc cp Parser/Encodings/windows-1250.enc blib/lib/XML/Parser/Encodings/windows-1250.enc cp Parser/Encodings/windows-1252.enc blib/lib/XML/Parser/Encodings/windows-1252.enc cp Parser/Encodings/big5.enc blib/lib/XML/Parser/Encodings/big5.enc cp Parser/Encodings/iso-8859-3.enc blib/lib/XML/Parser/Encodings/iso-8859-3.enc cp Parser/Encodings/Japanese_Encodings.msg blib/lib/XML/Parser/Encodings/Japanese_Encodings.msg cp Parser/Style/Subs.pm blib/lib/XML/Parser/Style/Subs.pm cp Parser/Encodings/x-euc-jp-jisx0221.enc blib/lib/XML/Parser/Encodings/x-euc-jp-jisx0221.enc cp Parser/Encodings/iso-8859-8.enc blib/lib/XML/Parser/Encodings/iso-8859-8.enc cp Parser/Encodings/iso-8859-4.enc blib/lib/XML/Parser/Encodings/iso-8859-4.enc cp Parser/Encodings/iso-8859-2.enc blib/lib/XML/Parser/Encodings/iso-8859-2.enc cp Parser/Encodings/x-sjis-jdk117.enc blib/lib/XML/Parser/Encodings/x-sjis-jdk117.enc cp Parser/LWPExternEnt.pl blib/lib/XML/Parser/LWPExternEnt.pl cp Parser/Encodings/x-sjis-unicode.enc blib/lib/XML/Parser/Encodings/x-sjis-unicode.enc cp Parser/Style/Objects.pm blib/lib/XML/Parser/Style/Objects.pm cp Parser/Style/Debug.pm blib/lib/XML/Parser/Style/Debug.pm cp Parser.pm blib/lib/XML/Parser.pm cp Parser/Encodings/x-sjis-jisx0221.enc blib/lib/XML/Parser/Encodings/x-sjis-jisx0221.enc cp Parser/Style/Stream.pm blib/lib/XML/Parser/Style/Stream.pm cp Parser/Encodings/iso-8859-5.enc blib/lib/XML/Parser/Encodings/iso-8859-5.enc make[1]: Entering directory `/root/.cpan/build/XML-Parser-2.34/Expat' cp Expat.pm ../blib/lib/XML/Parser/Expat.pm /usr/bin/perl /usr/lib/perl5/5.8.0/ExtUtils/xsubpp -noprototypes -typemap /usr/lib/perl5/5.8.0/ExtUtils/typemap -typemap typemap Expat.xs > Expat.xsc && mv Expat.xsc Expat.c gcc -c -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 -march=i386 -mcpu=i686 -DVERSION=\2.34\ -DXS_VERSION=\2.34\ -fpic "-I/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE" Expat.c Expat.xs:12:19: expat.h: No such file or directory This is from RedHat 8. A simple "find" under the directory /root/.cpan/sources/authors/id/M/MS/MSERGEANT/XML-Parser-2.34 shows no expat.h file anywhere. ---------------------------------------------------------------------- Comment By: Clark Cooper (coopercc) Date: 2000-12-21 07:37 Message: There's no file missing. Your cc doesn't recognize the flags for checking header dependencies. If it recognized -Wp,-MD,.deps/xmlparse.pp then your compiler would generate the file. This is a configuration and or Makefile problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=221310&group_id=10127 From noreply at sourceforge.net Fri Apr 30 11:16:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 30 11:19:46 2004 Subject: [Expat-bugs] [ expat-Bugs-945042 ] external.h not installed Message-ID: Bugs item #945042, was opened at 2004-04-30 00:13 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=945042&group_id=10127 Category: Build control Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Greg Stein (gstein) Summary: external.h not installed Initial Comment: Reported by Fr?d?ric L. W. Meunier: When compiling CVS, for some reason external.h doesn't get installed by make install. Since expat.h includes it, everything breaks. BTW, I'm not sure if external.h is a good name for a header that gets installed. What about expat_external.h or something with expat in the name? Or install external.h in an expat directory. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2004-04-30 11:16 Message: Logged In: YES user_id=290026 Just to establish the link: the addition of the new file external.h relates to issue #923913. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=945042&group_id=10127 From noreply at sourceforge.net Fri Apr 30 11:41:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 30 11:41:43 2004 Subject: [Expat-bugs] [ expat-Bugs-928113 ] XML_SetUnknownEncodingHandler() return values are mixed. Message-ID: Bugs item #928113, was opened at 2004-04-02 04:05 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=928113&group_id=10127 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Maxim Petrovich Dementiev (maximdementiev) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: XML_SetUnknownEncodingHandler() return values are mixed. Initial Comment: In documentation (reference.html) to expat-1.95.7 wrote: "If the handler knows how to deal with an encoding with the given name, it should fill in the info data structure and return XML_STATUS_ERROR. Otherwise it should return XML_STATUS_OK." In expat.h: enum XML_Status { XML_STATUS_ERROR = 0, // false #define XML_STATUS_ERROR XML_STATUS_ERROR XML_STATUS_OK = 1 // not zero - ture #define XML_STATUS_OK XML_STATUS_OK }; In xmlparse.c: if (unknownEncodingHandler(...)) { // ... handler knows how to deal ... ... return XML_ERROR_NONE; } ... return XML_ERROR_UNKNOWN_ENCODING; So right might be: "If the handler knows how to deal with an encoding ... return XML_STATUS_OK (not zero - ture). Otherwise it should return XML_STATUS_ERROR (zero - false)." ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2004-04-30 11:41 Message: Logged In: YES user_id=290026 Fixed in reference.html rev. 1.57. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=928113&group_id=10127 From noreply at sourceforge.net Fri Apr 30 11:47:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 30 11:47:17 2004 Subject: [Expat-bugs] [ expat-Bugs-928113 ] XML_SetUnknownEncodingHandler() return values are mixed. Message-ID: Bugs item #928113, was opened at 2004-04-02 04:05 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=928113&group_id=10127 Category: Documentation Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Maxim Petrovich Dementiev (maximdementiev) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: XML_SetUnknownEncodingHandler() return values are mixed. Initial Comment: In documentation (reference.html) to expat-1.95.7 wrote: "If the handler knows how to deal with an encoding with the given name, it should fill in the info data structure and return XML_STATUS_ERROR. Otherwise it should return XML_STATUS_OK." In expat.h: enum XML_Status { XML_STATUS_ERROR = 0, // false #define XML_STATUS_ERROR XML_STATUS_ERROR XML_STATUS_OK = 1 // not zero - ture #define XML_STATUS_OK XML_STATUS_OK }; In xmlparse.c: if (unknownEncodingHandler(...)) { // ... handler knows how to deal ... ... return XML_ERROR_NONE; } ... return XML_ERROR_UNKNOWN_ENCODING; So right might be: "If the handler knows how to deal with an encoding ... return XML_STATUS_OK (not zero - ture). Otherwise it should return XML_STATUS_ERROR (zero - false)." ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2004-04-30 11:47 Message: Logged In: YES user_id=290026 Fixed in reference.html rev. 1.57. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-04-30 11:41 Message: Logged In: YES user_id=290026 Fixed in reference.html rev. 1.57. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=928113&group_id=10127 From noreply at sourceforge.net Fri Apr 30 13:13:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 30 13:13:12 2004 Subject: [Expat-bugs] [ expat-Bugs-940135 ] Missing Win32 VCPROJ + SLN file Message-ID: Bugs item #940135, was opened at 2004-04-22 12:09 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=940135&group_id=10127 Category: Documentation Group: Platform Specific >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: D Brown (key88sf) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Missing Win32 VCPROJ + SLN file Initial Comment: You left out the Win32 .vcproj and .sln files, so there is no easy build for Win32 with Visual Studio. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2004-04-30 13:13 Message: Logged In: YES user_id=290026 Since I just installed VS.NET 2003, I tried to open the old VC++ 6.0 workspace/project files and had no problem. They were imported and I was able to build successfully without any extra steps. I see currently no reason why we should maintain an extra set of project/solution files for VS.NET 2003 when there is no discernible advantage. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-04-22 12:33 Message: Logged In: YES user_id=290026 We are not yet supporting VS.NET, only VC++ 6.0. Would you be willing to contribute the files needed to build under VS.NET? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=940135&group_id=10127