From noreply@sourceforge.net Tue Oct 1 04:37:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Sep 2002 20:37:40 -0700 Subject: [Expat-bugs] [ expat-Bugs-616863 ] Default xmlns=... in external subset Message-ID: Bugs item #616863, was opened at 2002-09-30 23:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=616863&group_id=10127 Category: None Group: Test Required Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Default xmlns=... in external subset Initial Comment: This bug was reported by Jeremy Kloth. It applies to Expat 1.95.2, 1.95.4 and 1.95.5. If an xmlns attribute is defaulted in the external subset, one gets a NULL pointer error when parsing an external general entity. This can be reproduced with the attached files i18n.xml, l10n.xml and en.xml. The fix for that requires switching to a separately allocated DTD structure and is therefore quite extensive. Check the attached files patch.diff and overview.txt. The patch also contains some source code comments. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=616863&group_id=10127 From noreply@sourceforge.net Thu Oct 3 19:53:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 11:53:03 -0700 Subject: [Expat-bugs] [ expat-Patches-618199 ] storeRawNames fix for localPart Message-ID: Patches item #618199, was opened at 2002-10-03 11:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=618199&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: storeRawNames fix for localPart Initial Comment: When storing the raw names after processing a buffer, the pointer to the local-name structure is not updated with the rest of the name structures. This leads to segfaults on my machine. Also when run through valgrind, it reports invalid read accesses. Supplied is a tiny fix for this problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=618199&group_id=10127 From noreply@sourceforge.net Thu Oct 3 20:25:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 12:25:13 -0700 Subject: [Expat-bugs] [ expat-Patches-618199 ] storeRawNames fix for localPart Message-ID: Patches item #618199, was opened at 2002-10-03 14:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=618199&group_id=10127 Category: None Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: storeRawNames fix for localPart Initial Comment: When storing the raw names after processing a buffer, the pointer to the local-name structure is not updated with the rest of the name structures. This leads to segfaults on my machine. Also when run through valgrind, it reports invalid read accesses. Supplied is a tiny fix for this problem. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-10-03 15:25 Message: Logged In: YES user_id=290026 Good catch! Will apply your patch. Thanks, Karl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=618199&group_id=10127 From noreply@sourceforge.net Sat Oct 5 16:37:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 05 Oct 2002 08:37:21 -0700 Subject: [Expat-bugs] [ expat-Bugs-491986 ] Charset decoding error (64-bit systems) Message-ID: Bugs item #491986, was opened at 2001-12-12 07:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=491986&group_id=10127 Category: None Group: Platform Specific Status: Open Resolution: Works For Me Priority: 5 Submitted By: Bent Jensen (bentjensen) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Charset decoding error (64-bit systems) Initial Comment: When parsing xml with Danish letters (æøåÆØÅ) with eight bit set and declaring the encoding as (where the danish letters is placed as eight bit chars - the parser goes wrong. If the input is: Worker Five Jørgen five@foo.com Jørgen five@foo.com (Remark the danish letters in two forms) The output is: START: email CD: (null) - 'J' - 1 CD: (null) - 'rgen five@foo.com' - 17 END: email CD: (null) - ' ' - 1 CD: (null) - ' ' - 4 START: email CD: (null) - 'JÃ؟rgen five@foo.com' - 20 END: email CD: (null) - ' ' - 1 CD: (null) - ' ' - 4 What am i doing wrong ? If I embedd the string 'æøåÆØÅ' in the xml file - it goes all rigth ?!?! I have modifyed the 'outline' example program for the above test. Sincerly Bent Jensen, Senior consultant. bent@kiya.dk ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-10-05 11:37 Message: Logged In: YES user_id=290026 About the portability of bit shifts: If Expat used integer types with fixed sizes (e.g.those defined in C99) instead of platform dependent ones, or if we defined our own types to be always of the desired size regardless of platform, should that not solve the problem? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-07-10 13:59 Message: Logged In: YES user_id=3066 I just tried this on the Alpha system on the SourceForge compile farm and the CVS version of Expat, and the regression test I added doesn't trigger. Can you still reproduce this with the CVS version of Expat? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-19 15:45 Message: Logged In: YES user_id=3066 Good point. I've re-opened the report and noted the 64-bit dependency in the summary. ---------------------------------------------------------------------- Comment By: Bent Jensen (bentjensen) Date: 2002-04-19 15:14 Message: Logged In: YES user_id=392963 Hi again I have tried all combinations of telleing the parset that i want to use iso-8859-1 encoding - also to the XML_ParserCreate function. But you have to remark that i am running on a 64 bit machine and in the routine where you are reading the input chars you are doing bit shifts 'en masse' - and here everything can goes wrong - bitshifts are not portable ! Sincerly Bent Jensen, Senior consultant. bent@kiya.dk ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-19 14:46 Message: Logged In: YES user_id=3066 I cannot reproduce this using CVS Expat. I've added a regression test for this to be sure it doesn't crop up (tests/runtests.c revision 1.7). Make sure that you're passing either NULL or "iso-8859-1" to the XML_ParserCreate*() function as the encoding name. ---------------------------------------------------------------------- Comment By: Bent Jensen (bentjensen) Date: 2001-12-12 07:56 Message: Logged In: YES user_id=392963 Info: The expat package (version 1.95.2) was build on alpha/axp OSF1 4.0D with gcc version 2.95.3. The test was run on the same machine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=491986&group_id=10127 From noreply@sourceforge.net Mon Oct 7 21:02:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 13:02:38 -0700 Subject: [Expat-bugs] [ expat-Bugs-618199 ] storeRawNames fix for localPart Message-ID: Bugs item #618199, was opened at 2002-10-03 14:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=618199&group_id=10127 Category: None Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: storeRawNames fix for localPart Initial Comment: When storing the raw names after processing a buffer, the pointer to the local-name structure is not updated with the rest of the name structures. This leads to segfaults on my machine. Also when run through valgrind, it reports invalid read accesses. Supplied is a tiny fix for this problem. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-07 16:02 Message: Logged In: YES user_id=3066 For the record: This was committed as lib/xmlparse.c 1.91. Converting to a bug report that needs a regression test written for it. Will assign to me. (The "new" bug is the lack of a corresponding test.) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-10-03 15:25 Message: Logged In: YES user_id=290026 Good catch! Will apply your patch. Thanks, Karl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=618199&group_id=10127 From noreply@sourceforge.net Mon Oct 7 21:03:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 13:03:22 -0700 Subject: [Expat-bugs] [ expat-Bugs-618199 ] storeRawNames fix for localPart Message-ID: Bugs item #618199, was opened at 2002-10-03 14:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=618199&group_id=10127 Category: None >Group: Test Required Status: Open Resolution: Accepted Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: storeRawNames fix for localPart Initial Comment: When storing the raw names after processing a buffer, the pointer to the local-name structure is not updated with the rest of the name structures. This leads to segfaults on my machine. Also when run through valgrind, it reports invalid read accesses. Supplied is a tiny fix for this problem. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-07 16:02 Message: Logged In: YES user_id=3066 For the record: This was committed as lib/xmlparse.c 1.91. Converting to a bug report that needs a regression test written for it. Will assign to me. (The "new" bug is the lack of a corresponding test.) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-10-03 15:25 Message: Logged In: YES user_id=290026 Good catch! Will apply your patch. Thanks, Karl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=618199&group_id=10127 From noreply@sourceforge.net Mon Oct 7 21:05:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 13:05:23 -0700 Subject: [Expat-bugs] [ expat-Bugs-616863 ] Default xmlns=... in external subset Message-ID: Bugs item #616863, was opened at 2002-09-30 23:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=616863&group_id=10127 Category: None Group: Test Required Status: Open >Resolution: Accepted Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Default xmlns=... in external subset Initial Comment: This bug was reported by Jeremy Kloth. It applies to Expat 1.95.2, 1.95.4 and 1.95.5. If an xmlns attribute is defaulted in the external subset, one gets a NULL pointer error when parsing an external general entity. This can be reproduced with the attached files i18n.xml, l10n.xml and en.xml. The fix for that requires switching to a separately allocated DTD structure and is therefore quite extensive. Check the attached files patch.diff and overview.txt. The patch also contains some source code comments. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-07 16:05 Message: Logged In: YES user_id=3066 For the record: The patch was checked in as lib/xmlparse.c 1.90. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=616863&group_id=10127 From noreply@sourceforge.net Tue Oct 8 08:36:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Oct 2002 00:36:53 -0700 Subject: [Expat-bugs] [ expat-Patches-620106 ] XML_SetEncoding and external entities Message-ID: Patches item #620106, was opened at 2002-10-08 07:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=620106&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pavel Hlavnicka (pavel_hlavnicka) Assigned to: Nobody/Anonymous (nobody) Summary: XML_SetEncoding and external entities Initial Comment: We are using expat with Sablotron XSLT processor. Before parsing (using always XML_Parse) we check the document encoding and in the case it is not supported by expat, we call XML_SetEncoding to set utf-8, and recode the document before feeding the parser. All is ok until we parse external entities. We create an external entity parser with XML_ExternalEntityParserCreate, but we don't know the document encoding at this time. We use XML_SetEncoding later (the same case as for the 'root' document). In this case it doesn't work. I found out, that problem is probably in the XML_SetEncoding function, what just returns zero in the case parsing is in progress. The ``parsing'' macro checks, whether the current processor is ``prologInitProcessor'', what is never true for external entity parser. For this is it ``externalEnityInitProcessor''. The patch seems be easy, but, of course, I'm not sure I'm not breaking anything else. Thanks and keep your good work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=620106&group_id=10127 From noreply@sourceforge.net Tue Oct 8 08:39:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Oct 2002 00:39:23 -0700 Subject: [Expat-bugs] [ expat-Patches-620106 ] XML_SetEncoding and external entities Message-ID: Patches item #620106, was opened at 2002-10-08 07:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=620106&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pavel Hlavnicka (pavel_hlavnicka) Assigned to: Nobody/Anonymous (nobody) Summary: XML_SetEncoding and external entities Initial Comment: We are using expat with Sablotron XSLT processor. Before parsing (using always XML_Parse) we check the document encoding and in the case it is not supported by expat, we call XML_SetEncoding to set utf-8, and recode the document before feeding the parser. All is ok until we parse external entities. We create an external entity parser with XML_ExternalEntityParserCreate, but we don't know the document encoding at this time. We use XML_SetEncoding later (the same case as for the 'root' document). In this case it doesn't work. I found out, that problem is probably in the XML_SetEncoding function, what just returns zero in the case parsing is in progress. The ``parsing'' macro checks, whether the current processor is ``prologInitProcessor'', what is never true for external entity parser. For this is it ``externalEnityInitProcessor''. The patch seems be easy, but, of course, I'm not sure I'm not breaking anything else. Thanks and keep your good work. ---------------------------------------------------------------------- >Comment By: Pavel Hlavnicka (pavel_hlavnicka) Date: 2002-10-08 07:39 Message: Logged In: YES user_id=302801 The patch was not uploaded for some reason (the magic checkbox?? :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=620106&group_id=10127 From noreply@sourceforge.net Tue Oct 8 15:43:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Oct 2002 07:43:43 -0700 Subject: [Expat-bugs] [ expat-Bugs-620106 ] XML_SetEncoding and external entities Message-ID: Bugs item #620106, was opened at 2002-10-08 03:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=620106&group_id=10127 Category: None Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Pavel Hlavnicka (pavel_hlavnicka) Assigned to: Nobody/Anonymous (nobody) Summary: XML_SetEncoding and external entities Initial Comment: We are using expat with Sablotron XSLT processor. Before parsing (using always XML_Parse) we check the document encoding and in the case it is not supported by expat, we call XML_SetEncoding to set utf-8, and recode the document before feeding the parser. All is ok until we parse external entities. We create an external entity parser with XML_ExternalEntityParserCreate, but we don't know the document encoding at this time. We use XML_SetEncoding later (the same case as for the 'root' document). In this case it doesn't work. I found out, that problem is probably in the XML_SetEncoding function, what just returns zero in the case parsing is in progress. The ``parsing'' macro checks, whether the current processor is ``prologInitProcessor'', what is never true for external entity parser. For this is it ``externalEnityInitProcessor''. The patch seems be easy, but, of course, I'm not sure I'm not breaking anything else. Thanks and keep your good work. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-10-08 10:43 Message: Logged In: YES user_id=290026 I have changed this to a bug report and accepted it. Your patch seems OK, but does not go far enough.. Please try this one and give it a quick check so that I can commit it to CVS: #define parsing \ (parentParser \ ? \ (isParamEntity \ ? \ (processor != externalParEntInitProcessor) \ : \ (processor != externalEntityInitProcessor)) \ : \ (processor != prologInitProcessor)) ---------------------------------------------------------------------- Comment By: Pavel Hlavnicka (pavel_hlavnicka) Date: 2002-10-08 03:39 Message: Logged In: YES user_id=302801 The patch was not uploaded for some reason (the magic checkbox?? :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=620106&group_id=10127 From noreply@sourceforge.net Tue Oct 8 17:50:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Oct 2002 09:50:46 -0700 Subject: [Expat-bugs] [ expat-Bugs-620343 ] segfault: bad API/callback interaction Message-ID: Bugs item #620343, was opened at 2002-10-08 12:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=620343&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: segfault: bad API/callback interaction Initial Comment: There is a bad interaction between the call to the start element handler and the Expat API: After the presence of the callback is checked, the addBinding() function can call XML_SetStartElementHandler(parser, NULL), after which doContent() will still attempt to call the start element handler. This results in a call to the NULL address, resulting in a memory fault. This is unlikely to be an issue for applications written entirely in C, but can reasonably happen when a wrapper library clears callbacks when an error condition or exception has been detected. I've attached a patch and a regression test for this case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=620343&group_id=10127 From noreply@sourceforge.net Tue Oct 8 18:21:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Oct 2002 10:21:43 -0700 Subject: [Expat-bugs] [ expat-Bugs-620343 ] segfault: bad API/callback interaction Message-ID: Bugs item #620343, was opened at 2002-10-08 12:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=620343&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: segfault: bad API/callback interaction Initial Comment: There is a bad interaction between the call to the start element handler and the Expat API: After the presence of the callback is checked, the addBinding() function can call XML_SetStartElementHandler(parser, NULL), after which doContent() will still attempt to call the start element handler. This results in a call to the NULL address, resulting in a memory fault. This is unlikely to be an issue for applications written entirely in C, but can reasonably happen when a wrapper library clears callbacks when an error condition or exception has been detected. I've attached a patch and a regression test for this case. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-10-08 13:21 Message: Logged In: YES user_id=290026 Yes, verified. To be precise, addBinding() can call back to startNamespaceDeclHandler() which then allows the application to clear the startElementHandler. One comment: storeAtts() is called like this if (startElementHandler) { result = storeAtts(parser, ...); ... } presumably because the attributes should only be stored if needed for the startElementHandler. However, storeAtts does double duty by also processing namespace declarations and calling startNamespaceDeclHandler(). So, if that handler is set, should then not storeAtts() be called like this: if (startElementHandler || startNamespaceDeclHandler) { result = storeAtts(parser, ...); ... } And, if true, one should then apply this logic to the other occasions when storeAtts() is called. Or does it not make sense to set startNamespaceDeclHandler when startElementHandler is cleared? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=620343&group_id=10127 From noreply@sourceforge.net Tue Oct 8 18:36:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Oct 2002 10:36:23 -0700 Subject: [Expat-bugs] [ expat-Bugs-620343 ] segfault: bad API/callback interaction Message-ID: Bugs item #620343, was opened at 2002-10-08 12:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=620343&group_id=10127 Category: None Group: None Status: Open >Resolution: Fixed Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: segfault: bad API/callback interaction Initial Comment: There is a bad interaction between the call to the start element handler and the Expat API: After the presence of the callback is checked, the addBinding() function can call XML_SetStartElementHandler(parser, NULL), after which doContent() will still attempt to call the start element handler. This results in a call to the NULL address, resulting in a memory fault. This is unlikely to be an issue for applications written entirely in C, but can reasonably happen when a wrapper library clears callbacks when an error condition or exception has been detected. I've attached a patch and a regression test for this case. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-08 13:36 Message: Logged In: YES user_id=3066 Original patch checked in as lib/xmlparse.c 1.92 and tests/runtests.c 1.36, before I saw Karl's comments. Karl: Yes, we should probably fix things so the namespace decl handlers can be set independently, as the API suggests. I can take care of this, unless you beat me to it. ;-) Don't know that it warrants a separate issue report, so I'll leave this one as fixed but open for now. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-10-08 13:21 Message: Logged In: YES user_id=290026 Yes, verified. To be precise, addBinding() can call back to startNamespaceDeclHandler() which then allows the application to clear the startElementHandler. One comment: storeAtts() is called like this if (startElementHandler) { result = storeAtts(parser, ...); ... } presumably because the attributes should only be stored if needed for the startElementHandler. However, storeAtts does double duty by also processing namespace declarations and calling startNamespaceDeclHandler(). So, if that handler is set, should then not storeAtts() be called like this: if (startElementHandler || startNamespaceDeclHandler) { result = storeAtts(parser, ...); ... } And, if true, one should then apply this logic to the other occasions when storeAtts() is called. Or does it not make sense to set startNamespaceDeclHandler when startElementHandler is cleared? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=620343&group_id=10127 From noreply@sourceforge.net Tue Oct 8 18:40:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Oct 2002 10:40:36 -0700 Subject: [Expat-bugs] [ expat-Bugs-620343 ] segfault: bad API/callback interaction Message-ID: Bugs item #620343, was opened at 2002-10-08 12:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=620343&group_id=10127 Category: None Group: None Status: Open Resolution: Fixed Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: segfault: bad API/callback interaction Initial Comment: There is a bad interaction between the call to the start element handler and the Expat API: After the presence of the callback is checked, the addBinding() function can call XML_SetStartElementHandler(parser, NULL), after which doContent() will still attempt to call the start element handler. This results in a call to the NULL address, resulting in a memory fault. This is unlikely to be an issue for applications written entirely in C, but can reasonably happen when a wrapper library clears callbacks when an error condition or exception has been detected. I've attached a patch and a regression test for this case. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-10-08 13:40 Message: Logged In: YES user_id=290026 I am not *that* eager . You take care of it. Thanks! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-08 13:36 Message: Logged In: YES user_id=3066 Original patch checked in as lib/xmlparse.c 1.92 and tests/runtests.c 1.36, before I saw Karl's comments. Karl: Yes, we should probably fix things so the namespace decl handlers can be set independently, as the API suggests. I can take care of this, unless you beat me to it. ;-) Don't know that it warrants a separate issue report, so I'll leave this one as fixed but open for now. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-10-08 13:21 Message: Logged In: YES user_id=290026 Yes, verified. To be precise, addBinding() can call back to startNamespaceDeclHandler() which then allows the application to clear the startElementHandler. One comment: storeAtts() is called like this if (startElementHandler) { result = storeAtts(parser, ...); ... } presumably because the attributes should only be stored if needed for the startElementHandler. However, storeAtts does double duty by also processing namespace declarations and calling startNamespaceDeclHandler(). So, if that handler is set, should then not storeAtts() be called like this: if (startElementHandler || startNamespaceDeclHandler) { result = storeAtts(parser, ...); ... } And, if true, one should then apply this logic to the other occasions when storeAtts() is called. Or does it not make sense to set startNamespaceDeclHandler when startElementHandler is cleared? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=620343&group_id=10127 From noreply@sourceforge.net Wed Oct 9 14:23:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Oct 2002 06:23:24 -0700 Subject: [Expat-bugs] [ expat-Bugs-620106 ] XML_SetEncoding and external entities Message-ID: Bugs item #620106, was opened at 2002-10-08 03:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=620106&group_id=10127 Category: None >Group: Test Required Status: Open Resolution: Accepted Priority: 5 Submitted By: Pavel Hlavnicka (pavel_hlavnicka) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: XML_SetEncoding and external entities Initial Comment: We are using expat with Sablotron XSLT processor. Before parsing (using always XML_Parse) we check the document encoding and in the case it is not supported by expat, we call XML_SetEncoding to set utf-8, and recode the document before feeding the parser. All is ok until we parse external entities. We create an external entity parser with XML_ExternalEntityParserCreate, but we don't know the document encoding at this time. We use XML_SetEncoding later (the same case as for the 'root' document). In this case it doesn't work. I found out, that problem is probably in the XML_SetEncoding function, what just returns zero in the case parsing is in progress. The ``parsing'' macro checks, whether the current processor is ``prologInitProcessor'', what is never true for external entity parser. For this is it ``externalEnityInitProcessor''. The patch seems be easy, but, of course, I'm not sure I'm not breaking anything else. Thanks and keep your good work. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-10-09 09:23 Message: Logged In: YES user_id=290026 Applied patch - xmlparse.c rev. 1.93. Leave open for Fred, in case he wants to add a regression test. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-10-08 10:43 Message: Logged In: YES user_id=290026 I have changed this to a bug report and accepted it. Your patch seems OK, but does not go far enough.. Please try this one and give it a quick check so that I can commit it to CVS: #define parsing \ (parentParser \ ? \ (isParamEntity \ ? \ (processor != externalParEntInitProcessor) \ : \ (processor != externalEntityInitProcessor)) \ : \ (processor != prologInitProcessor)) ---------------------------------------------------------------------- Comment By: Pavel Hlavnicka (pavel_hlavnicka) Date: 2002-10-08 03:39 Message: Logged In: YES user_id=302801 The patch was not uploaded for some reason (the magic checkbox?? :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=620106&group_id=10127 From noreply@sourceforge.net Wed Oct 9 16:15:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Oct 2002 08:15:44 -0700 Subject: [Expat-bugs] [ expat-Patches-620822 ] Windows DLL build with DEF file Message-ID: Patches item #620822, was opened at 2002-10-09 11:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=620822&group_id=10127 Category: Build Control Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Windows DLL build with DEF file Initial Comment: This patch changes the Windows build (under VC++) to using DEF files, so that the export table for the Dlls remains binary compatible. It is based on the export table in Expat 1.95.2, extracted from the binary distribution Dll. Four exported functions have been added to the end of that table for release 1.95.5. The attached zip archive DefBuild.zip contains two DEF files, one for the expat project, and the other for the expatw project. Just add each file to the corresponding project in VC++. There is also a small patch for xmlparse.c required - included in the zip archive. Please test and provide feedback. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=620822&group_id=10127 From noreply@sourceforge.net Wed Oct 9 16:30:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Oct 2002 08:30:08 -0700 Subject: [Expat-bugs] [ expat-Bugs-579144 ] DLLs are not drop-in compatible Message-ID: Bugs item #579144, was opened at 2002-07-09 11:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=579144&group_id=10127 Category: Build control Group: Feature Request Status: Open Resolution: None Priority: 6 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: DLLs are not drop-in compatible Initial Comment: For Windows DLLs, Expat should be using a .DEF file instead of __declspec(dllexport) to control the export of symbols. Using a .DEF file allows symbols to have the same ordinal position in the export table of the DLL regardless of accidents of the compiler's organization of the table, allowing newer DLLs to replace older DLLs by simply dropping them in place. More information on DLL exports: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/HTML/_core_determine_which_exporting_method_to_use.asp This feature request is based on an email conversation with Nick Lehman, following up from: http://sourceforge.net/mailarchive/message.php?msg_id=1783043 ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-10-09 11:30 Message: Logged In: YES user_id=290026 I have added a patch #620822. Sorry - I realized too late that there was a bug report where I could have attached the patch. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-07-10 09:24 Message: Logged In: YES user_id=290026 Fred, are you sure a lot of people are reading this? Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-07-10 00:47 Message: Logged In: YES user_id=3066 It looks like the .DEF file should be easy enough to create, and a nuissance to maintain. I'm going to plan on getting this done in the 1.95.5 release, since we're too close to the 1.95.4 release to make a mess of things now. The big question that comes up is this: should the symbols defined in lib/xmltok.h be exported, or only the symbols from expat.h? Originally, these were exported from two separate DLLs, but it's not clear the API defined in xmltok.h is really intended to be public. If you have a reasoned opinion, or use the xmltok.h API, please follow up to this feature request. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=579144&group_id=10127 From noreply@sourceforge.net Fri Oct 11 11:07:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Oct 2002 03:07:12 -0700 Subject: [Expat-bugs] [ expat-Bugs-621797 ] Expat 1.95-5 build failure under Cygwin Message-ID: Bugs item #621797, was opened at 2002-10-11 03:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=621797&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: Expat 1.95-5 build failure under Cygwin Initial Comment: Attempting to build expat 1.95-5 under cygwin fails with the following: "/usr/lib/libcygwin.a(libcmain.o)(.text+0x81): undefined reference to `WinMain@16'" Full info from configure & make robertm@CLEMFAR ~/expat-1.95.5 $ ./configure checking build system type... i686-pc-cygwin checking host system type... i686-pc-cygwin checking for gcc... gcc checking for C compiler default output... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... .exe checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for ld used by GCC... /usr/i686-pc-cygwin/bin/ld.exe checking if the linker (/usr/i686-pc-cygwin/bin/ld.exe) is GNU ld... yes checking for /usr/i686-pc-cygwin/bin/ld.exe option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependant libraries... file_magic file format pei*-i386(.*architecture: i386)? checking command to parse /usr/bin/nm -B output... ok checking how to run the C preprocessor... 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... no 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 gcc option to produce PIC... -DDLL_EXPORT checking if gcc PIC flag -DDLL_EXPORT works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.lo... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking whether the linker (/usr/i686-pc-cygwin/bin/ld.exe) supports shared libraries... yes checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking dynamic linker characteristics... Win32 ld.exe 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) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ANSI C... (cached) none needed checking for a BSD-compatible install... /usr/bin/install -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... no 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... no checking for memmove... yes checking for bcopy... yes configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h robertm@CLEMFAR ~/expat-1.95.5 $ make /bin/bash ./libtool --silent --mode=compile gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -I./lib -I. -o lib/xmlparse.lo -c lib/xmlparse.c /bin/bash ./libtool --silent --mode=compile gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -I./lib -I. -o lib/xmltok.lo -c lib/xmltok.c /bin/bash ./libtool --silent --mode=compile gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -I./lib -I. -o lib/xmlrole.lo -c lib/xmlrole.c /bin/bash ./libtool --silent --mode=link gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -I./lib -I. -no-undefined -version-info 4:0:4 -rpath /usr/local/lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo /usr/lib/libcygwin.a(libcmain.o)(.text+0x81): undefined reference to `WinMain@16' collect2: ld returned 1 exit status make: *** [libexpat.la] Error 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=621797&group_id=10127 From noreply@sourceforge.net Fri Oct 11 14:10:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Oct 2002 06:10:35 -0700 Subject: [Expat-bugs] [ expat-Bugs-621797 ] Expat 1.95-5 build failure under Cygwin Message-ID: Bugs item #621797, was opened at 2002-10-11 06:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=621797&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Gerrit Haase (siebenschlaefer) Summary: Expat 1.95-5 build failure under Cygwin Initial Comment: Attempting to build expat 1.95-5 under cygwin fails with the following: "/usr/lib/libcygwin.a(libcmain.o)(.text+0x81): undefined reference to `WinMain@16'" Full info from configure & make robertm@CLEMFAR ~/expat-1.95.5 $ ./configure checking build system type... i686-pc-cygwin checking host system type... i686-pc-cygwin checking for gcc... gcc checking for C compiler default output... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... .exe checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for ld used by GCC... /usr/i686-pc-cygwin/bin/ld.exe checking if the linker (/usr/i686-pc-cygwin/bin/ld.exe) is GNU ld... yes checking for /usr/i686-pc-cygwin/bin/ld.exe option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependant libraries... file_magic file format pei*-i386(.*architecture: i386)? checking command to parse /usr/bin/nm -B output... ok checking how to run the C preprocessor... 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... no 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 gcc option to produce PIC... -DDLL_EXPORT checking if gcc PIC flag -DDLL_EXPORT works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.lo... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking whether the linker (/usr/i686-pc-cygwin/bin/ld.exe) supports shared libraries... yes checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking dynamic linker characteristics... Win32 ld.exe 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) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ANSI C... (cached) none needed checking for a BSD-compatible install... /usr/bin/install -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... no 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... no checking for memmove... yes checking for bcopy... yes configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h robertm@CLEMFAR ~/expat-1.95.5 $ make /bin/bash ./libtool --silent --mode=compile gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -I./lib -I. -o lib/xmlparse.lo -c lib/xmlparse.c /bin/bash ./libtool --silent --mode=compile gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -I./lib -I. -o lib/xmltok.lo -c lib/xmltok.c /bin/bash ./libtool --silent --mode=compile gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -I./lib -I. -o lib/xmlrole.lo -c lib/xmlrole.c /bin/bash ./libtool --silent --mode=link gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -I./lib -I. -no-undefined -version-info 4:0:4 -rpath /usr/local/lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo /usr/lib/libcygwin.a(libcmain.o)(.text+0x81): undefined reference to `WinMain@16' collect2: ld returned 1 exit status make: *** [libexpat.la] Error 1 ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-11 09:10 Message: Logged In: YES user_id=3066 Re-assigned to the CygWin expert. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=621797&group_id=10127 From noreply@sourceforge.net Fri Oct 11 14:33:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Oct 2002 06:33:45 -0700 Subject: [Expat-bugs] [ expat-Bugs-620106 ] XML_SetEncoding and external entities Message-ID: Bugs item #620106, was opened at 2002-10-08 07:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=620106&group_id=10127 Category: None Group: Test Required Status: Open Resolution: Accepted Priority: 5 Submitted By: Pavel Hlavnicka (pavel_hlavnicka) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: XML_SetEncoding and external entities Initial Comment: We are using expat with Sablotron XSLT processor. Before parsing (using always XML_Parse) we check the document encoding and in the case it is not supported by expat, we call XML_SetEncoding to set utf-8, and recode the document before feeding the parser. All is ok until we parse external entities. We create an external entity parser with XML_ExternalEntityParserCreate, but we don't know the document encoding at this time. We use XML_SetEncoding later (the same case as for the 'root' document). In this case it doesn't work. I found out, that problem is probably in the XML_SetEncoding function, what just returns zero in the case parsing is in progress. The ``parsing'' macro checks, whether the current processor is ``prologInitProcessor'', what is never true for external entity parser. For this is it ``externalEnityInitProcessor''. The patch seems be easy, but, of course, I'm not sure I'm not breaking anything else. Thanks and keep your good work. ---------------------------------------------------------------------- >Comment By: Pavel Hlavnicka (pavel_hlavnicka) Date: 2002-10-11 13:33 Message: Logged In: YES user_id=302801 It makes a good job for me, so I can confirm. Thanks, it was pretty fast. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-10-09 13:23 Message: Logged In: YES user_id=290026 Applied patch - xmlparse.c rev. 1.93. Leave open for Fred, in case he wants to add a regression test. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-10-08 14:43 Message: Logged In: YES user_id=290026 I have changed this to a bug report and accepted it. Your patch seems OK, but does not go far enough.. Please try this one and give it a quick check so that I can commit it to CVS: #define parsing \ (parentParser \ ? \ (isParamEntity \ ? \ (processor != externalParEntInitProcessor) \ : \ (processor != externalEntityInitProcessor)) \ : \ (processor != prologInitProcessor)) ---------------------------------------------------------------------- Comment By: Pavel Hlavnicka (pavel_hlavnicka) Date: 2002-10-08 07:39 Message: Logged In: YES user_id=302801 The patch was not uploaded for some reason (the magic checkbox?? :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=620106&group_id=10127 From noreply@sourceforge.net Sat Oct 12 21:45:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 12 Oct 2002 13:45:43 -0700 Subject: [Expat-bugs] [ expat-Bugs-622436 ] Static lib with other calling convention Message-ID: Bugs item #622436, was opened at 2002-10-12 13:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=622436&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: Static lib with other calling convention Initial Comment: Windows/Visual C++ 6.0 If you try to build the static lib with another default calling convention (__stdcall) or try using the given lib in a context where the calling convention is not __cdecl you have to apply the following changes. Reason: malloc(), realloc() and free() have always the __cdecl calling convention, and so XML_Memory_Handling_Suite must use the same. In file expat.h replace line 185-187 void *(*malloc_fcn)(size_t size); void *(*realloc_fcn)(void *ptr, size_t size); void (*free_fcn)(void *ptr); with void *(__cdecl *malloc_fcn)(size_t size); void *(__cdecl *realloc_fcn)(void *ptr, size_t size); void (__cdecl *free_fcn)(void *ptr); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=622436&group_id=10127 From noreply@sourceforge.net Sat Oct 12 21:50:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 12 Oct 2002 13:50:03 -0700 Subject: [Expat-bugs] [ expat-Bugs-622436 ] Static lib with other calling convention Message-ID: Bugs item #622436, was opened at 2002-10-12 13:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=622436&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: Static lib with other calling convention Initial Comment: Windows/Visual C++ 6.0 If you try to build the static lib with another default calling convention (__stdcall) or try using the given lib in a context where the calling convention is not __cdecl you have to apply the following changes. Reason: malloc(), realloc() and free() have always the __cdecl calling convention, and so XML_Memory_Handling_Suite must use the same. In file expat.h replace line 185-187 void *(*malloc_fcn)(size_t size); void *(*realloc_fcn)(void *ptr, size_t size); void (*free_fcn)(void *ptr); with void *(__cdecl *malloc_fcn)(size_t size); void *(__cdecl *realloc_fcn)(void *ptr, size_t size); void (__cdecl *free_fcn)(void *ptr); ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-10-12 13:50 Message: Logged In: NO Forgot to say that I am using 1.95.5 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=622436&group_id=10127 From noreply@sourceforge.net Wed Oct 16 20:03:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Oct 2002 12:03:37 -0700 Subject: [Expat-bugs] [ expat-Bugs-624251 ] Problem parsing Latin-1 symbols Message-ID: Bugs item #624251, was opened at 2002-10-16 12:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=624251&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Problem parsing Latin-1 symbols Initial Comment: Expat 1.95-5 Getting an extra character from the parser when parsing extended ASCII characters (161 - 255 decimal). The XML_CharacterDataHandler function reports 2 characters for every 1 extended character encountered. Below is a small XML file demonstrating the problem. The character handler function reports two charaters (0xC2 and 0xA9) when the xml file contains only one (0xA9). © Platform: Windows 2000 exe statically linked to expat. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=624251&group_id=10127 From noreply@sourceforge.net Wed Oct 16 20:23:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Oct 2002 12:23:49 -0700 Subject: [Expat-bugs] [ expat-Bugs-624251 ] Problem parsing Latin-1 symbols Message-ID: Bugs item #624251, was opened at 2002-10-16 15:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=624251&group_id=10127 Category: None Group: None Status: Open >Resolution: Rejected Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Problem parsing Latin-1 symbols Initial Comment: Expat 1.95-5 Getting an extra character from the parser when parsing extended ASCII characters (161 - 255 decimal). The XML_CharacterDataHandler function reports 2 characters for every 1 extended character encountered. Below is a small XML file demonstrating the problem. The character handler function reports two charaters (0xC2 and 0xA9) when the xml file contains only one (0xA9). © Platform: Windows 2000 exe statically linked to expat. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-10-16 15:23 Message: Logged In: YES user_id=290026 Expat reports characters encoded as UTF-8 or UTF-16. It does not generate ISO-8859-1 output. What you are reporting looks lik UTF-8 encoding, which means the character 0xA9 will be encoded in two bytes. This does not appear to be a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=624251&group_id=10127 From noreply@sourceforge.net Thu Oct 17 16:35:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Oct 2002 08:35:59 -0700 Subject: [Expat-bugs] [ expat-Bugs-624724 ] Distinguishing between GE's and PE's Message-ID: Bugs item #624724, was opened at 2002-10-17 17:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=624724&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Ernst Jan Plugge (rmc) Assigned to: Nobody/Anonymous (nobody) Summary: Distinguishing between GE's and PE's Initial Comment: There is no documented way to distinguish between a general entity and a parameter entity in an ExternalEntityRefHandler. Right now, the undocumented way is to examine the value of the context parameter to the handler, but the docs clearly state that the context should be considered opaque. The feature request is to provide a proper, documented way to distinguish between the two. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=624724&group_id=10127 From noreply@sourceforge.net Thu Oct 17 17:30:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Oct 2002 09:30:26 -0700 Subject: [Expat-bugs] [ expat-Bugs-624724 ] Distinguishing between GE's and PE's Message-ID: Bugs item #624724, was opened at 2002-10-17 11:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=624724&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Ernst Jan Plugge (rmc) >Assigned to: Karl Waclawek (kwaclaw) Summary: Distinguishing between GE's and PE's Initial Comment: There is no documented way to distinguish between a general entity and a parameter entity in an ExternalEntityRefHandler. Right now, the undocumented way is to examine the value of the context parameter to the handler, but the docs clearly state that the context should be considered opaque. The feature request is to provide a proper, documented way to distinguish between the two. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-10-17 12:30 Message: Logged In: YES user_id=290026 You are right, it is not documented, but it is the right way to check the entity type. Yes, the docs indicate (not clearly, IMO) that context is an opaque pointer, but checking whether the pointer is NULL is still OK, since that is not an attempt to "look behind the curtain". We need to update reference.html to properly document this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=624724&group_id=10127 From noreply@sourceforge.net Fri Oct 18 12:45:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Oct 2002 04:45:12 -0700 Subject: [Expat-bugs] [ expat-Bugs-625156 ] iso-8859-1 support not working? Message-ID: Bugs item #625156, was opened at 2002-10-18 04:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=625156&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: iso-8859-1 support not working? Initial Comment: libversion: expat-1.95.5 os: FreeBSD 4.6-STABLE I've run into problems when using a xml-document with encoding defined to "iso-8859-1" as: The document gets processed ok, but some of the characters, special to this encoding, gets transformed to garbage in the output. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=625156&group_id=10127 From noreply@sourceforge.net Fri Oct 18 14:29:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Oct 2002 06:29:54 -0700 Subject: [Expat-bugs] [ expat-Bugs-625156 ] iso-8859-1 support not working? Message-ID: Bugs item #625156, was opened at 2002-10-18 04:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=625156&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: iso-8859-1 support not working? Initial Comment: libversion: expat-1.95.5 os: FreeBSD 4.6-STABLE I've run into problems when using a xml-document with encoding defined to "iso-8859-1" as: The document gets processed ok, but some of the characters, special to this encoding, gets transformed to garbage in the output. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-10-18 06:29 Message: Logged In: NO This is because Expat outputs UTF-8 encoded text. You need to convert the output to iso-8859-1 yourself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=625156&group_id=10127 From noreply@sourceforge.net Sun Oct 20 19:43:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 20 Oct 2002 11:43:53 -0700 Subject: [Expat-bugs] [ expat-Bugs-626001 ] ld: Mismatched ABI (not an ELF file) for Message-ID: Bugs item #626001, was opened at 2002-10-20 18:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=626001&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sanjay (sanjaywaza) Assigned to: Nobody/Anonymous (nobody) Summary: ld: Mismatched ABI (not an ELF file) for Initial Comment: I tried to install the expat1.95.4) on HP-UX 11.0 (64 Bit). Then I tried to build XML::Parser2.31.1 and I am getting the error (ld: Mismatched ABI (not an ELF file). I am getting the following error during make . cp Parser/Encodings/README blib/lib/XML/Parser/Encodings/README cp Parser/Encodings/x-sjis-cp932.enc blib/lib/XML/Parser/Encodings/x-sjis-cp932.enc cp Parser/Encodings/iso-8859-7.enc blib/lib/XML/Parser/Encodings/iso-8859-7.enc cp Parser/Encodings/big5.enc blib/lib/XML/Parser/Encodings/big5.enc cp Parser/Encodings/windows-1250.enc blib/lib/XML/Parser/Encodings/windows-1250.enc cp Parser/Encodings/iso-8859-8.enc blib/lib/XML/Parser/Encodings/iso-8859-8.enc cp Parser/Encodings/iso-8859-2.enc blib/lib/XML/Parser/Encodings/iso-8859-2.enc cp Parser/Encodings/x-euc-jp-jisx0221.enc blib/lib/XML/Parser/Encodings/x-euc-jp-jisx0221.enc cp Parser/Encodings/iso-8859-9.enc blib/lib/XML/Parser/Encodings/iso-8859-9.enc cp Parser/Encodings/x-sjis-unicode.enc blib/lib/XML/Parser/Encodings/x-sjis-unicode.enc cp Parser/Encodings/iso-8859-3.enc blib/lib/XML/Parser/Encodings/iso-8859-3.enc cp Parser/Encodings/x-sjis-jdk117.enc blib/lib/XML/Parser/Encodings/x-sjis-jdk117.enc cp Parser/Encodings/euc-kr.enc blib/lib/XML/Parser/Encodings/euc-kr.enc cp Parser/Encodings/iso-8859-4.enc blib/lib/XML/Parser/Encodings/iso-8859-4.enc cp Parser/Encodings/Japanese_Encodings.msg blib/lib/XML/Parser/Encodings/Japanese_Encodings.msg cp Parser/Encodings/x-sjis-jisx0221.enc blib/lib/XML/Parser/Encodings/x-sjis-jisx0221.enc cp Parser.pm blib/lib/XML/Parser.pm cp Parser/Encodings/iso-8859-5.enc blib/lib/XML/Parser/Encodings/iso-8859-5.enc cp Parser/Encodings/x-euc-jp-unicode.enc blib/lib/XML/Parser/Encodings/x-euc-jp-unicode.enc cp Parser/LWPExternEnt.pl blib/lib/XML/Parser/LWPExternEnt.pl cp Expat.pm ../blib/lib/XML/Parser/Expat.pm /bin/perl -I/opt/perl5.6.1/lib/5.6.1/PA-RISC2.0 - I/opt/perl5.6.1/lib/5.6.1 /opt/perl5.6.1/lib/5.6.1/ExtUtils/x s ubpp -noprotc cc -c +z -D_HPUX_SOURCE +DD64 -Ae - I/usr/local/include -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64 -O -DVERSION=\2.31\c Running Mkbootstrap for XML::Parser::Expat () chmod 644 Expat.bs rm -f ../blib/arch/auto/XML/Parser/Expat/Expat.sl LD_RUN_PATH="/usr/local/lib" /usr/bin/ld -b +vnocompatwarnings -L/usr/local/lib -L/lib/pa20_64 Expat.o -o ../blib/arch/au ld: Mismatched ABI (not an ELF file) for -lexpat Fatal error. *** Error exit code 1 Stop. *** Error exit code 1 Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=626001&group_id=10127 From noreply@sourceforge.net Sun Oct 20 19:44:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 20 Oct 2002 11:44:38 -0700 Subject: [Expat-bugs] [ expat-Bugs-626001 ] ld: Mismatched ABI (not an ELF file) for Message-ID: Bugs item #626001, was opened at 2002-10-20 18:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=626001&group_id=10127 Category: None Group: None Status: Open Resolution: None >Priority: 9 Submitted By: Sanjay (sanjaywaza) Assigned to: Nobody/Anonymous (nobody) Summary: ld: Mismatched ABI (not an ELF file) for Initial Comment: I tried to install the expat1.95.4) on HP-UX 11.0 (64 Bit). Then I tried to build XML::Parser2.31.1 and I am getting the error (ld: Mismatched ABI (not an ELF file). I am getting the following error during make . cp Parser/Encodings/README blib/lib/XML/Parser/Encodings/README cp Parser/Encodings/x-sjis-cp932.enc blib/lib/XML/Parser/Encodings/x-sjis-cp932.enc cp Parser/Encodings/iso-8859-7.enc blib/lib/XML/Parser/Encodings/iso-8859-7.enc cp Parser/Encodings/big5.enc blib/lib/XML/Parser/Encodings/big5.enc cp Parser/Encodings/windows-1250.enc blib/lib/XML/Parser/Encodings/windows-1250.enc cp Parser/Encodings/iso-8859-8.enc blib/lib/XML/Parser/Encodings/iso-8859-8.enc cp Parser/Encodings/iso-8859-2.enc blib/lib/XML/Parser/Encodings/iso-8859-2.enc cp Parser/Encodings/x-euc-jp-jisx0221.enc blib/lib/XML/Parser/Encodings/x-euc-jp-jisx0221.enc cp Parser/Encodings/iso-8859-9.enc blib/lib/XML/Parser/Encodings/iso-8859-9.enc cp Parser/Encodings/x-sjis-unicode.enc blib/lib/XML/Parser/Encodings/x-sjis-unicode.enc cp Parser/Encodings/iso-8859-3.enc blib/lib/XML/Parser/Encodings/iso-8859-3.enc cp Parser/Encodings/x-sjis-jdk117.enc blib/lib/XML/Parser/Encodings/x-sjis-jdk117.enc cp Parser/Encodings/euc-kr.enc blib/lib/XML/Parser/Encodings/euc-kr.enc cp Parser/Encodings/iso-8859-4.enc blib/lib/XML/Parser/Encodings/iso-8859-4.enc cp Parser/Encodings/Japanese_Encodings.msg blib/lib/XML/Parser/Encodings/Japanese_Encodings.msg cp Parser/Encodings/x-sjis-jisx0221.enc blib/lib/XML/Parser/Encodings/x-sjis-jisx0221.enc cp Parser.pm blib/lib/XML/Parser.pm cp Parser/Encodings/iso-8859-5.enc blib/lib/XML/Parser/Encodings/iso-8859-5.enc cp Parser/Encodings/x-euc-jp-unicode.enc blib/lib/XML/Parser/Encodings/x-euc-jp-unicode.enc cp Parser/LWPExternEnt.pl blib/lib/XML/Parser/LWPExternEnt.pl cp Expat.pm ../blib/lib/XML/Parser/Expat.pm /bin/perl -I/opt/perl5.6.1/lib/5.6.1/PA-RISC2.0 - I/opt/perl5.6.1/lib/5.6.1 /opt/perl5.6.1/lib/5.6.1/ExtUtils/x s ubpp -noprotc cc -c +z -D_HPUX_SOURCE +DD64 -Ae - I/usr/local/include -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64 -O -DVERSION=\2.31\c Running Mkbootstrap for XML::Parser::Expat () chmod 644 Expat.bs rm -f ../blib/arch/auto/XML/Parser/Expat/Expat.sl LD_RUN_PATH="/usr/local/lib" /usr/bin/ld -b +vnocompatwarnings -L/usr/local/lib -L/lib/pa20_64 Expat.o -o ../blib/arch/au ld: Mismatched ABI (not an ELF file) for -lexpat Fatal error. *** Error exit code 1 Stop. *** Error exit code 1 Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=626001&group_id=10127 From noreply@sourceforge.net Sun Oct 20 19:48:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 20 Oct 2002 11:48:12 -0700 Subject: [Expat-bugs] [ expat-Bugs-626001 ] ld: Mismatched ABI (not an ELF file) for Message-ID: Bugs item #626001, was opened at 2002-10-20 18:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=626001&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 9 Submitted By: Sanjay (sanjaywaza) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: ld: Mismatched ABI (not an ELF file) for Initial Comment: I tried to install the expat1.95.4) on HP-UX 11.0 (64 Bit). Then I tried to build XML::Parser2.31.1 and I am getting the error (ld: Mismatched ABI (not an ELF file). I am getting the following error during make . cp Parser/Encodings/README blib/lib/XML/Parser/Encodings/README cp Parser/Encodings/x-sjis-cp932.enc blib/lib/XML/Parser/Encodings/x-sjis-cp932.enc cp Parser/Encodings/iso-8859-7.enc blib/lib/XML/Parser/Encodings/iso-8859-7.enc cp Parser/Encodings/big5.enc blib/lib/XML/Parser/Encodings/big5.enc cp Parser/Encodings/windows-1250.enc blib/lib/XML/Parser/Encodings/windows-1250.enc cp Parser/Encodings/iso-8859-8.enc blib/lib/XML/Parser/Encodings/iso-8859-8.enc cp Parser/Encodings/iso-8859-2.enc blib/lib/XML/Parser/Encodings/iso-8859-2.enc cp Parser/Encodings/x-euc-jp-jisx0221.enc blib/lib/XML/Parser/Encodings/x-euc-jp-jisx0221.enc cp Parser/Encodings/iso-8859-9.enc blib/lib/XML/Parser/Encodings/iso-8859-9.enc cp Parser/Encodings/x-sjis-unicode.enc blib/lib/XML/Parser/Encodings/x-sjis-unicode.enc cp Parser/Encodings/iso-8859-3.enc blib/lib/XML/Parser/Encodings/iso-8859-3.enc cp Parser/Encodings/x-sjis-jdk117.enc blib/lib/XML/Parser/Encodings/x-sjis-jdk117.enc cp Parser/Encodings/euc-kr.enc blib/lib/XML/Parser/Encodings/euc-kr.enc cp Parser/Encodings/iso-8859-4.enc blib/lib/XML/Parser/Encodings/iso-8859-4.enc cp Parser/Encodings/Japanese_Encodings.msg blib/lib/XML/Parser/Encodings/Japanese_Encodings.msg cp Parser/Encodings/x-sjis-jisx0221.enc blib/lib/XML/Parser/Encodings/x-sjis-jisx0221.enc cp Parser.pm blib/lib/XML/Parser.pm cp Parser/Encodings/iso-8859-5.enc blib/lib/XML/Parser/Encodings/iso-8859-5.enc cp Parser/Encodings/x-euc-jp-unicode.enc blib/lib/XML/Parser/Encodings/x-euc-jp-unicode.enc cp Parser/LWPExternEnt.pl blib/lib/XML/Parser/LWPExternEnt.pl cp Expat.pm ../blib/lib/XML/Parser/Expat.pm /bin/perl -I/opt/perl5.6.1/lib/5.6.1/PA-RISC2.0 - I/opt/perl5.6.1/lib/5.6.1 /opt/perl5.6.1/lib/5.6.1/ExtUtils/x s ubpp -noprotc cc -c +z -D_HPUX_SOURCE +DD64 -Ae - I/usr/local/include -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64 -O -DVERSION=\2.31\c Running Mkbootstrap for XML::Parser::Expat () chmod 644 Expat.bs rm -f ../blib/arch/auto/XML/Parser/Expat/Expat.sl LD_RUN_PATH="/usr/local/lib" /usr/bin/ld -b +vnocompatwarnings -L/usr/local/lib -L/lib/pa20_64 Expat.o -o ../blib/arch/au ld: Mismatched ABI (not an ELF file) for -lexpat Fatal error. *** Error exit code 1 Stop. *** Error exit code 1 Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=626001&group_id=10127 From noreply@sourceforge.net Mon Oct 21 18:59:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Oct 2002 10:59:55 -0700 Subject: [Expat-bugs] [ expat-Bugs-615028 ] (expat-1.95.5) Solaris 2.6 make error Message-ID: Bugs item #615028, was opened at 2002-09-26 09:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615028&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: (expat-1.95.5) Solaris 2.6 make error Initial Comment: Hi, I am trying to install expat and get the following error when runnng "make" under the expat directory. /bin/ksh ./libtool --silent --mode=link cc -g -I./lib -I. -o xmlwf/xmlwf xmlw f/xmlwf.o xmlwf/xmlfile.o xmlwf/codepage.o xmlwf/unixfilemap.o libexpat.la cc: Can't exec /opt/SUNWspro/bin/../SC4.2/bin/ild *** Error code 100 make: Fatal error: Command failed for target `xmlwf/xmlwf' I have no idea where/what the "ild" command is. Any ideas? Thanks. Alan. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-10-21 10:59 Message: Logged In: NO I am trying to install expat on a Solaris 2.6 box too and I come up with the following: @everlast:/tmp/tkdnload/expat-1.95.5 > make /bin/ksh ./libtool --silent --mode=link gcc -g -O2 -Wall - Wmissing-prototypes -Wstrict-prototypes -fexceptions -I./lib -I. -no-undefined - version-info 4:0:4 -rpath /usr/local/lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo ./libtool[4119]: ar: not found make: *** [libexpat.la] Error 127 I have checked and ar is in /usr/cs/bin which is in my PATH. Any ideas where I getting off track? Thanks Ken ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615028&group_id=10127