From noreply@sourceforge.net Thu May 2 14:39:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu May 2 13:39:12 2002 Subject: [ expat-Patches-551599 ] Patch for bugs # 483514, 544679, 548690 Message-ID: Patches item #551599, was opened at 2002-05-02 16:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=551599&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for bugs # 483514, 544679, 548690 Initial Comment: This is an extensive patch, and needs not only testing, but also a review by my fellow developers! It addresses these issues: # 483514 (default handler reports too much from DTD): only the following data are reported now: - ignored DTD sections - unhandled external parameter entity references - top level whitespace This may not be what is needed, but more would have been a lot of work # 544679, 548690 (DTD handling of external entities): - the storeEntityValue function has been modified to call the external entity reference handler, since it did not handle external PE references at all - a new STRING_POOL has been added that gets passed from a parent to a child parser (member of DTD structure), so that entity values can be built across parsers - new functions entityValueInitProcessor and entityValueProcessor have been added - the old usage of dtd.complete was completely changed - I never understood how it worked, and it didn't work properly anyway; therefore there is a danger now that some logic will not work anymore - please review and check - the usage of hadExternalDoctype was modified too - there have been changes in xmlrole.c too - the chain of state handlers was extended from entity9 to entity10 - in analogy to how general entities - please review the diff file - as a result, this patch now processes all of James Clark's test cases in the /valid/not-sa and /valid/ext-sa directories properly * I have also made some fixes to the recently introduced XML_ParserReset function (incl. changing it's return type), and one fix that prevents a null pointer error The patch is based on these revisions: - expat.h rev. 1.17 - xmlparse.c rev. 1.31 - xmlrole.c rev. 1.5 - xmlrole.h rev. 1.3 I have included the full patch files, an annotated version of xmlparse.c - good to understand my changes, and the diff files. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=551599&group_id=10127 From noreply@sourceforge.net Thu May 2 14:44:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu May 2 13:44:05 2002 Subject: [ expat-Patches-548786 ] Fix attempt for bug # 548690 Message-ID: Patches item #548786, was opened at 2002-04-25 16:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=548786&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) Summary: Fix attempt for bug # 548690 Initial Comment: Under the following switch case: case XML_ROLE_PARAM_ENTITY_REF: the original code would simply do return XML_ERROR_UNDEFINED_ENTITY; if the entity's name was not declared before. I have replace this with: if (dtd.standalone) return XML_ERROR_UNDEFINED_ENTITY; if (defaultHandler) reportDefault(parser, enc, s, next); break; In addition, under the following case: case XML_ROLE_PARAM_ENTITY_NAME: the original code would only store the name of the parameter entity if dtd.complete was true. I have removed this condition. Obviously, this could potentially break some other code. Sofar it has been working for me. The attached file xmlparse.c is based on revision 1.30 and also includes patch # 548210. A diff file is attached as well. Karl ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-02 16:43 Message: Logged In: YES user_id=290026 This patch has been superceded by patch # 551599 Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=548786&group_id=10127 From noreply@sourceforge.net Thu May 2 14:45:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu May 2 13:45:02 2002 Subject: [ expat-Patches-548210 ] Enable reporting of external PE declarat Message-ID: Patches item #548210, was opened at 2002-04-24 13:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=548210&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) Summary: Enable reporting of external PE declarat Initial Comment: It seems that Expat does not report declarations of external parameter entities, even though it reports the associated parameter entity references. This patch should enable Expat to call the external entity ref handler when it encounters external PE declarations. I have attached full versions of the modified files xmlparse.c and xmlrole.c, as well as the corresponding diffs. The modifications have been made against xmlrole.c rev. 1.5 and xmlparse.c rev. 1.30. Karl ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-02 16:44 Message: Logged In: YES user_id=290026 This patch has been superceded by patch # 551599 Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=548210&group_id=10127 From noreply@sourceforge.net Fri May 3 03:48:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 3 02:48:02 2002 Subject: [ expat-Bugs-551772 ] Cannot download. Message-ID: Bugs item #551772, was opened at 2002-05-03 09:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=551772&group_id=10127 Category: XML::Parser (Perl module) Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Daniel (doormouse) Assigned to: Clark Cooper (coopercc) Summary: Cannot download. Initial Comment: I am unable to download the latest version of Expat. Do you know why this is. I have tried from a number of different machines as well as trying to get the windows and unix versions of the file. Any help would be great thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=551772&group_id=10127 From noreply@sourceforge.net Fri May 3 07:54:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 3 06:54:19 2002 Subject: [ expat-Bugs-551852 ] BOM causes error with small buffers Message-ID: Bugs item #551852, was opened at 2002-05-03 09:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=551852&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) Summary: BOM causes error with small buffers Initial Comment: This happens when an external entity that has a BOM *and* a text declaration, is parsed, and the buffer size is very small. For instance, take these two files: --- test.xml --- ]> &e; --- end of file --- and this external entity, saved in UTF-16 with BOM: --- test.ent --- some text --- end of file --- When parsing this with a buffer size of 1 (using XML_GetBuffer), you get the error "xml processing instruction not at start of entity". This error won't happen if you remove the BOM. I have traced this to the function externalEntityInitProcessor2. I found a fix for this: original code: ... switch (tok) { case XML_TOK_BOM: start = next; break; ... fixed code: ... switch (tok) { case XML_TOK_BOM: if (next == end && endPtr) { *endPtr = next; return XML_ERROR_NONE; } start = next; break; ... Explanation for fix: If we are at the end of the buffer, the original code would pass control to the next stage, i.e. externalEntityInitProcessor3, which would detect XML_TOK_NONE and pass control directly to doContent without processing any xml text declaration. However, in doContent the xml text declaration will then be parsed and this will cause the error XML_ERROR_MISPLACED_XML_PI, sinc doContent does not allow text declarations. The fix simply prevents control to be passed to doContent before externalEntityInitProcessor2 can process the xml text declaration. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=551852&group_id=10127 From noreply@sourceforge.net Fri May 3 08:10:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 3 07:10:03 2002 Subject: [ expat-Patches-551599 ] Patch for bugs # 483514, 544679, 548690 Message-ID: Patches item #551599, was opened at 2002-05-02 16:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=551599&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for bugs # 483514, 544679, 548690 Initial Comment: This is an extensive patch, and needs not only testing, but also a review by my fellow developers! It addresses these issues: # 483514 (default handler reports too much from DTD): only the following data are reported now: - ignored DTD sections - unhandled external parameter entity references - top level whitespace This may not be what is needed, but more would have been a lot of work # 544679, 548690 (DTD handling of external entities): - the storeEntityValue function has been modified to call the external entity reference handler, since it did not handle external PE references at all - a new STRING_POOL has been added that gets passed from a parent to a child parser (member of DTD structure), so that entity values can be built across parsers - new functions entityValueInitProcessor and entityValueProcessor have been added - the old usage of dtd.complete was completely changed - I never understood how it worked, and it didn't work properly anyway; therefore there is a danger now that some logic will not work anymore - please review and check - the usage of hadExternalDoctype was modified too - there have been changes in xmlrole.c too - the chain of state handlers was extended from entity9 to entity10 - in analogy to how general entities - please review the diff file - as a result, this patch now processes all of James Clark's test cases in the /valid/not-sa and /valid/ext-sa directories properly * I have also made some fixes to the recently introduced XML_ParserReset function (incl. changing it's return type), and one fix that prevents a null pointer error The patch is based on these revisions: - expat.h rev. 1.17 - xmlparse.c rev. 1.31 - xmlrole.c rev. 1.5 - xmlrole.h rev. 1.3 I have included the full patch files, an annotated version of xmlparse.c - good to understand my changes, and the diff files. Karl ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 10:09 Message: Logged In: YES user_id=290026 Forgot to add: the fix for bug # 551852 is included too. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=551599&group_id=10127 From noreply@sourceforge.net Fri May 3 10:38:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 3 09:38:10 2002 Subject: [ expat-Bugs-549014 ] May cause memory error in dtdCopy. Message-ID: Bugs item #549014, was opened at 2002-04-26 06:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=549014&group_id=10127 Category: None Group: None Status: Open Resolution: None >Priority: 6 Submitted By: Jun Huang (huangjun_se) Assigned to: Nobody/Anonymous (nobody) Summary: May cause memory error in dtdCopy. Initial Comment: This problem may not a bug.If not ,I want somebody to tell me how to use the XML_ExternalEntityParserCreate and XML_ParserFree.Thank you. In function "dtdCopy",there is a comment "/* Don't want deep copying for scaffolding */".I don't understand it's meaning.But the following code set oldDtd->scaffIndex to newDtd->scaffIndex.I found it may cause a memory error. If a parentParser has allocated the memory pointed by scaffIndex,I use XML_ExternalEntityParserCreate to create a subParser.So the subParser will get the scaffIndex of the parentParser.And then I call XML_ParserFree to free the subParser,it will free the memory pointed by scaffIndex of the subParser.But the scaffIndex of the parentParser still pointed the memory freed.Then if the following code visit the memory pointed by the scaffIndex ,it will cause a memory error. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 12:37 Message: Logged In: YES user_id=290026 It seems your observation is correct. This can cause memory errors. I am just curious why I haven't seen them yet. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=549014&group_id=10127 From noreply@sourceforge.net Fri May 3 12:58:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 3 11:58:02 2002 Subject: [ expat-Bugs-549014 ] May cause memory error in dtdCopy. Message-ID: Bugs item #549014, was opened at 2002-04-26 06:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=549014&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 6 Submitted By: Jun Huang (huangjun_se) Assigned to: Nobody/Anonymous (nobody) Summary: May cause memory error in dtdCopy. Initial Comment: This problem may not a bug.If not ,I want somebody to tell me how to use the XML_ExternalEntityParserCreate and XML_ParserFree.Thank you. In function "dtdCopy",there is a comment "/* Don't want deep copying for scaffolding */".I don't understand it's meaning.But the following code set oldDtd->scaffIndex to newDtd->scaffIndex.I found it may cause a memory error. If a parentParser has allocated the memory pointed by scaffIndex,I use XML_ExternalEntityParserCreate to create a subParser.So the subParser will get the scaffIndex of the parentParser.And then I call XML_ParserFree to free the subParser,it will free the memory pointed by scaffIndex of the subParser.But the scaffIndex of the parentParser still pointed the memory freed.Then if the following code visit the memory pointed by the scaffIndex ,it will cause a memory error. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 14:57 Message: Logged In: YES user_id=290026 Looking closer at the code: dtdCopy will only be called for a child parser, if the entity is a general entity, not a parameter entity. dtd.scaffold will only be used when the parser is processing the external or internal subset, which always happens *before* any general external entity is processed. So, by planning (or coincidence ) dtd.scaffold will not get used after being freed as described. However, we still have a dangling pointer, which should be set to null. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 12:37 Message: Logged In: YES user_id=290026 It seems your observation is correct. This can cause memory errors. I am just curious why I haven't seen them yet. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=549014&group_id=10127 From noreply@sourceforge.net Fri May 3 12:58:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 3 11:58:03 2002 Subject: [ expat-Bugs-549014 ] May cause memory error in dtdCopy. Message-ID: Bugs item #549014, was opened at 2002-04-26 06:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=549014&group_id=10127 Category: None Group: None Status: Open Resolution: None >Priority: 5 Submitted By: Jun Huang (huangjun_se) Assigned to: Nobody/Anonymous (nobody) Summary: May cause memory error in dtdCopy. Initial Comment: This problem may not a bug.If not ,I want somebody to tell me how to use the XML_ExternalEntityParserCreate and XML_ParserFree.Thank you. In function "dtdCopy",there is a comment "/* Don't want deep copying for scaffolding */".I don't understand it's meaning.But the following code set oldDtd->scaffIndex to newDtd->scaffIndex.I found it may cause a memory error. If a parentParser has allocated the memory pointed by scaffIndex,I use XML_ExternalEntityParserCreate to create a subParser.So the subParser will get the scaffIndex of the parentParser.And then I call XML_ParserFree to free the subParser,it will free the memory pointed by scaffIndex of the subParser.But the scaffIndex of the parentParser still pointed the memory freed.Then if the following code visit the memory pointed by the scaffIndex ,it will cause a memory error. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 14:57 Message: Logged In: YES user_id=290026 Looking closer at the code: dtdCopy will only be called for a child parser, if the entity is a general entity, not a parameter entity. dtd.scaffold will only be used when the parser is processing the external or internal subset, which always happens *before* any general external entity is processed. So, by planning (or coincidence ) dtd.scaffold will not get used after being freed as described. However, we still have a dangling pointer, which should be set to null. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 12:37 Message: Logged In: YES user_id=290026 It seems your observation is correct. This can cause memory errors. I am just curious why I haven't seen them yet. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=549014&group_id=10127 From noreply@sourceforge.net Fri May 3 20:50:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 3 19:50:02 2002 Subject: [ expat-Bugs-549014 ] May cause memory error in dtdCopy. Message-ID: Bugs item #549014, was opened at 2002-04-26 10:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=549014&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jun Huang (huangjun_se) Assigned to: Nobody/Anonymous (nobody) Summary: May cause memory error in dtdCopy. Initial Comment: This problem may not a bug.If not ,I want somebody to tell me how to use the XML_ExternalEntityParserCreate and XML_ParserFree.Thank you. In function "dtdCopy",there is a comment "/* Don't want deep copying for scaffolding */".I don't understand it's meaning.But the following code set oldDtd->scaffIndex to newDtd->scaffIndex.I found it may cause a memory error. If a parentParser has allocated the memory pointed by scaffIndex,I use XML_ExternalEntityParserCreate to create a subParser.So the subParser will get the scaffIndex of the parentParser.And then I call XML_ParserFree to free the subParser,it will free the memory pointed by scaffIndex of the subParser.But the scaffIndex of the parentParser still pointed the memory freed.Then if the following code visit the memory pointed by the scaffIndex ,it will cause a memory error. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-04 02:49 Message: Logged In: YES user_id=13222 Exactly. I came to the same conclusion as Jun Huang, while debugging some rare seg faults of an expat based application, I work with. You have to work with external entities (must use XML_ExternalEntityParserCreate()) to see the error. I second this bug report, saying loud that this man is right, not only in that there is a very hard problem (seg fault) with using external enitities with expat but also with his analysis of the reason for this problem. OK, given that, the obvious question is, how to fix that? As far as I see, there isn't a simple way to determine, if a parser is, well, the 'master', or the 'main' parser or if it's a parser, created to parse an external entity. It's OK, to collect the DTD Information of the internal subset and the parts in the (could be) multiple parameter entities in one memory structure, ie I think, it's OK to not deep dopying the scaffolding. But the memory has to be freed in the outmost parser. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 18:57 Message: Logged In: YES user_id=290026 Looking closer at the code: dtdCopy will only be called for a child parser, if the entity is a general entity, not a parameter entity. dtd.scaffold will only be used when the parser is processing the external or internal subset, which always happens *before* any general external entity is processed. So, by planning (or coincidence ) dtd.scaffold will not get used after being freed as described. However, we still have a dangling pointer, which should be set to null. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 16:37 Message: Logged In: YES user_id=290026 It seems your observation is correct. This can cause memory errors. I am just curious why I haven't seen them yet. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=549014&group_id=10127 From noreply@sourceforge.net Fri May 3 20:55:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 3 19:55:03 2002 Subject: [ expat-Bugs-549014 ] May cause memory error in dtdCopy. Message-ID: Bugs item #549014, was opened at 2002-04-26 06:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=549014&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jun Huang (huangjun_se) Assigned to: Nobody/Anonymous (nobody) Summary: May cause memory error in dtdCopy. Initial Comment: This problem may not a bug.If not ,I want somebody to tell me how to use the XML_ExternalEntityParserCreate and XML_ParserFree.Thank you. In function "dtdCopy",there is a comment "/* Don't want deep copying for scaffolding */".I don't understand it's meaning.But the following code set oldDtd->scaffIndex to newDtd->scaffIndex.I found it may cause a memory error. If a parentParser has allocated the memory pointed by scaffIndex,I use XML_ExternalEntityParserCreate to create a subParser.So the subParser will get the scaffIndex of the parentParser.And then I call XML_ParserFree to free the subParser,it will free the memory pointed by scaffIndex of the subParser.But the scaffIndex of the parentParser still pointed the memory freed.Then if the following code visit the memory pointed by the scaffIndex ,it will cause a memory error. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-03 22:54 Message: Logged In: YES user_id=3066 Since the "master" and descendent parsers are created using different functions, we should just add an internal field that indicates whether the parser is the master or not. I think we just need to know whether the parser is the master, but don't need a pointer to the master. Karl, does this sound sufficient? I think we can do this with no public API changes. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-03 22:49 Message: Logged In: YES user_id=13222 Exactly. I came to the same conclusion as Jun Huang, while debugging some rare seg faults of an expat based application, I work with. You have to work with external entities (must use XML_ExternalEntityParserCreate()) to see the error. I second this bug report, saying loud that this man is right, not only in that there is a very hard problem (seg fault) with using external enitities with expat but also with his analysis of the reason for this problem. OK, given that, the obvious question is, how to fix that? As far as I see, there isn't a simple way to determine, if a parser is, well, the 'master', or the 'main' parser or if it's a parser, created to parse an external entity. It's OK, to collect the DTD Information of the internal subset and the parts in the (could be) multiple parameter entities in one memory structure, ie I think, it's OK to not deep dopying the scaffolding. But the memory has to be freed in the outmost parser. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 14:57 Message: Logged In: YES user_id=290026 Looking closer at the code: dtdCopy will only be called for a child parser, if the entity is a general entity, not a parameter entity. dtd.scaffold will only be used when the parser is processing the external or internal subset, which always happens *before* any general external entity is processed. So, by planning (or coincidence ) dtd.scaffold will not get used after being freed as described. However, we still have a dangling pointer, which should be set to null. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 12:37 Message: Logged In: YES user_id=290026 It seems your observation is correct. This can cause memory errors. I am just curious why I haven't seen them yet. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=549014&group_id=10127 From noreply@sourceforge.net Fri May 3 21:07:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 3 20:07:02 2002 Subject: [ expat-Bugs-549014 ] May cause memory error in dtdCopy. Message-ID: Bugs item #549014, was opened at 2002-04-26 10:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=549014&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jun Huang (huangjun_se) Assigned to: Nobody/Anonymous (nobody) Summary: May cause memory error in dtdCopy. Initial Comment: This problem may not a bug.If not ,I want somebody to tell me how to use the XML_ExternalEntityParserCreate and XML_ParserFree.Thank you. In function "dtdCopy",there is a comment "/* Don't want deep copying for scaffolding */".I don't understand it's meaning.But the following code set oldDtd->scaffIndex to newDtd->scaffIndex.I found it may cause a memory error. If a parentParser has allocated the memory pointed by scaffIndex,I use XML_ExternalEntityParserCreate to create a subParser.So the subParser will get the scaffIndex of the parentParser.And then I call XML_ParserFree to free the subParser,it will free the memory pointed by scaffIndex of the subParser.But the scaffIndex of the parentParser still pointed the memory freed.Then if the following code visit the memory pointed by the scaffIndex ,it will cause a memory error. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-04 03:06 Message: Logged In: YES user_id=13222 An internal flag for this would be great; the simplest solution, very low cost in speed and memory. I would love, to have a this way fixed expat. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-04 02:54 Message: Logged In: YES user_id=3066 Since the "master" and descendent parsers are created using different functions, we should just add an internal field that indicates whether the parser is the master or not. I think we just need to know whether the parser is the master, but don't need a pointer to the master. Karl, does this sound sufficient? I think we can do this with no public API changes. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-04 02:49 Message: Logged In: YES user_id=13222 Exactly. I came to the same conclusion as Jun Huang, while debugging some rare seg faults of an expat based application, I work with. You have to work with external entities (must use XML_ExternalEntityParserCreate()) to see the error. I second this bug report, saying loud that this man is right, not only in that there is a very hard problem (seg fault) with using external enitities with expat but also with his analysis of the reason for this problem. OK, given that, the obvious question is, how to fix that? As far as I see, there isn't a simple way to determine, if a parser is, well, the 'master', or the 'main' parser or if it's a parser, created to parse an external entity. It's OK, to collect the DTD Information of the internal subset and the parts in the (could be) multiple parameter entities in one memory structure, ie I think, it's OK to not deep dopying the scaffolding. But the memory has to be freed in the outmost parser. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 18:57 Message: Logged In: YES user_id=290026 Looking closer at the code: dtdCopy will only be called for a child parser, if the entity is a general entity, not a parameter entity. dtd.scaffold will only be used when the parser is processing the external or internal subset, which always happens *before* any general external entity is processed. So, by planning (or coincidence ) dtd.scaffold will not get used after being freed as described. However, we still have a dangling pointer, which should be set to null. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 16:37 Message: Logged In: YES user_id=290026 It seems your observation is correct. This can cause memory errors. I am just curious why I haven't seen them yet. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=549014&group_id=10127 From noreply@sourceforge.net Fri May 3 21:16:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 3 20:16:03 2002 Subject: [ expat-Bugs-548690 ] Incorrect "undefined entity" error Message-ID: Bugs item #548690, was opened at 2002-04-25 16:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=548690&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect "undefined entity" error Initial Comment: I came across the following behaviour, given this document: %worldupdtd; %visiondtd; ]> some text Expat will report an "undefined entity" fatal error for the reference %visiondtd;. However, the XML spec says this (look at the tag: Well-formedness constraint: Entity Declared In a document without any DTD, a document with only an internal DTD subset which contains no parameter entity references, or a document with "standalone='yes'", for an entity reference that does not occur within the external subset or a parameter entity, the Name given in the entity reference must match that in an entity declaration that does not occur within the external subset or a parameter entity, except that well-formed documents need not declare any of the following entities: amp, lt, gt, apos, quot. The declaration of a general entity must precede any reference to it which appears in a default value in an attribute- list declaration. Note that if entities are declared in the external subset or in external parameter entities, a non-validating processor is not obligated to read and process their declarations; for such documents, the rule that an entity must be declared is a well-formedness constraint only if standalone='yes'. Validity constraint: Entity Declared In a document with an external subset or external parameter entities with "standalone='no'", the Name given in the entity reference must match that in an entity declaration. For interoperability, valid documents should declare the entities amp, lt, gt, apos, quot, in the form specified in 4.6 Predefined Entities. The declaration of a parameter entity must precede any reference to it. Similarly, the declaration of a general entity must precede any attribute-list declaration containing a default value with a direct or indirect reference to that general entity. Since Expat is not validating, the emphasized section should apply. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-04 03:15 Message: Logged In: YES user_id=13222 I'm a bit confused about the subject. While Karl Waclawe's observation is right by it's own, I don't want to loose the ability of exapt, to claim about not to be able to resolve an external parameter entity. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-04-27 13:24 Message: Logged In: YES user_id=290026 This bug and bug # 544679 seem to be related to a set of difficulties Expat has in handling DTDs and PEs. The best way to detect those problems and test them is to subject Expat to James Clark's test cases at ftp://ftp.jclark.com/pub/xml/xmltest.zip, specifically the test cases in the subdirectory /valid/not-sa/ . Expat does not handle most of them correctly, it seems. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-04-26 03:46 Message: Logged In: YES user_id=290026 To supply more detail: - the external entityref handler is set - it is called for the entity that isn't declared, as well as the external subset - it always returns 1 - and SetParamEntityParsing was called with XML_PARAM_ENTITY_PARSING_ALWAYS ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-26 01:45 Message: Logged In: YES user_id=3066 I need more information to construct the test case. In particular, is a callback set with XML_SetExternalEntityRefHandler(), how many times is it called (is it called for the entity that isn't declared?), and what does it return? Was XML_SetParamEntityParsing() called, and with which value for the 'code' argument? Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=548690&group_id=10127 From noreply@sourceforge.net Fri May 3 21:46:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 3 20:46:02 2002 Subject: [ expat-Bugs-549014 ] May cause memory error in dtdCopy. Message-ID: Bugs item #549014, was opened at 2002-04-26 06:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=549014&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jun Huang (huangjun_se) Assigned to: Nobody/Anonymous (nobody) Summary: May cause memory error in dtdCopy. Initial Comment: This problem may not a bug.If not ,I want somebody to tell me how to use the XML_ExternalEntityParserCreate and XML_ParserFree.Thank you. In function "dtdCopy",there is a comment "/* Don't want deep copying for scaffolding */".I don't understand it's meaning.But the following code set oldDtd->scaffIndex to newDtd->scaffIndex.I found it may cause a memory error. If a parentParser has allocated the memory pointed by scaffIndex,I use XML_ExternalEntityParserCreate to create a subParser.So the subParser will get the scaffIndex of the parentParser.And then I call XML_ParserFree to free the subParser,it will free the memory pointed by scaffIndex of the subParser.But the scaffIndex of the parentParser still pointed the memory freed.Then if the following code visit the memory pointed by the scaffIndex ,it will cause a memory error. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 23:45 Message: Logged In: YES user_id=290026 There is already a flag: look at the parentParser macro. However, as I said, this dangling pointer does not cause an actual problem. I found this out by looking at the code as well as creating a specific test situation, where an external parser would be created, then freed, and then element declaration would be parsed which would require use of the dtd.scaffold member. However, as it appeared to me, all of this happens during parsing of the DTD, but the dtdCopy function will not have been be called since it is only called when the childparser has context !=0, which means it parses a general entity. And that never happens before the DTD parsing is completed. The dangling pointers could simply be set to null like this in XML_ParserFree: ... #ifdef XML_DTD if (parentParser) { dtdSwap(&dtd, &((Parser *)parentParser)->m_dtd); } #endif /* XML_DTD */ dtdDestroy(&dtd, parser); // now, add this code: ((Parser *)parentParser)->m_dtd.scaffold = 0; ((Parser *)parentParser)->m_dtd.scaffIndex = 0; Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-03 23:06 Message: Logged In: YES user_id=13222 An internal flag for this would be great; the simplest solution, very low cost in speed and memory. I would love, to have a this way fixed expat. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-03 22:54 Message: Logged In: YES user_id=3066 Since the "master" and descendent parsers are created using different functions, we should just add an internal field that indicates whether the parser is the master or not. I think we just need to know whether the parser is the master, but don't need a pointer to the master. Karl, does this sound sufficient? I think we can do this with no public API changes. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-03 22:49 Message: Logged In: YES user_id=13222 Exactly. I came to the same conclusion as Jun Huang, while debugging some rare seg faults of an expat based application, I work with. You have to work with external entities (must use XML_ExternalEntityParserCreate()) to see the error. I second this bug report, saying loud that this man is right, not only in that there is a very hard problem (seg fault) with using external enitities with expat but also with his analysis of the reason for this problem. OK, given that, the obvious question is, how to fix that? As far as I see, there isn't a simple way to determine, if a parser is, well, the 'master', or the 'main' parser or if it's a parser, created to parse an external entity. It's OK, to collect the DTD Information of the internal subset and the parts in the (could be) multiple parameter entities in one memory structure, ie I think, it's OK to not deep dopying the scaffolding. But the memory has to be freed in the outmost parser. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 14:57 Message: Logged In: YES user_id=290026 Looking closer at the code: dtdCopy will only be called for a child parser, if the entity is a general entity, not a parameter entity. dtd.scaffold will only be used when the parser is processing the external or internal subset, which always happens *before* any general external entity is processed. So, by planning (or coincidence ) dtd.scaffold will not get used after being freed as described. However, we still have a dangling pointer, which should be set to null. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 12:37 Message: Logged In: YES user_id=290026 It seems your observation is correct. This can cause memory errors. I am just curious why I haven't seen them yet. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=549014&group_id=10127 From noreply@sourceforge.net Fri May 3 22:13:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 3 21:13:03 2002 Subject: [ expat-Bugs-548690 ] Incorrect "undefined entity" error Message-ID: Bugs item #548690, was opened at 2002-04-25 12:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=548690&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) >Summary: Incorrect "undefined entity" error Initial Comment: I came across the following behaviour, given this document: %worldupdtd; %visiondtd; ]> some text Expat will report an "undefined entity" fatal error for the reference %visiondtd;. However, the XML spec says this (look at the tag: Well-formedness constraint: Entity Declared In a document without any DTD, a document with only an internal DTD subset which contains no parameter entity references, or a document with "standalone='yes'", for an entity reference that does not occur within the external subset or a parameter entity, the Name given in the entity reference must match that in an entity declaration that does not occur within the external subset or a parameter entity, except that well-formed documents need not declare any of the following entities: amp, lt, gt, apos, quot. The declaration of a general entity must precede any reference to it which appears in a default value in an attribute- list declaration. Note that if entities are declared in the external subset or in external parameter entities, a non-validating processor is not obligated to read and process their declarations; for such documents, the rule that an entity must be declared is a well-formedness constraint only if standalone='yes'. Validity constraint: Entity Declared In a document with an external subset or external parameter entities with "standalone='no'", the Name given in the entity reference must match that in an entity declaration. For interoperability, valid documents should declare the entities amp, lt, gt, apos, quot, in the form specified in 4.6 Predefined Entities. The declaration of a parameter entity must precede any reference to it. Similarly, the declaration of a general entity must precede any attribute-list declaration containing a default value with a direct or indirect reference to that general entity. Since Expat is not validating, the emphasized section should apply. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 00:12 Message: Logged In: YES user_id=290026 I think the priority should be that Expat conforms to the spec. So, if there is no well-formedness violation, then Expat should not report one. However, your concern is valid, but should be dealt with differently. We were already discussing the introduction of a skippedEntity callback, like the one in SAX. Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-03 23:15 Message: Logged In: YES user_id=13222 I'm a bit confused about the subject. While Karl Waclawe's observation is right by it's own, I don't want to loose the ability of exapt, to claim about not to be able to resolve an external parameter entity. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-04-27 09:24 Message: Logged In: YES user_id=290026 This bug and bug # 544679 seem to be related to a set of difficulties Expat has in handling DTDs and PEs. The best way to detect those problems and test them is to subject Expat to James Clark's test cases at ftp://ftp.jclark.com/pub/xml/xmltest.zip, specifically the test cases in the subdirectory /valid/not-sa/ . Expat does not handle most of them correctly, it seems. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-04-25 23:46 Message: Logged In: YES user_id=290026 To supply more detail: - the external entityref handler is set - it is called for the entity that isn't declared, as well as the external subset - it always returns 1 - and SetParamEntityParsing was called with XML_PARAM_ENTITY_PARSING_ALWAYS ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-25 21:45 Message: Logged In: YES user_id=3066 I need more information to construct the test case. In particular, is a callback set with XML_SetExternalEntityRefHandler(), how many times is it called (is it called for the entity that isn't declared?), and what does it return? Was XML_SetParamEntityParsing() called, and with which value for the 'code' argument? Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=548690&group_id=10127 From noreply@sourceforge.net Fri May 3 23:26:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 3 22:26:03 2002 Subject: [ expat-Bugs-549014 ] May cause memory error in dtdCopy. Message-ID: Bugs item #549014, was opened at 2002-04-26 06:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=549014&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jun Huang (huangjun_se) Assigned to: Nobody/Anonymous (nobody) Summary: May cause memory error in dtdCopy. Initial Comment: This problem may not a bug.If not ,I want somebody to tell me how to use the XML_ExternalEntityParserCreate and XML_ParserFree.Thank you. In function "dtdCopy",there is a comment "/* Don't want deep copying for scaffolding */".I don't understand it's meaning.But the following code set oldDtd->scaffIndex to newDtd->scaffIndex.I found it may cause a memory error. If a parentParser has allocated the memory pointed by scaffIndex,I use XML_ExternalEntityParserCreate to create a subParser.So the subParser will get the scaffIndex of the parentParser.And then I call XML_ParserFree to free the subParser,it will free the memory pointed by scaffIndex of the subParser.But the scaffIndex of the parentParser still pointed the memory freed.Then if the following code visit the memory pointed by the scaffIndex ,it will cause a memory error. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 01:25 Message: Logged In: YES user_id=290026 Just tested my solution for the dangling pointers: Won't work, since it should only be applied when a dtdCopy was performed (external GE), not when a dtdSwap was done (external PE). However, we don't have a flag that tells us which type of external entity was parsed. Another approach could be to clear the old pointers right when dtdCopy is performed (and also reset scaffCount and scaffSize). That way, even if dtd.scaffold was used again, it would be allocated fram scratch, since the code will detect the null pointers. A lot depends on how dtdCopy and dtd.scaffold are used. Currently dtdCopy is only called for creating an external GE parser, and dtd.scaffold is only used for building the content model of an element declaration, which means it is not shared across parsers. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 23:45 Message: Logged In: YES user_id=290026 There is already a flag: look at the parentParser macro. However, as I said, this dangling pointer does not cause an actual problem. I found this out by looking at the code as well as creating a specific test situation, where an external parser would be created, then freed, and then element declaration would be parsed which would require use of the dtd.scaffold member. However, as it appeared to me, all of this happens during parsing of the DTD, but the dtdCopy function will not have been be called since it is only called when the childparser has context !=0, which means it parses a general entity. And that never happens before the DTD parsing is completed. The dangling pointers could simply be set to null like this in XML_ParserFree: ... #ifdef XML_DTD if (parentParser) { dtdSwap(&dtd, &((Parser *)parentParser)->m_dtd); } #endif /* XML_DTD */ dtdDestroy(&dtd, parser); // now, add this code: ((Parser *)parentParser)->m_dtd.scaffold = 0; ((Parser *)parentParser)->m_dtd.scaffIndex = 0; Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-03 23:06 Message: Logged In: YES user_id=13222 An internal flag for this would be great; the simplest solution, very low cost in speed and memory. I would love, to have a this way fixed expat. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-03 22:54 Message: Logged In: YES user_id=3066 Since the "master" and descendent parsers are created using different functions, we should just add an internal field that indicates whether the parser is the master or not. I think we just need to know whether the parser is the master, but don't need a pointer to the master. Karl, does this sound sufficient? I think we can do this with no public API changes. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-03 22:49 Message: Logged In: YES user_id=13222 Exactly. I came to the same conclusion as Jun Huang, while debugging some rare seg faults of an expat based application, I work with. You have to work with external entities (must use XML_ExternalEntityParserCreate()) to see the error. I second this bug report, saying loud that this man is right, not only in that there is a very hard problem (seg fault) with using external enitities with expat but also with his analysis of the reason for this problem. OK, given that, the obvious question is, how to fix that? As far as I see, there isn't a simple way to determine, if a parser is, well, the 'master', or the 'main' parser or if it's a parser, created to parse an external entity. It's OK, to collect the DTD Information of the internal subset and the parts in the (could be) multiple parameter entities in one memory structure, ie I think, it's OK to not deep dopying the scaffolding. But the memory has to be freed in the outmost parser. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 14:57 Message: Logged In: YES user_id=290026 Looking closer at the code: dtdCopy will only be called for a child parser, if the entity is a general entity, not a parameter entity. dtd.scaffold will only be used when the parser is processing the external or internal subset, which always happens *before* any general external entity is processed. So, by planning (or coincidence ) dtd.scaffold will not get used after being freed as described. However, we still have a dangling pointer, which should be set to null. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 12:37 Message: Logged In: YES user_id=290026 It seems your observation is correct. This can cause memory errors. I am just curious why I haven't seen them yet. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=549014&group_id=10127 From noreply@sourceforge.net Sat May 4 08:06:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat May 4 07:06:03 2002 Subject: [ expat-Bugs-549014 ] May cause memory error in dtdCopy. Message-ID: Bugs item #549014, was opened at 2002-04-26 06:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=549014&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jun Huang (huangjun_se) Assigned to: Nobody/Anonymous (nobody) Summary: May cause memory error in dtdCopy. Initial Comment: This problem may not a bug.If not ,I want somebody to tell me how to use the XML_ExternalEntityParserCreate and XML_ParserFree.Thank you. In function "dtdCopy",there is a comment "/* Don't want deep copying for scaffolding */".I don't understand it's meaning.But the following code set oldDtd->scaffIndex to newDtd->scaffIndex.I found it may cause a memory error. If a parentParser has allocated the memory pointed by scaffIndex,I use XML_ExternalEntityParserCreate to create a subParser.So the subParser will get the scaffIndex of the parentParser.And then I call XML_ParserFree to free the subParser,it will free the memory pointed by scaffIndex of the subParser.But the scaffIndex of the parentParser still pointed the memory freed.Then if the following code visit the memory pointed by the scaffIndex ,it will cause a memory error. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 10:05 Message: Logged In: YES user_id=290026 Here is some more analysis (I am fairly new to Expat, so I may repeat what you already know): dtd.scaffold is used as a "working memory" pool for building content models passed to an element declaration handler. It is passed between parsers only so that the working memory does not have to be allocated again (speed). The passing from parent to child is done using dtdCopy or dtdSwap. From all of that I would say that it should only be freed at the very end, when the root parser gets destroyed. So, to achieve that, simply change the code in dtdDestroy from: ... if (p->scaffIndex) FREE(p->scaffIndex); if (p->scaffold) FREE(p->scaffold); ... to: ... if (!parentParser) { if (p->scaffIndex) FREE(p->scaffIndex); if (p->scaffold) FREE(p->scaffold); } ... Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 01:25 Message: Logged In: YES user_id=290026 Just tested my solution for the dangling pointers: Won't work, since it should only be applied when a dtdCopy was performed (external GE), not when a dtdSwap was done (external PE). However, we don't have a flag that tells us which type of external entity was parsed. Another approach could be to clear the old pointers right when dtdCopy is performed (and also reset scaffCount and scaffSize). That way, even if dtd.scaffold was used again, it would be allocated fram scratch, since the code will detect the null pointers. A lot depends on how dtdCopy and dtd.scaffold are used. Currently dtdCopy is only called for creating an external GE parser, and dtd.scaffold is only used for building the content model of an element declaration, which means it is not shared across parsers. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 23:45 Message: Logged In: YES user_id=290026 There is already a flag: look at the parentParser macro. However, as I said, this dangling pointer does not cause an actual problem. I found this out by looking at the code as well as creating a specific test situation, where an external parser would be created, then freed, and then element declaration would be parsed which would require use of the dtd.scaffold member. However, as it appeared to me, all of this happens during parsing of the DTD, but the dtdCopy function will not have been be called since it is only called when the childparser has context !=0, which means it parses a general entity. And that never happens before the DTD parsing is completed. The dangling pointers could simply be set to null like this in XML_ParserFree: ... #ifdef XML_DTD if (parentParser) { dtdSwap(&dtd, &((Parser *)parentParser)->m_dtd); } #endif /* XML_DTD */ dtdDestroy(&dtd, parser); // now, add this code: ((Parser *)parentParser)->m_dtd.scaffold = 0; ((Parser *)parentParser)->m_dtd.scaffIndex = 0; Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-03 23:06 Message: Logged In: YES user_id=13222 An internal flag for this would be great; the simplest solution, very low cost in speed and memory. I would love, to have a this way fixed expat. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-03 22:54 Message: Logged In: YES user_id=3066 Since the "master" and descendent parsers are created using different functions, we should just add an internal field that indicates whether the parser is the master or not. I think we just need to know whether the parser is the master, but don't need a pointer to the master. Karl, does this sound sufficient? I think we can do this with no public API changes. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-03 22:49 Message: Logged In: YES user_id=13222 Exactly. I came to the same conclusion as Jun Huang, while debugging some rare seg faults of an expat based application, I work with. You have to work with external entities (must use XML_ExternalEntityParserCreate()) to see the error. I second this bug report, saying loud that this man is right, not only in that there is a very hard problem (seg fault) with using external enitities with expat but also with his analysis of the reason for this problem. OK, given that, the obvious question is, how to fix that? As far as I see, there isn't a simple way to determine, if a parser is, well, the 'master', or the 'main' parser or if it's a parser, created to parse an external entity. It's OK, to collect the DTD Information of the internal subset and the parts in the (could be) multiple parameter entities in one memory structure, ie I think, it's OK to not deep dopying the scaffolding. But the memory has to be freed in the outmost parser. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 14:57 Message: Logged In: YES user_id=290026 Looking closer at the code: dtdCopy will only be called for a child parser, if the entity is a general entity, not a parameter entity. dtd.scaffold will only be used when the parser is processing the external or internal subset, which always happens *before* any general external entity is processed. So, by planning (or coincidence ) dtd.scaffold will not get used after being freed as described. However, we still have a dangling pointer, which should be set to null. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 12:37 Message: Logged In: YES user_id=290026 It seems your observation is correct. This can cause memory errors. I am just curious why I haven't seen them yet. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=549014&group_id=10127 From noreply@sourceforge.net Sat May 4 10:24:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat May 4 09:24:01 2002 Subject: [ expat-Bugs-549014 ] May cause memory error in dtdCopy. Message-ID: Bugs item #549014, was opened at 2002-04-26 10:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=549014&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jun Huang (huangjun_se) Assigned to: Nobody/Anonymous (nobody) Summary: May cause memory error in dtdCopy. Initial Comment: This problem may not a bug.If not ,I want somebody to tell me how to use the XML_ExternalEntityParserCreate and XML_ParserFree.Thank you. In function "dtdCopy",there is a comment "/* Don't want deep copying for scaffolding */".I don't understand it's meaning.But the following code set oldDtd->scaffIndex to newDtd->scaffIndex.I found it may cause a memory error. If a parentParser has allocated the memory pointed by scaffIndex,I use XML_ExternalEntityParserCreate to create a subParser.So the subParser will get the scaffIndex of the parentParser.And then I call XML_ParserFree to free the subParser,it will free the memory pointed by scaffIndex of the subParser.But the scaffIndex of the parentParser still pointed the memory freed.Then if the following code visit the memory pointed by the scaffIndex ,it will cause a memory error. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-04 16:23 Message: Logged In: YES user_id=13222 I'm sure, I don't understand all the internals in every detail. But: I would say, Karl Waclawek's code if (!parentParser) { if (p->scaffIndex) FREE(p->scaffIndex); if (p->scaffold) FREE(p->scaffold); } goes into the right direction, but this alone doesn't fix the problem (at least doesn't fix the problem completely). I've an example, which triggers the seg fault (it's a bit complex, a hole application, to much, to attach it, but if somebody is interested enough, I can point you to the code and supply test data.) Even with Karls modification, this example still seg faults. But, as said, where at the right trace. If I remove the freeing of p->scaffIndex and p->scaffold from dtdDestroy(), everthing works as expected (but with a memory leak, of course). But how could this be? Well, as far as I see, parentParser is _not_ set in every case in XML_ExternalEntityParserCreate(). Take a look at the end of this function: if (context) { #endif /* XML_DTD */ if (!dtdCopy(&dtd, oldDtd, parser) || !setContext(parser, context)) { XML_ParserFree(parser); return 0; } processor = externalEntityInitProcessor; #ifdef XML_DTD } else { dtdSwap(&dtd, oldDtd); parentParser = oldParser; XmlPrologStateInitExternalEntity(&prologState); dtd.complete = 1; hadExternalDoctype = 1; } parentParser is only set (to a value != 0), if context is false. If I use parentParser = oldParser; if (context) { #endif /* XML_DTD */ if (!dtdCopy(&dtd, oldDtd, parser) || !setContext(parser, context)) { XML_ParserFree(parser); return 0; } processor = externalEntityInitProcessor; #ifdef XML_DTD } else { dtdSwap(&dtd, oldDtd); XmlPrologStateInitExternalEntity(&prologState); dtd.complete = 1; hadExternalDoctype = 1; } (moved the parentParser setting outside the if, so that it's always set). This, together with Karl's code fixes the problem for me. But I'm really not sure, if this could (should) be done. I don't recall all details of my debugging sessions (it was some month ago), but if I recall right, there are reasons, for that the parentParser is not always set. It's a way to distinguish, if the external entity parser parses an external parameter entity or a general external entity (for parameter entities context is 0). This distinction seems to be used at some places and it looks like, we need it (please correct me, if I'm wrong). So, what to do? Back to Fred's propose of a new interal flag, that's only set for the master parser? Looks like this would be the simplest solution, with the lowest risk of unexpected side effects. Does somebody knows, if this distinction is necessary somewhere, for the parser, to work correct? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 14:05 Message: Logged In: YES user_id=290026 Here is some more analysis (I am fairly new to Expat, so I may repeat what you already know): dtd.scaffold is used as a "working memory" pool for building content models passed to an element declaration handler. It is passed between parsers only so that the working memory does not have to be allocated again (speed). The passing from parent to child is done using dtdCopy or dtdSwap. From all of that I would say that it should only be freed at the very end, when the root parser gets destroyed. So, to achieve that, simply change the code in dtdDestroy from: ... if (p->scaffIndex) FREE(p->scaffIndex); if (p->scaffold) FREE(p->scaffold); ... to: ... if (!parentParser) { if (p->scaffIndex) FREE(p->scaffIndex); if (p->scaffold) FREE(p->scaffold); } ... Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 05:25 Message: Logged In: YES user_id=290026 Just tested my solution for the dangling pointers: Won't work, since it should only be applied when a dtdCopy was performed (external GE), not when a dtdSwap was done (external PE). However, we don't have a flag that tells us which type of external entity was parsed. Another approach could be to clear the old pointers right when dtdCopy is performed (and also reset scaffCount and scaffSize). That way, even if dtd.scaffold was used again, it would be allocated fram scratch, since the code will detect the null pointers. A lot depends on how dtdCopy and dtd.scaffold are used. Currently dtdCopy is only called for creating an external GE parser, and dtd.scaffold is only used for building the content model of an element declaration, which means it is not shared across parsers. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 03:45 Message: Logged In: YES user_id=290026 There is already a flag: look at the parentParser macro. However, as I said, this dangling pointer does not cause an actual problem. I found this out by looking at the code as well as creating a specific test situation, where an external parser would be created, then freed, and then element declaration would be parsed which would require use of the dtd.scaffold member. However, as it appeared to me, all of this happens during parsing of the DTD, but the dtdCopy function will not have been be called since it is only called when the childparser has context !=0, which means it parses a general entity. And that never happens before the DTD parsing is completed. The dangling pointers could simply be set to null like this in XML_ParserFree: ... #ifdef XML_DTD if (parentParser) { dtdSwap(&dtd, &((Parser *)parentParser)->m_dtd); } #endif /* XML_DTD */ dtdDestroy(&dtd, parser); // now, add this code: ((Parser *)parentParser)->m_dtd.scaffold = 0; ((Parser *)parentParser)->m_dtd.scaffIndex = 0; Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-04 03:06 Message: Logged In: YES user_id=13222 An internal flag for this would be great; the simplest solution, very low cost in speed and memory. I would love, to have a this way fixed expat. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-04 02:54 Message: Logged In: YES user_id=3066 Since the "master" and descendent parsers are created using different functions, we should just add an internal field that indicates whether the parser is the master or not. I think we just need to know whether the parser is the master, but don't need a pointer to the master. Karl, does this sound sufficient? I think we can do this with no public API changes. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-04 02:49 Message: Logged In: YES user_id=13222 Exactly. I came to the same conclusion as Jun Huang, while debugging some rare seg faults of an expat based application, I work with. You have to work with external entities (must use XML_ExternalEntityParserCreate()) to see the error. I second this bug report, saying loud that this man is right, not only in that there is a very hard problem (seg fault) with using external enitities with expat but also with his analysis of the reason for this problem. OK, given that, the obvious question is, how to fix that? As far as I see, there isn't a simple way to determine, if a parser is, well, the 'master', or the 'main' parser or if it's a parser, created to parse an external entity. It's OK, to collect the DTD Information of the internal subset and the parts in the (could be) multiple parameter entities in one memory structure, ie I think, it's OK to not deep dopying the scaffolding. But the memory has to be freed in the outmost parser. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 18:57 Message: Logged In: YES user_id=290026 Looking closer at the code: dtdCopy will only be called for a child parser, if the entity is a general entity, not a parameter entity. dtd.scaffold will only be used when the parser is processing the external or internal subset, which always happens *before* any general external entity is processed. So, by planning (or coincidence ) dtd.scaffold will not get used after being freed as described. However, we still have a dangling pointer, which should be set to null. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 16:37 Message: Logged In: YES user_id=290026 It seems your observation is correct. This can cause memory errors. I am just curious why I haven't seen them yet. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=549014&group_id=10127 From noreply@sourceforge.net Sat May 4 10:59:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat May 4 09:59:05 2002 Subject: [ expat-Bugs-548690 ] Incorrect "undefined entity" error Message-ID: Bugs item #548690, was opened at 2002-04-25 16:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=548690&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect "undefined entity" error Initial Comment: I came across the following behaviour, given this document: %worldupdtd; %visiondtd; ]> some text Expat will report an "undefined entity" fatal error for the reference %visiondtd;. However, the XML spec says this (look at the tag: Well-formedness constraint: Entity Declared In a document without any DTD, a document with only an internal DTD subset which contains no parameter entity references, or a document with "standalone='yes'", for an entity reference that does not occur within the external subset or a parameter entity, the Name given in the entity reference must match that in an entity declaration that does not occur within the external subset or a parameter entity, except that well-formed documents need not declare any of the following entities: amp, lt, gt, apos, quot. The declaration of a general entity must precede any reference to it which appears in a default value in an attribute- list declaration. Note that if entities are declared in the external subset or in external parameter entities, a non-validating processor is not obligated to read and process their declarations; for such documents, the rule that an entity must be declared is a well-formedness constraint only if standalone='yes'. Validity constraint: Entity Declared In a document with an external subset or external parameter entities with "standalone='no'", the Name given in the entity reference must match that in an entity declaration. For interoperability, valid documents should declare the entities amp, lt, gt, apos, quot, in the form specified in 4.6 Predefined Entities. The declaration of a parameter entity must precede any reference to it. Similarly, the declaration of a general entity must precede any attribute-list declaration containing a default value with a direct or indirect reference to that general entity. Since Expat is not validating, the emphasized section should apply. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-04 16:58 Message: Logged In: YES user_id=13222 _Please_ don't change expats behavior in this area without giving the programmer a chance to get noticed about such not resolvable entities. A skippedEntity callback seems to be a way. The reason for this is, that it is possible to do DTD validation on top of the current expat. If expat silently skip not resolvable entities, this is would be over. (Well,almost complete DTD validation. I mentioned a few remainig problems in http://sourceforge.net/mailarchive/message.php?msg_id=839092 with a bit more information to the nested parameter entities problem also discoverd by Karl in http://sourceforge.net/mailarchive/message.php?msg_id=839078) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 04:12 Message: Logged In: YES user_id=290026 I think the priority should be that Expat conforms to the spec. So, if there is no well-formedness violation, then Expat should not report one. However, your concern is valid, but should be dealt with differently. We were already discussing the introduction of a skippedEntity callback, like the one in SAX. Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-04 03:15 Message: Logged In: YES user_id=13222 I'm a bit confused about the subject. While Karl Waclawe's observation is right by it's own, I don't want to loose the ability of exapt, to claim about not to be able to resolve an external parameter entity. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-04-27 13:24 Message: Logged In: YES user_id=290026 This bug and bug # 544679 seem to be related to a set of difficulties Expat has in handling DTDs and PEs. The best way to detect those problems and test them is to subject Expat to James Clark's test cases at ftp://ftp.jclark.com/pub/xml/xmltest.zip, specifically the test cases in the subdirectory /valid/not-sa/ . Expat does not handle most of them correctly, it seems. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-04-26 03:46 Message: Logged In: YES user_id=290026 To supply more detail: - the external entityref handler is set - it is called for the entity that isn't declared, as well as the external subset - it always returns 1 - and SetParamEntityParsing was called with XML_PARAM_ENTITY_PARSING_ALWAYS ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-26 01:45 Message: Logged In: YES user_id=3066 I need more information to construct the test case. In particular, is a callback set with XML_SetExternalEntityRefHandler(), how many times is it called (is it called for the entity that isn't declared?), and what does it return? Was XML_SetParamEntityParsing() called, and with which value for the 'code' argument? Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=548690&group_id=10127 From noreply@sourceforge.net Sat May 4 11:14:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat May 4 10:14:03 2002 Subject: [ expat-Patches-551599 ] Patch for bugs # 483514, 544679, 548690 Message-ID: Patches item #551599, was opened at 2002-05-02 16:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=551599&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for bugs # 483514, 544679, 548690 Initial Comment: This is an extensive patch, and needs not only testing, but also a review by my fellow developers! It addresses these issues: # 483514 (default handler reports too much from DTD): only the following data are reported now: - ignored DTD sections - unhandled external parameter entity references - top level whitespace This may not be what is needed, but more would have been a lot of work # 544679, 548690 (DTD handling of external entities): - the storeEntityValue function has been modified to call the external entity reference handler, since it did not handle external PE references at all - a new STRING_POOL has been added that gets passed from a parent to a child parser (member of DTD structure), so that entity values can be built across parsers - new functions entityValueInitProcessor and entityValueProcessor have been added - the old usage of dtd.complete was completely changed - I never understood how it worked, and it didn't work properly anyway; therefore there is a danger now that some logic will not work anymore - please review and check - the usage of hadExternalDoctype was modified too - there have been changes in xmlrole.c too - the chain of state handlers was extended from entity9 to entity10 - in analogy to how general entities - please review the diff file - as a result, this patch now processes all of James Clark's test cases in the /valid/not-sa and /valid/ext-sa directories properly * I have also made some fixes to the recently introduced XML_ParserReset function (incl. changing it's return type), and one fix that prevents a null pointer error The patch is based on these revisions: - expat.h rev. 1.17 - xmlparse.c rev. 1.31 - xmlrole.c rev. 1.5 - xmlrole.h rev. 1.3 I have included the full patch files, an annotated version of xmlparse.c - good to understand my changes, and the diff files. Karl ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 13:13 Message: Logged In: YES user_id=290026 I improved the patch to cover one more problem: I found that bug # 551852 (BOM problem with small buffers), that was reported for general external entities, also applied to external parameter entities. This problem only applied to this patch, since the current release of Expat simply ignores external PEs (which causes bug # 548690). Included is also a fix for bug # 549014 (dtdCopy problem). The attached file are xmlparse_1.c, xmlparse_1.c.annotated and xmlparse_1.diff (against rev. 1.31). Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 10:09 Message: Logged In: YES user_id=290026 Forgot to add: the fix for bug # 551852 is included too. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=551599&group_id=10127 From noreply@sourceforge.net Sat May 4 11:42:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat May 4 10:42:02 2002 Subject: [ expat-Bugs-552297 ] Request for skippedEntity handler Message-ID: Bugs item #552297, was opened at 2002-05-04 13:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=552297&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) Summary: Request for skippedEntity handler Initial Comment: It would be very useful if Expat reported skipped entities, like in the SAX2 specification. I have identified the following situations for that: B) External Entities are reported as skipped: - if no external entity ref handler is set - if the entity ref handler returns a special value (e.g. we can define 2 as meaning: "skip this one") B) Internal Entities are reported as skipped: - SetDefaultHandler was called (which turns off expansion of internal general entities) C) Any entity reference is reported as skipped - if no declaration is found & that is not an error (otherwise return a well-formedness error) Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=552297&group_id=10127 From noreply@sourceforge.net Sat May 4 11:44:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat May 4 10:44:01 2002 Subject: [ expat-Bugs-548690 ] Incorrect "undefined entity" error Message-ID: Bugs item #548690, was opened at 2002-04-25 12:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=548690&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) >Summary: Incorrect "undefined entity" error Initial Comment: I came across the following behaviour, given this document: %worldupdtd; %visiondtd; ]> some text Expat will report an "undefined entity" fatal error for the reference %visiondtd;. However, the XML spec says this (look at the tag: Well-formedness constraint: Entity Declared In a document without any DTD, a document with only an internal DTD subset which contains no parameter entity references, or a document with "standalone='yes'", for an entity reference that does not occur within the external subset or a parameter entity, the Name given in the entity reference must match that in an entity declaration that does not occur within the external subset or a parameter entity, except that well-formed documents need not declare any of the following entities: amp, lt, gt, apos, quot. The declaration of a general entity must precede any reference to it which appears in a default value in an attribute- list declaration. Note that if entities are declared in the external subset or in external parameter entities, a non-validating processor is not obligated to read and process their declarations; for such documents, the rule that an entity must be declared is a well-formedness constraint only if standalone='yes'. Validity constraint: Entity Declared In a document with an external subset or external parameter entities with "standalone='no'", the Name given in the entity reference must match that in an entity declaration. For interoperability, valid documents should declare the entities amp, lt, gt, apos, quot, in the form specified in 4.6 Predefined Entities. The declaration of a parameter entity must precede any reference to it. Similarly, the declaration of a general entity must precede any attribute-list declaration containing a default value with a direct or indirect reference to that general entity. Since Expat is not validating, the emphasized section should apply. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 13:43 Message: Logged In: YES user_id=290026 OK, I have added a bug report as feature request for a skippedEntity handler (# 552297). Please review and add your comments. Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-04 12:58 Message: Logged In: YES user_id=13222 _Please_ don't change expats behavior in this area without giving the programmer a chance to get noticed about such not resolvable entities. A skippedEntity callback seems to be a way. The reason for this is, that it is possible to do DTD validation on top of the current expat. If expat silently skip not resolvable entities, this is would be over. (Well,almost complete DTD validation. I mentioned a few remainig problems in http://sourceforge.net/mailarchive/message.php?msg_id=839092 with a bit more information to the nested parameter entities problem also discoverd by Karl in http://sourceforge.net/mailarchive/message.php?msg_id=839078) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 00:12 Message: Logged In: YES user_id=290026 I think the priority should be that Expat conforms to the spec. So, if there is no well-formedness violation, then Expat should not report one. However, your concern is valid, but should be dealt with differently. We were already discussing the introduction of a skippedEntity callback, like the one in SAX. Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-03 23:15 Message: Logged In: YES user_id=13222 I'm a bit confused about the subject. While Karl Waclawe's observation is right by it's own, I don't want to loose the ability of exapt, to claim about not to be able to resolve an external parameter entity. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-04-27 09:24 Message: Logged In: YES user_id=290026 This bug and bug # 544679 seem to be related to a set of difficulties Expat has in handling DTDs and PEs. The best way to detect those problems and test them is to subject Expat to James Clark's test cases at ftp://ftp.jclark.com/pub/xml/xmltest.zip, specifically the test cases in the subdirectory /valid/not-sa/ . Expat does not handle most of them correctly, it seems. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-04-25 23:46 Message: Logged In: YES user_id=290026 To supply more detail: - the external entityref handler is set - it is called for the entity that isn't declared, as well as the external subset - it always returns 1 - and SetParamEntityParsing was called with XML_PARAM_ENTITY_PARSING_ALWAYS ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-25 21:45 Message: Logged In: YES user_id=3066 I need more information to construct the test case. In particular, is a callback set with XML_SetExternalEntityRefHandler(), how many times is it called (is it called for the entity that isn't declared?), and what does it return? Was XML_SetParamEntityParsing() called, and with which value for the 'code' argument? Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=548690&group_id=10127 From noreply@sourceforge.net Sat May 4 12:45:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat May 4 11:45:03 2002 Subject: [ expat-Bugs-549014 ] May cause memory error in dtdCopy. Message-ID: Bugs item #549014, was opened at 2002-04-26 06:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=549014&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jun Huang (huangjun_se) Assigned to: Nobody/Anonymous (nobody) Summary: May cause memory error in dtdCopy. Initial Comment: This problem may not a bug.If not ,I want somebody to tell me how to use the XML_ExternalEntityParserCreate and XML_ParserFree.Thank you. In function "dtdCopy",there is a comment "/* Don't want deep copying for scaffolding */".I don't understand it's meaning.But the following code set oldDtd->scaffIndex to newDtd->scaffIndex.I found it may cause a memory error. If a parentParser has allocated the memory pointed by scaffIndex,I use XML_ExternalEntityParserCreate to create a subParser.So the subParser will get the scaffIndex of the parentParser.And then I call XML_ParserFree to free the subParser,it will free the memory pointed by scaffIndex of the subParser.But the scaffIndex of the parentParser still pointed the memory freed.Then if the following code visit the memory pointed by the scaffIndex ,it will cause a memory error. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 14:44 Message: Logged In: YES user_id=290026 You are right - damn! I have to revisit my recent patch for PE handling! Anyway, if parentParser does not fit the bill, then prologState.documentEntity might. Could you please check that too. Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-04 12:23 Message: Logged In: YES user_id=13222 I'm sure, I don't understand all the internals in every detail. But: I would say, Karl Waclawek's code if (!parentParser) { if (p->scaffIndex) FREE(p->scaffIndex); if (p->scaffold) FREE(p->scaffold); } goes into the right direction, but this alone doesn't fix the problem (at least doesn't fix the problem completely). I've an example, which triggers the seg fault (it's a bit complex, a hole application, to much, to attach it, but if somebody is interested enough, I can point you to the code and supply test data.) Even with Karls modification, this example still seg faults. But, as said, where at the right trace. If I remove the freeing of p->scaffIndex and p->scaffold from dtdDestroy(), everthing works as expected (but with a memory leak, of course). But how could this be? Well, as far as I see, parentParser is _not_ set in every case in XML_ExternalEntityParserCreate(). Take a look at the end of this function: if (context) { #endif /* XML_DTD */ if (!dtdCopy(&dtd, oldDtd, parser) || !setContext(parser, context)) { XML_ParserFree(parser); return 0; } processor = externalEntityInitProcessor; #ifdef XML_DTD } else { dtdSwap(&dtd, oldDtd); parentParser = oldParser; XmlPrologStateInitExternalEntity(&prologState); dtd.complete = 1; hadExternalDoctype = 1; } parentParser is only set (to a value != 0), if context is false. If I use parentParser = oldParser; if (context) { #endif /* XML_DTD */ if (!dtdCopy(&dtd, oldDtd, parser) || !setContext(parser, context)) { XML_ParserFree(parser); return 0; } processor = externalEntityInitProcessor; #ifdef XML_DTD } else { dtdSwap(&dtd, oldDtd); XmlPrologStateInitExternalEntity(&prologState); dtd.complete = 1; hadExternalDoctype = 1; } (moved the parentParser setting outside the if, so that it's always set). This, together with Karl's code fixes the problem for me. But I'm really not sure, if this could (should) be done. I don't recall all details of my debugging sessions (it was some month ago), but if I recall right, there are reasons, for that the parentParser is not always set. It's a way to distinguish, if the external entity parser parses an external parameter entity or a general external entity (for parameter entities context is 0). This distinction seems to be used at some places and it looks like, we need it (please correct me, if I'm wrong). So, what to do? Back to Fred's propose of a new interal flag, that's only set for the master parser? Looks like this would be the simplest solution, with the lowest risk of unexpected side effects. Does somebody knows, if this distinction is necessary somewhere, for the parser, to work correct? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 10:05 Message: Logged In: YES user_id=290026 Here is some more analysis (I am fairly new to Expat, so I may repeat what you already know): dtd.scaffold is used as a "working memory" pool for building content models passed to an element declaration handler. It is passed between parsers only so that the working memory does not have to be allocated again (speed). The passing from parent to child is done using dtdCopy or dtdSwap. From all of that I would say that it should only be freed at the very end, when the root parser gets destroyed. So, to achieve that, simply change the code in dtdDestroy from: ... if (p->scaffIndex) FREE(p->scaffIndex); if (p->scaffold) FREE(p->scaffold); ... to: ... if (!parentParser) { if (p->scaffIndex) FREE(p->scaffIndex); if (p->scaffold) FREE(p->scaffold); } ... Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 01:25 Message: Logged In: YES user_id=290026 Just tested my solution for the dangling pointers: Won't work, since it should only be applied when a dtdCopy was performed (external GE), not when a dtdSwap was done (external PE). However, we don't have a flag that tells us which type of external entity was parsed. Another approach could be to clear the old pointers right when dtdCopy is performed (and also reset scaffCount and scaffSize). That way, even if dtd.scaffold was used again, it would be allocated fram scratch, since the code will detect the null pointers. A lot depends on how dtdCopy and dtd.scaffold are used. Currently dtdCopy is only called for creating an external GE parser, and dtd.scaffold is only used for building the content model of an element declaration, which means it is not shared across parsers. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 23:45 Message: Logged In: YES user_id=290026 There is already a flag: look at the parentParser macro. However, as I said, this dangling pointer does not cause an actual problem. I found this out by looking at the code as well as creating a specific test situation, where an external parser would be created, then freed, and then element declaration would be parsed which would require use of the dtd.scaffold member. However, as it appeared to me, all of this happens during parsing of the DTD, but the dtdCopy function will not have been be called since it is only called when the childparser has context !=0, which means it parses a general entity. And that never happens before the DTD parsing is completed. The dangling pointers could simply be set to null like this in XML_ParserFree: ... #ifdef XML_DTD if (parentParser) { dtdSwap(&dtd, &((Parser *)parentParser)->m_dtd); } #endif /* XML_DTD */ dtdDestroy(&dtd, parser); // now, add this code: ((Parser *)parentParser)->m_dtd.scaffold = 0; ((Parser *)parentParser)->m_dtd.scaffIndex = 0; Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-03 23:06 Message: Logged In: YES user_id=13222 An internal flag for this would be great; the simplest solution, very low cost in speed and memory. I would love, to have a this way fixed expat. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-03 22:54 Message: Logged In: YES user_id=3066 Since the "master" and descendent parsers are created using different functions, we should just add an internal field that indicates whether the parser is the master or not. I think we just need to know whether the parser is the master, but don't need a pointer to the master. Karl, does this sound sufficient? I think we can do this with no public API changes. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-03 22:49 Message: Logged In: YES user_id=13222 Exactly. I came to the same conclusion as Jun Huang, while debugging some rare seg faults of an expat based application, I work with. You have to work with external entities (must use XML_ExternalEntityParserCreate()) to see the error. I second this bug report, saying loud that this man is right, not only in that there is a very hard problem (seg fault) with using external enitities with expat but also with his analysis of the reason for this problem. OK, given that, the obvious question is, how to fix that? As far as I see, there isn't a simple way to determine, if a parser is, well, the 'master', or the 'main' parser or if it's a parser, created to parse an external entity. It's OK, to collect the DTD Information of the internal subset and the parts in the (could be) multiple parameter entities in one memory structure, ie I think, it's OK to not deep dopying the scaffolding. But the memory has to be freed in the outmost parser. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 14:57 Message: Logged In: YES user_id=290026 Looking closer at the code: dtdCopy will only be called for a child parser, if the entity is a general entity, not a parameter entity. dtd.scaffold will only be used when the parser is processing the external or internal subset, which always happens *before* any general external entity is processed. So, by planning (or coincidence ) dtd.scaffold will not get used after being freed as described. However, we still have a dangling pointer, which should be set to null. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 12:37 Message: Logged In: YES user_id=290026 It seems your observation is correct. This can cause memory errors. I am just curious why I haven't seen them yet. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=549014&group_id=10127 From noreply@sourceforge.net Sat May 4 14:45:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat May 4 13:45:01 2002 Subject: [ expat-Bugs-549014 ] May cause memory error in dtdCopy. Message-ID: Bugs item #549014, was opened at 2002-04-26 06:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=549014&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jun Huang (huangjun_se) Assigned to: Nobody/Anonymous (nobody) Summary: May cause memory error in dtdCopy. Initial Comment: This problem may not a bug.If not ,I want somebody to tell me how to use the XML_ExternalEntityParserCreate and XML_ParserFree.Thank you. In function "dtdCopy",there is a comment "/* Don't want deep copying for scaffolding */".I don't understand it's meaning.But the following code set oldDtd->scaffIndex to newDtd->scaffIndex.I found it may cause a memory error. If a parentParser has allocated the memory pointed by scaffIndex,I use XML_ExternalEntityParserCreate to create a subParser.So the subParser will get the scaffIndex of the parentParser.And then I call XML_ParserFree to free the subParser,it will free the memory pointed by scaffIndex of the subParser.But the scaffIndex of the parentParser still pointed the memory freed.Then if the following code visit the memory pointed by the scaffIndex ,it will cause a memory error. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 16:44 Message: Logged In: YES user_id=290026 No, documentEntity does not fit the bill either, so it seems we need a new member. After having a closer look: parentParser is not set for external general entities probably because none of the related code uses it. As far as I can tell, parentParser is used exclusively by DTD processing code, except for the XML_ParserFree function. I have put together a patch (based on my patch # 551599) that does the following: - adds a new member m_isParamEntity and the associated macro - sets parentParser to oldParser for both, external GEs and PEs, in XML_ExternalEntityParserCreate - initializes isParamEntity to 0, but sets it to 1 where parentParser used to be set to oldParser - replaces "if (parentParser)" with "if (isParamEntity)" in XML_ParserFree - keeps the previously suggested code in dtdDestroy: if (!parentParser) { if (p->scaffIndex) FREE(p->scaffIndex); if (p->scaffold) FREE(p->scaffold); } which should guarantee that dtd.scaffold is freed for the root parser only, since parentParser will always be set for child parsers - all other checks of parentParentParser in the DTD handling code should probably be replaced with checks for isParamEntity, however, in DTD handling code, whenever parentParser is set, isParamEntity = 1, and whenever parentParser is null, isParamEntity = 0, so the two are equivalent. Only outside of DTD handling code can they be different If anybody is interested, I can e-mail the patch. If it works - for those that can test it - then I will probably add it as another improvement to patch # 551599. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 14:44 Message: Logged In: YES user_id=290026 You are right - damn! I have to revisit my recent patch for PE handling! Anyway, if parentParser does not fit the bill, then prologState.documentEntity might. Could you please check that too. Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-04 12:23 Message: Logged In: YES user_id=13222 I'm sure, I don't understand all the internals in every detail. But: I would say, Karl Waclawek's code if (!parentParser) { if (p->scaffIndex) FREE(p->scaffIndex); if (p->scaffold) FREE(p->scaffold); } goes into the right direction, but this alone doesn't fix the problem (at least doesn't fix the problem completely). I've an example, which triggers the seg fault (it's a bit complex, a hole application, to much, to attach it, but if somebody is interested enough, I can point you to the code and supply test data.) Even with Karls modification, this example still seg faults. But, as said, where at the right trace. If I remove the freeing of p->scaffIndex and p->scaffold from dtdDestroy(), everthing works as expected (but with a memory leak, of course). But how could this be? Well, as far as I see, parentParser is _not_ set in every case in XML_ExternalEntityParserCreate(). Take a look at the end of this function: if (context) { #endif /* XML_DTD */ if (!dtdCopy(&dtd, oldDtd, parser) || !setContext(parser, context)) { XML_ParserFree(parser); return 0; } processor = externalEntityInitProcessor; #ifdef XML_DTD } else { dtdSwap(&dtd, oldDtd); parentParser = oldParser; XmlPrologStateInitExternalEntity(&prologState); dtd.complete = 1; hadExternalDoctype = 1; } parentParser is only set (to a value != 0), if context is false. If I use parentParser = oldParser; if (context) { #endif /* XML_DTD */ if (!dtdCopy(&dtd, oldDtd, parser) || !setContext(parser, context)) { XML_ParserFree(parser); return 0; } processor = externalEntityInitProcessor; #ifdef XML_DTD } else { dtdSwap(&dtd, oldDtd); XmlPrologStateInitExternalEntity(&prologState); dtd.complete = 1; hadExternalDoctype = 1; } (moved the parentParser setting outside the if, so that it's always set). This, together with Karl's code fixes the problem for me. But I'm really not sure, if this could (should) be done. I don't recall all details of my debugging sessions (it was some month ago), but if I recall right, there are reasons, for that the parentParser is not always set. It's a way to distinguish, if the external entity parser parses an external parameter entity or a general external entity (for parameter entities context is 0). This distinction seems to be used at some places and it looks like, we need it (please correct me, if I'm wrong). So, what to do? Back to Fred's propose of a new interal flag, that's only set for the master parser? Looks like this would be the simplest solution, with the lowest risk of unexpected side effects. Does somebody knows, if this distinction is necessary somewhere, for the parser, to work correct? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 10:05 Message: Logged In: YES user_id=290026 Here is some more analysis (I am fairly new to Expat, so I may repeat what you already know): dtd.scaffold is used as a "working memory" pool for building content models passed to an element declaration handler. It is passed between parsers only so that the working memory does not have to be allocated again (speed). The passing from parent to child is done using dtdCopy or dtdSwap. From all of that I would say that it should only be freed at the very end, when the root parser gets destroyed. So, to achieve that, simply change the code in dtdDestroy from: ... if (p->scaffIndex) FREE(p->scaffIndex); if (p->scaffold) FREE(p->scaffold); ... to: ... if (!parentParser) { if (p->scaffIndex) FREE(p->scaffIndex); if (p->scaffold) FREE(p->scaffold); } ... Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 01:25 Message: Logged In: YES user_id=290026 Just tested my solution for the dangling pointers: Won't work, since it should only be applied when a dtdCopy was performed (external GE), not when a dtdSwap was done (external PE). However, we don't have a flag that tells us which type of external entity was parsed. Another approach could be to clear the old pointers right when dtdCopy is performed (and also reset scaffCount and scaffSize). That way, even if dtd.scaffold was used again, it would be allocated fram scratch, since the code will detect the null pointers. A lot depends on how dtdCopy and dtd.scaffold are used. Currently dtdCopy is only called for creating an external GE parser, and dtd.scaffold is only used for building the content model of an element declaration, which means it is not shared across parsers. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 23:45 Message: Logged In: YES user_id=290026 There is already a flag: look at the parentParser macro. However, as I said, this dangling pointer does not cause an actual problem. I found this out by looking at the code as well as creating a specific test situation, where an external parser would be created, then freed, and then element declaration would be parsed which would require use of the dtd.scaffold member. However, as it appeared to me, all of this happens during parsing of the DTD, but the dtdCopy function will not have been be called since it is only called when the childparser has context !=0, which means it parses a general entity. And that never happens before the DTD parsing is completed. The dangling pointers could simply be set to null like this in XML_ParserFree: ... #ifdef XML_DTD if (parentParser) { dtdSwap(&dtd, &((Parser *)parentParser)->m_dtd); } #endif /* XML_DTD */ dtdDestroy(&dtd, parser); // now, add this code: ((Parser *)parentParser)->m_dtd.scaffold = 0; ((Parser *)parentParser)->m_dtd.scaffIndex = 0; Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-03 23:06 Message: Logged In: YES user_id=13222 An internal flag for this would be great; the simplest solution, very low cost in speed and memory. I would love, to have a this way fixed expat. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-03 22:54 Message: Logged In: YES user_id=3066 Since the "master" and descendent parsers are created using different functions, we should just add an internal field that indicates whether the parser is the master or not. I think we just need to know whether the parser is the master, but don't need a pointer to the master. Karl, does this sound sufficient? I think we can do this with no public API changes. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-03 22:49 Message: Logged In: YES user_id=13222 Exactly. I came to the same conclusion as Jun Huang, while debugging some rare seg faults of an expat based application, I work with. You have to work with external entities (must use XML_ExternalEntityParserCreate()) to see the error. I second this bug report, saying loud that this man is right, not only in that there is a very hard problem (seg fault) with using external enitities with expat but also with his analysis of the reason for this problem. OK, given that, the obvious question is, how to fix that? As far as I see, there isn't a simple way to determine, if a parser is, well, the 'master', or the 'main' parser or if it's a parser, created to parse an external entity. It's OK, to collect the DTD Information of the internal subset and the parts in the (could be) multiple parameter entities in one memory structure, ie I think, it's OK to not deep dopying the scaffolding. But the memory has to be freed in the outmost parser. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 14:57 Message: Logged In: YES user_id=290026 Looking closer at the code: dtdCopy will only be called for a child parser, if the entity is a general entity, not a parameter entity. dtd.scaffold will only be used when the parser is processing the external or internal subset, which always happens *before* any general external entity is processed. So, by planning (or coincidence ) dtd.scaffold will not get used after being freed as described. However, we still have a dangling pointer, which should be set to null. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 12:37 Message: Logged In: YES user_id=290026 It seems your observation is correct. This can cause memory errors. I am just curious why I haven't seen them yet. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=549014&group_id=10127 From noreply@sourceforge.net Sat May 4 15:11:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat May 4 14:11:01 2002 Subject: [ expat-Bugs-551852 ] BOM causes error with small buffers Message-ID: Bugs item #551852, was opened at 2002-05-03 09:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=551852&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) >Assigned to: Karl Waclawek (kwaclaw) Summary: BOM causes error with small buffers Initial Comment: This happens when an external entity that has a BOM *and* a text declaration, is parsed, and the buffer size is very small. For instance, take these two files: --- test.xml --- ]> &e; --- end of file --- and this external entity, saved in UTF-16 with BOM: --- test.ent --- some text --- end of file --- When parsing this with a buffer size of 1 (using XML_GetBuffer), you get the error "xml processing instruction not at start of entity". This error won't happen if you remove the BOM. I have traced this to the function externalEntityInitProcessor2. I found a fix for this: original code: ... switch (tok) { case XML_TOK_BOM: start = next; break; ... fixed code: ... switch (tok) { case XML_TOK_BOM: if (next == end && endPtr) { *endPtr = next; return XML_ERROR_NONE; } start = next; break; ... Explanation for fix: If we are at the end of the buffer, the original code would pass control to the next stage, i.e. externalEntityInitProcessor3, which would detect XML_TOK_NONE and pass control directly to doContent without processing any xml text declaration. However, in doContent the xml text declaration will then be parsed and this will cause the error XML_ERROR_MISPLACED_XML_PI, sinc doContent does not allow text declarations. The fix simply prevents control to be passed to doContent before externalEntityInitProcessor2 can process the xml text declaration. Karl ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-04 17:10 Message: Logged In: YES user_id=3066 Karl, I have a test case for this one and can confirm your suggested fix. Check it in whenever you're ready, and I'll follow with the test case. (Still working on the other tests; I got swamped by work & kids this week.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=551852&group_id=10127 From noreply@sourceforge.net Sat May 4 15:17:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat May 4 14:17:02 2002 Subject: [ expat-Bugs-549014 ] May cause memory error in dtdCopy. Message-ID: Bugs item #549014, was opened at 2002-04-26 10:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=549014&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jun Huang (huangjun_se) Assigned to: Nobody/Anonymous (nobody) Summary: May cause memory error in dtdCopy. Initial Comment: This problem may not a bug.If not ,I want somebody to tell me how to use the XML_ExternalEntityParserCreate and XML_ParserFree.Thank you. In function "dtdCopy",there is a comment "/* Don't want deep copying for scaffolding */".I don't understand it's meaning.But the following code set oldDtd->scaffIndex to newDtd->scaffIndex.I found it may cause a memory error. If a parentParser has allocated the memory pointed by scaffIndex,I use XML_ExternalEntityParserCreate to create a subParser.So the subParser will get the scaffIndex of the parentParser.And then I call XML_ParserFree to free the subParser,it will free the memory pointed by scaffIndex of the subParser.But the scaffIndex of the parentParser still pointed the memory freed.Then if the following code visit the memory pointed by the scaffIndex ,it will cause a memory error. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-04 21:16 Message: Logged In: YES user_id=13222 In other words, your mean: if (prologState.documentEntity) { if (p->scaffIndex) FREE(p->scaffIndex); if (p->scaffold) FREE(p->scaffold); } at the end of dtdDestroy? Nope, still seg faults. And it seems for the same reason, why parentParser could not used for this. As far, as I see, documentEntity is only set in XmlPrologStateInit() (to 1) and in XmlPrologStateInitExternalEntity() (to 0). Now take again a look at the already quoted end of XML_ExternalEntityParserCreate(): if (context) { #endif /* XML_DTD */ if (!dtdCopy(&dtd, oldDtd, parser) || !setContext(parser, context)) { XML_ParserFree(parser); return 0; } processor = externalEntityInitProcessor; #ifdef XML_DTD } else { dtdSwap(&dtd, oldDtd); parentParser = oldParser; XmlPrologStateInitExternalEntity(&prologState); dtd.complete = 1; hadExternalDoctype = 1; } XmlPrologStateInitExternalEntity() is only called for external parameter entities and the external DTD subset (for this, context is 0). For external general entities, documentEntity isn't set to 0. And therefor the test in dtdDestroy() above doesn't work. I can track this in my test case. This test case has an external subset (for which documentEntity is set to 0) and various external general entities in the content. documentEntity is set to 0 for the parser, that parses the external subset. The external entity parser created to parse the external general entities doesn't have set documentEntity to 0. Consequently, the scaffolding stuff is free'ed in dtdDestroy() - in the current CVS the same as with both proposed tests - at the moment, the parser for the first external general entity is free'ed. If the 'child' parser created for the second external general entity is freed, it makes *bang*: seg fault. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 20:44 Message: Logged In: YES user_id=290026 No, documentEntity does not fit the bill either, so it seems we need a new member. After having a closer look: parentParser is not set for external general entities probably because none of the related code uses it. As far as I can tell, parentParser is used exclusively by DTD processing code, except for the XML_ParserFree function. I have put together a patch (based on my patch # 551599) that does the following: - adds a new member m_isParamEntity and the associated macro - sets parentParser to oldParser for both, external GEs and PEs, in XML_ExternalEntityParserCreate - initializes isParamEntity to 0, but sets it to 1 where parentParser used to be set to oldParser - replaces "if (parentParser)" with "if (isParamEntity)" in XML_ParserFree - keeps the previously suggested code in dtdDestroy: if (!parentParser) { if (p->scaffIndex) FREE(p->scaffIndex); if (p->scaffold) FREE(p->scaffold); } which should guarantee that dtd.scaffold is freed for the root parser only, since parentParser will always be set for child parsers - all other checks of parentParentParser in the DTD handling code should probably be replaced with checks for isParamEntity, however, in DTD handling code, whenever parentParser is set, isParamEntity = 1, and whenever parentParser is null, isParamEntity = 0, so the two are equivalent. Only outside of DTD handling code can they be different If anybody is interested, I can e-mail the patch. If it works - for those that can test it - then I will probably add it as another improvement to patch # 551599. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 18:44 Message: Logged In: YES user_id=290026 You are right - damn! I have to revisit my recent patch for PE handling! Anyway, if parentParser does not fit the bill, then prologState.documentEntity might. Could you please check that too. Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-04 16:23 Message: Logged In: YES user_id=13222 I'm sure, I don't understand all the internals in every detail. But: I would say, Karl Waclawek's code if (!parentParser) { if (p->scaffIndex) FREE(p->scaffIndex); if (p->scaffold) FREE(p->scaffold); } goes into the right direction, but this alone doesn't fix the problem (at least doesn't fix the problem completely). I've an example, which triggers the seg fault (it's a bit complex, a hole application, to much, to attach it, but if somebody is interested enough, I can point you to the code and supply test data.) Even with Karls modification, this example still seg faults. But, as said, where at the right trace. If I remove the freeing of p->scaffIndex and p->scaffold from dtdDestroy(), everthing works as expected (but with a memory leak, of course). But how could this be? Well, as far as I see, parentParser is _not_ set in every case in XML_ExternalEntityParserCreate(). Take a look at the end of this function: if (context) { #endif /* XML_DTD */ if (!dtdCopy(&dtd, oldDtd, parser) || !setContext(parser, context)) { XML_ParserFree(parser); return 0; } processor = externalEntityInitProcessor; #ifdef XML_DTD } else { dtdSwap(&dtd, oldDtd); parentParser = oldParser; XmlPrologStateInitExternalEntity(&prologState); dtd.complete = 1; hadExternalDoctype = 1; } parentParser is only set (to a value != 0), if context is false. If I use parentParser = oldParser; if (context) { #endif /* XML_DTD */ if (!dtdCopy(&dtd, oldDtd, parser) || !setContext(parser, context)) { XML_ParserFree(parser); return 0; } processor = externalEntityInitProcessor; #ifdef XML_DTD } else { dtdSwap(&dtd, oldDtd); XmlPrologStateInitExternalEntity(&prologState); dtd.complete = 1; hadExternalDoctype = 1; } (moved the parentParser setting outside the if, so that it's always set). This, together with Karl's code fixes the problem for me. But I'm really not sure, if this could (should) be done. I don't recall all details of my debugging sessions (it was some month ago), but if I recall right, there are reasons, for that the parentParser is not always set. It's a way to distinguish, if the external entity parser parses an external parameter entity or a general external entity (for parameter entities context is 0). This distinction seems to be used at some places and it looks like, we need it (please correct me, if I'm wrong). So, what to do? Back to Fred's propose of a new interal flag, that's only set for the master parser? Looks like this would be the simplest solution, with the lowest risk of unexpected side effects. Does somebody knows, if this distinction is necessary somewhere, for the parser, to work correct? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 14:05 Message: Logged In: YES user_id=290026 Here is some more analysis (I am fairly new to Expat, so I may repeat what you already know): dtd.scaffold is used as a "working memory" pool for building content models passed to an element declaration handler. It is passed between parsers only so that the working memory does not have to be allocated again (speed). The passing from parent to child is done using dtdCopy or dtdSwap. From all of that I would say that it should only be freed at the very end, when the root parser gets destroyed. So, to achieve that, simply change the code in dtdDestroy from: ... if (p->scaffIndex) FREE(p->scaffIndex); if (p->scaffold) FREE(p->scaffold); ... to: ... if (!parentParser) { if (p->scaffIndex) FREE(p->scaffIndex); if (p->scaffold) FREE(p->scaffold); } ... Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 05:25 Message: Logged In: YES user_id=290026 Just tested my solution for the dangling pointers: Won't work, since it should only be applied when a dtdCopy was performed (external GE), not when a dtdSwap was done (external PE). However, we don't have a flag that tells us which type of external entity was parsed. Another approach could be to clear the old pointers right when dtdCopy is performed (and also reset scaffCount and scaffSize). That way, even if dtd.scaffold was used again, it would be allocated fram scratch, since the code will detect the null pointers. A lot depends on how dtdCopy and dtd.scaffold are used. Currently dtdCopy is only called for creating an external GE parser, and dtd.scaffold is only used for building the content model of an element declaration, which means it is not shared across parsers. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 03:45 Message: Logged In: YES user_id=290026 There is already a flag: look at the parentParser macro. However, as I said, this dangling pointer does not cause an actual problem. I found this out by looking at the code as well as creating a specific test situation, where an external parser would be created, then freed, and then element declaration would be parsed which would require use of the dtd.scaffold member. However, as it appeared to me, all of this happens during parsing of the DTD, but the dtdCopy function will not have been be called since it is only called when the childparser has context !=0, which means it parses a general entity. And that never happens before the DTD parsing is completed. The dangling pointers could simply be set to null like this in XML_ParserFree: ... #ifdef XML_DTD if (parentParser) { dtdSwap(&dtd, &((Parser *)parentParser)->m_dtd); } #endif /* XML_DTD */ dtdDestroy(&dtd, parser); // now, add this code: ((Parser *)parentParser)->m_dtd.scaffold = 0; ((Parser *)parentParser)->m_dtd.scaffIndex = 0; Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-04 03:06 Message: Logged In: YES user_id=13222 An internal flag for this would be great; the simplest solution, very low cost in speed and memory. I would love, to have a this way fixed expat. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-04 02:54 Message: Logged In: YES user_id=3066 Since the "master" and descendent parsers are created using different functions, we should just add an internal field that indicates whether the parser is the master or not. I think we just need to know whether the parser is the master, but don't need a pointer to the master. Karl, does this sound sufficient? I think we can do this with no public API changes. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-04 02:49 Message: Logged In: YES user_id=13222 Exactly. I came to the same conclusion as Jun Huang, while debugging some rare seg faults of an expat based application, I work with. You have to work with external entities (must use XML_ExternalEntityParserCreate()) to see the error. I second this bug report, saying loud that this man is right, not only in that there is a very hard problem (seg fault) with using external enitities with expat but also with his analysis of the reason for this problem. OK, given that, the obvious question is, how to fix that? As far as I see, there isn't a simple way to determine, if a parser is, well, the 'master', or the 'main' parser or if it's a parser, created to parse an external entity. It's OK, to collect the DTD Information of the internal subset and the parts in the (could be) multiple parameter entities in one memory structure, ie I think, it's OK to not deep dopying the scaffolding. But the memory has to be freed in the outmost parser. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 18:57 Message: Logged In: YES user_id=290026 Looking closer at the code: dtdCopy will only be called for a child parser, if the entity is a general entity, not a parameter entity. dtd.scaffold will only be used when the parser is processing the external or internal subset, which always happens *before* any general external entity is processed. So, by planning (or coincidence ) dtd.scaffold will not get used after being freed as described. However, we still have a dangling pointer, which should be set to null. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 16:37 Message: Logged In: YES user_id=290026 It seems your observation is correct. This can cause memory errors. I am just curious why I haven't seen them yet. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=549014&group_id=10127 From noreply@sourceforge.net Sat May 4 21:47:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat May 4 20:47:02 2002 Subject: [ expat-Bugs-551852 ] BOM causes error with small buffers Message-ID: Bugs item #551852, was opened at 2002-05-03 09:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=551852&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) Summary: BOM causes error with small buffers Initial Comment: This happens when an external entity that has a BOM *and* a text declaration, is parsed, and the buffer size is very small. For instance, take these two files: --- test.xml --- ]> &e; --- end of file --- and this external entity, saved in UTF-16 with BOM: --- test.ent --- some text --- end of file --- When parsing this with a buffer size of 1 (using XML_GetBuffer), you get the error "xml processing instruction not at start of entity". This error won't happen if you remove the BOM. I have traced this to the function externalEntityInitProcessor2. I found a fix for this: original code: ... switch (tok) { case XML_TOK_BOM: start = next; break; ... fixed code: ... switch (tok) { case XML_TOK_BOM: if (next == end && endPtr) { *endPtr = next; return XML_ERROR_NONE; } start = next; break; ... Explanation for fix: If we are at the end of the buffer, the original code would pass control to the next stage, i.e. externalEntityInitProcessor3, which would detect XML_TOK_NONE and pass control directly to doContent without processing any xml text declaration. However, in doContent the xml text declaration will then be parsed and this will cause the error XML_ERROR_MISPLACED_XML_PI, sinc doContent does not allow text declarations. The fix simply prevents control to be passed to doContent before externalEntityInitProcessor2 can process the xml text declaration. Karl ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 23:46 Message: Logged In: YES user_id=290026 Should we check this in, or wait until the PE references patch is tested also. The reason I am mentioning this is that parsing external PE references has the same problem. It just does not show in the current revision, since Expat does not pass such references to the external entity ref handler. Karl Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-04 17:10 Message: Logged In: YES user_id=3066 Karl, I have a test case for this one and can confirm your suggested fix. Check it in whenever you're ready, and I'll follow with the test case. (Still working on the other tests; I got swamped by work & kids this week.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=551852&group_id=10127 From anh-thu.tran@lmco.com Tue May 7 05:59:02 2002 From: anh-thu.tran@lmco.com (Tran, Anh-thu) Date: Tue May 7 04:59:02 2002 Subject: bugs when installing expat 1.95.2 on Sun 5.6 Message-ID: <25AF30BCCD7BD411968200508BDF7FAE0B072175@emss10m02.rck.atm.lmco.com> When I ran make command, nothing happened. It just returned the prompt, and looked like it didn't build anything. I just tried to run make install and got errors: cc -o xmlwf -static xmlwf.o xmlfile.o codepage.o unixfilemap.o -L../lib/.libs -lexpat cc: -a conflicts with -dy. *** Error code 1 make: Fatal error: Command failed for target `xmlwf' Current working directory /tmp/expat-1.95.2/xmlwf *** Error code 1 make: Fatal error: Command failed for target `install' Please help. Thank you. From noreply@sourceforge.net Tue May 7 08:29:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue May 7 07:29:03 2002 Subject: [ expat-Bugs-553288 ] install expat 1.95.2 on sun os 5.6 Message-ID: Bugs item #553288, was opened at 2002-05-07 14:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=553288&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anh-Thu Tran (atran4) Assigned to: Nobody/Anonymous (nobody) Summary: install expat 1.95.2 on sun os 5.6 Initial Comment: When I ran make command, nothing happened. It just returned the prompt. I just continued to run make install and got errors: cc -o xmlwf -static xmlwf.o xmlfile.o codepage.o unixfilemap.o -L../lib/.libs -lexpat cc: -a conflicts with -dy. *** Error code 1 make: Fatal error: Command failed for target `xmlwf' Current working directory /tmp/expat-1.95.2/xmlwf *** Error code 1 make: Fatal error: Command failed for target `install' Please help. Thank you. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=553288&group_id=10127 From noreply@sourceforge.net Tue May 7 09:38:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue May 7 08:38:04 2002 Subject: [ expat-Bugs-553318 ] XML_ParserReset does not reset everythi Message-ID: Bugs item #553318, was opened at 2002-05-07 11:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=553318&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) Summary: XML_ParserReset does not reset everythi Initial Comment: I have identified three problems with XML_ParserReset in xmlparse.ca rev. 1.31: 1) tempPool and temp2Pool are not cleared, which means that they may grow much larger than needed (the poolClear function does not deallocate memory!) 2) the dtd structure is not reset 3) it should not be legal to call XML_ParserReset on a child parser, since sometimes the child parser shares the dtd structure with the parent parser, and because a child parser created for parsing an external entity cannot be used for the same purpose anymore - the initialization would need to be different I propose to split XML_ParserReset into two functions, an internal one, called parserInit, and an exported one with the original name. This one would then use parserInit like this: int XML_ParserReset(XML_Parser parser, const XML_Char *encodingName) { if (parentParser) return 0; #ifdef XML_DTD if (dtd.scaffold) dtdDestroy(&dtd, parser); #endif poolClear(&tempPool); poolClear(&temp2Pool); return parserInit(parser, encodingName); } whereas parserInit would be called by XML_ParserCreate_MM instead of XML_ParserReset, since not everything that applies to the exported version applies to the internal one. This examples necessitates that parentParser is always set for a child parser, which is currently not the case, but patch # 551599 includes it as a "byproduct" of fixing bug # 549014. Also, parserInit (and consequently XML_ParserReset) may potentially fail (since parserInit calls dtdInit internally) and therefore the return type should be changed from void to int. Changes according to this have been included in patch # 551599 (2nd improved version). Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=553318&group_id=10127 From noreply@sourceforge.net Tue May 7 09:54:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue May 7 08:54:03 2002 Subject: [ expat-Bugs-553318 ] XML_ParserReset does not reset everythi Message-ID: Bugs item #553318, was opened at 2002-05-07 11:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=553318&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) >Assigned to: Karl Waclawek (kwaclaw) Summary: XML_ParserReset does not reset everythi Initial Comment: I have identified three problems with XML_ParserReset in xmlparse.ca rev. 1.31: 1) tempPool and temp2Pool are not cleared, which means that they may grow much larger than needed (the poolClear function does not deallocate memory!) 2) the dtd structure is not reset 3) it should not be legal to call XML_ParserReset on a child parser, since sometimes the child parser shares the dtd structure with the parent parser, and because a child parser created for parsing an external entity cannot be used for the same purpose anymore - the initialization would need to be different I propose to split XML_ParserReset into two functions, an internal one, called parserInit, and an exported one with the original name. This one would then use parserInit like this: int XML_ParserReset(XML_Parser parser, const XML_Char *encodingName) { if (parentParser) return 0; #ifdef XML_DTD if (dtd.scaffold) dtdDestroy(&dtd, parser); #endif poolClear(&tempPool); poolClear(&temp2Pool); return parserInit(parser, encodingName); } whereas parserInit would be called by XML_ParserCreate_MM instead of XML_ParserReset, since not everything that applies to the exported version applies to the internal one. This examples necessitates that parentParser is always set for a child parser, which is currently not the case, but patch # 551599 includes it as a "byproduct" of fixing bug # 549014. Also, parserInit (and consequently XML_ParserReset) may potentially fail (since parserInit calls dtdInit internally) and therefore the return type should be changed from void to int. Changes according to this have been included in patch # 551599 (2nd improved version). Karl ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-07 11:53 Message: Logged In: YES user_id=3066 Sounds good to me. Assigning to you since you've already written the patch. ;-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=553318&group_id=10127 From noreply@sourceforge.net Tue May 7 09:54:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue May 7 08:54:07 2002 Subject: [ expat-Patches-551599 ] Patch for bugs # 483514, 544679, 548690 Message-ID: Patches item #551599, was opened at 2002-05-02 16:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=551599&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for bugs # 483514, 544679, 548690 Initial Comment: This is an extensive patch, and needs not only testing, but also a review by my fellow developers! It addresses these issues: # 483514 (default handler reports too much from DTD): only the following data are reported now: - ignored DTD sections - unhandled external parameter entity references - top level whitespace This may not be what is needed, but more would have been a lot of work # 544679, 548690 (DTD handling of external entities): - the storeEntityValue function has been modified to call the external entity reference handler, since it did not handle external PE references at all - a new STRING_POOL has been added that gets passed from a parent to a child parser (member of DTD structure), so that entity values can be built across parsers - new functions entityValueInitProcessor and entityValueProcessor have been added - the old usage of dtd.complete was completely changed - I never understood how it worked, and it didn't work properly anyway; therefore there is a danger now that some logic will not work anymore - please review and check - the usage of hadExternalDoctype was modified too - there have been changes in xmlrole.c too - the chain of state handlers was extended from entity9 to entity10 - in analogy to how general entities - please review the diff file - as a result, this patch now processes all of James Clark's test cases in the /valid/not-sa and /valid/ext-sa directories properly * I have also made some fixes to the recently introduced XML_ParserReset function (incl. changing it's return type), and one fix that prevents a null pointer error The patch is based on these revisions: - expat.h rev. 1.17 - xmlparse.c rev. 1.31 - xmlrole.c rev. 1.5 - xmlrole.h rev. 1.3 I have included the full patch files, an annotated version of xmlparse.c - good to understand my changes, and the diff files. Karl ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-07 11:53 Message: Logged In: YES user_id=290026 This is the second improvement and probably the final version of the patch. If there should be more changes, a new patch will be entered, since it might get confusing otherwise. The following changes have been made: - some improvements on external PE reference handling - a better fix (hopefully) for bug # 549014 - the changes to DefaultHandler calls for DTDs have been undone - I realized that more extensive changes (also to xmlrole.c and xmlrole.h) would be necessary, so the old behaviour is back: everything for DTDs is reported, even if handlers are set, except for PIs, Comments and XML text declarations. This patch now applies to the following bugs: - # 553318 - # 551852 - # 549014 - # 548690 - # 544679 Uploaded as files xmlparse_2.c and xmlparse_2.c.diff. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 13:13 Message: Logged In: YES user_id=290026 I improved the patch to cover one more problem: I found that bug # 551852 (BOM problem with small buffers), that was reported for general external entities, also applied to external parameter entities. This problem only applied to this patch, since the current release of Expat simply ignores external PEs (which causes bug # 548690). Included is also a fix for bug # 549014 (dtdCopy problem). The attached file are xmlparse_1.c, xmlparse_1.c.annotated and xmlparse_1.diff (against rev. 1.31). Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 10:09 Message: Logged In: YES user_id=290026 Forgot to add: the fix for bug # 551852 is included too. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=551599&group_id=10127 From noreply@sourceforge.net Tue May 7 10:00:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue May 7 09:00:02 2002 Subject: [ expat-Bugs-532407 ] Can't compile 1.95.2 on SCO OpenServer Message-ID: Bugs item #532407, was opened at 2002-03-20 05:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=532407&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: Can't compile 1.95.2 on SCO OpenServer Initial Comment: I can't compile expat 1.95.2 on SCO openserver . 'make' does nothing. I can't check out CVS version because of a firewall. How can I do? see below for details expat-1.95.2 $ ./configure creating cache ./config.cache checking host system type... i686-pc-sco3.2v5.0.6 checking build system type... i686-pc-sco3.2v5.0.6 checking for ranlib... : checking for gcc... no checking for cc... cc checking whether the C compiler (cc ) works... yes checking whether the C compiler (cc ) is a cross-compiler... no checking whether we are using GNU C... no checking whether cc accepts -g... yes checking for non-GNU ld... /bin/ld checking if the linker (/bin/ld) is GNU ld... no checking for BSD-compatible nm... /bin/nm -p checking whether ln -s works... yes checking whether the C compiler needs -belf... yes updating cache ./config.cache 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... -Kpic checking if cc PIC flag -Kpic works... yes checking if cc supports -c -o file.o... yes checking if cc supports -c -o file.lo... yes ltconfig: warning: `cc' requires `-belf' to build shared libraries checking if cc static flag -dn works... -dn checking if the linker (/bin/ld) is GNU ld... no checking whether the linker (/bin/ld) supports shared libraries... yes checking command to parse /bin/nm -p output... ok checking how to hardcode library paths into programs... immediate checking for /bin/ld option to reload object files... -r checking dynamic linker characteristics... sco3.2v5.0.6 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 loading cache ./config.cache checking for gcc... (cached) cc checking whether the C compiler (cc -g -belf ) works... yes checking whether the C compiler (cc -g -belf ) 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/bin/X11/scoinst -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... no checking for memmove... yes checking for bcopy... yes updating cache ./config.cache creating ./config.status creating Makefile creating lib/Makefile creating lib/expat.h creating xmlwf/Makefile creating examples/Makefile creating config.h expat-1.95.2 $ make expat-1.95.2 $ cd lib expat-1.95.2/lib $ make /bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -DPACKAGE='"expat"' -DVERSION='"expat_1.95.2"' -I. -I. -I.. -g -belf -c xmlparse.c mkdir .libs cc -DHAVE_CONFIG_H -DPACKAGE=\expat\ -DVERSION=\expat_1.95.2\ -I. -I. -I.. -g -belf -c xmlparse.c -Kpic -DPIC -o .libs/xmlparse.lo cc -DHAVE_CONFIG_H -DPACKAGE=\expat\ -DVERSION=\expat_1.95.2\ -I. -I. -I.. -g -belf -c xmlparse.c -o xmlparse.o >/dev/null 2>&1 mv -f .libs/xmlparse.lo xmlparse.lo /bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -DPACKAGE='"expat"' -DVERSION='"expat_1.95.2"' -I. -I. -I.. -g -belf -c xmltok.c rm -f .libs/xmltok.lo cc -DHAVE_CONFIG_H -DPACKAGE=\expat\ -DVERSION=\expat_1.95.2\ -I. -I. -I.. -g -belf -c xmltok.c -Kpic -DPIC -o .libs/xmltok.lo cc -DHAVE_CONFIG_H -DPACKAGE=\expat\ -DVERSION=\expat_1.95.2\ -I. -I. -I.. -g -belf -c xmltok.c -o xmltok.o >/dev/null 2>&1 mv -f .libs/xmltok.lo xmltok.lo /bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -DPACKAGE='"expat"' -DVERSION='"expat_1.95.2"' -I. -I. -I.. -g -belf -c xmlrole.c rm -f .libs/xmlrole.lo cc -DHAVE_CONFIG_H -DPACKAGE=\expat\ -DVERSION=\expat_1.95.2\ -I. -I. -I.. -g -belf -c xmlrole.c -Kpic -DPIC -o .libs/xmlrole.lo cc -DHAVE_CONFIG_H -DPACKAGE=\expat\ -DVERSION=\expat_1.95.2\ -I. -I. -I.. -g -belf -c xmlrole.c -o xmlrole.o >/dev/null 2>&1 mv -f .libs/xmlrole.lo xmlrole.lo /bin/sh ../libtool --mode=link cc -version-info 1:0:1 -g -belf -o libexpat.la -rpath /usr/local/lib xmlparse.lo xmltok.lo xmlrole.lo rm -fr .libs/libexpat.la .libs/libexpat.* .libs/libexpat.* /bin/ld -G -h libexpat.so0 -o .libs/libexpat.so.1.1.0 xmlparse.lo xmltok.lo xmlrole.lo (cd .libs && rm -f libexpat.so0 && ln -s libexpat.so.1.1.0 libexpat.so0) (cd .libs && rm -f libexpat.so && ln -s libexpat.so.1.1.0 libexpat.so) ar cru .libs/libexpat.a xmlparse.o xmltok.o xmlrole.o : .libs/libexpat.a creating libexpat.la (cd .libs && rm -f libexpat.la && ln -s ../libexpat.la libexpat.la) expat-1.95.2/lib $ cd ../xmlwf expat-1.95.2/xmlwf $ make cc -g -belf -I../lib -c xmlwf.c cc -g -belf -I../lib -c xmlfile.c cc -g -belf -I../lib -c codepage.c cc -g -belf -I../lib -c unixfilemap.c cc -o xmlwf -static xmlwf.o xmlfile.o codepage.o unixfilemap.o -L../lib/.libs -lexpat error: unknown -a option: tic *** Error code 1 (bu21) expat-1.95.2/xmlwf $ cd ../examples expat-1.95.2/examples $ make cc -g -belf -I../lib -c elements.c cc -o elements -static -L../lib/.libs -lexpat error: unknown -a option: tic *** Error code 1 (bu21) ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-07 11:59 Message: Logged In: YES user_id=3066 You note that you can't checkout from CVS and ask what you can do, but I don't see an email address. I'll be glad to package a copy based on the current state of CVS, but don't know where to send it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=532407&group_id=10127 From noreply@sourceforge.net Tue May 7 12:38:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue May 7 11:38:03 2002 Subject: [ expat-Bugs-547350 ] make install of xmlwf failed on FreeBSD Message-ID: Bugs item #547350, was opened at 2002-04-22 18:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=547350&group_id=10127 Category: Build control Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexey Kulentsov (akul) Assigned to: Greg Stein (gstein) Summary: make install of xmlwf failed on FreeBSD Initial Comment: 1.95.2 # make install /bin/csh ../conftools/mkinstalldirs /usr/local/bin errstatus=0: Command not found. for: Command not found. do: Command not found. set: Variable name must begin with a letter. *** Error code 1 Stop in /usr/src/expat-1.95.2/xmlwf. xmlwf part seems to be windows specific part because .c sources are executable. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-07 11:37 Message: Logged In: NO Use gmake instead of make. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=547350&group_id=10127 From noreply@sourceforge.net Wed May 8 15:41:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed May 8 14:41:03 2002 Subject: [ expat-Bugs-477667 ] illegal utf-8 seqs do not throw error Message-ID: Bugs item #477667, was opened at 2001-11-02 22:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=477667&group_id=10127 Category: None Group: None Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Patrick McCormick (patrickmc) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: illegal utf-8 seqs do not throw error Initial Comment: I have a problem where users like to use iso-8859-1 without declaring it in the prolog, like this: abécdef expat properly defaults to utf-8 in this case. As I understand utf-8, the é character (0xE7) has a bitfield that looks like the start of a three byte sequence. A 3-byte sequence is supposed to look like this: bytes | bits | representation 3 | 16 | 1110vvvv 10vvvvvv 10vvvvvv the above two bytes (c and d) don't match the 10vvvvvv mask, so écd is an illegal utf-8 sequence. But expat doesn't throw a well-formedness error. Expat uses this macro in xmltok.c to figure out what's illegal: #define UTF8_INVALID3(p) \ ((*p) == 0xED \ ? (((p)[1] & 0x20) != 0) \ : ((*p) == 0xEF \ ? ((p)[1] == 0xBF && ((p)[2] == 0xBF || (p)[2] == 0xBE)) \ : 0)) but this doesn't seem strict enough. I wrote a patch that makes expat check UTF-8 sequences against the Table 3.1B of the Unicode 3.1 standard: http://www.unicode.org/unicode/reports/tr27/ as originally clarified in this Corrigendum: http://www.unicode.org/unicode/uni2errata/UTF- 8_Corrigendum.html and it's attached. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-08 21:40 Message: Logged In: YES user_id=13222 I'm not happy with closing this bug report without action. Contrary to Fred's test result, I still find, that the described bug is still there (as it was at the time, the bug was reported). I've tested this with the current CVS HEAD. The bug is in deed easly demonstrable with the example out of the bug report. I use: abécdef The third character of the PCDATA is a small e with acute, that's 0xe9 in the iso-8859-1 char table (and the unicode char 00e9), if there may be an encoding problem throu the web interface. xmlwf passes this test file, without any error report, which is, to the best of my knowledge, wrong. rxp and libxml (i.e. xmllint) confirm, that the test file is not proper UTF-8. IHMO, this is a real _crucial_ bug. Please, __Please__, re-check this. rolf ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-19 19:19 Message: Logged In: YES user_id=3066 Added a test (tests/runtests.c revision 1.9) that shows this bug does not exist in the CVS version. You did not state which version of Expat you're using. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=477667&group_id=10127 From noreply@sourceforge.net Thu May 9 07:36:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu May 9 06:36:06 2002 Subject: [ expat-Bugs-552297 ] Request for skippedEntity handler Message-ID: Bugs item #552297, was opened at 2002-05-04 13:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=552297&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) Summary: Request for skippedEntity handler Initial Comment: It would be very useful if Expat reported skipped entities, like in the SAX2 specification. I have identified the following situations for that: B) External Entities are reported as skipped: - if no external entity ref handler is set - if the entity ref handler returns a special value (e.g. we can define 2 as meaning: "skip this one") B) Internal Entities are reported as skipped: - SetDefaultHandler was called (which turns off expansion of internal general entities) C) Any entity reference is reported as skipped - if no declaration is found & that is not an error (otherwise return a well-formedness error) Karl ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-09 09:35 Message: Logged In: YES user_id=290026 I propose the following signature for the handler: enum XML_Skip_Reason { XML_SKIP_UNDEFINED, XML_SKIP_NOHANDLER, XML_SKIP_REQUESTED }; typedef void (*XML_SkippedEntityHandler) (void *userData, const XML_Char *entityName, int is_parameter_entity, const XML_Char *systemId, const XML_Char *publicId, enum XML_Skip_Reason skipReason); where the values of skipReason have the following meanings: - XML_SKIP_UNDEFINED: entity was skipped because no declaration was found, and this was not an error - XML_SKIP_NOHANDLER: entity was skipped because there was no ExternalEntityRefHandler installed - XML_SKIP_REQUESTED: the ExternalEntityRefHandler returned a value of 2, which means the handler requested the entity to be skipped I hope this makes sense. Comments welcome! Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=552297&group_id=10127 From noreply@sourceforge.net Thu May 9 08:25:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu May 9 07:25:07 2002 Subject: [ expat-Bugs-477667 ] illegal utf-8 seqs do not throw error Message-ID: Bugs item #477667, was opened at 2001-11-02 17:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=477667&group_id=10127 Category: None Group: None >Status: Open Resolution: Works For Me Priority: 5 Submitted By: Patrick McCormick (patrickmc) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: illegal utf-8 seqs do not throw error Initial Comment: I have a problem where users like to use iso-8859-1 without declaring it in the prolog, like this: abécdef expat properly defaults to utf-8 in this case. As I understand utf-8, the é character (0xE7) has a bitfield that looks like the start of a three byte sequence. A 3-byte sequence is supposed to look like this: bytes | bits | representation 3 | 16 | 1110vvvv 10vvvvvv 10vvvvvv the above two bytes (c and d) don't match the 10vvvvvv mask, so écd is an illegal utf-8 sequence. But expat doesn't throw a well-formedness error. Expat uses this macro in xmltok.c to figure out what's illegal: #define UTF8_INVALID3(p) \ ((*p) == 0xED \ ? (((p)[1] & 0x20) != 0) \ : ((*p) == 0xEF \ ? ((p)[1] == 0xBF && ((p)[2] == 0xBF || (p)[2] == 0xBE)) \ : 0)) but this doesn't seem strict enough. I wrote a patch that makes expat check UTF-8 sequences against the Table 3.1B of the Unicode 3.1 standard: http://www.unicode.org/unicode/reports/tr27/ as originally clarified in this Corrigendum: http://www.unicode.org/unicode/uni2errata/UTF- 8_Corrigendum.html and it's attached. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-09 10:24 Message: Logged In: YES user_id=290026 I can confirm that the current CVS does indeed not report an error against: abécdef Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-08 17:40 Message: Logged In: YES user_id=13222 I'm not happy with closing this bug report without action. Contrary to Fred's test result, I still find, that the described bug is still there (as it was at the time, the bug was reported). I've tested this with the current CVS HEAD. The bug is in deed easly demonstrable with the example out of the bug report. I use: abécdef The third character of the PCDATA is a small e with acute, that's 0xe9 in the iso-8859-1 char table (and the unicode char 00e9), if there may be an encoding problem throu the web interface. xmlwf passes this test file, without any error report, which is, to the best of my knowledge, wrong. rxp and libxml (i.e. xmllint) confirm, that the test file is not proper UTF-8. IHMO, this is a real _crucial_ bug. Please, __Please__, re-check this. rolf ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-19 15:19 Message: Logged In: YES user_id=3066 Added a test (tests/runtests.c revision 1.9) that shows this bug does not exist in the CVS version. You did not state which version of Expat you're using. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=477667&group_id=10127 From noreply@sourceforge.net Thu May 9 08:45:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu May 9 07:45:05 2002 Subject: [ expat-Bugs-477667 ] illegal utf-8 seqs do not throw error Message-ID: Bugs item #477667, was opened at 2001-11-02 17:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=477667&group_id=10127 Category: None Group: None Status: Open Resolution: Works For Me Priority: 5 Submitted By: Patrick McCormick (patrickmc) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: illegal utf-8 seqs do not throw error Initial Comment: I have a problem where users like to use iso-8859-1 without declaring it in the prolog, like this: abécdef expat properly defaults to utf-8 in this case. As I understand utf-8, the é character (0xE7) has a bitfield that looks like the start of a three byte sequence. A 3-byte sequence is supposed to look like this: bytes | bits | representation 3 | 16 | 1110vvvv 10vvvvvv 10vvvvvv the above two bytes (c and d) don't match the 10vvvvvv mask, so écd is an illegal utf-8 sequence. But expat doesn't throw a well-formedness error. Expat uses this macro in xmltok.c to figure out what's illegal: #define UTF8_INVALID3(p) \ ((*p) == 0xED \ ? (((p)[1] & 0x20) != 0) \ : ((*p) == 0xEF \ ? ((p)[1] == 0xBF && ((p)[2] == 0xBF || (p)[2] == 0xBE)) \ : 0)) but this doesn't seem strict enough. I wrote a patch that makes expat check UTF-8 sequences against the Table 3.1B of the Unicode 3.1 standard: http://www.unicode.org/unicode/reports/tr27/ as originally clarified in this Corrigendum: http://www.unicode.org/unicode/uni2errata/UTF- 8_Corrigendum.html and it's attached. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-09 10:44 Message: Logged In: YES user_id=290026 There is official conversion code at unicode.org. Download the files ConvertUTF.c and ConvertUTF.h from ftp://www.unicode.org/Public/PROGRAMS/CVTUTF/ and then look at the function static Boolean isLegalUTF8(UTF8 *source, int length) Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-09 10:24 Message: Logged In: YES user_id=290026 I can confirm that the current CVS does indeed not report an error against: abécdef Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-08 17:40 Message: Logged In: YES user_id=13222 I'm not happy with closing this bug report without action. Contrary to Fred's test result, I still find, that the described bug is still there (as it was at the time, the bug was reported). I've tested this with the current CVS HEAD. The bug is in deed easly demonstrable with the example out of the bug report. I use: abécdef The third character of the PCDATA is a small e with acute, that's 0xe9 in the iso-8859-1 char table (and the unicode char 00e9), if there may be an encoding problem throu the web interface. xmlwf passes this test file, without any error report, which is, to the best of my knowledge, wrong. rxp and libxml (i.e. xmllint) confirm, that the test file is not proper UTF-8. IHMO, this is a real _crucial_ bug. Please, __Please__, re-check this. rolf ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-19 15:19 Message: Logged In: YES user_id=3066 Added a test (tests/runtests.c revision 1.9) that shows this bug does not exist in the CVS version. You did not state which version of Expat you're using. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=477667&group_id=10127 From noreply@sourceforge.net Thu May 9 14:29:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu May 9 13:29:02 2002 Subject: [ expat-Bugs-469271 ] error on valid entity Message-ID: Bugs item #469271, was opened at 2001-10-08 16:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=469271&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Reed (dtreed) Assigned to: Nobody/Anonymous (nobody) Summary: error on valid entity Initial Comment: The library is erroring out on a valid entity "â". It processes the other ones just fine but the outline program that ships in the examples directory outputs the following: Parse error at line 3: undefined entity when a file containing the following is fed into it: lâst <in> help As soon as I take the "â" out, it works just fine. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-09 16:28 Message: Logged In: YES user_id=290026 Where is this entity defined? It is not a predefined entity, so not valid per se. I think this bug report should be closed, unless someone provides an example where acirc is explicitly declared. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=469271&group_id=10127 From noreply@sourceforge.net Thu May 9 14:34:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu May 9 13:34:02 2002 Subject: [ expat-Bugs-483514 ] Default handler reports handled events Message-ID: Bugs item #483514, was opened at 2001-11-19 12:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=483514&group_id=10127 Category: None Group: None Status: Open Resolution: None >Priority: 3 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) Summary: Default handler reports handled events Initial Comment: It seems that the default handler always reports DTD declarations, even if they are handled, i.e. even if the following handlers are set: - ElementDeclHandler - AttListDeclHandler - EntityDeclHandler - DocTypeDeclHandler - NotationDeclHandler - EntityDeclHandler I posted this this to the mailing list and nobody objected, so it seems to be a bug. Btw, this applies to version 1.95.2. Karl ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-09 16:33 Message: Logged In: YES user_id=290026 I have inspected the source code since, and IMO, the changes necessary would be significant compared to what one would gain. I still consider this a bug, but not a serious one. So, currently everything for DTDs is reported, even if handlers are set, except for PIs, Comments and XML text declarations, as far as I can determine. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=483514&group_id=10127 From noreply@sourceforge.net Thu May 9 19:27:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu May 9 18:27:03 2002 Subject: [ expat-Patches-461763 ] BOM and ExternalSubset Message-ID: Patches item #461763, was opened at 2001-09-15 00:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=461763&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 6 Submitted By: Gilles Marichal (gilou) Assigned to: Nobody/Anonymous (nobody) Summary: BOM and ExternalSubset Initial Comment: Hello, Expat parsing failed when the file to parse had an external subset starting with a BOM. Adding the following two lines at the start of function externalSubset0 in xmlrole.c fixes the problem: if (tok == XML_TOK_BOM) return XML_ROLE_NONE; Note: while correcting that problem, I looked in the xmlrole.c file the others parts of the code handling the XML_TOK_BOM token. I'd like to know the rationale for handling it in prolog1 (wouldn't it always be handled in prolog0 only?). G. Marichal ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-09 21:26 Message: Logged In: YES user_id=290026 It seems this is related to bug # 551852. In this bug, as well as in patch #551599, a fix has been proposed as well. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=461763&group_id=10127 From noreply@sourceforge.net Sat May 11 02:38:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat May 11 01:38:02 2002 Subject: [ expat-Bugs-547350 ] make install of xmlwf failed on FreeBSD Message-ID: Bugs item #547350, was opened at 2002-04-22 18:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=547350&group_id=10127 Category: Build control Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexey Kulentsov (akul) Assigned to: Greg Stein (gstein) Summary: make install of xmlwf failed on FreeBSD Initial Comment: 1.95.2 # make install /bin/csh ../conftools/mkinstalldirs /usr/local/bin errstatus=0: Command not found. for: Command not found. do: Command not found. set: Variable name must begin with a letter. *** Error code 1 Stop in /usr/src/expat-1.95.2/xmlwf. xmlwf part seems to be windows specific part because .c sources are executable. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-11 01:37 Message: Logged In: NO This may or may not be the solution. The ports system on FreeBSD uses gmake anyway (or at least it does for this port) -- typing 'make' in a port uses gmake automatically. I was getting this error, and found that xmlwf/Makefile does not define 'SHELL'. For this reason, the Makefile uses the user's shell (which may be tcsh as in my case, which is not good). Adding SHELL=/bin/sh to xmlwf/Makefile fixed it for me. P.S. I don't know if this has been cleared up, and I don't have time to search through this bug list, so sorry if I'm restating old news. Adios. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-07 11:37 Message: Logged In: NO Use gmake instead of make. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=547350&group_id=10127 From noreply@sourceforge.net Sat May 11 09:50:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat May 11 08:50:02 2002 Subject: [ expat-Bugs-547350 ] make install of xmlwf failed on FreeBSD Message-ID: Bugs item #547350, was opened at 2002-04-22 21:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=547350&group_id=10127 Category: Build control Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Alexey Kulentsov (akul) Assigned to: Greg Stein (gstein) Summary: make install of xmlwf failed on FreeBSD Initial Comment: 1.95.2 # make install /bin/csh ../conftools/mkinstalldirs /usr/local/bin errstatus=0: Command not found. for: Command not found. do: Command not found. set: Variable name must begin with a letter. *** Error code 1 Stop in /usr/src/expat-1.95.2/xmlwf. xmlwf part seems to be windows specific part because .c sources are executable. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-11 11:49 Message: Logged In: YES user_id=3066 Ah, this is the $(SHELL) problem again... Greg has already fixed this in the current CVS, so this should be fine for Expat 1.95.3. Closing this report as "already fixed in CVS". ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-11 04:37 Message: Logged In: NO This may or may not be the solution. The ports system on FreeBSD uses gmake anyway (or at least it does for this port) -- typing 'make' in a port uses gmake automatically. I was getting this error, and found that xmlwf/Makefile does not define 'SHELL'. For this reason, the Makefile uses the user's shell (which may be tcsh as in my case, which is not good). Adding SHELL=/bin/sh to xmlwf/Makefile fixed it for me. P.S. I don't know if this has been cleared up, and I don't have time to search through this bug list, so sorry if I'm restating old news. Adios. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-07 14:37 Message: Logged In: NO Use gmake instead of make. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=547350&group_id=10127 From noreply@sourceforge.net Sat May 11 09:59:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat May 11 08:59:03 2002 Subject: [ expat-Bugs-551772 ] Cannot download. Message-ID: Bugs item #551772, was opened at 2002-05-03 05:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=551772&group_id=10127 >Category: None Group: Not a Bug >Status: Pending Resolution: None >Priority: 4 Submitted By: Daniel (doormouse) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Cannot download. Initial Comment: I am unable to download the latest version of Expat. Do you know why this is. I have tried from a number of different machines as well as trying to get the windows and unix versions of the file. Any help would be great thanks. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-11 11:58 Message: Logged In: YES user_id=3066 Are you trying to download from SourceForge or some re-distribution point? What platform(s) are you using? What tools/browsers are you using to perform the download? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=551772&group_id=10127 From noreply@sourceforge.net Sun May 12 18:24:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun May 12 17:24:01 2002 Subject: [ expat-Patches-551599 ] For # 544679, 548690, 549014, 551852, 553318 Message-ID: Patches item #551599, was opened at 2002-05-02 16:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=551599&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) >Summary: For # 544679, 548690, 549014, 551852, 553318 Initial Comment: This is an extensive patch, and needs not only testing, but also a review by my fellow developers! It addresses these issues: # 483514 (default handler reports too much from DTD): only the following data are reported now: - ignored DTD sections - unhandled external parameter entity references - top level whitespace This may not be what is needed, but more would have been a lot of work # 544679, 548690 (DTD handling of external entities): - the storeEntityValue function has been modified to call the external entity reference handler, since it did not handle external PE references at all - a new STRING_POOL has been added that gets passed from a parent to a child parser (member of DTD structure), so that entity values can be built across parsers - new functions entityValueInitProcessor and entityValueProcessor have been added - the old usage of dtd.complete was completely changed - I never understood how it worked, and it didn't work properly anyway; therefore there is a danger now that some logic will not work anymore - please review and check - the usage of hadExternalDoctype was modified too - there have been changes in xmlrole.c too - the chain of state handlers was extended from entity9 to entity10 - in analogy to how general entities - please review the diff file - as a result, this patch now processes all of James Clark's test cases in the /valid/not-sa and /valid/ext-sa directories properly * I have also made some fixes to the recently introduced XML_ParserReset function (incl. changing it's return type), and one fix that prevents a null pointer error The patch is based on these revisions: - expat.h rev. 1.17 - xmlparse.c rev. 1.31 - xmlrole.c rev. 1.5 - xmlrole.h rev. 1.3 I have included the full patch files, an annotated version of xmlparse.c - good to understand my changes, and the diff files. Karl ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-12 20:23 Message: Logged In: YES user_id=290026 There were only a few modifications necessary to make this patch perform well under testing: - It did not compile when XML_DTD was not defined - fixed - forgot to adjust the appendAttribute() function for the modifications in DTD handling logic - fixed This is the final version of the patch - check the new file xmlparse_final.c (and the diff created from it). So, to get the full final patch, download expat.h, xmlrole.h, xmlrole.c and xmlparse_final.c from the set of attached files. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-07 11:53 Message: Logged In: YES user_id=290026 This is the second improvement and probably the final version of the patch. If there should be more changes, a new patch will be entered, since it might get confusing otherwise. The following changes have been made: - some improvements on external PE reference handling - a better fix (hopefully) for bug # 549014 - the changes to DefaultHandler calls for DTDs have been undone - I realized that more extensive changes (also to xmlrole.c and xmlrole.h) would be necessary, so the old behaviour is back: everything for DTDs is reported, even if handlers are set, except for PIs, Comments and XML text declarations. This patch now applies to the following bugs: - # 553318 - # 551852 - # 549014 - # 548690 - # 544679 Uploaded as files xmlparse_2.c and xmlparse_2.c.diff. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 13:13 Message: Logged In: YES user_id=290026 I improved the patch to cover one more problem: I found that bug # 551852 (BOM problem with small buffers), that was reported for general external entities, also applied to external parameter entities. This problem only applied to this patch, since the current release of Expat simply ignores external PEs (which causes bug # 548690). Included is also a fix for bug # 549014 (dtdCopy problem). The attached file are xmlparse_1.c, xmlparse_1.c.annotated and xmlparse_1.diff (against rev. 1.31). Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 10:09 Message: Logged In: YES user_id=290026 Forgot to add: the fix for bug # 551852 is included too. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=551599&group_id=10127 From noreply@sourceforge.net Sun May 12 18:28:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun May 12 17:28:02 2002 Subject: [ expat-Patches-551599 ] Patch for # 544679, 548690, 549014, 551852, 553318 Message-ID: Patches item #551599, was opened at 2002-05-02 16:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=551599&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) >Summary: Patch for # 544679, 548690, 549014, 551852, 553318 Initial Comment: This is an extensive patch, and needs not only testing, but also a review by my fellow developers! It addresses these issues: # 483514 (default handler reports too much from DTD): only the following data are reported now: - ignored DTD sections - unhandled external parameter entity references - top level whitespace This may not be what is needed, but more would have been a lot of work # 544679, 548690 (DTD handling of external entities): - the storeEntityValue function has been modified to call the external entity reference handler, since it did not handle external PE references at all - a new STRING_POOL has been added that gets passed from a parent to a child parser (member of DTD structure), so that entity values can be built across parsers - new functions entityValueInitProcessor and entityValueProcessor have been added - the old usage of dtd.complete was completely changed - I never understood how it worked, and it didn't work properly anyway; therefore there is a danger now that some logic will not work anymore - please review and check - the usage of hadExternalDoctype was modified too - there have been changes in xmlrole.c too - the chain of state handlers was extended from entity9 to entity10 - in analogy to how general entities - please review the diff file - as a result, this patch now processes all of James Clark's test cases in the /valid/not-sa and /valid/ext-sa directories properly * I have also made some fixes to the recently introduced XML_ParserReset function (incl. changing it's return type), and one fix that prevents a null pointer error The patch is based on these revisions: - expat.h rev. 1.17 - xmlparse.c rev. 1.31 - xmlrole.c rev. 1.5 - xmlrole.h rev. 1.3 I have included the full patch files, an annotated version of xmlparse.c - good to understand my changes, and the diff files. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-12 20:23 Message: Logged In: YES user_id=290026 There were only a few modifications necessary to make this patch perform well under testing: - It did not compile when XML_DTD was not defined - fixed - forgot to adjust the appendAttribute() function for the modifications in DTD handling logic - fixed This is the final version of the patch - check the new file xmlparse_final.c (and the diff created from it). So, to get the full final patch, download expat.h, xmlrole.h, xmlrole.c and xmlparse_final.c from the set of attached files. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-07 11:53 Message: Logged In: YES user_id=290026 This is the second improvement and probably the final version of the patch. If there should be more changes, a new patch will be entered, since it might get confusing otherwise. The following changes have been made: - some improvements on external PE reference handling - a better fix (hopefully) for bug # 549014 - the changes to DefaultHandler calls for DTDs have been undone - I realized that more extensive changes (also to xmlrole.c and xmlrole.h) would be necessary, so the old behaviour is back: everything for DTDs is reported, even if handlers are set, except for PIs, Comments and XML text declarations. This patch now applies to the following bugs: - # 553318 - # 551852 - # 549014 - # 548690 - # 544679 Uploaded as files xmlparse_2.c and xmlparse_2.c.diff. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 13:13 Message: Logged In: YES user_id=290026 I improved the patch to cover one more problem: I found that bug # 551852 (BOM problem with small buffers), that was reported for general external entities, also applied to external parameter entities. This problem only applied to this patch, since the current release of Expat simply ignores external PEs (which causes bug # 548690). Included is also a fix for bug # 549014 (dtdCopy problem). The attached file are xmlparse_1.c, xmlparse_1.c.annotated and xmlparse_1.diff (against rev. 1.31). Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 10:09 Message: Logged In: YES user_id=290026 Forgot to add: the fix for bug # 551852 is included too. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=551599&group_id=10127 From noreply@sourceforge.net Thu May 16 17:45:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu May 16 16:45:03 2002 Subject: [ expat-Bugs-552297 ] Request for skippedEntity handler Message-ID: Bugs item #552297, was opened at 2002-05-04 13:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=552297&group_id=10127 Category: None >Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) >Assigned to: Karl Waclawek (kwaclaw) Summary: Request for skippedEntity handler Initial Comment: It would be very useful if Expat reported skipped entities, like in the SAX2 specification. I have identified the following situations for that: B) External Entities are reported as skipped: - if no external entity ref handler is set - if the entity ref handler returns a special value (e.g. we can define 2 as meaning: "skip this one") B) Internal Entities are reported as skipped: - SetDefaultHandler was called (which turns off expansion of internal general entities) C) Any entity reference is reported as skipped - if no declaration is found & that is not an error (otherwise return a well-formedness error) Karl ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-16 19:44 Message: Logged In: YES user_id=3066 This feature description and proposed callback interface sounds good to me. We might want to think about how such a handler would interact with (or be combined with) a handler so that defined general entities (including "standard" ones like < and friends) can be reported, for applications that need to produce output with minimal changes. (This is commonly needed if the output is going to land in front of a human rather than another processing tool.) Let's target this for 1.95.4. Assigning to Karl since he's indicated specific interest. ;-) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-09 09:35 Message: Logged In: YES user_id=290026 I propose the following signature for the handler: enum XML_Skip_Reason { XML_SKIP_UNDEFINED, XML_SKIP_NOHANDLER, XML_SKIP_REQUESTED }; typedef void (*XML_SkippedEntityHandler) (void *userData, const XML_Char *entityName, int is_parameter_entity, const XML_Char *systemId, const XML_Char *publicId, enum XML_Skip_Reason skipReason); where the values of skipReason have the following meanings: - XML_SKIP_UNDEFINED: entity was skipped because no declaration was found, and this was not an error - XML_SKIP_NOHANDLER: entity was skipped because there was no ExternalEntityRefHandler installed - XML_SKIP_REQUESTED: the ExternalEntityRefHandler returned a value of 2, which means the handler requested the entity to be skipped I hope this makes sense. Comments welcome! Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=552297&group_id=10127 From noreply@sourceforge.net Thu May 16 20:19:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu May 16 19:19:03 2002 Subject: [ expat-Bugs-453546 ] memmove() segv inside XML_GetBuffer (mod_perl) Message-ID: Bugs item #453546, was opened at 2001-08-20 19:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=453546&group_id=10127 Category: XML::Parser (Perl module) Group: None Status: Open Resolution: None Priority: 2 Submitted By: Bart Schaefer (barts) >Assigned to: Nobody/Anonymous (nobody) Summary: memmove() segv inside XML_GetBuffer (mod_perl) Initial Comment: I do not believe this to be the same bug as 434665. I'm using XML::Parser::EasyTree. I wrote a module that, when perl is run from the shell command line, successfully parses an XML file and interprets the resulting tree. When I use the same module as a mod_perl handler for an upload of exactly the same file, I get a segmentation fault. GDB on a single-threaded httpd shows this to be happening on a memmove() call with dest=0x0, *inside* XML_GetBuffer(). The fix in xmlparse.c rev 1.22 only helps after XML_GetBuffer() returns 0, and I don't get that far. I'm using the 1.95.2-1 RPM on RedHat 6.2 linux, with perl 5.6.0 and XML::Parser both installed using the CPAN shell. I've tried it on two different machines with Apache 1.3.14/ mod_perl 1.24_01 and Apache 1.3.19/mod_perl 1.25, with the same results. If I can come up with a minimal file that reproduces this, I'll attach it to this bug report later. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-16 22:18 Message: Logged In: YES user_id=3066 Is it possible that two copies of Expat are getting loaded? This sounds like a classic problem with Apache and mod_perl; using XML::Parser from mod_perl causes a new copy of Expat to be loaded, even though there's already a copy provided as part of Apache. This situation has been improved in more recent Apache versions (1.3.21 and newer). Does the problem go away with more recent versions of Apache? ---------------------------------------------------------------------- Comment By: Bart Schaefer (barts) Date: 2001-08-20 21:11 Message: Logged In: YES user_id=22647 This appears to be a problem with use of global data that is getting messed up by mod_perl. I converted to a CGI script and it works fine now. I reduced the priority and mentioned mod_perl in the summary. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=453546&group_id=10127 From noreply@sourceforge.net Thu May 16 20:23:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu May 16 19:23:02 2002 Subject: [ expat-Bugs-511175 ] efence catches freeing freed Message-ID: Bugs item #511175, was opened at 2002-01-31 07:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=511175&group_id=10127 Category: XML::Parser (Perl module) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel Horn (hellcatv) >Assigned to: Nobody/Anonymous (nobody) Summary: efence catches freeing freed Initial Comment: I am on an intel pentium III 550 i use expat numerous times in my application vegastrike.sourceforge.net it seems randomly in 10,000 parses of different, short documents I get an error when running efence with set environment EF_PROTECT_FREE 1 no stack is left and it took me about 25 hours to figure out where it was happening I added printf's to almost every line of my code to find this..... but here is what XML_FreeBuffer said your memory management routines are kinda funky though...could it be playing tricks on efence?? anyhow here's the trace of what happens: parser 59358d8 bufget59b61000 parsing.... 59358d8cxml_freefor if (tagstack0==0) TagSTack= freeTagList5935efdc p = tagStack5935efdc Free p->buf59b66fe0 Destroy p->bindings59b66fe0 FREE (p5935ef "`G\021\b\200:\021\b0\035\021\b`T\021\bàP\021\b\220R\021\bp]\021\b°^\021\b\020_\021\b\220_\021\b\220W\021\b\020[\021\b0\\021\bà_\021\bÐV\021\bÀ`\021\b`a\021\b\001", 0x8122ad0 "U\211å\203ì\b\203ì\bÿu\024ÿu\020ÿu\fj", 0x8122b00 "U\211å\203ì\b\203ì\bÿu\024ÿu\020ÿu\fj\001ÿu\bh¬¯\030\bè\037üÿÿ\203Ä \211À\211À\211ì]Ã\215t&", 0x0 , 0x8121560 "U\211å\203ì\bÿu\024ÿu\020ÿu\fh`^\030\bègJÿÿ\203Ä\020\211ì]ÃU\211å\203ì\b\215Eÿ\211Eø\203ì\f\213U\b\213Eø@P\215EøPÿu\020\215E\fPÿu\b\213B<ÿÐ\203Ä \2---Type to continue, or q to quit--- 15Eÿ9Eøu\013¸ÿÿÿÿë\n\215t&", 0x0, 0x0, 0x0, 0x0, 0x600
, 0x56e98e18 "`^\030\bÐ*\022\b", 0x8186160 "`G\021\b\200:\021\dc) for p = tagStack59b6efdc Free p->buf59b70fe0 Destroy p->bindings59b70fe0 FREE (p59b6efdc) for if (tagstack0==0) poolDest (tempPool0) poolDest (temp2Pool0) free (atts5935af00) free (buffer59b61000) ElectricFence Aborting: free(59b61000): freeing free memory. Program received signal SIGILL, Illegal instruction. [Switching to Thread 1024 (LWP 3627)] 0x4018a971 in kill () from /lib/libc.so.6 Current language: auto; currently c (gdb) bt #0 0x4018a971 in kill () from /lib/libc.so.6 #1 0x400ed953 in EF_Abort () from /usr/lib/libefence.so.0 #2 0x40829000 in ?? () this happens very consistently an earlier run (takes about 1 hour of continuous parsing of small files) parscreated at 56e98d8c bufget58c41000ebufget xml_free(56e98d8c) ElectricFence Aborting: free(58c41000): freeing free memory. Program received signal SIGILL, Illegal instruction. 0x4018a971 in ?? () (gdb) (gdb) up #1 0x40829000 in ?? () (gdb) Initial frame selected; you cannot go up. (gdb) down #0 0x4018a971 in ?? () (gdb) Bottom (i.e., innermost) frame selected; you cannot go down. (gdb) print 56e98d8c Invalid number "56e98d8c". (gdb) print 0x56e98d8c $1 = 1458146700 (gdb) print (char *[10])((XML_Parser)0x56e98d8c) Invalid cast. (gdb) print (char *[10])*(char **)((XML_Parser)0x56e98d8c) $9 = {0x56e09fc8 "¤\235#[\003", 0x56e09fc8 "¤\235#[\003", 0x58c41000 "\n", 0x804dd84 "ÿ%\210ê\035\bh`\001", 0x804e244 "ÿ%¸ë\035\bhÀ\003", 0x804e9a4 "ÿ%\220í\035\bhp\a", 0x58c41000 "\n", 0x58c410a5 "", 0x58c45000
, 0xa5
} (gdb) print (char *[100])*(char **)((XML_Parser)0x56e98d8c) $10 = {0x56e09fc8 "¤\235#[\003", 0x56e09fc8 "¤\235#[\003", 0x58c41000 "\n", 0x804dd84 "ÿ%\210ê\035\bh`\001", 0x804e244 "ÿ%¸ë\035\bhÀ\003", 0x804e9a4 "ÿ%\220í\035\bhp\a", 0x58c41000 "\n", 0x58c410a5 "", 0x58c45000
, 0xa5
, 0x58c410a5 "", 0x56e9cc00 "", 0x56e9d000
, 0x8093c00 "U\211å\203ì(\203ì\004ÿu\fhò\215\027\bÿ5ðî\035\bèÈ ûÿ\203Ä\020\203ì\004\203ì\004ÿu\020\215EèPè\237¡üÿ\203Ä\f\215EèPÿu\f\215EØPè,\016\t", 0x8093ce0 "U\211å\203ì\030\203ì\004ÿu\fhú\215\027\bÿ5ðî\035\bèè\237ûÿ\203Ä\020\203ì\bÿu\f\215EèPèb\r\t", 0x0 , 0x56e98d8c "È\237àVÈ\237àV", 0x0, 0x0, 0x0, 0x0, 0x0, 0x8185e60 ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-16 22:22 Message: Logged In: YES user_id=3066 Removed assignment to Clark since he's not longer working on Expat. What version of Expat was being used in the application? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=511175&group_id=10127 From noreply@sourceforge.net Thu May 16 20:24:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu May 16 19:24:02 2002 Subject: [ expat-Bugs-443205 ] XML_UNICODE_WCHAR_T on Unix Message-ID: Bugs item #443205, was opened at 2001-07-20 17:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=443205&group_id=10127 Category: XML::Parser (Perl module) Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Nobody/Anonymous (nobody) Summary: XML_UNICODE_WCHAR_T on Unix Initial Comment: Expat when compiled in wide character mode (using the flag XML_UNICODE_WCHAR_T) on Unix results in "t@1 (l@1) signal BUS (invalid address alignment) in poolStoreString at line 4459 in file xmlparse.c" ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-16 22:23 Message: Logged In: YES user_id=3066 Removed assignment to Clark since he's no longer working on Expat. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-26 17:52 Message: Logged In: NO To answer fdrake question: The platform is unix os on solaris. wchar_t on unix is 4 bytes as opposed to 2 bytes on windows. -- manisha ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-20 22:17 Message: Logged In: YES user_id=3066 We need more specific platform information on this; what hardware and operating system was used? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=443205&group_id=10127 From noreply@sourceforge.net Fri May 17 05:54:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 17 04:54:03 2002 Subject: [ expat-Bugs-505721 ] Parsing valid external DTD fails. Message-ID: Bugs item #505721, was opened at 2002-01-19 06:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=505721&group_id=10127 Category: None >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Parsing valid external DTD fails. Initial Comment: Parsing the following DTD using the XML_ExternalEntityParserCreate call fails with "syntax error" on line 182 column 51. Here's a link to the DTD ... http://xml.coverpages.org/idmef-dtd-200007.txt I've commented out the "" declaration on line 8. Otherwise the entity declararion and entity reference on line 182 appear correct. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-17 07:53 Message: Logged In: YES user_id=3066 Closed based on submitters followup message. ---------------------------------------------------------------------- Comment By: Rick Parrish (rfmobile) Date: 2002-01-19 07:48 Message: Logged In: YES user_id=432137 Oops. Calling XML_SetParamEntityParsing with XML_PARAM_ENTITY_PARSING_ALWAYS fixed this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=505721&group_id=10127 From noreply@sourceforge.net Fri May 17 08:23:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 17 07:23:03 2002 Subject: [ expat-Bugs-469271 ] error on valid entity Message-ID: Bugs item #469271, was opened at 2001-10-08 16:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=469271&group_id=10127 Category: None >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: David Reed (dtreed) Assigned to: Nobody/Anonymous (nobody) Summary: error on valid entity Initial Comment: The library is erroring out on a valid entity "â". It processes the other ones just fine but the outline program that ships in the examples directory outputs the following: Parse error at line 3: undefined entity when a file containing the following is fed into it: lâst <in> help As soon as I take the "â" out, it works just fine. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-17 10:22 Message: Logged In: YES user_id=3066 Agered. Closed due to lack of followup from the submitter. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-09 16:28 Message: Logged In: YES user_id=290026 Where is this entity defined? It is not a predefined entity, so not valid per se. I think this bug report should be closed, unless someone provides an example where acirc is explicitly declared. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=469271&group_id=10127 From noreply@sourceforge.net Fri May 17 09:26:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 17 08:26:04 2002 Subject: [ expat-Bugs-496505 ] checking for malloc failures Message-ID: Bugs item #496505, was opened at 2001-12-24 11:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=496505&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Eric C. Newton (ericnewton) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: checking for malloc failures Initial Comment: expat 1.95.2 (under RedHat linux 2.4) The following code (xmlparse.c:578) will crash, should the malloc() call fail: XML_Memory_Handling_Suite *mtemp; parser = malloc(sizeof(Parser)); mtemp = &(((Parser *) parser)->m_mem); mtemp->malloc_fcn = malloc; Likewise (xmlparse.c:1139) XML_GetBuffer() returns NULL when malloc() fails, and the result is not checked: memcpy(XML_GetBuffer(parser, len), s, len); Other than that, expat works quite well. Very nice library. -Eric ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-17 11:25 Message: Logged In: YES user_id=3066 The unchecked use of the XML_GetBuffer() return value in XML_Parse() was fixed in CVS a while ago, but possibly after this bug report was filed. I've added the remaining MALLOC() and REALLOC() checks in lib/xmlparse.c revisions 1.33 though 1.35. These will be part of the 1.95.3 release. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=496505&group_id=10127 From noreply@sourceforge.net Fri May 17 09:53:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 17 08:53:02 2002 Subject: [ expat-Bugs-477667 ] illegal utf-8 seqs do not throw error Message-ID: Bugs item #477667, was opened at 2001-11-02 17:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=477667&group_id=10127 Category: None Group: None Status: Open Resolution: Works For Me >Priority: 6 Submitted By: Patrick McCormick (patrickmc) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: illegal utf-8 seqs do not throw error Initial Comment: I have a problem where users like to use iso-8859-1 without declaring it in the prolog, like this: abécdef expat properly defaults to utf-8 in this case. As I understand utf-8, the é character (0xE7) has a bitfield that looks like the start of a three byte sequence. A 3-byte sequence is supposed to look like this: bytes | bits | representation 3 | 16 | 1110vvvv 10vvvvvv 10vvvvvv the above two bytes (c and d) don't match the 10vvvvvv mask, so écd is an illegal utf-8 sequence. But expat doesn't throw a well-formedness error. Expat uses this macro in xmltok.c to figure out what's illegal: #define UTF8_INVALID3(p) \ ((*p) == 0xED \ ? (((p)[1] & 0x20) != 0) \ : ((*p) == 0xEF \ ? ((p)[1] == 0xBF && ((p)[2] == 0xBF || (p)[2] == 0xBE)) \ : 0)) but this doesn't seem strict enough. I wrote a patch that makes expat check UTF-8 sequences against the Table 3.1B of the Unicode 3.1 standard: http://www.unicode.org/unicode/reports/tr27/ as originally clarified in this Corrigendum: http://www.unicode.org/unicode/uni2errata/UTF- 8_Corrigendum.html and it's attached. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-17 11:52 Message: Logged In: YES user_id=3066 This is strange. Using the CVS version of Expat, the test case (in tests/runtests.c:test_illegal_utf8) sees the error properly reported. xmlwf doesn't report it, however. Are you using the library directly or going through xmlwf? I'll see what I can figure out. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-09 10:44 Message: Logged In: YES user_id=290026 There is official conversion code at unicode.org. Download the files ConvertUTF.c and ConvertUTF.h from ftp://www.unicode.org/Public/PROGRAMS/CVTUTF/ and then look at the function static Boolean isLegalUTF8(UTF8 *source, int length) Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-09 10:24 Message: Logged In: YES user_id=290026 I can confirm that the current CVS does indeed not report an error against: abécdef Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-08 17:40 Message: Logged In: YES user_id=13222 I'm not happy with closing this bug report without action. Contrary to Fred's test result, I still find, that the described bug is still there (as it was at the time, the bug was reported). I've tested this with the current CVS HEAD. The bug is in deed easly demonstrable with the example out of the bug report. I use: abécdef The third character of the PCDATA is a small e with acute, that's 0xe9 in the iso-8859-1 char table (and the unicode char 00e9), if there may be an encoding problem throu the web interface. xmlwf passes this test file, without any error report, which is, to the best of my knowledge, wrong. rxp and libxml (i.e. xmllint) confirm, that the test file is not proper UTF-8. IHMO, this is a real _crucial_ bug. Please, __Please__, re-check this. rolf ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-19 15:19 Message: Logged In: YES user_id=3066 Added a test (tests/runtests.c revision 1.9) that shows this bug does not exist in the CVS version. You did not state which version of Expat you're using. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=477667&group_id=10127 From noreply@sourceforge.net Fri May 17 10:21:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 17 09:21:02 2002 Subject: [ expat-Bugs-477667 ] illegal utf-8 seqs do not throw error Message-ID: Bugs item #477667, was opened at 2001-11-02 17:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=477667&group_id=10127 Category: None Group: None Status: Open Resolution: Works For Me Priority: 6 Submitted By: Patrick McCormick (patrickmc) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: illegal utf-8 seqs do not throw error Initial Comment: I have a problem where users like to use iso-8859-1 without declaring it in the prolog, like this: abécdef expat properly defaults to utf-8 in this case. As I understand utf-8, the é character (0xE7) has a bitfield that looks like the start of a three byte sequence. A 3-byte sequence is supposed to look like this: bytes | bits | representation 3 | 16 | 1110vvvv 10vvvvvv 10vvvvvv the above two bytes (c and d) don't match the 10vvvvvv mask, so écd is an illegal utf-8 sequence. But expat doesn't throw a well-formedness error. Expat uses this macro in xmltok.c to figure out what's illegal: #define UTF8_INVALID3(p) \ ((*p) == 0xED \ ? (((p)[1] & 0x20) != 0) \ : ((*p) == 0xEF \ ? ((p)[1] == 0xBF && ((p)[2] == 0xBF || (p)[2] == 0xBE)) \ : 0)) but this doesn't seem strict enough. I wrote a patch that makes expat check UTF-8 sequences against the Table 3.1B of the Unicode 3.1 standard: http://www.unicode.org/unicode/reports/tr27/ as originally clarified in this Corrigendum: http://www.unicode.org/unicode/uni2errata/UTF- 8_Corrigendum.html and it's attached. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-17 12:20 Message: Logged In: YES user_id=290026 I am using the library directly - with my own code. Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-17 11:52 Message: Logged In: YES user_id=3066 This is strange. Using the CVS version of Expat, the test case (in tests/runtests.c:test_illegal_utf8) sees the error properly reported. xmlwf doesn't report it, however. Are you using the library directly or going through xmlwf? I'll see what I can figure out. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-09 10:44 Message: Logged In: YES user_id=290026 There is official conversion code at unicode.org. Download the files ConvertUTF.c and ConvertUTF.h from ftp://www.unicode.org/Public/PROGRAMS/CVTUTF/ and then look at the function static Boolean isLegalUTF8(UTF8 *source, int length) Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-09 10:24 Message: Logged In: YES user_id=290026 I can confirm that the current CVS does indeed not report an error against: abécdef Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-08 17:40 Message: Logged In: YES user_id=13222 I'm not happy with closing this bug report without action. Contrary to Fred's test result, I still find, that the described bug is still there (as it was at the time, the bug was reported). I've tested this with the current CVS HEAD. The bug is in deed easly demonstrable with the example out of the bug report. I use: abécdef The third character of the PCDATA is a small e with acute, that's 0xe9 in the iso-8859-1 char table (and the unicode char 00e9), if there may be an encoding problem throu the web interface. xmlwf passes this test file, without any error report, which is, to the best of my knowledge, wrong. rxp and libxml (i.e. xmllint) confirm, that the test file is not proper UTF-8. IHMO, this is a real _crucial_ bug. Please, __Please__, re-check this. rolf ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-19 15:19 Message: Logged In: YES user_id=3066 Added a test (tests/runtests.c revision 1.9) that shows this bug does not exist in the CVS version. You did not state which version of Expat you're using. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=477667&group_id=10127 From noreply@sourceforge.net Fri May 17 10:31:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 17 09:31:02 2002 Subject: [ expat-Bugs-488899 ] Bad pointer from characterData handler Message-ID: Bugs item #488899, was opened at 2001-12-04 09:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=488899&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Plummer (plummpj) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Bad pointer from characterData handler Initial Comment: Expat frequently returns bad data pointers to my handler for XML_SetCharacterDataHandler. I have expat V 1.95.2 installed on a SUN w Solaris 2.5.1. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-17 12:30 Message: Logged In: YES user_id=3066 Your test for a "bad pointer" in Element::copyData() looks strange to me, but there's definately something weird going on. I'll add it to my plate. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=488899&group_id=10127 From noreply@sourceforge.net Fri May 17 10:32:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 17 09:32:02 2002 Subject: [ expat-Bugs-477667 ] illegal utf-8 seqs do not throw error Message-ID: Bugs item #477667, was opened at 2001-11-02 17:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=477667&group_id=10127 Category: None Group: None Status: Open Resolution: Works For Me Priority: 6 Submitted By: Patrick McCormick (patrickmc) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: illegal utf-8 seqs do not throw error Initial Comment: I have a problem where users like to use iso-8859-1 without declaring it in the prolog, like this: abécdef expat properly defaults to utf-8 in this case. As I understand utf-8, the é character (0xE7) has a bitfield that looks like the start of a three byte sequence. A 3-byte sequence is supposed to look like this: bytes | bits | representation 3 | 16 | 1110vvvv 10vvvvvv 10vvvvvv the above two bytes (c and d) don't match the 10vvvvvv mask, so écd is an illegal utf-8 sequence. But expat doesn't throw a well-formedness error. Expat uses this macro in xmltok.c to figure out what's illegal: #define UTF8_INVALID3(p) \ ((*p) == 0xED \ ? (((p)[1] & 0x20) != 0) \ : ((*p) == 0xEF \ ? ((p)[1] == 0xBF && ((p)[2] == 0xBF || (p)[2] == 0xBE)) \ : 0)) but this doesn't seem strict enough. I wrote a patch that makes expat check UTF-8 sequences against the Table 3.1B of the Unicode 3.1 standard: http://www.unicode.org/unicode/reports/tr27/ as originally clarified in this Corrigendum: http://www.unicode.org/unicode/uni2errata/UTF- 8_Corrigendum.html and it's attached. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-17 12:31 Message: Logged In: YES user_id=3066 Ok, I've found a bug in the test case (re-using the parser without resetting it); I've fixed that in my copy and can now reproduce the error. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-17 12:20 Message: Logged In: YES user_id=290026 I am using the library directly - with my own code. Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-17 11:52 Message: Logged In: YES user_id=3066 This is strange. Using the CVS version of Expat, the test case (in tests/runtests.c:test_illegal_utf8) sees the error properly reported. xmlwf doesn't report it, however. Are you using the library directly or going through xmlwf? I'll see what I can figure out. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-09 10:44 Message: Logged In: YES user_id=290026 There is official conversion code at unicode.org. Download the files ConvertUTF.c and ConvertUTF.h from ftp://www.unicode.org/Public/PROGRAMS/CVTUTF/ and then look at the function static Boolean isLegalUTF8(UTF8 *source, int length) Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-09 10:24 Message: Logged In: YES user_id=290026 I can confirm that the current CVS does indeed not report an error against: abécdef Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-08 17:40 Message: Logged In: YES user_id=13222 I'm not happy with closing this bug report without action. Contrary to Fred's test result, I still find, that the described bug is still there (as it was at the time, the bug was reported). I've tested this with the current CVS HEAD. The bug is in deed easly demonstrable with the example out of the bug report. I use: abécdef The third character of the PCDATA is a small e with acute, that's 0xe9 in the iso-8859-1 char table (and the unicode char 00e9), if there may be an encoding problem throu the web interface. xmlwf passes this test file, without any error report, which is, to the best of my knowledge, wrong. rxp and libxml (i.e. xmllint) confirm, that the test file is not proper UTF-8. IHMO, this is a real _crucial_ bug. Please, __Please__, re-check this. rolf ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-19 15:19 Message: Logged In: YES user_id=3066 Added a test (tests/runtests.c revision 1.9) that shows this bug does not exist in the CVS version. You did not state which version of Expat you're using. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=477667&group_id=10127 From noreply@sourceforge.net Fri May 17 10:37:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 17 09:37:01 2002 Subject: [ expat-Bugs-478611 ] expat.h not included in RPMs Message-ID: Bugs item #478611, was opened at 2001-11-06 05:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=478611&group_id=10127 Category: Build control Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: expat.h not included in RPMs Initial Comment: The include file 'expat.h' seems not to be included in the binary releases of expat (at least 1.95.2-1). It will only be installed if you build expat from source. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=478611&group_id=10127 From noreply@sourceforge.net Fri May 17 11:59:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 17 10:59:06 2002 Subject: [ expat-Bugs-477667 ] illegal utf-8 seqs do not throw error Message-ID: Bugs item #477667, was opened at 2001-11-02 17:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=477667&group_id=10127 Category: None Group: None Status: Open Resolution: Works For Me Priority: 6 Submitted By: Patrick McCormick (patrickmc) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: illegal utf-8 seqs do not throw error Initial Comment: I have a problem where users like to use iso-8859-1 without declaring it in the prolog, like this: abécdef expat properly defaults to utf-8 in this case. As I understand utf-8, the é character (0xE7) has a bitfield that looks like the start of a three byte sequence. A 3-byte sequence is supposed to look like this: bytes | bits | representation 3 | 16 | 1110vvvv 10vvvvvv 10vvvvvv the above two bytes (c and d) don't match the 10vvvvvv mask, so écd is an illegal utf-8 sequence. But expat doesn't throw a well-formedness error. Expat uses this macro in xmltok.c to figure out what's illegal: #define UTF8_INVALID3(p) \ ((*p) == 0xED \ ? (((p)[1] & 0x20) != 0) \ : ((*p) == 0xEF \ ? ((p)[1] == 0xBF && ((p)[2] == 0xBF || (p)[2] == 0xBE)) \ : 0)) but this doesn't seem strict enough. I wrote a patch that makes expat check UTF-8 sequences against the Table 3.1B of the Unicode 3.1 standard: http://www.unicode.org/unicode/reports/tr27/ as originally clarified in this Corrigendum: http://www.unicode.org/unicode/uni2errata/UTF- 8_Corrigendum.html and it's attached. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-17 13:58 Message: Logged In: YES user_id=3066 It's not just that the UTF8_INVALID3() macro is wrong, but that it isn't used at all! The macro is referenced from utf8_isInvalid3(), but that function is not referenced. ;-( ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-17 12:31 Message: Logged In: YES user_id=3066 Ok, I've found a bug in the test case (re-using the parser without resetting it); I've fixed that in my copy and can now reproduce the error. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-17 12:20 Message: Logged In: YES user_id=290026 I am using the library directly - with my own code. Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-17 11:52 Message: Logged In: YES user_id=3066 This is strange. Using the CVS version of Expat, the test case (in tests/runtests.c:test_illegal_utf8) sees the error properly reported. xmlwf doesn't report it, however. Are you using the library directly or going through xmlwf? I'll see what I can figure out. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-09 10:44 Message: Logged In: YES user_id=290026 There is official conversion code at unicode.org. Download the files ConvertUTF.c and ConvertUTF.h from ftp://www.unicode.org/Public/PROGRAMS/CVTUTF/ and then look at the function static Boolean isLegalUTF8(UTF8 *source, int length) Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-09 10:24 Message: Logged In: YES user_id=290026 I can confirm that the current CVS does indeed not report an error against: abécdef Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-08 17:40 Message: Logged In: YES user_id=13222 I'm not happy with closing this bug report without action. Contrary to Fred's test result, I still find, that the described bug is still there (as it was at the time, the bug was reported). I've tested this with the current CVS HEAD. The bug is in deed easly demonstrable with the example out of the bug report. I use: abécdef The third character of the PCDATA is a small e with acute, that's 0xe9 in the iso-8859-1 char table (and the unicode char 00e9), if there may be an encoding problem throu the web interface. xmlwf passes this test file, without any error report, which is, to the best of my knowledge, wrong. rxp and libxml (i.e. xmllint) confirm, that the test file is not proper UTF-8. IHMO, this is a real _crucial_ bug. Please, __Please__, re-check this. rolf ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-19 15:19 Message: Logged In: YES user_id=3066 Added a test (tests/runtests.c revision 1.9) that shows this bug does not exist in the CVS version. You did not state which version of Expat you're using. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=477667&group_id=10127 From noreply@sourceforge.net Fri May 17 13:20:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 17 12:20:01 2002 Subject: [ expat-Bugs-477667 ] illegal utf-8 seqs do not throw error Message-ID: Bugs item #477667, was opened at 2001-11-02 14:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=477667&group_id=10127 Category: None Group: None Status: Open Resolution: Works For Me Priority: 6 Submitted By: Patrick McCormick (patrickmc) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: illegal utf-8 seqs do not throw error Initial Comment: I have a problem where users like to use iso-8859-1 without declaring it in the prolog, like this: abécdef expat properly defaults to utf-8 in this case. As I understand utf-8, the é character (0xE7) has a bitfield that looks like the start of a three byte sequence. A 3-byte sequence is supposed to look like this: bytes | bits | representation 3 | 16 | 1110vvvv 10vvvvvv 10vvvvvv the above two bytes (c and d) don't match the 10vvvvvv mask, so écd is an illegal utf-8 sequence. But expat doesn't throw a well-formedness error. Expat uses this macro in xmltok.c to figure out what's illegal: #define UTF8_INVALID3(p) \ ((*p) == 0xED \ ? (((p)[1] & 0x20) != 0) \ : ((*p) == 0xEF \ ? ((p)[1] == 0xBF && ((p)[2] == 0xBF || (p)[2] == 0xBE)) \ : 0)) but this doesn't seem strict enough. I wrote a patch that makes expat check UTF-8 sequences against the Table 3.1B of the Unicode 3.1 standard: http://www.unicode.org/unicode/reports/tr27/ as originally clarified in this Corrigendum: http://www.unicode.org/unicode/uni2errata/UTF- 8_Corrigendum.html and it's attached. ---------------------------------------------------------------------- >Comment By: Patrick McCormick (patrickmc) Date: 2002-05-17 12:18 Message: Logged In: YES user_id=363812 not referenced? sure it is! you have to tap into the crazy zen of expat's vtables-without-C++. look at the struct utf8_encoding. at the bottom, it uses the macro NORMAL_VTABLE(utf8_), which creates a struct entry "utf8_invalid3". the macro IS_INVALID_CHAR turns into a function call to the appropriate utf8_invalidN struct member. at some point the struct members are hooked up to the functions, but I'm not sure where. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-17 10:58 Message: Logged In: YES user_id=3066 It's not just that the UTF8_INVALID3() macro is wrong, but that it isn't used at all! The macro is referenced from utf8_isInvalid3(), but that function is not referenced. ;-( ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-17 09:31 Message: Logged In: YES user_id=3066 Ok, I've found a bug in the test case (re-using the parser without resetting it); I've fixed that in my copy and can now reproduce the error. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-17 09:20 Message: Logged In: YES user_id=290026 I am using the library directly - with my own code. Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-17 08:52 Message: Logged In: YES user_id=3066 This is strange. Using the CVS version of Expat, the test case (in tests/runtests.c:test_illegal_utf8) sees the error properly reported. xmlwf doesn't report it, however. Are you using the library directly or going through xmlwf? I'll see what I can figure out. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-09 07:44 Message: Logged In: YES user_id=290026 There is official conversion code at unicode.org. Download the files ConvertUTF.c and ConvertUTF.h from ftp://www.unicode.org/Public/PROGRAMS/CVTUTF/ and then look at the function static Boolean isLegalUTF8(UTF8 *source, int length) Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-09 07:24 Message: Logged In: YES user_id=290026 I can confirm that the current CVS does indeed not report an error against: abécdef Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-08 14:40 Message: Logged In: YES user_id=13222 I'm not happy with closing this bug report without action. Contrary to Fred's test result, I still find, that the described bug is still there (as it was at the time, the bug was reported). I've tested this with the current CVS HEAD. The bug is in deed easly demonstrable with the example out of the bug report. I use: abécdef The third character of the PCDATA is a small e with acute, that's 0xe9 in the iso-8859-1 char table (and the unicode char 00e9), if there may be an encoding problem throu the web interface. xmlwf passes this test file, without any error report, which is, to the best of my knowledge, wrong. rxp and libxml (i.e. xmllint) confirm, that the test file is not proper UTF-8. IHMO, this is a real _crucial_ bug. Please, __Please__, re-check this. rolf ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-19 12:19 Message: Logged In: YES user_id=3066 Added a test (tests/runtests.c revision 1.9) that shows this bug does not exist in the CVS version. You did not state which version of Expat you're using. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=477667&group_id=10127 From noreply@sourceforge.net Fri May 17 13:25:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 17 12:25:07 2002 Subject: [ expat-Bugs-477667 ] illegal utf-8 seqs do not throw error Message-ID: Bugs item #477667, was opened at 2001-11-02 17:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=477667&group_id=10127 Category: None Group: None Status: Open Resolution: Works For Me Priority: 6 Submitted By: Patrick McCormick (patrickmc) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: illegal utf-8 seqs do not throw error Initial Comment: I have a problem where users like to use iso-8859-1 without declaring it in the prolog, like this: abécdef expat properly defaults to utf-8 in this case. As I understand utf-8, the é character (0xE7) has a bitfield that looks like the start of a three byte sequence. A 3-byte sequence is supposed to look like this: bytes | bits | representation 3 | 16 | 1110vvvv 10vvvvvv 10vvvvvv the above two bytes (c and d) don't match the 10vvvvvv mask, so écd is an illegal utf-8 sequence. But expat doesn't throw a well-formedness error. Expat uses this macro in xmltok.c to figure out what's illegal: #define UTF8_INVALID3(p) \ ((*p) == 0xED \ ? (((p)[1] & 0x20) != 0) \ : ((*p) == 0xEF \ ? ((p)[1] == 0xBF && ((p)[2] == 0xBF || (p)[2] == 0xBE)) \ : 0)) but this doesn't seem strict enough. I wrote a patch that makes expat check UTF-8 sequences against the Table 3.1B of the Unicode 3.1 standard: http://www.unicode.org/unicode/reports/tr27/ as originally clarified in this Corrigendum: http://www.unicode.org/unicode/uni2errata/UTF- 8_Corrigendum.html and it's attached. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-17 15:24 Message: Logged In: YES user_id=3066 Aargh! This is why I hate token pasting! "grep" doesn't like it either. It gets glued in in four "struct normal_encoding" structures statically defined, starting with "utf8_encoding_ns". Ok, I'll keep digging. ---------------------------------------------------------------------- Comment By: Patrick McCormick (patrickmc) Date: 2002-05-17 15:18 Message: Logged In: YES user_id=363812 not referenced? sure it is! you have to tap into the crazy zen of expat's vtables-without-C++. look at the struct utf8_encoding. at the bottom, it uses the macro NORMAL_VTABLE(utf8_), which creates a struct entry "utf8_invalid3". the macro IS_INVALID_CHAR turns into a function call to the appropriate utf8_invalidN struct member. at some point the struct members are hooked up to the functions, but I'm not sure where. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-17 13:58 Message: Logged In: YES user_id=3066 It's not just that the UTF8_INVALID3() macro is wrong, but that it isn't used at all! The macro is referenced from utf8_isInvalid3(), but that function is not referenced. ;-( ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-17 12:31 Message: Logged In: YES user_id=3066 Ok, I've found a bug in the test case (re-using the parser without resetting it); I've fixed that in my copy and can now reproduce the error. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-17 12:20 Message: Logged In: YES user_id=290026 I am using the library directly - with my own code. Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-17 11:52 Message: Logged In: YES user_id=3066 This is strange. Using the CVS version of Expat, the test case (in tests/runtests.c:test_illegal_utf8) sees the error properly reported. xmlwf doesn't report it, however. Are you using the library directly or going through xmlwf? I'll see what I can figure out. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-09 10:44 Message: Logged In: YES user_id=290026 There is official conversion code at unicode.org. Download the files ConvertUTF.c and ConvertUTF.h from ftp://www.unicode.org/Public/PROGRAMS/CVTUTF/ and then look at the function static Boolean isLegalUTF8(UTF8 *source, int length) Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-09 10:24 Message: Logged In: YES user_id=290026 I can confirm that the current CVS does indeed not report an error against: abécdef Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-08 17:40 Message: Logged In: YES user_id=13222 I'm not happy with closing this bug report without action. Contrary to Fred's test result, I still find, that the described bug is still there (as it was at the time, the bug was reported). I've tested this with the current CVS HEAD. The bug is in deed easly demonstrable with the example out of the bug report. I use: abécdef The third character of the PCDATA is a small e with acute, that's 0xe9 in the iso-8859-1 char table (and the unicode char 00e9), if there may be an encoding problem throu the web interface. xmlwf passes this test file, without any error report, which is, to the best of my knowledge, wrong. rxp and libxml (i.e. xmllint) confirm, that the test file is not proper UTF-8. IHMO, this is a real _crucial_ bug. Please, __Please__, re-check this. rolf ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-19 15:19 Message: Logged In: YES user_id=3066 Added a test (tests/runtests.c revision 1.9) that shows this bug does not exist in the CVS version. You did not state which version of Expat you're using. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=477667&group_id=10127 From noreply@sourceforge.net Fri May 17 13:26:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 17 12:26:03 2002 Subject: [ expat-Bugs-477667 ] illegal utf-8 seqs do not throw error Message-ID: Bugs item #477667, was opened at 2001-11-02 14:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=477667&group_id=10127 Category: None Group: None Status: Open Resolution: Works For Me Priority: 6 Submitted By: Patrick McCormick (patrickmc) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: illegal utf-8 seqs do not throw error Initial Comment: I have a problem where users like to use iso-8859-1 without declaring it in the prolog, like this: abécdef expat properly defaults to utf-8 in this case. As I understand utf-8, the é character (0xE7) has a bitfield that looks like the start of a three byte sequence. A 3-byte sequence is supposed to look like this: bytes | bits | representation 3 | 16 | 1110vvvv 10vvvvvv 10vvvvvv the above two bytes (c and d) don't match the 10vvvvvv mask, so écd is an illegal utf-8 sequence. But expat doesn't throw a well-formedness error. Expat uses this macro in xmltok.c to figure out what's illegal: #define UTF8_INVALID3(p) \ ((*p) == 0xED \ ? (((p)[1] & 0x20) != 0) \ : ((*p) == 0xEF \ ? ((p)[1] == 0xBF && ((p)[2] == 0xBF || (p)[2] == 0xBE)) \ : 0)) but this doesn't seem strict enough. I wrote a patch that makes expat check UTF-8 sequences against the Table 3.1B of the Unicode 3.1 standard: http://www.unicode.org/unicode/reports/tr27/ as originally clarified in this Corrigendum: http://www.unicode.org/unicode/uni2errata/UTF- 8_Corrigendum.html and it's attached. ---------------------------------------------------------------------- >Comment By: Patrick McCormick (patrickmc) Date: 2002-05-17 12:25 Message: Logged In: YES user_id=363812 actually NORMAL_VTABLE *initializes* the struct, it doesn't define it; that's done at "struct normal_encoding". so that's how the functions are hooked up. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-17 12:24 Message: Logged In: YES user_id=3066 Aargh! This is why I hate token pasting! "grep" doesn't like it either. It gets glued in in four "struct normal_encoding" structures statically defined, starting with "utf8_encoding_ns". Ok, I'll keep digging. ---------------------------------------------------------------------- Comment By: Patrick McCormick (patrickmc) Date: 2002-05-17 12:18 Message: Logged In: YES user_id=363812 not referenced? sure it is! you have to tap into the crazy zen of expat's vtables-without-C++. look at the struct utf8_encoding. at the bottom, it uses the macro NORMAL_VTABLE(utf8_), which creates a struct entry "utf8_invalid3". the macro IS_INVALID_CHAR turns into a function call to the appropriate utf8_invalidN struct member. at some point the struct members are hooked up to the functions, but I'm not sure where. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-17 10:58 Message: Logged In: YES user_id=3066 It's not just that the UTF8_INVALID3() macro is wrong, but that it isn't used at all! The macro is referenced from utf8_isInvalid3(), but that function is not referenced. ;-( ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-17 09:31 Message: Logged In: YES user_id=3066 Ok, I've found a bug in the test case (re-using the parser without resetting it); I've fixed that in my copy and can now reproduce the error. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-17 09:20 Message: Logged In: YES user_id=290026 I am using the library directly - with my own code. Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-17 08:52 Message: Logged In: YES user_id=3066 This is strange. Using the CVS version of Expat, the test case (in tests/runtests.c:test_illegal_utf8) sees the error properly reported. xmlwf doesn't report it, however. Are you using the library directly or going through xmlwf? I'll see what I can figure out. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-09 07:44 Message: Logged In: YES user_id=290026 There is official conversion code at unicode.org. Download the files ConvertUTF.c and ConvertUTF.h from ftp://www.unicode.org/Public/PROGRAMS/CVTUTF/ and then look at the function static Boolean isLegalUTF8(UTF8 *source, int length) Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-09 07:24 Message: Logged In: YES user_id=290026 I can confirm that the current CVS does indeed not report an error against: abécdef Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-08 14:40 Message: Logged In: YES user_id=13222 I'm not happy with closing this bug report without action. Contrary to Fred's test result, I still find, that the described bug is still there (as it was at the time, the bug was reported). I've tested this with the current CVS HEAD. The bug is in deed easly demonstrable with the example out of the bug report. I use: abécdef The third character of the PCDATA is a small e with acute, that's 0xe9 in the iso-8859-1 char table (and the unicode char 00e9), if there may be an encoding problem throu the web interface. xmlwf passes this test file, without any error report, which is, to the best of my knowledge, wrong. rxp and libxml (i.e. xmllint) confirm, that the test file is not proper UTF-8. IHMO, this is a real _crucial_ bug. Please, __Please__, re-check this. rolf ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-19 12:19 Message: Logged In: YES user_id=3066 Added a test (tests/runtests.c revision 1.9) that shows this bug does not exist in the CVS version. You did not state which version of Expat you're using. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=477667&group_id=10127 From noreply@sourceforge.net Fri May 17 16:03:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 17 15:03:01 2002 Subject: [ expat-Patches-502865 ] cygwin patch not working Message-ID: Patches item #502865, was opened at 2002-01-12 16:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=502865&group_id=10127 Category: Build Control Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Jari Aalto (jaalto) Assigned to: Greg Stein (gstein) Summary: cygwin patch not working Initial Comment: unable to compile under cygwin with the patch :-( Details in separate file ... xmlfile.o(.text+0x4a1):xmlfile.c: undefined reference to `_imp__XML_SetBase' xmlfile.o(.text+0x4da):xmlfile.c: undefined reference to `_imp__XML_ParserFree' xmlfile.o(.text+0x51c):xmlfile.c: undefined reference to `_imp__XML_SetBase' xmlfile.o(.text+0x584):xmlfile.c: undefined reference to `_imp__XML_SetExternalEntityRefHandler' collect2: ld returned 1 exit status make[1]: *** [xmlwf] Error 1 make[1]: Leaving directory `/usr/src/nok/expat- 1.95.2/xmlwf' make: *** [xmlwf] Error 2 //root@W2KPICASSO /usr/src/nok/expat-1.95.2 $ ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2002-05-17 15:02 Message: Logged In: YES user_id=6501 I'll presume that siebenschlaefer has properly addressed the problem: the latest autotools are needed. Closing. If the problem has /not/ been fixed, then this can always be reopened. ---------------------------------------------------------------------- Comment By: Gerrit Haase (siebenschlaefer) Date: 2002-03-02 10:16 Message: Logged In: YES user_id=76037 That is not true!!! Be sure to use all the latest versions of the autotools which are available for Cygwin. Get the patch: http://sourceforge.net/tracker/download.php? group_id=10127&atid=310127&file_id=15738&aid=501295 Unpack expat-1.95.2, unpack the patch, cd expat-1.95.2, patch the sources: $ patch -p1<../expat-cygwin[1].patch patching file `aclocal.m4' patching file `config.h.in' patching file `configure' patching file `configure.in' patching file `conftools/config.guess' patching file `conftools/config.sub' patching file `conftools/ltconfig' patching file `conftools/ltmain.sh' patching file `conftools/missing' patching file `conftools/mkinstalldirs' patching file `lib/Makefile.in' patching file `xmlwf/Makefile.in' Now type in: ./configure make make install Thats it... The part that is failing for you: cd xmlwf && make make[1]: Entering directory `/stuff/xml/expat-1.95.2/xmlwf' gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes - fexceptions -I../lib -c -o xmlwf.o xmlwf.c gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes - fexceptions -I../lib -c -o xmlfile.o xmlfile.c xmlfile.c: In function `processStream': xmlfile.c:149: warning: implicit declaration of function `close' xmlfile.c:153: warning: implicit declaration of function `read' gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes - fexceptions -I../lib -c -o codepage.o codepage.c gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes - fexceptions -I../lib -c -o unixfilemap.o unixfilemap.c gcc -o xmlwf xmlwf.o xmlfile.o codepage.o unixfilemap.o - L../lib/.libs -lexpat make[1]: Leaving directory `/stuff/xml/expat-1.95.2/xmlwf' Gerrit -- =^..^= ---------------------------------------------------------------------- Comment By: Gerrit Haase (siebenschlaefer) Date: 2002-02-17 06:20 Message: Logged In: YES user_id=76037 Make sure you have the latest libtool and autotools and the latest binutils. I used this patch and it builds ok for me... Gerrit -- =^..^= ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=502865&group_id=10127 From noreply@sourceforge.net Fri May 17 18:31:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 17 17:31:02 2002 Subject: [ expat-Patches-501295 ] Cygwin patch (use dynamic library) Message-ID: Patches item #501295, was opened at 2002-01-09 05:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=501295&group_id=10127 Category: Build Control Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Gerrit Haase (siebenschlaefer) Assigned to: Greg Stein (gstein) Summary: Cygwin patch (use dynamic library) Initial Comment: One more try to upload the patchfile. Gerrit ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2002-05-17 17:30 Message: Logged In: YES user_id=6501 I've applied portions of this. Much of it was applied to generated files, so it wasn't needed. But that also means that I might have missed something. Please try the new stuff from CVS or 1.95.3 when it comes out, and file new bugs/patches as appropriate. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-23 20:57 Message: Logged In: YES user_id=3066 Comments from the original patch report, so I can close that one and have this all in one place: ---------------------------------------------------- I figured out that there were some issues with my lightweight patch to build expat on Cygwin with a shared library, so I patched it again, now standard Cygwin libs are created (cygexpat-x.dll) and a standard importlib (libexpat.dll.a) and also a static library (libexpat.a), xmlwf.exe will be linked against the dll. Build just as usual: ./configure make make install puts everything in /usr/local/* Have fun, Gerrit ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-01-09 06:41 Message: Logged In: YES user_id=3066 This goes with SF patch #501294. ---------------------------------------------------------------------- Comment By: Gerrit Haase (siebenschlaefer) Date: 2002-01-09 05:51 Message: Logged In: YES user_id=76037 Where is the uploaded file? G. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=501295&group_id=10127 From noreply@sourceforge.net Fri May 17 18:32:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 17 17:32:02 2002 Subject: [ expat-Patches-515804 ] compile expat-1.95.2 on cygwin (_imp__) Message-ID: Patches item #515804, was opened at 2002-02-11 00:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=515804&group_id=10127 Category: Build Control Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Dmitry Frolov (endsguy) Assigned to: Greg Stein (gstein) Summary: compile expat-1.95.2 on cygwin (_imp__) Initial Comment: When compiling unmodified expat-1.95.2 on cygwin following errors occur: "make[1]: Entering directory `/home/Administrator/expat-1.95.2/xmlwf' gcc -o xmlwf -static xmlwf.o xmlfile.o codepage.o unixfilemap.o -L../lib/.libs - lexpat xmlwf.o: In function `defaultCharacterData': /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:239: undefined reference to `_imp __XML_DefaultCurrent' xmlwf.o: In function `defaultStartElement':" To fix this a small change should be done to expat.h.in. This will cause gcc to link with correct names to the libexpat.a. Apply the patch and see for yourself, this patch has been tested only one one cygwin installation... ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2002-05-17 17:31 Message: Logged In: YES user_id=6501 This patch has been accepted and applied. ---------------------------------------------------------------------- Comment By: Gerrit Haase (siebenschlaefer) Date: 2002-02-17 06:18 Message: Logged In: YES user_id=76037 I sent a new (completer) patch recently here: https://sourceforge.net/tracker/index.php? func=detail&aid=501295&group_id=10127&atid=310127 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=515804&group_id=10127 From noreply@sourceforge.net Fri May 17 18:34:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 17 17:34:01 2002 Subject: [ expat-Bugs-480273 ] Failing to install on Cygwin Message-ID: Bugs item #480273, was opened at 2001-11-09 16:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=480273&group_id=10127 Category: Build control Group: Platform Specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Carlos Araya (elrond25) Assigned to: Greg Stein (gstein) Summary: Failing to install on Cygwin Initial Comment: When trying to build against cygwin 1.3.4 I get the following list of errors: $ make cd lib && make make[1]: Entering directory `/home/Administrator/expat- 1.95.2/lib' /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H - DPACKAGE='"expat"' -DVERS ION='"expat_1.95.2"' -I. -I. -I.. -g -O2 -Wall - Wmissing-prototypes -Wstrict-pr ototypes -fexceptions -c xmlparse.c mkdir .libs gcc -DHAVE_CONFIG_H -DPACKAGE=\expat\ - DVERSION=\expat_1.95.2\ -I. -I. -I.. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes - fexceptions -c xmlparse.c -DPIC -o .libs/xmlparse.lo mv -f .libs/xmlparse.lo xmlparse.o (cd . && ln -s xmlparse.o xmlparse.lo) /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H - DPACKAGE='"expat"' -DVERS ION='"expat_1.95.2"' -I. -I. -I.. -g -O2 -Wall - Wmissing-prototypes -Wstrict-pr ototypes -fexceptions -c xmltok.c rm -f .libs/xmltok.lo gcc -DHAVE_CONFIG_H -DPACKAGE=\expat\ - DVERSION=\expat_1.95.2\ -I. -I. -I.. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes - fexceptions -c xmltok.c -DPIC -o .libs/xmltok.lo mv -f .libs/xmltok.lo xmltok.o (cd . && ln -s xmltok.o xmltok.lo) /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H - DPACKAGE='"expat"' -DVERS ION='"expat_1.95.2"' -I. -I. -I.. -g -O2 -Wall - Wmissing-prototypes -Wstrict-pr ototypes -fexceptions -c xmlrole.c rm -f .libs/xmlrole.lo gcc -DHAVE_CONFIG_H -DPACKAGE=\expat\ - DVERSION=\expat_1.95.2\ -I. -I. -I.. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes - fexceptions -c xmlrole.c -DPIC -o .libs/xmlrole.lo xmlrole.c:7: warning: `RCSId' defined but not used mv -f .libs/xmlrole.lo xmlrole.o (cd . && ln -s xmlrole.o xmlrole.lo) /bin/sh ../libtool --mode=link gcc -version-info 1:0:1 -g -O2 -Wall -Wmissing-p rototypes -Wstrict-prototypes -fexceptions -o libexpat.la -rpath /usr/local/lib xmlparse.lo xmltok.lo xmlrole.lo libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared l ibraries rm - fr .libs/libexpat.la .libs/libexpat.* .libs/libexpat.* ar cru .libs/libexpat.a xmlparse.o xmltok.o xmlrole.o ranlib .libs/libexpat.a creating libexpat.la (cd .libs && rm -f libexpat.la && ln -s ../libexpat.la libexpat.la) make[1]: Leaving directory `/home/Administrator/expat- 1.95.2/lib' cd xmlwf && make make[1]: Entering directory `/home/Administrator/expat- 1.95.2/xmlwf' gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict- prototypes -fexceptions -I../lib -c -o xmlwf.o xmlwf.c gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict- prototypes -fexceptions -I../lib -c -o xmlfile.o xmlfile.c xmlfile.c: In function `processStream': xmlfile.c:149: warning: implicit declaration of function `close' xmlfile.c:153: warning: implicit declaration of function `read' gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict- prototypes -fexceptions -I../lib -c -o codepage.o codepage.c gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict- prototypes -fexceptions -I../lib -c -o unixfilemap.o unixfilemap.c gcc -o xmlwf -static xmlwf.o xmlfile.o codepage.o unixfilemap.o -L../lib/.libs - lexpat xmlwf.o: In function `defaultCharacterData': /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:239: undefined reference to `_imp __XML_DefaultCurrent' xmlwf.o: In function `defaultStartElement': /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:244: undefined reference to `_imp __XML_DefaultCurrent' xmlwf.o: In function `defaultEndElement': /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:249: undefined reference to `_imp __XML_DefaultCurrent' xmlwf.o: In function `defaultProcessingInstruction': /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:254: undefined reference to `_imp __XML_DefaultCurrent' xmlwf.o: In function `metaLocation': /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:283: undefined reference to `_imp __XML_GetBase' /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:286: undefined reference to `_imp __XML_GetCurrentColumnNumber' /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:286: undefined reference to `_imp __XML_GetCurrentLineNumber' /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:286: undefined reference to `_imp __XML_GetCurrentByteCount' /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:286: undefined reference to `_imp __XML_GetCurrentByteIndex' xmlwf.o: In function `metaStartElement': /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:311: undefined reference to `_imp __XML_GetSpecifiedAttributeCount' /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:313: undefined reference to `_imp __XML_GetIdAttributeIndex' xmlwf.o: In function `main': /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:676: undefined reference to `_imp __XML_ParserCreateNS' /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:678: undefined reference to `_imp __XML_ParserCreate' /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:680: undefined reference to `_imp __XML_SetNotStandaloneHandler' /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:681: undefined reference to `_imp __XML_SetParamEntityParsing' /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:686: undefined reference to `_imp __XML_SetElementHandler' /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:687: undefined reference to `_imp __XML_SetCharacterDataHandler' /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:711: undefined reference to `_imp __XML_SetUserData' /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:714: undefined reference to `_imp __XML_UseParserAsHandlerArg' /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:715: undefined reference to `_imp __XML_SetElementHandler' /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:716: undefined reference to `_imp __XML_SetProcessingInstructionHandler' /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:717: undefined reference to `_imp __XML_SetCommentHandler' /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:718: undefined reference to `_imp __XML_SetCdataSectionHandler' /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:719: undefined reference to `_imp __XML_SetCharacterDataHandler' /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:720: undefined reference to `_imp __XML_SetDoctypeDeclHandler' /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:721: undefined reference to `_imp __XML_SetEntityDeclHandler' /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:722: undefined reference to `_imp __XML_SetNotationDeclHandler' /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:723: undefined reference to `_imp __XML_SetNamespaceDeclHandler' /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:727: undefined reference to `_imp __XML_UseParserAsHandlerArg' /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:728: undefined reference to `_imp __XML_SetDefaultHandler' /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:729: undefined reference to `_imp __XML_SetElementHandler' /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:730: undefined reference to `_imp __XML_SetCharacterDataHandler' /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:731: undefined reference to `_imp __XML_SetProcessingInstructionHandler' /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:737: undefined reference to `_imp __XML_SetElementHandler' /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:738: undefined reference to `_imp __XML_SetCharacterDataHandler' /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:740: undefined reference to `_imp __XML_SetProcessingInstructionHandler' /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:746: undefined reference to `_imp __XML_SetUnknownEncodingHandler' /home/Administrator/expat-1.95.2/xmlwf/xmlwf.c:756: undefined reference to `_imp __XML_ParserFree' xmlfile.o: In function `reportError': /home/Administrator/expat-1.95.2/xmlwf/xmlfile.c:48: undefined reference to `_im p__XML_GetErrorCode' /home/Administrator/expat-1.95.2/xmlwf/xmlfile.c:49: undefined reference to `_im p__XML_ErrorString' /home/Administrator/expat-1.95.2/xmlwf/xmlfile.c:51: undefined reference to `_im p__XML_GetCurrentColumnNumber' /home/Administrator/expat-1.95.2/xmlwf/xmlfile.c:51: undefined reference to `_im p__XML_GetCurrentLineNumber' xmlfile.o: In function `processFile': /home/Administrator/expat-1.95.2/xmlwf/xmlfile.c:68: undefined reference to `_im p__XML_Parse' xmlfile.o: In function `externalEntityRefFilemap': /home/Administrator/expat-1.95.2/xmlwf/xmlfile.c:124: undefined reference to `_i mp__XML_ExternalEntityParserCreate' /home/Administrator/expat-1.95.2/xmlwf/xmlfile.c:129: undefined reference to `_i mp__XML_SetBase' /home/Administrator/expat-1.95.2/xmlwf/xmlfile.c:133: undefined reference to `_i mp__XML_ParserFree' xmlfile.o: In function `processStream': /home/Administrator/expat-1.95.2/xmlwf/xmlfile.c:147: undefined reference to `_i mp__XML_GetBuffer' /home/Administrator/expat-1.95.2/xmlwf/xmlfile.c:159: undefined reference to `_i mp__XML_ParseBuffer' xmlfile.o: In function `externalEntityRefStream': /home/Administrator/expat-1.95.2/xmlwf/xmlfile.c:182: undefined reference to `_imp__XML_ExternalEntityParserCreate' /home/Administrator/expat-1.95.2/xmlwf/xmlfile.c:184: undefined reference to `_imp__XML_SetBase' /home/Administrator/expat-1.95.2/xmlwf/xmlfile.c:187: undefined reference to `_imp__XML_ParserFree' xmlfile.o: In function `XML_ProcessFile': /home/Administrator/expat-1.95.2/xmlwf/xmlfile.c:197: undefined reference to `_imp__XML_SetBase' /home/Administrator/expat-1.95.2/xmlwf/xmlfile.c:203: undefined reference to `_imp__XML_SetExternalEntityRefHandler' collect2: ld returned 1 exit status make[1]: *** [xmlwf] Error 1 make[1]: Leaving directory `/home/Administrator/expat- 1.95.2/xmlwf' make: *** [xmlwf] Error 2 Don't know what the problem is and I need to get XML::Parser and other software installed soon ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2002-05-17 17:33 Message: Logged In: YES user_id=6501 Some cygwin fixes have been applied, and will appear in expat 1.95.3. Please try a new copy from CVS, or the upcoming release; reopen if problems persist. ---------------------------------------------------------------------- Comment By: Gerrit Haase (siebenschlaefer) Date: 2001-11-14 16:01 Message: Logged In: YES user_id=76037 Apply my patch and make sure you are using the latest binutils and cygwin 1.3.5 (latest of the latest versions available;) I posted the patch here, (all in one line, please): http://sourceforge.net/tracker/index.php? func=detail&aid=474548&group_id=10127&atid=310127 Gerrit ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=480273&group_id=10127 From noreply@sourceforge.net Fri May 17 18:36:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 17 17:36:01 2002 Subject: [ expat-Bugs-454879 ] Compile of xmlwf fails in cygwin v1.95.2 Message-ID: Bugs item #454879, was opened at 2001-08-24 00:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=454879&group_id=10127 Category: Build control Group: Platform Specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Pabs (pabs3) Assigned to: Greg Stein (gstein) Summary: Compile of xmlwf fails in cygwin v1.95.2 Initial Comment: make.log attached The short of it is that the .o files in the xmlwf dir reference functions in the lib as _imp__, but in the lib (libexpat.a) the functions are named _ & just Probably some gcc flag was omitted from one or the other. Bye, Pabs ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2002-05-17 17:35 Message: Logged In: YES user_id=6501 Some fixes for cygwin have been applied. Please update from CVS or try the upcoming 1.95.3 release; reopen if problems persist. ---------------------------------------------------------------------- Comment By: Gerrit Haase (siebenschlaefer) Date: 2001-11-14 15:54 Message: Logged In: YES user_id=76037 You need to upgrade to the latest available version of cygwin and binutils to use the autoimport feature of ld. Gerrit ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-14 11:19 Message: Logged In: NO Do these solutions create shared libraries? With just the changes below, I'm not getting a .so file -- any advice? ---------------------------------------------------------------------- Comment By: Gerrit Haase (siebenschlaefer) Date: 2001-10-24 10:19 Message: Logged In: YES user_id=76037 I posted the patch here, (all in one line, please): http://sourceforge.net/tracker/index.php? func=detail&aid=454879&group_id=10127&atid=110127 Gerrit ---------------------------------------------------------------------- Comment By: Gerrit Haase (siebenschlaefer) Date: 2001-10-24 09:52 Message: Logged In: YES user_id=76037 Come on, I added a -no-undefined at the link line for libexpat and the dll is build and also xmlwf links o.k. against the dll. Patch: --- lib/Makefile.in.orig Wed Oct 24 18:24:58 2001 +++ lib/Makefile.in Wed Oct 24 18:23:29 2001 @@ -90,7 +90,7 @@ COMPILE = $(CC) $(DEFS) $(INCLUDES) $(CPPFLAGS) $(CFLAGS) LTCOMPILE = $(LIBTOOL) --mode=compile $(CC) $(DEFS) $(INCLUDES) $(CPPFLAGS) $(CFLAGS) CCLD = $(CC) -LINK = $(LIBTOOL) --mode=link $(CCLD) -version-info $(LIBCURRENT):$(LIBREVISION):$(LIBAGE) $(CFLAGS) $(LDFLAGS) -o $@ +LINK = $(LIBTOOL) --mode=link $(CCLD) -no-undefined - version-info $(LIBCURRENT):$(LIBREVISION):$(LIBAGE) $(CFLAGS) $(LDFLAGS) -o $@ DIST_COMMON = Makefile.in Gerrit ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2001-09-13 02:02 Message: Logged In: YES user_id=60314 I can confirm that adding the &&!defined() to the #if line in expat.h.in fixes everything for me on Cygwin, although I tested defined(__CYGWIN__) rather than defined (__CYGWIN32__) (seems more generally useful...?) ---------------------------------------------------------------------- Comment By: Neil Lunn (corrosion) Date: 2001-08-29 04:38 Message: Logged In: YES user_id=78218 Meaning that the above patch should actually be applied to expat.h.in from the source distribution. Could someone confirm the CVS commit? ---------------------------------------------------------------------- Comment By: David Crowley (dcrowley) Date: 2001-08-27 16:29 Message: Logged In: YES user_id=27458 I have this same problem. I had to make a change to expat.h. I fixed it by changing the macro for XMLPARSEAPI. I just added the "&& !defined(__CYGWIN32)". Here it is: #ifndef XMLPARSEAPI # if defined(__declspec) && !defined(__BEOS__) && !defined (__CYGWIN32__) # define XMLPARSEAPI(type) __declspec(dllimport) type __cdecl # else # define XMLPARSEAPI(type) type # endif #endif /* not defined XMLPARSEAPI */ ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-08-26 22:38 Message: Logged In: NO to clarify v1.95.2 is the expat version number ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=454879&group_id=10127 From noreply@sourceforge.net Fri May 17 18:37:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 17 17:37:03 2002 Subject: [ expat-Bugs-553288 ] install expat 1.95.2 on sun os 5.6 Message-ID: Bugs item #553288, was opened at 2002-05-07 07:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=553288&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Anh-Thu Tran (atran4) Assigned to: Nobody/Anonymous (nobody) Summary: install expat 1.95.2 on sun os 5.6 Initial Comment: When I ran make command, nothing happened. It just returned the prompt. I just continued to run make install and got errors: cc -o xmlwf -static xmlwf.o xmlfile.o codepage.o unixfilemap.o -L../lib/.libs -lexpat cc: -a conflicts with -dy. *** Error code 1 make: Fatal error: Command failed for target `xmlwf' Current working directory /tmp/expat-1.95.2/xmlwf *** Error code 1 make: Fatal error: Command failed for target `install' Please help. Thank you. ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2002-05-17 17:36 Message: Logged In: YES user_id=6501 I believe this has been fixed in the CVS version of Expat, and in the upcoming 1.95.3 release. Please try one of those copies, and if problems persist, then reopen this bug. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=553288&group_id=10127 From noreply@sourceforge.net Fri May 17 18:44:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 17 17:44:01 2002 Subject: [ expat-Bugs-495115 ] expat 1.95.2 fails to build on OS X Message-ID: Bugs item #495115, was opened at 2001-12-19 09:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=495115&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.2 fails to build on OS X Initial Comment: Fails on Mac OS X 10.1.1 (Darwin) output: cd xmlwf && make cc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -I../lib -c -o xmlwf.o xmlwf.c cc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -I../lib -c -o xmlfile.o xmlfile.c xmlfile.c: In function `processStream': xmlfile.c:149: warning: implicit declaration of function `close' xmlfile.c:153: warning: implicit declaration of function `read' cc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -I../lib -c -o codepage.o codepage.c cc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -I../lib -c -o unixfilemap.o unixfilemap.c cc -o xmlwf -static xmlwf.o xmlfile.o codepage.o unixfilemap.o -L../lib/.libs -lexpat /usr/bin/ld: can't locate file for: -lcrt0.o make[1]: *** [xmlwf] Error 1 make: *** [xmlwf] Error 2 ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2002-05-17 17:43 Message: Logged In: YES user_id=6501 The build process has been revamped, and the -static stuff no longer exists. Please try a copy from CVS or the upcoming 1.95.3 release; reopen if the problem has not gone away. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=495115&group_id=10127 From noreply@sourceforge.net Fri May 17 18:45:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 17 17:45:01 2002 Subject: [ expat-Bugs-495115 ] expat 1.95.2 fails to build on OS X Message-ID: Bugs item #495115, was opened at 2001-12-19 09:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=495115&group_id=10127 Category: Build control Group: Platform Specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: expat 1.95.2 fails to build on OS X Initial Comment: Fails on Mac OS X 10.1.1 (Darwin) output: cd xmlwf && make cc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -I../lib -c -o xmlwf.o xmlwf.c cc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -I../lib -c -o xmlfile.o xmlfile.c xmlfile.c: In function `processStream': xmlfile.c:149: warning: implicit declaration of function `close' xmlfile.c:153: warning: implicit declaration of function `read' cc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -I../lib -c -o codepage.o codepage.c cc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -I../lib -c -o unixfilemap.o unixfilemap.c cc -o xmlwf -static xmlwf.o xmlfile.o codepage.o unixfilemap.o -L../lib/.libs -lexpat /usr/bin/ld: can't locate file for: -lcrt0.o make[1]: *** [xmlwf] Error 1 make: *** [xmlwf] Error 2 ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2002-05-17 17:44 Message: Logged In: YES user_id=6501 oops. forgot to close :-) ---------------------------------------------------------------------- Comment By: Greg Stein (gstein) Date: 2002-05-17 17:43 Message: Logged In: YES user_id=6501 The build process has been revamped, and the -static stuff no longer exists. Please try a copy from CVS or the upcoming 1.95.3 release; reopen if the problem has not gone away. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=495115&group_id=10127 From noreply@sourceforge.net Fri May 17 18:54:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 17 17:54:02 2002 Subject: [ expat-Bugs-462960 ] configure fails on OSX Message-ID: Bugs item #462960, was opened at 2001-09-19 12:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=462960&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: configure fails on OSX Initial Comment: [mda@IDRG401 expat-1.95.2]$ ./configure -- prefix=/opt creating cache ./config.cache checking host system type... Invalid configuration `unknown-apple-darwin1.3.7': machine `unknown- apple' not recognized checking build system type... Invalid configuration `unknown-apple-darwin1.3.7': machine `unknown- apple' not recognized checking for ranlib... ranlib checking for gcc... no checking for cc... cc checking whether the C compiler (cc ) works... yes checking whether the C compiler (cc ) is a cross- compiler... no checking whether we are using GNU C... yes checking whether cc accepts -g... yes checking for ld used by GCC... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for BSD-compatible nm... /usr/bin/nm -p checking whether ln -s works... yes updating cache ./config.cache ltconfig: you must specify a host type if you use `-- no-verify' Try `ltconfig --help' for more information. configure: error: libtool configure failed [mda@IDRG401 expat-1.95.2]$ ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2002-05-17 17:53 Message: Logged In: YES user_id=6501 Mac OS X is notoriously problematic w.r.t libtool. Even if we generated the scripts with libtool 1.4.2, additional patches are needed. I believe the only answer is that Mac OS X users would need to get the source, install the properly-patched libtool, and run buildconf to generate new config stuff. With some additional work, I think we can get this fixed up, but it'll take some more investigation that I don't have right now. [ I believe the patched libtool stuff has been posted on the 'net by Pier Fumagalli; need to look that up ] ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-10 14:40 Message: Logged In: NO After copying the files from /usr/share/libtool, and also trying to copy the files from an alternate GNU version of libtool that I have, the exact same error results. What now? ---------------------------------------------------------------------- Comment By: Max Horn (fingolfin) Date: 2001-10-31 13:37 Message: Logged In: YES user_id=12935 This problem is due to old version of config.guess and config.sub being used. In OS X, you can usually copy the ones from /usr/share/libtool/ over the ones supplied in the source to be compiled. The package maintainers can easily fix this issue by updating to the latest versions of the files (and/or also to newer version of autoconf/automake) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=462960&group_id=10127 From noreply@sourceforge.net Fri May 17 18:56:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 17 17:56:02 2002 Subject: [ expat-Bugs-432456 ] DLL name 'expat.dll' causes problems Message-ID: Bugs item #432456, was opened at 2001-06-12 09:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=432456&group_id=10127 Category: None Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Kevin Gilpin (kgilpin) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: DLL name 'expat.dll' causes problems Initial Comment: On Win32, when attempting to build the XML::Parser Perl module with expat, the name 'expat.dll' is used by both projects. This causes problems when running XML::Parser, because only one of the 2 dlls can be loaded. By changing the output target of expat to 'libexpat.dll' (and generating and linking against the corresponding libexpat.lib) I was able to get XML::Parser successfully built and running on Win NT. ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2002-05-17 17:55 Message: Logged In: YES user_id=6501 Calling the library expat2.dll would be fine with me. libexpat.dll might also be fine. But also note: *we* are Expat, not the Perl extension. We have more "right" to expat.dll if that is what we choose to do. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-10-01 15:08 Message: Logged In: YES user_id=3066 So this appearantly never worked with Expat 1.95+. Sigh. We could go back to xmlparse.dll I suppose, but I don't really like that. I don't know that we've retained enough compatibility with that. Perhaps "expat2" would be good enough, since the real target right now is a stable Expat 2.0. I'll think about this a little more, but I'd like to have it solved in Expat 1.95.3. Assigning to me since Clark has been abducted by aliens. ---------------------------------------------------------------------- Comment By: Kevin Gilpin (kgilpin) Date: 2001-10-01 14:51 Message: Logged In: YES user_id=44882 The problem is that the Perl extension consists of 2 dlls: 1) the expat DLL, which does not contain any perl references 2) the perl -> expat DLL, which references both the Perl APIs and the Expat APIs Both of these DLLs are called 'expat.dll', which is a problem b/c Windows will cannot tell the difference between them when the Perl program is run ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-10-01 13:26 Message: Logged In: YES user_id=3066 Thinking about this again, I realize I don't know enough about the Perl extension machinery and mod_perl to be sure of this. Is mod_perl providing an expat.dll which is something different, or is it a different version of that mod_perl uses? We need a mod_perl/XML::Parser expert to answer reports like this one! Leaving this one assigned to Clark until we have such a person with available time. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-25 09:39 Message: Logged In: YES user_id=3066 This relates to having multiple versions of the library being made available in the same process. Assigned to Clark since he might have more of the context information related to XML::Parser. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=432456&group_id=10127 From noreply@sourceforge.net Fri May 17 18:59:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 17 17:59:03 2002 Subject: [ expat-Bugs-463928 ] 1.95.2 Cygwin build fails Message-ID: Bugs item #463928, was opened at 2001-09-22 12:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=463928&group_id=10127 Category: Build control Group: Platform Specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jari Aalto (jaalto) Assigned to: Greg Stein (gstein) Summary: 1.95.2 Cygwin build fails Initial Comment: Hi, Is there any chance to get expat compiled under cygwin? http://www.cygwin.com/ I would like to install the Perl XML modules, but they require expat first. If you need help to debug this, I will help gladly. I'm former C++ programmer. Jari.aalto@poboxes.com //root@W2KPICASSO /usr/src/expat-1.95.2 $ CFLAGS=- fexceptions ./configure creating cache ./config.cache checking host system type... i686-pc-cygwin checking build system type... i686-pc-cygwin checking for ranlib... ranlib checking for gcc... gcc checking whether the C compiler (gcc -fexceptions ) works... yes checking whether the C compiler (gcc -fexceptions ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes 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 BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking for dlltool... dlltool checking for as... as checking for objdump... objdump updating cache ./config.cache checking for object suffix... o checking for executable suffix... .exe checking for gcc option to produce PIC... none 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 if gcc static flag -static works... -static checking if the linker (/usr/i686-pc- cygwin/bin/ld.exe) is GNU ld... yes checking whether the linker (/usr/i686-pc- cygwin/bin/ld.exe) supports shared lib raries... yes checking command to parse /usr/bin/nm -B output... ok checking how to hardcode library paths into programs... immediate checking for /usr/i686-pc-cygwin/bin/ld.exe option to reload object files... -r checking dynamic linker characteristics... Win32 ld.exe checking if libtool supports shared libraries... yes checking if package supports dlls... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for objdir... .libs creating libtool loading cache ./config.cache checking for gcc... (cached) gcc checking whether the C compiler (gcc -fexceptions ) works... yes checking whether the C compiler (gcc -fexceptions ) is a cross-compiler... no checking whether we are using GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes checking for a BSD compatible install... /usr/bin/install -c checking how to run the C preprocessor... gcc -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... no checking for memmove... yes checking for bcopy... yes updating cache ./config.cache creating ./config.status creating Makefile creating lib/Makefile creating lib/expat.h creating xmlwf/Makefile creating examples/Makefile creating config.h config.h is unchanged //root@W2KPICASSO /usr/src/expat-1.95.2 $ make cd lib && make make[1]: Entering directory `/usr/src/expat-1.95.2/lib' /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H - DPACKAGE='"expat"' -DVERS ION='"expat_1.95.2"' -I. -I. -I.. -fexceptions -Wall - Wmissing-prototypes -Wstr ict-prototypes -fexceptions -c xmlparse.c rm -f .libs/xmlparse.lo gcc -DHAVE_CONFIG_H -DPACKAGE=\expat\ - DVERSION=\expat_1.95.2\ -I. -I. -I.. -fexceptions -Wall -Wmissing-prototypes -Wstrict- prototypes -fexceptions -c xmlp arse.c -DPIC -o .libs/xmlparse.lo mv -f .libs/xmlparse.lo xmlparse.o (cd . && ln -s xmlparse.o xmlparse.lo) /bin/sh ../libtool --mode=link gcc -version-info 1:0:1 -fexceptions -Wall -Wmis sing-prototypes -Wstrict-prototypes -fexceptions -o libexpat.la -rpath /usr/loc al/lib xmlparse.lo xmltok.lo xmlrole.lo libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared l ibraries rm - fr .libs/libexpat.la .libs/libexpat.* .libs/libexpat.* ar cru .libs/libexpat.a xmlparse.o xmltok.o xmlrole.o ranlib .libs/libexpat.a creating libexpat.la (cd .libs && rm -f libexpat.la && ln -s ../libexpat.la libexpat.la) make[1]: Leaving directory `/usr/src/expat-1.95.2/lib' cd xmlwf && make make[1]: Entering directory `/usr/src/expat- 1.95.2/xmlwf' gcc -o xmlwf -static xmlwf.o xmlfile.o codepage.o unixfilemap.o -L../lib/.libs - lexpat xmlwf.o(.text+0x914):xmlwf.c: undefined reference to `_imp__XML_DefaultCurrent' xmlwf.o(.text+0x934):xmlwf.c: undefined reference to `_imp__XML_DefaultCurrent' xmlwf.o(.text+0x954):xmlwf.c: undefined reference to `_imp__XML_DefaultCurrent' xmlwf.o(.text+0x974):xmlwf.c: undefined reference to `_imp__XML_DefaultCurrent' xmlwf.o(.text+0xa3c):xmlwf.c: undefined reference to `_imp__XML_GetBase' xmlwf.o(.text+0xa76):xmlwf.c: undefined reference to `_imp__XML_GetCurrentColumn Number' xmlwf.o(.text+0xa8b):xmlwf.c: undefined reference to `_imp__XML_GetCurrentLineNu mber' xmlwf.o(.text+0xaa0):xmlwf.c: undefined reference to `_imp__XML_GetCurrentByteCo unt' xmlwf.o(.text+0xab5):xmlwf.c: undefined reference to `_imp__XML_GetCurrentByteIn dex' xmlwf.o(.text+0xbc0):xmlwf.c: undefined reference to `_imp__XML_GetSpecifiedAttr ibuteCount' xmlwf.o(.text+0xbe3):xmlwf.c: undefined reference to `_imp__XML_GetIdAttributeIn dex' xmlwf.o(.text+0x1bef):xmlwf.c: undefined reference to `_imp__XML_ParserCreateNS' xmlwf.o(.text+0x1c09):xmlwf.c: undefined reference to `_imp__XML_ParserCreate' xmlwf.o(.text+0x1c2b):xmlwf.c: undefined reference to `_imp__XML_SetNotStandalon eHandler' xmlwf.o(.text+0x1c41):xmlwf.c: undefined reference to `_imp__XML_SetParamEntityP arsing' xmlwf.o(.text+0x1c6a):xmlwf.c: undefined reference to `_imp__XML_SetElementHandl ... xmlwf.o(.text+0x207b):xmlwf.c: undefined reference to `_imp__XML_ParserFree' xmlfile.o(.text+0x38):xmlfile.c: undefined reference to `_imp__XML_GetErrorCode' xmlfile.o(.text+0x4d):xmlfile.c: undefined reference to `_imp__XML_ErrorString' xmlfile.o(.text+0x71):xmlfile.c: undefined reference to `_imp__XML_GetCurrentCol umnNumber' xmlfile.o(.text+0x86):xmlfile.c: undefined reference to `_imp__XML_GetCurrentLin eNumber' xmlfile.o(.text+0x100):xmlfile.c: undefined reference to `_imp__XML_Parse' xmlfile.o(.text+0x242):xmlfile.c: undefined reference to `_imp__XML_ExternalEnti tyParserCreate' xmlfile.o(.text+0x285):xmlfile.c: undefined reference to `_imp__XML_SetBase' xmlfile.o(.text+0x2cb):xmlfile.c: undefined reference to `_imp__XML_ParserFree' xmlfile.o(.text+0x346):xmlfile.c: undefined reference to `_imp__XML_GetBuffer' xmlfile.o(.text+0x3ec):xmlfile.c: undefined reference to `_imp__XML_ParseBuffer' xmlfile.o(.text+0x46a):xmlfile.c: undefined reference to `_imp__XML_ExternalEnti tyParserCreate' xmlfile.o(.text+0x4a1):xmlfile.c: undefined reference to `_imp__XML_SetBase' xmlfile.o(.text+0x4da):xmlfile.c: undefined reference to `_imp__XML_ParserFree' xmlfile.o(.text+0x51c):xmlfile.c: undefined reference to `_imp__XML_SetBase' xmlfile.o(.text+0x584):xmlfile.c: undefined reference to `_imp__XML_SetExternalE ntityRefHandler' collect2: ld returned 1 exit status make[1]: *** [xmlwf] Error 1 make[1]: Leaving directory `/usr/src/expat- 1.95.2/xmlwf' make: *** [xmlwf] Error 2 //root@W2KPICASSO /usr/src/expat-1.95.2 $ ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2002-05-17 17:58 Message: Logged In: YES user_id=6501 Patches have been applied for cygwin compilation. Please try a copy from CVS for the upcoming 1.95.3 release; reopen if problems persist. ---------------------------------------------------------------------- Comment By: Gerrit Haase (siebenschlaefer) Date: 2002-02-17 06:17 Message: Logged In: YES user_id=76037 I sent a new (completer) patch recently here: https://sourceforge.net/tracker/index.php? func=detail&aid=501295&group_id=10127&atid=310127 ---------------------------------------------------------------------- Comment By: Jari Aalto (jaalto) Date: 2002-02-05 14:42 Message: Logged In: YES user_id=65014 Fellow cygwin user sent a full package that compiles fine, so here is patch against the full expat tar.gz tree. ---------------------------------------------------------------------- Comment By: Jari Aalto (jaalto) Date: 2002-02-05 13:05 Message: Logged In: YES user_id=65014 One clarification: After I applied the Gerrit's patch (-no-undefined) the compilation error still persists and the program does not compile under cygwin. Any progress on this? ---------------------------------------------------------------------- Comment By: Gerrit Haase (siebenschlaefer) Date: 2001-10-24 10:19 Message: Logged In: YES user_id=76037 I posted the patch here, (all in one line, please): http://sourceforge.net/tracker/index.php? func=detail&aid=454879&group_id=10127&atid=110127 Gerrit ---------------------------------------------------------------------- Comment By: Gerrit Haase (siebenschlaefer) Date: 2001-10-24 09:50 Message: Logged In: YES user_id=76037 There is not much to do, a little change in the lib/Makefile.in and the expat-x.dll is build properly (I used the latest autotools of today, libtool-1.4.2, autoconf- 2.52, automake-1.5), here the patch (I added just -no- undefined at the link line): --- lib/Makefile.in.orig Wed Oct 24 18:24:58 2001 +++ lib/Makefile.in Wed Oct 24 18:23:29 2001 @@ -90,7 +90,7 @@ COMPILE = $(CC) $(DEFS) $(INCLUDES) $(CPPFLAGS) $(CFLAGS) LTCOMPILE = $(LIBTOOL) --mode=compile $(CC) $(DEFS) $(INCLUDES) $(CPPFLAGS) $(CFLAGS) CCLD = $(CC) -LINK = $(LIBTOOL) --mode=link $(CCLD) -version-info $(LIBCURRENT):$(LIBREVISION):$(LIBAGE) $(CFLAGS) $(LDFLAGS) -o $@ +LINK = $(LIBTOOL) --mode=link $(CCLD) -no-undefined - version-info $(LIBCURRENT):$(LIBREVISION):$(LIBAGE) $(CFLAGS) $(LDFLAGS) -o $@ DIST_COMMON = Makefile.in ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=463928&group_id=10127 From noreply@sourceforge.net Fri May 17 19:06:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 17 18:06:04 2002 Subject: [ expat-Bugs-538445 ] cc: -a conflicts with -dy Message-ID: Bugs item #538445, was opened at 2002-04-02 13:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=538445&group_id=10127 Category: Build control Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: cc: -a conflicts with -dy Initial Comment: I am trying to build expat on a sun solaris system and I get the following error during the build. cc: -a conflicts with -dy I used the --prefix option during the ./configure execution. Everything else was done just as the documentation suggested. Any help would be much appreciated. Thank you. ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2002-05-17 18:05 Message: Logged In: YES user_id=6501 duplicate of 553288 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-04-25 18:30 Message: Logged In: NO Isn't cc -flags shows: -d[y|n] dynamic [-dy] or static [-dn] option to linker I simply changed -static to -dn and it worked fine man ld shows-a In static mode only, produces an executable object file; gives errors for undefined references. This is the default behavior for static mode. -a may not be used with the -r option. -d y | n When -d y, the default, is specified, ld uses dynamic linking; when -d n is specified, ld uses static link- ing. See also -B dynamic|static. ---------------------------------------------------------------------- Comment By: Mathew Bevilacqua (matbev1) Date: 2002-04-02 14:40 Message: Logged In: YES user_id=501365 I, too, followed the instructions exactly, and some more tweaking was needed. For my build to work, I had to: 1. make sure that LIBTOOL in the makefile in /lib was set correctly 2. build as a super user Also, you could try removing -dy. It's just a debug utility. From noreply@sourceforge.net Fri May 17 19:21:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 17 18:21:01 2002 Subject: [ expat-Bugs-414993 ] xmlfile.obj : error LNK2001: unresolved Message-ID: Bugs item #414993, was opened at 2001-04-09 13:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=414993&group_id=10127 Category: Build control Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: xmlfile.obj : error LNK2001: unresolved Initial Comment: I'm unable to resolve this problem. I don't which file is missing for this error to show up. Here is a sample of the error message. I am compiling with MS VC++ 6.0. I am attempting to create the perl module that incorporates expat. The Perl version is 5.005-3 from ActiveState. Expat.obj : error LNK2001: unresolved external symbol _XML_DefaultCurrent Expat.obj : error LNK2001: unresolved external symbol _XML_GetSpecifiedAttributeCount Expat.obj : error LNK2001: unresolved external symbol _XML_GetCurrentByteCount Expat.obj : error LNK2001: unresolved external symbol _XML_SetStartCdataSectionHandler Expat.obj : error LNK2001: unresolved external symbol _XML_SetEndCdataSectionHandler ..\blib\arch\auto\XML\Parser\Expat\Expat.dll : fatal error LNK1120: 55 unresolved externals NMAKE : fatal error U1077: 'link' : return code '0x460' Stop. NMAKE : fatal error U1077: 'cd' : return code '0x2' Stop. ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2002-05-17 18:20 Message: Logged In: YES user_id=6501 This is a problem with the Perl wrappers, not Expat itself. Closing as invalid. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-03-12 05:51 Message: Logged In: NO Hi, I have a similar problem. I would like to run the outline.c file that is given as an example with the expat documentation. I include (I first had to add expat.h to my library, and also xmlparse.h that is used in the c-program) With compiling, everything goes great, (no problems), but to execute it, I receive the following errors: outline.obj : error LNK2001: unresolved external symbol __imp__XML_GetCurrentLineNumber outline.obj : error LNK2001: unresolved external symbol __imp__XML_ErrorString outline.obj : error LNK2001: unresolved external symbol __imp__XML_GetErrorCode outline.obj : error LNK2001: unresolved external symbol __imp__XML_Parse outline.obj : error LNK2001: unresolved external symbol __imp__XML_SetElementHandler outline.obj : error LNK2001: unresolved external symbol __imp__XML_ParserCreate Debug/outline.exe : fatal error LNK1120: 6 unresolved externals Error executing link.exe. outline.exe - 7 error(s), 0 warning(s) I have version 1.95.2 greetings and thanks for your help. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-20 20:56 Message: Logged In: YES user_id=3066 Which version of expat was this using? 1.95.x, or the latest CVS sources? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=414993&group_id=10127 From noreply@sourceforge.net Fri May 17 19:23:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 17 18:23:02 2002 Subject: [ expat-Bugs-532407 ] Can't compile 1.95.2 on SCO OpenServer Message-ID: Bugs item #532407, was opened at 2002-03-20 02:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=532407&group_id=10127 Category: Build control Group: Platform Specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Can't compile 1.95.2 on SCO OpenServer Initial Comment: I can't compile expat 1.95.2 on SCO openserver . 'make' does nothing. I can't check out CVS version because of a firewall. How can I do? see below for details expat-1.95.2 $ ./configure creating cache ./config.cache checking host system type... i686-pc-sco3.2v5.0.6 checking build system type... i686-pc-sco3.2v5.0.6 checking for ranlib... : checking for gcc... no checking for cc... cc checking whether the C compiler (cc ) works... yes checking whether the C compiler (cc ) is a cross-compiler... no checking whether we are using GNU C... no checking whether cc accepts -g... yes checking for non-GNU ld... /bin/ld checking if the linker (/bin/ld) is GNU ld... no checking for BSD-compatible nm... /bin/nm -p checking whether ln -s works... yes checking whether the C compiler needs -belf... yes updating cache ./config.cache 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... -Kpic checking if cc PIC flag -Kpic works... yes checking if cc supports -c -o file.o... yes checking if cc supports -c -o file.lo... yes ltconfig: warning: `cc' requires `-belf' to build shared libraries checking if cc static flag -dn works... -dn checking if the linker (/bin/ld) is GNU ld... no checking whether the linker (/bin/ld) supports shared libraries... yes checking command to parse /bin/nm -p output... ok checking how to hardcode library paths into programs... immediate checking for /bin/ld option to reload object files... -r checking dynamic linker characteristics... sco3.2v5.0.6 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 loading cache ./config.cache checking for gcc... (cached) cc checking whether the C compiler (cc -g -belf ) works... yes checking whether the C compiler (cc -g -belf ) 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/bin/X11/scoinst -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... no checking for memmove... yes checking for bcopy... yes updating cache ./config.cache creating ./config.status creating Makefile creating lib/Makefile creating lib/expat.h creating xmlwf/Makefile creating examples/Makefile creating config.h expat-1.95.2 $ make expat-1.95.2 $ cd lib expat-1.95.2/lib $ make /bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -DPACKAGE='"expat"' -DVERSION='"expat_1.95.2"' -I. -I. -I.. -g -belf -c xmlparse.c mkdir .libs cc -DHAVE_CONFIG_H -DPACKAGE=\expat\ -DVERSION=\expat_1.95.2\ -I. -I. -I.. -g -belf -c xmlparse.c -Kpic -DPIC -o .libs/xmlparse.lo cc -DHAVE_CONFIG_H -DPACKAGE=\expat\ -DVERSION=\expat_1.95.2\ -I. -I. -I.. -g -belf -c xmlparse.c -o xmlparse.o >/dev/null 2>&1 mv -f .libs/xmlparse.lo xmlparse.lo /bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -DPACKAGE='"expat"' -DVERSION='"expat_1.95.2"' -I. -I. -I.. -g -belf -c xmltok.c rm -f .libs/xmltok.lo cc -DHAVE_CONFIG_H -DPACKAGE=\expat\ -DVERSION=\expat_1.95.2\ -I. -I. -I.. -g -belf -c xmltok.c -Kpic -DPIC -o .libs/xmltok.lo cc -DHAVE_CONFIG_H -DPACKAGE=\expat\ -DVERSION=\expat_1.95.2\ -I. -I. -I.. -g -belf -c xmltok.c -o xmltok.o >/dev/null 2>&1 mv -f .libs/xmltok.lo xmltok.lo /bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -DPACKAGE='"expat"' -DVERSION='"expat_1.95.2"' -I. -I. -I.. -g -belf -c xmlrole.c rm -f .libs/xmlrole.lo cc -DHAVE_CONFIG_H -DPACKAGE=\expat\ -DVERSION=\expat_1.95.2\ -I. -I. -I.. -g -belf -c xmlrole.c -Kpic -DPIC -o .libs/xmlrole.lo cc -DHAVE_CONFIG_H -DPACKAGE=\expat\ -DVERSION=\expat_1.95.2\ -I. -I. -I.. -g -belf -c xmlrole.c -o xmlrole.o >/dev/null 2>&1 mv -f .libs/xmlrole.lo xmlrole.lo /bin/sh ../libtool --mode=link cc -version-info 1:0:1 -g -belf -o libexpat.la -rpath /usr/local/lib xmlparse.lo xmltok.lo xmlrole.lo rm -fr .libs/libexpat.la .libs/libexpat.* .libs/libexpat.* /bin/ld -G -h libexpat.so0 -o .libs/libexpat.so.1.1.0 xmlparse.lo xmltok.lo xmlrole.lo (cd .libs && rm -f libexpat.so0 && ln -s libexpat.so.1.1.0 libexpat.so0) (cd .libs && rm -f libexpat.so && ln -s libexpat.so.1.1.0 libexpat.so) ar cru .libs/libexpat.a xmlparse.o xmltok.o xmlrole.o : .libs/libexpat.a creating libexpat.la (cd .libs && rm -f libexpat.la && ln -s ../libexpat.la libexpat.la) expat-1.95.2/lib $ cd ../xmlwf expat-1.95.2/xmlwf $ make cc -g -belf -I../lib -c xmlwf.c cc -g -belf -I../lib -c xmlfile.c cc -g -belf -I../lib -c codepage.c cc -g -belf -I../lib -c unixfilemap.c cc -o xmlwf -static xmlwf.o xmlfile.o codepage.o unixfilemap.o -L../lib/.libs -lexpat error: unknown -a option: tic *** Error code 1 (bu21) expat-1.95.2/xmlwf $ cd ../examples expat-1.95.2/examples $ make cc -g -belf -I../lib -c elements.c cc -o elements -static -L../lib/.libs -lexpat error: unknown -a option: tic *** Error code 1 (bu21) ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2002-05-17 18:22 Message: Logged In: YES user_id=6501 We've removed the -static option in the current CVS. Please try again with the latest CVS or with the upcoming 1.95.3 release. Reopen if problems persist. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-07 08:59 Message: Logged In: YES user_id=3066 You note that you can't checkout from CVS and ask what you can do, but I don't see an email address. I'll be glad to package a copy based on the current state of CVS, but don't know where to send it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=532407&group_id=10127 From noreply@sourceforge.net Fri May 17 19:25:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 17 18:25:01 2002 Subject: [ expat-Bugs-497193 ] xmlparse.c compile failure on Windows Message-ID: Bugs item #497193, was opened at 2001-12-27 16:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=497193&group_id=10127 Category: Build control Group: Platform Specific >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Mike Brown (mike_j_brown) Assigned to: Greg Stein (gstein) Summary: xmlparse.c compile failure on Windows Initial Comment: I encountered the following error while trying to build PyXML-0.7.0 from source on Windows 2000, with Python 2.1.1 installed. I didn't get this error when trying to build under Python 2.2. I am using Visual C 98. building '_xmlplus.parsers.pyexpat' extension creating build\temp.win32-2.1 creating build\temp.win32-2.1\Release C:\_Apps\VisualC\VC98 \Bin\cl.exe /c /nologo /Ox /MD /W3 /GX -DHAVE_EXPAT_H - DVERSION="1.95.2" -DXML_NS=1 -DXML_DTD=1 - DXML_BYTE_ORDER=12 -DXML_CONTEXT_BYTES=1024 - Iextensions/expat/lib -IC:\Python21 \Include /Tcextensions/pyexpat.c /Fobuild\temp.win32- 2.1\Release\pyexpat.obj pyexpat.c C:\_Apps\VisualC\VC98 \Bin\cl.exe /c /nologo /Ox /MD /W3 /GX -DHAVE_EXPAT_H - DVERSION="1.95.2" -DXML_NS=1 -DXML_DTD=1 - DXML_BYTE_ORDER=12 -DXML_CONTEXT_BYTES=1024 - Iextensions/expat/lib -IC:\Python21 \Include /Tcextensions/expat/lib/xmlparse.c /Fobuild\te mp.win32-2.1\Release\xmlparse.obj xmlparse.c extensions/expat/lib/xmlparse.c(1329) : error C2143: syntax error : missing ';' before 'constant' extensions/expat/lib/xmlparse.c(1329) : error C2115: 'return' : incompatible types error: command 'cl.exe' failed with exit status 2 ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2002-05-17 18:24 Message: Logged In: YES user_id=6501 Closing; as the author states, this was filed against the wrong project. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2001-12-27 16:22 Message: Logged In: YES user_id=371366 Sorry; I meant to post this to the PyXML project. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=497193&group_id=10127 From noreply@sourceforge.net Fri May 17 19:26:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 17 18:26:01 2002 Subject: [ expat-Bugs-487385 ] Expat.obj : error LNK2001: Message-ID: Bugs item #487385, was opened at 2001-11-29 21:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=487385&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Expat.obj : error LNK2001: Initial Comment: I am trying to install XML::Parser which uses Expat. I installes expat using expat_win32bin_1_95_2.exe. When I try to build XML::Parser, I get a few errors(Error message given Below). I am using Microsoft VC++ Version 6.0 to compile. Perl was built from Source(Version 5.6.1) and is not activestte perl. What could be wrong?? Error Message: Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. cl -c -nologo -O1 -MD -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -DPERL_MSVCRT_READFIX -O1 -MD -DNDEBUG -DVERSION=\2.30\ -DXS_VERSION=\2.30\ -ID:\perl\5.6.1\lib\MSWin32-x86\ Expat.c "Running Mkbootstrap for XML::Parser::Expat ()" D:\perl\5.6.1\bin\MSWin32-x86\perl.exe -Id:\perl\5.6.1\lib\MSWin32-x86 -Id:\perl\5.6.1\lib -MExtUtils::Command -e chmod 644 Expat.bs link -out:..\blib\arch\auto\XML\Parser\Expat\Expat.dll -dll -nologo -nodefaultlib -release -libpath:"d:\perl\5.6.1\lib\MSWin32-x86\CORE" -machine:x86 Expat.obj D:\perl\5.6.1\li ~1\MICROS~3\VC98\lib\advapi32.lib C:\PROGRA~1\MICROS~3\VC98\lib\shell32.lib C:\PROGRA~1\MICROS~3\VC98\lib\ole32.lib C:\PROGRA~1\MICROS~3\VC98\lib\oleaut32.lib C:\PROGRA~1\MICROS~3\VC98\lib 32.lib C:\PROGRA~1\MICROS~3\VC98\lib\msvcrt.lib -def:Expat.def Creating library ..\blib\arch\auto\XML\Parser\Expat\Expat.lib and object ..\blib\arch\auto\XML\Parser\Expat\Expat.exp Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetParamEntityParsing Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetUnknownEncodingHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetElementHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetUserData Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetNamespaceDeclHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_ParserCreate_MM Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetExternalEntityRefHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetNotationDeclHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetUnparsedEntityDeclHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetCdataSectionHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetCommentHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetProcessingInstructionHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetCharacterDataHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_ParserFree Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetBase Expat.obj : error LNK2001: unresolved external symbol __imp__XML_GetBase Expat.obj : error LNK2001: unresolved external symbol __imp__XML_ExternalEntityParserCreate Expat.obj : error LNK2001: unresolved external symbol __imp__XML_GetCurrentLineNumber Expat.obj : error LNK2001: unresolved external symbol __imp__XML_GetCurrentColumnNumber Expat.obj : error LNK2001: unresolved external symbol __imp__XML_GetCurrentByteIndex Expat.obj : error LNK2001: unresolved external symbol __imp__XML_ErrorString Expat.obj : error LNK2001: unresolved external symbol __imp__XML_GetErrorCode Expat.obj : error LNK2001: unresolved external symbol __imp__XML_Parse Expat.obj : error LNK2001: unresolved external symbol __imp__XML_ParseBuffer Expat.obj : error LNK2001: unresolved external symbol __imp__XML_GetBuffer ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2002-05-17 18:25 Message: Logged In: YES user_id=6501 This is a problem with the Perl module, not Expat. Closing as invalid. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=487385&group_id=10127 From noreply@sourceforge.net Fri May 17 19:52:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 17 18:52:03 2002 Subject: [ expat-Patches-502187 ] How to build Expat-1.95.2 on OS X 10.1.2 Message-ID: Patches item #502187, was opened at 2002-01-10 20:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=502187&group_id=10127 Category: Build Control Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: How to build Expat-1.95.2 on OS X 10.1.2 Initial Comment: How to build expat-1.95.2 on OS X 10.1.2 - Joel Rodrigues 1. username% tar -zxvf expat-1.95.2.tar.gz 2. cd expat-1.95.2 3. cp /usr/share/libtool/config.guess conftools/config.guess cp /usr/share/libtool/config.sub conftools/config.sub cp /usr/share/libtool/ltconfig conftools/ltconfig cp /usr/share/libtool/ltmain.sh conftools/ltmain.sh 4. Change line 1375 of conftools/Itconfig to read like so : darwin* | rhapsody*) allow_undefined_flag='-undefined warning -flat_namespace' 5. In xmlwf/Makefile.in change "LDFLAGS = @LDFLAGS@ -static" to "LDFLAGS = @LDFLAGS@ -dynamic" 6. Make the same change in examples/makefile.in : "LDFLAGS = @LDFLAGS@ -static" to "LDFLAGS = @LDFLAGS@ -dynamic" 7. Run the following commands : ./configure make make check sudo make install 8. You should see the foll. in the subsequent output : ---------------------------------------------------------------------- Libraries have been installed in: /usr/local/lib If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `DYLD_LIBRARY_PATH' environment variable during execution usage: basename string [suffix] - use the `-install_name LIBDIR/' linker flag See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. ---------------------------------------------------------------------- Cheers ! ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2002-05-17 18:51 Message: Logged In: YES user_id=6501 libtool is simply whacked on Mac OS X. We've got some work to get things working properly. Some of the above problems have been resolve (e.g. we don't use -static any more). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-03-06 17:37 Message: Logged In: NO Me too. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-02-16 13:02 Message: Logged In: NO This does not work.. I get the following errors: /usr/bin/libtool: file: xmltok.lo is not an object file (not allowed in a library) /usr/bin/libtool: file: xmlrole.lo is not an object file (not allowed in a library) make[1]: *** [libexpat.la] Error 1 make: *** [lib] Error 2 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=502187&group_id=10127 From noreply@sourceforge.net Fri May 17 20:21:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 17 19:21:02 2002 Subject: [ expat-Bugs-557530 ] Cygwin install fails Message-ID: Bugs item #557530, was opened at 2002-05-17 21:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=557530&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Chad Austin (aegis) Assigned to: Greg Stein (gstein) Summary: Cygwin install fails Initial Comment: Building expat within Cygwin succeeds now, but 'make install' fails. $ gmake install /bin/sh ./conftools/mkinstalldirs /usr/local/bin /usr/local/lib /usr/local/inclu de /bin/sh ./libtool --mode=install /usr/bin/install -c xmlwf/xmlwf /usr/local/bin/ xmlwf libtool: install: warning: `lib/libexpat.la' has not been installed in `/usr/loc al/lib' /usr/bin/install -c xmlwf/.libs/xmlwf /usr/local/bin/xmlwf /bin/sh ./libtool --mode=install /usr/bin/install -c lib/libexpat.la /usr/local/ lib/libexpat.la /usr/bin/install -c lib/.libs/libexpat.dll.a /usr/local/lib/libexpat.dll.a dlpath=`bash 2>&1 -c '. lib/.libs/lib/libexpat.lai;echo $dlname'` dldir=/usr/local/lib/`dirname $dlpath` dirname: too many arguments Try `dirname --help' for more information. make: *** [install] Error 1 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=557530&group_id=10127 From noreply@sourceforge.net Fri May 17 20:24:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 17 19:24:01 2002 Subject: [ expat-Bugs-463928 ] 1.95.2 Cygwin build fails Message-ID: Bugs item #463928, was opened at 2001-09-22 14:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=463928&group_id=10127 Category: Build control Group: Platform Specific Status: Closed Resolution: Fixed Priority: 5 Submitted By: Jari Aalto (jaalto) Assigned to: Greg Stein (gstein) Summary: 1.95.2 Cygwin build fails Initial Comment: Hi, Is there any chance to get expat compiled under cygwin? http://www.cygwin.com/ I would like to install the Perl XML modules, but they require expat first. If you need help to debug this, I will help gladly. I'm former C++ programmer. Jari.aalto@poboxes.com //root@W2KPICASSO /usr/src/expat-1.95.2 $ CFLAGS=- fexceptions ./configure creating cache ./config.cache checking host system type... i686-pc-cygwin checking build system type... i686-pc-cygwin checking for ranlib... ranlib checking for gcc... gcc checking whether the C compiler (gcc -fexceptions ) works... yes checking whether the C compiler (gcc -fexceptions ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes 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 BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking for dlltool... dlltool checking for as... as checking for objdump... objdump updating cache ./config.cache checking for object suffix... o checking for executable suffix... .exe checking for gcc option to produce PIC... none 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 if gcc static flag -static works... -static checking if the linker (/usr/i686-pc- cygwin/bin/ld.exe) is GNU ld... yes checking whether the linker (/usr/i686-pc- cygwin/bin/ld.exe) supports shared lib raries... yes checking command to parse /usr/bin/nm -B output... ok checking how to hardcode library paths into programs... immediate checking for /usr/i686-pc-cygwin/bin/ld.exe option to reload object files... -r checking dynamic linker characteristics... Win32 ld.exe checking if libtool supports shared libraries... yes checking if package supports dlls... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for objdir... .libs creating libtool loading cache ./config.cache checking for gcc... (cached) gcc checking whether the C compiler (gcc -fexceptions ) works... yes checking whether the C compiler (gcc -fexceptions ) is a cross-compiler... no checking whether we are using GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes checking for a BSD compatible install... /usr/bin/install -c checking how to run the C preprocessor... gcc -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... no checking for memmove... yes checking for bcopy... yes updating cache ./config.cache creating ./config.status creating Makefile creating lib/Makefile creating lib/expat.h creating xmlwf/Makefile creating examples/Makefile creating config.h config.h is unchanged //root@W2KPICASSO /usr/src/expat-1.95.2 $ make cd lib && make make[1]: Entering directory `/usr/src/expat-1.95.2/lib' /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H - DPACKAGE='"expat"' -DVERS ION='"expat_1.95.2"' -I. -I. -I.. -fexceptions -Wall - Wmissing-prototypes -Wstr ict-prototypes -fexceptions -c xmlparse.c rm -f .libs/xmlparse.lo gcc -DHAVE_CONFIG_H -DPACKAGE=\expat\ - DVERSION=\expat_1.95.2\ -I. -I. -I.. -fexceptions -Wall -Wmissing-prototypes -Wstrict- prototypes -fexceptions -c xmlp arse.c -DPIC -o .libs/xmlparse.lo mv -f .libs/xmlparse.lo xmlparse.o (cd . && ln -s xmlparse.o xmlparse.lo) /bin/sh ../libtool --mode=link gcc -version-info 1:0:1 -fexceptions -Wall -Wmis sing-prototypes -Wstrict-prototypes -fexceptions -o libexpat.la -rpath /usr/loc al/lib xmlparse.lo xmltok.lo xmlrole.lo libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared l ibraries rm - fr .libs/libexpat.la .libs/libexpat.* .libs/libexpat.* ar cru .libs/libexpat.a xmlparse.o xmltok.o xmlrole.o ranlib .libs/libexpat.a creating libexpat.la (cd .libs && rm -f libexpat.la && ln -s ../libexpat.la libexpat.la) make[1]: Leaving directory `/usr/src/expat-1.95.2/lib' cd xmlwf && make make[1]: Entering directory `/usr/src/expat- 1.95.2/xmlwf' gcc -o xmlwf -static xmlwf.o xmlfile.o codepage.o unixfilemap.o -L../lib/.libs - lexpat xmlwf.o(.text+0x914):xmlwf.c: undefined reference to `_imp__XML_DefaultCurrent' xmlwf.o(.text+0x934):xmlwf.c: undefined reference to `_imp__XML_DefaultCurrent' xmlwf.o(.text+0x954):xmlwf.c: undefined reference to `_imp__XML_DefaultCurrent' xmlwf.o(.text+0x974):xmlwf.c: undefined reference to `_imp__XML_DefaultCurrent' xmlwf.o(.text+0xa3c):xmlwf.c: undefined reference to `_imp__XML_GetBase' xmlwf.o(.text+0xa76):xmlwf.c: undefined reference to `_imp__XML_GetCurrentColumn Number' xmlwf.o(.text+0xa8b):xmlwf.c: undefined reference to `_imp__XML_GetCurrentLineNu mber' xmlwf.o(.text+0xaa0):xmlwf.c: undefined reference to `_imp__XML_GetCurrentByteCo unt' xmlwf.o(.text+0xab5):xmlwf.c: undefined reference to `_imp__XML_GetCurrentByteIn dex' xmlwf.o(.text+0xbc0):xmlwf.c: undefined reference to `_imp__XML_GetSpecifiedAttr ibuteCount' xmlwf.o(.text+0xbe3):xmlwf.c: undefined reference to `_imp__XML_GetIdAttributeIn dex' xmlwf.o(.text+0x1bef):xmlwf.c: undefined reference to `_imp__XML_ParserCreateNS' xmlwf.o(.text+0x1c09):xmlwf.c: undefined reference to `_imp__XML_ParserCreate' xmlwf.o(.text+0x1c2b):xmlwf.c: undefined reference to `_imp__XML_SetNotStandalon eHandler' xmlwf.o(.text+0x1c41):xmlwf.c: undefined reference to `_imp__XML_SetParamEntityP arsing' xmlwf.o(.text+0x1c6a):xmlwf.c: undefined reference to `_imp__XML_SetElementHandl ... xmlwf.o(.text+0x207b):xmlwf.c: undefined reference to `_imp__XML_ParserFree' xmlfile.o(.text+0x38):xmlfile.c: undefined reference to `_imp__XML_GetErrorCode' xmlfile.o(.text+0x4d):xmlfile.c: undefined reference to `_imp__XML_ErrorString' xmlfile.o(.text+0x71):xmlfile.c: undefined reference to `_imp__XML_GetCurrentCol umnNumber' xmlfile.o(.text+0x86):xmlfile.c: undefined reference to `_imp__XML_GetCurrentLin eNumber' xmlfile.o(.text+0x100):xmlfile.c: undefined reference to `_imp__XML_Parse' xmlfile.o(.text+0x242):xmlfile.c: undefined reference to `_imp__XML_ExternalEnti tyParserCreate' xmlfile.o(.text+0x285):xmlfile.c: undefined reference to `_imp__XML_SetBase' xmlfile.o(.text+0x2cb):xmlfile.c: undefined reference to `_imp__XML_ParserFree' xmlfile.o(.text+0x346):xmlfile.c: undefined reference to `_imp__XML_GetBuffer' xmlfile.o(.text+0x3ec):xmlfile.c: undefined reference to `_imp__XML_ParseBuffer' xmlfile.o(.text+0x46a):xmlfile.c: undefined reference to `_imp__XML_ExternalEnti tyParserCreate' xmlfile.o(.text+0x4a1):xmlfile.c: undefined reference to `_imp__XML_SetBase' xmlfile.o(.text+0x4da):xmlfile.c: undefined reference to `_imp__XML_ParserFree' xmlfile.o(.text+0x51c):xmlfile.c: undefined reference to `_imp__XML_SetBase' xmlfile.o(.text+0x584):xmlfile.c: undefined reference to `_imp__XML_SetExternalE ntityRefHandler' collect2: ld returned 1 exit status make[1]: *** [xmlwf] Error 1 make[1]: Leaving directory `/usr/src/expat- 1.95.2/xmlwf' make: *** [xmlwf] Error 2 //root@W2KPICASSO /usr/src/expat-1.95.2 $ ---------------------------------------------------------------------- Comment By: Chad Austin (aegis) Date: 2002-05-17 21:23 Message: Logged In: YES user_id=7212 Build succeeds, but install doesn't. I filed bug 557530 for that issue. ---------------------------------------------------------------------- Comment By: Greg Stein (gstein) Date: 2002-05-17 19:58 Message: Logged In: YES user_id=6501 Patches have been applied for cygwin compilation. Please try a copy from CVS for the upcoming 1.95.3 release; reopen if problems persist. ---------------------------------------------------------------------- Comment By: Gerrit Haase (siebenschlaefer) Date: 2002-02-17 08:17 Message: Logged In: YES user_id=76037 I sent a new (completer) patch recently here: https://sourceforge.net/tracker/index.php? func=detail&aid=501295&group_id=10127&atid=310127 ---------------------------------------------------------------------- Comment By: Jari Aalto (jaalto) Date: 2002-02-05 16:42 Message: Logged In: YES user_id=65014 Fellow cygwin user sent a full package that compiles fine, so here is patch against the full expat tar.gz tree. ---------------------------------------------------------------------- Comment By: Jari Aalto (jaalto) Date: 2002-02-05 15:05 Message: Logged In: YES user_id=65014 One clarification: After I applied the Gerrit's patch (-no-undefined) the compilation error still persists and the program does not compile under cygwin. Any progress on this? ---------------------------------------------------------------------- Comment By: Gerrit Haase (siebenschlaefer) Date: 2001-10-24 12:19 Message: Logged In: YES user_id=76037 I posted the patch here, (all in one line, please): http://sourceforge.net/tracker/index.php? func=detail&aid=454879&group_id=10127&atid=110127 Gerrit ---------------------------------------------------------------------- Comment By: Gerrit Haase (siebenschlaefer) Date: 2001-10-24 11:50 Message: Logged In: YES user_id=76037 There is not much to do, a little change in the lib/Makefile.in and the expat-x.dll is build properly (I used the latest autotools of today, libtool-1.4.2, autoconf- 2.52, automake-1.5), here the patch (I added just -no- undefined at the link line): --- lib/Makefile.in.orig Wed Oct 24 18:24:58 2001 +++ lib/Makefile.in Wed Oct 24 18:23:29 2001 @@ -90,7 +90,7 @@ COMPILE = $(CC) $(DEFS) $(INCLUDES) $(CPPFLAGS) $(CFLAGS) LTCOMPILE = $(LIBTOOL) --mode=compile $(CC) $(DEFS) $(INCLUDES) $(CPPFLAGS) $(CFLAGS) CCLD = $(CC) -LINK = $(LIBTOOL) --mode=link $(CCLD) -version-info $(LIBCURRENT):$(LIBREVISION):$(LIBAGE) $(CFLAGS) $(LDFLAGS) -o $@ +LINK = $(LIBTOOL) --mode=link $(CCLD) -no-undefined - version-info $(LIBCURRENT):$(LIBREVISION):$(LIBAGE) $(CFLAGS) $(LDFLAGS) -o $@ DIST_COMMON = Makefile.in ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=463928&group_id=10127 From noreply@sourceforge.net Fri May 17 20:29:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 17 19:29:02 2002 Subject: [ expat-Bugs-557531 ] "make check" fails Message-ID: Bugs item #557531, was opened at 2002-05-17 21:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=557531&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chad Austin (aegis) Assigned to: Nobody/Anonymous (nobody) Summary: "make check" fails Initial Comment: $ make check gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -Ilib - I. -o tests/runtests.o -c tests/runtests.c tests/runtests.c:2: check.h: No such file or directory make: *** [tests/runtests.o] Error 1 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=557531&group_id=10127 From noreply@sourceforge.net Sat May 18 10:33:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat May 18 09:33:02 2002 Subject: [ expat-Bugs-462960 ] configure fails on OSX Message-ID: Bugs item #462960, was opened at 2001-09-19 21:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=462960&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: configure fails on OSX Initial Comment: [mda@IDRG401 expat-1.95.2]$ ./configure -- prefix=/opt creating cache ./config.cache checking host system type... Invalid configuration `unknown-apple-darwin1.3.7': machine `unknown- apple' not recognized checking build system type... Invalid configuration `unknown-apple-darwin1.3.7': machine `unknown- apple' not recognized checking for ranlib... ranlib checking for gcc... no checking for cc... cc checking whether the C compiler (cc ) works... yes checking whether the C compiler (cc ) is a cross- compiler... no checking whether we are using GNU C... yes checking whether cc accepts -g... yes checking for ld used by GCC... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for BSD-compatible nm... /usr/bin/nm -p checking whether ln -s works... yes updating cache ./config.cache ltconfig: you must specify a host type if you use `-- no-verify' Try `ltconfig --help' for more information. configure: error: libtool configure failed [mda@IDRG401 expat-1.95.2]$ ---------------------------------------------------------------------- Comment By: Max Horn (fingolfin) Date: 2002-05-18 18:32 Message: Logged In: YES user_id=12935 I disagree, being somebody who has ported several dozen Unix packages using libtool to OS X. First off, the problem in this bug report is caused by the fact that the configure script is not checking for the HOST type as it should; adding a simple statment to it would fix that, provided you made sure to use current versions of config.sub / config.guess. For hints on libtool patches on OS X, check out http:// fink.sourceforge.net/doc/porting/libtool.php All of these fixes have been cleaned up and submitted to the libtool team by us, and most should be in the next version (I really hope they make a 1.4.3 some day soon with these bugs fixed). For Fink, we also have an expat package: http:// fink.sourceforge.net/pdb/package.php/expat I see that it's not the current expat version, though I doubt that there are fundamental problems; I will contact the author. ---------------------------------------------------------------------- Comment By: Greg Stein (gstein) Date: 2002-05-18 02:53 Message: Logged In: YES user_id=6501 Mac OS X is notoriously problematic w.r.t libtool. Even if we generated the scripts with libtool 1.4.2, additional patches are needed. I believe the only answer is that Mac OS X users would need to get the source, install the properly-patched libtool, and run buildconf to generate new config stuff. With some additional work, I think we can get this fixed up, but it'll take some more investigation that I don't have right now. [ I believe the patched libtool stuff has been posted on the 'net by Pier Fumagalli; need to look that up ] ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-10 23:40 Message: Logged In: NO After copying the files from /usr/share/libtool, and also trying to copy the files from an alternate GNU version of libtool that I have, the exact same error results. What now? ---------------------------------------------------------------------- Comment By: Max Horn (fingolfin) Date: 2001-10-31 22:37 Message: Logged In: YES user_id=12935 This problem is due to old version of config.guess and config.sub being used. In OS X, you can usually copy the ones from /usr/share/libtool/ over the ones supplied in the source to be compiled. The package maintainers can easily fix this issue by updating to the latest versions of the files (and/or also to newer version of autoconf/automake) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=462960&group_id=10127 From noreply@sourceforge.net Sat May 18 12:07:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat May 18 11:07:03 2002 Subject: [ expat-Patches-548210 ] Enable reporting of external PE declarat Message-ID: Patches item #548210, was opened at 2002-04-24 13:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=548210&group_id=10127 Category: None Group: Feature Request >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) Summary: Enable reporting of external PE declarat Initial Comment: It seems that Expat does not report declarations of external parameter entities, even though it reports the associated parameter entity references. This patch should enable Expat to call the external entity ref handler when it encounters external PE declarations. I have attached full versions of the modified files xmlparse.c and xmlrole.c, as well as the corresponding diffs. The modifications have been made against xmlrole.c rev. 1.5 and xmlparse.c rev. 1.30. Karl ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-18 14:06 Message: Logged In: YES user_id=290026 Closed, because this patch was made obsolete by patch # 551599, which has been checked in. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-02 16:44 Message: Logged In: YES user_id=290026 This patch has been superceded by patch # 551599 Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=548210&group_id=10127 From noreply@sourceforge.net Sat May 18 12:08:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat May 18 11:08:02 2002 Subject: [ expat-Patches-548786 ] Fix attempt for bug # 548690 Message-ID: Patches item #548786, was opened at 2002-04-25 16:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=548786&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) Summary: Fix attempt for bug # 548690 Initial Comment: Under the following switch case: case XML_ROLE_PARAM_ENTITY_REF: the original code would simply do return XML_ERROR_UNDEFINED_ENTITY; if the entity's name was not declared before. I have replace this with: if (dtd.standalone) return XML_ERROR_UNDEFINED_ENTITY; if (defaultHandler) reportDefault(parser, enc, s, next); break; In addition, under the following case: case XML_ROLE_PARAM_ENTITY_NAME: the original code would only store the name of the parameter entity if dtd.complete was true. I have removed this condition. Obviously, this could potentially break some other code. Sofar it has been working for me. The attached file xmlparse.c is based on revision 1.30 and also includes patch # 548210. A diff file is attached as well. Karl ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-18 14:07 Message: Logged In: YES user_id=290026 Closed, because this patch was made obsolete by patch # 551599, which has been checked in. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-02 16:43 Message: Logged In: YES user_id=290026 This patch has been superceded by patch # 551599 Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=548786&group_id=10127 From noreply@sourceforge.net Sat May 18 12:14:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat May 18 11:14:02 2002 Subject: [ expat-Bugs-549014 ] May cause memory error in dtdCopy. Message-ID: Bugs item #549014, was opened at 2002-04-26 06:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=549014&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jun Huang (huangjun_se) Assigned to: Nobody/Anonymous (nobody) Summary: May cause memory error in dtdCopy. Initial Comment: This problem may not a bug.If not ,I want somebody to tell me how to use the XML_ExternalEntityParserCreate and XML_ParserFree.Thank you. In function "dtdCopy",there is a comment "/* Don't want deep copying for scaffolding */".I don't understand it's meaning.But the following code set oldDtd->scaffIndex to newDtd->scaffIndex.I found it may cause a memory error. If a parentParser has allocated the memory pointed by scaffIndex,I use XML_ExternalEntityParserCreate to create a subParser.So the subParser will get the scaffIndex of the parentParser.And then I call XML_ParserFree to free the subParser,it will free the memory pointed by scaffIndex of the subParser.But the scaffIndex of the parentParser still pointed the memory freed.Then if the following code visit the memory pointed by the scaffIndex ,it will cause a memory error. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-18 14:13 Message: Logged In: YES user_id=290026 The fix in patch # 551599 seems to fix this, but I suggest we leave this bug open until more people have tested it. Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-04 17:16 Message: Logged In: YES user_id=13222 In other words, your mean: if (prologState.documentEntity) { if (p->scaffIndex) FREE(p->scaffIndex); if (p->scaffold) FREE(p->scaffold); } at the end of dtdDestroy? Nope, still seg faults. And it seems for the same reason, why parentParser could not used for this. As far, as I see, documentEntity is only set in XmlPrologStateInit() (to 1) and in XmlPrologStateInitExternalEntity() (to 0). Now take again a look at the already quoted end of XML_ExternalEntityParserCreate(): if (context) { #endif /* XML_DTD */ if (!dtdCopy(&dtd, oldDtd, parser) || !setContext(parser, context)) { XML_ParserFree(parser); return 0; } processor = externalEntityInitProcessor; #ifdef XML_DTD } else { dtdSwap(&dtd, oldDtd); parentParser = oldParser; XmlPrologStateInitExternalEntity(&prologState); dtd.complete = 1; hadExternalDoctype = 1; } XmlPrologStateInitExternalEntity() is only called for external parameter entities and the external DTD subset (for this, context is 0). For external general entities, documentEntity isn't set to 0. And therefor the test in dtdDestroy() above doesn't work. I can track this in my test case. This test case has an external subset (for which documentEntity is set to 0) and various external general entities in the content. documentEntity is set to 0 for the parser, that parses the external subset. The external entity parser created to parse the external general entities doesn't have set documentEntity to 0. Consequently, the scaffolding stuff is free'ed in dtdDestroy() - in the current CVS the same as with both proposed tests - at the moment, the parser for the first external general entity is free'ed. If the 'child' parser created for the second external general entity is freed, it makes *bang*: seg fault. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 16:44 Message: Logged In: YES user_id=290026 No, documentEntity does not fit the bill either, so it seems we need a new member. After having a closer look: parentParser is not set for external general entities probably because none of the related code uses it. As far as I can tell, parentParser is used exclusively by DTD processing code, except for the XML_ParserFree function. I have put together a patch (based on my patch # 551599) that does the following: - adds a new member m_isParamEntity and the associated macro - sets parentParser to oldParser for both, external GEs and PEs, in XML_ExternalEntityParserCreate - initializes isParamEntity to 0, but sets it to 1 where parentParser used to be set to oldParser - replaces "if (parentParser)" with "if (isParamEntity)" in XML_ParserFree - keeps the previously suggested code in dtdDestroy: if (!parentParser) { if (p->scaffIndex) FREE(p->scaffIndex); if (p->scaffold) FREE(p->scaffold); } which should guarantee that dtd.scaffold is freed for the root parser only, since parentParser will always be set for child parsers - all other checks of parentParentParser in the DTD handling code should probably be replaced with checks for isParamEntity, however, in DTD handling code, whenever parentParser is set, isParamEntity = 1, and whenever parentParser is null, isParamEntity = 0, so the two are equivalent. Only outside of DTD handling code can they be different If anybody is interested, I can e-mail the patch. If it works - for those that can test it - then I will probably add it as another improvement to patch # 551599. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 14:44 Message: Logged In: YES user_id=290026 You are right - damn! I have to revisit my recent patch for PE handling! Anyway, if parentParser does not fit the bill, then prologState.documentEntity might. Could you please check that too. Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-04 12:23 Message: Logged In: YES user_id=13222 I'm sure, I don't understand all the internals in every detail. But: I would say, Karl Waclawek's code if (!parentParser) { if (p->scaffIndex) FREE(p->scaffIndex); if (p->scaffold) FREE(p->scaffold); } goes into the right direction, but this alone doesn't fix the problem (at least doesn't fix the problem completely). I've an example, which triggers the seg fault (it's a bit complex, a hole application, to much, to attach it, but if somebody is interested enough, I can point you to the code and supply test data.) Even with Karls modification, this example still seg faults. But, as said, where at the right trace. If I remove the freeing of p->scaffIndex and p->scaffold from dtdDestroy(), everthing works as expected (but with a memory leak, of course). But how could this be? Well, as far as I see, parentParser is _not_ set in every case in XML_ExternalEntityParserCreate(). Take a look at the end of this function: if (context) { #endif /* XML_DTD */ if (!dtdCopy(&dtd, oldDtd, parser) || !setContext(parser, context)) { XML_ParserFree(parser); return 0; } processor = externalEntityInitProcessor; #ifdef XML_DTD } else { dtdSwap(&dtd, oldDtd); parentParser = oldParser; XmlPrologStateInitExternalEntity(&prologState); dtd.complete = 1; hadExternalDoctype = 1; } parentParser is only set (to a value != 0), if context is false. If I use parentParser = oldParser; if (context) { #endif /* XML_DTD */ if (!dtdCopy(&dtd, oldDtd, parser) || !setContext(parser, context)) { XML_ParserFree(parser); return 0; } processor = externalEntityInitProcessor; #ifdef XML_DTD } else { dtdSwap(&dtd, oldDtd); XmlPrologStateInitExternalEntity(&prologState); dtd.complete = 1; hadExternalDoctype = 1; } (moved the parentParser setting outside the if, so that it's always set). This, together with Karl's code fixes the problem for me. But I'm really not sure, if this could (should) be done. I don't recall all details of my debugging sessions (it was some month ago), but if I recall right, there are reasons, for that the parentParser is not always set. It's a way to distinguish, if the external entity parser parses an external parameter entity or a general external entity (for parameter entities context is 0). This distinction seems to be used at some places and it looks like, we need it (please correct me, if I'm wrong). So, what to do? Back to Fred's propose of a new interal flag, that's only set for the master parser? Looks like this would be the simplest solution, with the lowest risk of unexpected side effects. Does somebody knows, if this distinction is necessary somewhere, for the parser, to work correct? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 10:05 Message: Logged In: YES user_id=290026 Here is some more analysis (I am fairly new to Expat, so I may repeat what you already know): dtd.scaffold is used as a "working memory" pool for building content models passed to an element declaration handler. It is passed between parsers only so that the working memory does not have to be allocated again (speed). The passing from parent to child is done using dtdCopy or dtdSwap. From all of that I would say that it should only be freed at the very end, when the root parser gets destroyed. So, to achieve that, simply change the code in dtdDestroy from: ... if (p->scaffIndex) FREE(p->scaffIndex); if (p->scaffold) FREE(p->scaffold); ... to: ... if (!parentParser) { if (p->scaffIndex) FREE(p->scaffIndex); if (p->scaffold) FREE(p->scaffold); } ... Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 01:25 Message: Logged In: YES user_id=290026 Just tested my solution for the dangling pointers: Won't work, since it should only be applied when a dtdCopy was performed (external GE), not when a dtdSwap was done (external PE). However, we don't have a flag that tells us which type of external entity was parsed. Another approach could be to clear the old pointers right when dtdCopy is performed (and also reset scaffCount and scaffSize). That way, even if dtd.scaffold was used again, it would be allocated fram scratch, since the code will detect the null pointers. A lot depends on how dtdCopy and dtd.scaffold are used. Currently dtdCopy is only called for creating an external GE parser, and dtd.scaffold is only used for building the content model of an element declaration, which means it is not shared across parsers. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 23:45 Message: Logged In: YES user_id=290026 There is already a flag: look at the parentParser macro. However, as I said, this dangling pointer does not cause an actual problem. I found this out by looking at the code as well as creating a specific test situation, where an external parser would be created, then freed, and then element declaration would be parsed which would require use of the dtd.scaffold member. However, as it appeared to me, all of this happens during parsing of the DTD, but the dtdCopy function will not have been be called since it is only called when the childparser has context !=0, which means it parses a general entity. And that never happens before the DTD parsing is completed. The dangling pointers could simply be set to null like this in XML_ParserFree: ... #ifdef XML_DTD if (parentParser) { dtdSwap(&dtd, &((Parser *)parentParser)->m_dtd); } #endif /* XML_DTD */ dtdDestroy(&dtd, parser); // now, add this code: ((Parser *)parentParser)->m_dtd.scaffold = 0; ((Parser *)parentParser)->m_dtd.scaffIndex = 0; Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-03 23:06 Message: Logged In: YES user_id=13222 An internal flag for this would be great; the simplest solution, very low cost in speed and memory. I would love, to have a this way fixed expat. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-03 22:54 Message: Logged In: YES user_id=3066 Since the "master" and descendent parsers are created using different functions, we should just add an internal field that indicates whether the parser is the master or not. I think we just need to know whether the parser is the master, but don't need a pointer to the master. Karl, does this sound sufficient? I think we can do this with no public API changes. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-03 22:49 Message: Logged In: YES user_id=13222 Exactly. I came to the same conclusion as Jun Huang, while debugging some rare seg faults of an expat based application, I work with. You have to work with external entities (must use XML_ExternalEntityParserCreate()) to see the error. I second this bug report, saying loud that this man is right, not only in that there is a very hard problem (seg fault) with using external enitities with expat but also with his analysis of the reason for this problem. OK, given that, the obvious question is, how to fix that? As far as I see, there isn't a simple way to determine, if a parser is, well, the 'master', or the 'main' parser or if it's a parser, created to parse an external entity. It's OK, to collect the DTD Information of the internal subset and the parts in the (could be) multiple parameter entities in one memory structure, ie I think, it's OK to not deep dopying the scaffolding. But the memory has to be freed in the outmost parser. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 14:57 Message: Logged In: YES user_id=290026 Looking closer at the code: dtdCopy will only be called for a child parser, if the entity is a general entity, not a parameter entity. dtd.scaffold will only be used when the parser is processing the external or internal subset, which always happens *before* any general external entity is processed. So, by planning (or coincidence ) dtd.scaffold will not get used after being freed as described. However, we still have a dangling pointer, which should be set to null. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 12:37 Message: Logged In: YES user_id=290026 It seems your observation is correct. This can cause memory errors. I am just curious why I haven't seen them yet. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=549014&group_id=10127 From noreply@sourceforge.net Sat May 18 12:16:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat May 18 11:16:01 2002 Subject: [ expat-Bugs-551852 ] BOM causes error with small buffers Message-ID: Bugs item #551852, was opened at 2002-05-03 09:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=551852&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) Summary: BOM causes error with small buffers Initial Comment: This happens when an external entity that has a BOM *and* a text declaration, is parsed, and the buffer size is very small. For instance, take these two files: --- test.xml --- ]> &e; --- end of file --- and this external entity, saved in UTF-16 with BOM: --- test.ent --- some text --- end of file --- When parsing this with a buffer size of 1 (using XML_GetBuffer), you get the error "xml processing instruction not at start of entity". This error won't happen if you remove the BOM. I have traced this to the function externalEntityInitProcessor2. I found a fix for this: original code: ... switch (tok) { case XML_TOK_BOM: start = next; break; ... fixed code: ... switch (tok) { case XML_TOK_BOM: if (next == end && endPtr) { *endPtr = next; return XML_ERROR_NONE; } start = next; break; ... Explanation for fix: If we are at the end of the buffer, the original code would pass control to the next stage, i.e. externalEntityInitProcessor3, which would detect XML_TOK_NONE and pass control directly to doContent without processing any xml text declaration. However, in doContent the xml text declaration will then be parsed and this will cause the error XML_ERROR_MISPLACED_XML_PI, sinc doContent does not allow text declarations. The fix simply prevents control to be passed to doContent before externalEntityInitProcessor2 can process the xml text declaration. Karl ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-18 14:15 Message: Logged In: YES user_id=290026 Patch # 551599 containing the proposed fix has been checked in. I'd like to leave this issue open until more people have tested it. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 23:46 Message: Logged In: YES user_id=290026 Should we check this in, or wait until the PE references patch is tested also. The reason I am mentioning this is that parsing external PE references has the same problem. It just does not show in the current revision, since Expat does not pass such references to the external entity ref handler. Karl Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-04 17:10 Message: Logged In: YES user_id=3066 Karl, I have a test case for this one and can confirm your suggested fix. Check it in whenever you're ready, and I'll follow with the test case. (Still working on the other tests; I got swamped by work & kids this week.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=551852&group_id=10127 From noreply@sourceforge.net Sat May 18 12:17:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat May 18 11:17:03 2002 Subject: [ expat-Bugs-553318 ] XML_ParserReset does not reset everythi Message-ID: Bugs item #553318, was opened at 2002-05-07 11:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=553318&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) Summary: XML_ParserReset does not reset everythi Initial Comment: I have identified three problems with XML_ParserReset in xmlparse.ca rev. 1.31: 1) tempPool and temp2Pool are not cleared, which means that they may grow much larger than needed (the poolClear function does not deallocate memory!) 2) the dtd structure is not reset 3) it should not be legal to call XML_ParserReset on a child parser, since sometimes the child parser shares the dtd structure with the parent parser, and because a child parser created for parsing an external entity cannot be used for the same purpose anymore - the initialization would need to be different I propose to split XML_ParserReset into two functions, an internal one, called parserInit, and an exported one with the original name. This one would then use parserInit like this: int XML_ParserReset(XML_Parser parser, const XML_Char *encodingName) { if (parentParser) return 0; #ifdef XML_DTD if (dtd.scaffold) dtdDestroy(&dtd, parser); #endif poolClear(&tempPool); poolClear(&temp2Pool); return parserInit(parser, encodingName); } whereas parserInit would be called by XML_ParserCreate_MM instead of XML_ParserReset, since not everything that applies to the exported version applies to the internal one. This examples necessitates that parentParser is always set for a child parser, which is currently not the case, but patch # 551599 includes it as a "byproduct" of fixing bug # 549014. Also, parserInit (and consequently XML_ParserReset) may potentially fail (since parserInit calls dtdInit internally) and therefore the return type should be changed from void to int. Changes according to this have been included in patch # 551599 (2nd improved version). Karl ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-18 14:16 Message: Logged In: YES user_id=290026 Proposed fix is part of patch # 551599 which has been checked in. Let's wait until more testing has been done. Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-07 11:53 Message: Logged In: YES user_id=3066 Sounds good to me. Assigning to you since you've already written the patch. ;-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=553318&group_id=10127 From noreply@sourceforge.net Sat May 18 12:20:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat May 18 11:20:02 2002 Subject: [ expat-Bugs-548690 ] Incorrect "undefined entity" error Message-ID: Bugs item #548690, was opened at 2002-04-25 12:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=548690&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) >Summary: Incorrect "undefined entity" error Initial Comment: I came across the following behaviour, given this document: %worldupdtd; %visiondtd; ]> some text Expat will report an "undefined entity" fatal error for the reference %visiondtd;. However, the XML spec says this (look at the tag: Well-formedness constraint: Entity Declared In a document without any DTD, a document with only an internal DTD subset which contains no parameter entity references, or a document with "standalone='yes'", for an entity reference that does not occur within the external subset or a parameter entity, the Name given in the entity reference must match that in an entity declaration that does not occur within the external subset or a parameter entity, except that well-formed documents need not declare any of the following entities: amp, lt, gt, apos, quot. The declaration of a general entity must precede any reference to it which appears in a default value in an attribute- list declaration. Note that if entities are declared in the external subset or in external parameter entities, a non-validating processor is not obligated to read and process their declarations; for such documents, the rule that an entity must be declared is a well-formedness constraint only if standalone='yes'. Validity constraint: Entity Declared In a document with an external subset or external parameter entities with "standalone='no'", the Name given in the entity reference must match that in an entity declaration. For interoperability, valid documents should declare the entities amp, lt, gt, apos, quot, in the form specified in 4.6 Predefined Entities. The declaration of a parameter entity must precede any reference to it. Similarly, the declaration of a general entity must precede any attribute-list declaration containing a default value with a direct or indirect reference to that general entity. Since Expat is not validating, the emphasized section should apply. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-18 14:19 Message: Logged In: YES user_id=290026 Patch # 551599 contains fixes which make Expat conform to the spec. Leave this open until a skippedEntityHandler patch has been submitted, so that we don't loose sight of the related issues. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 13:43 Message: Logged In: YES user_id=290026 OK, I have added a bug report as feature request for a skippedEntity handler (# 552297). Please review and add your comments. Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-04 12:58 Message: Logged In: YES user_id=13222 _Please_ don't change expats behavior in this area without giving the programmer a chance to get noticed about such not resolvable entities. A skippedEntity callback seems to be a way. The reason for this is, that it is possible to do DTD validation on top of the current expat. If expat silently skip not resolvable entities, this is would be over. (Well,almost complete DTD validation. I mentioned a few remainig problems in http://sourceforge.net/mailarchive/message.php?msg_id=839092 with a bit more information to the nested parameter entities problem also discoverd by Karl in http://sourceforge.net/mailarchive/message.php?msg_id=839078) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 00:12 Message: Logged In: YES user_id=290026 I think the priority should be that Expat conforms to the spec. So, if there is no well-formedness violation, then Expat should not report one. However, your concern is valid, but should be dealt with differently. We were already discussing the introduction of a skippedEntity callback, like the one in SAX. Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-03 23:15 Message: Logged In: YES user_id=13222 I'm a bit confused about the subject. While Karl Waclawe's observation is right by it's own, I don't want to loose the ability of exapt, to claim about not to be able to resolve an external parameter entity. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-04-27 09:24 Message: Logged In: YES user_id=290026 This bug and bug # 544679 seem to be related to a set of difficulties Expat has in handling DTDs and PEs. The best way to detect those problems and test them is to subject Expat to James Clark's test cases at ftp://ftp.jclark.com/pub/xml/xmltest.zip, specifically the test cases in the subdirectory /valid/not-sa/ . Expat does not handle most of them correctly, it seems. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-04-25 23:46 Message: Logged In: YES user_id=290026 To supply more detail: - the external entityref handler is set - it is called for the entity that isn't declared, as well as the external subset - it always returns 1 - and SetParamEntityParsing was called with XML_PARAM_ENTITY_PARSING_ALWAYS ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-25 21:45 Message: Logged In: YES user_id=3066 I need more information to construct the test case. In particular, is a callback set with XML_SetExternalEntityRefHandler(), how many times is it called (is it called for the entity that isn't declared?), and what does it return? Was XML_SetParamEntityParsing() called, and with which value for the 'code' argument? Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=548690&group_id=10127 From noreply@sourceforge.net Sat May 18 12:20:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat May 18 11:20:02 2002 Subject: [ expat-Bugs-548690 ] Incorrect "undefined entity" error Message-ID: Bugs item #548690, was opened at 2002-04-25 12:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=548690&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) >Assigned to: Karl Waclawek (kwaclaw) >Summary: Incorrect "undefined entity" error Initial Comment: I came across the following behaviour, given this document: %worldupdtd; %visiondtd; ]> some text Expat will report an "undefined entity" fatal error for the reference %visiondtd;. However, the XML spec says this (look at the tag: Well-formedness constraint: Entity Declared In a document without any DTD, a document with only an internal DTD subset which contains no parameter entity references, or a document with "standalone='yes'", for an entity reference that does not occur within the external subset or a parameter entity, the Name given in the entity reference must match that in an entity declaration that does not occur within the external subset or a parameter entity, except that well-formed documents need not declare any of the following entities: amp, lt, gt, apos, quot. The declaration of a general entity must precede any reference to it which appears in a default value in an attribute- list declaration. Note that if entities are declared in the external subset or in external parameter entities, a non-validating processor is not obligated to read and process their declarations; for such documents, the rule that an entity must be declared is a well-formedness constraint only if standalone='yes'. Validity constraint: Entity Declared In a document with an external subset or external parameter entities with "standalone='no'", the Name given in the entity reference must match that in an entity declaration. For interoperability, valid documents should declare the entities amp, lt, gt, apos, quot, in the form specified in 4.6 Predefined Entities. The declaration of a parameter entity must precede any reference to it. Similarly, the declaration of a general entity must precede any attribute-list declaration containing a default value with a direct or indirect reference to that general entity. Since Expat is not validating, the emphasized section should apply. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-18 14:19 Message: Logged In: YES user_id=290026 Patch # 551599 contains fixes which make Expat conform to the spec. Leave this open until a skippedEntityHandler patch has been submitted, so that we don't loose sight of the related issues. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 13:43 Message: Logged In: YES user_id=290026 OK, I have added a bug report as feature request for a skippedEntity handler (# 552297). Please review and add your comments. Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-04 12:58 Message: Logged In: YES user_id=13222 _Please_ don't change expats behavior in this area without giving the programmer a chance to get noticed about such not resolvable entities. A skippedEntity callback seems to be a way. The reason for this is, that it is possible to do DTD validation on top of the current expat. If expat silently skip not resolvable entities, this is would be over. (Well,almost complete DTD validation. I mentioned a few remainig problems in http://sourceforge.net/mailarchive/message.php?msg_id=839092 with a bit more information to the nested parameter entities problem also discoverd by Karl in http://sourceforge.net/mailarchive/message.php?msg_id=839078) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 00:12 Message: Logged In: YES user_id=290026 I think the priority should be that Expat conforms to the spec. So, if there is no well-formedness violation, then Expat should not report one. However, your concern is valid, but should be dealt with differently. We were already discussing the introduction of a skippedEntity callback, like the one in SAX. Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-03 23:15 Message: Logged In: YES user_id=13222 I'm a bit confused about the subject. While Karl Waclawe's observation is right by it's own, I don't want to loose the ability of exapt, to claim about not to be able to resolve an external parameter entity. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-04-27 09:24 Message: Logged In: YES user_id=290026 This bug and bug # 544679 seem to be related to a set of difficulties Expat has in handling DTDs and PEs. The best way to detect those problems and test them is to subject Expat to James Clark's test cases at ftp://ftp.jclark.com/pub/xml/xmltest.zip, specifically the test cases in the subdirectory /valid/not-sa/ . Expat does not handle most of them correctly, it seems. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-04-25 23:46 Message: Logged In: YES user_id=290026 To supply more detail: - the external entityref handler is set - it is called for the entity that isn't declared, as well as the external subset - it always returns 1 - and SetParamEntityParsing was called with XML_PARAM_ENTITY_PARSING_ALWAYS ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-25 21:45 Message: Logged In: YES user_id=3066 I need more information to construct the test case. In particular, is a callback set with XML_SetExternalEntityRefHandler(), how many times is it called (is it called for the entity that isn't declared?), and what does it return? Was XML_SetParamEntityParsing() called, and with which value for the 'code' argument? Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=548690&group_id=10127 From noreply@sourceforge.net Sat May 18 12:34:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat May 18 11:34:02 2002 Subject: [ expat-Bugs-544679 ] PEs in external subset error Message-ID: Bugs item #544679, was opened at 2002-04-16 10:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=544679&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) Summary: PEs in external subset error Initial Comment: I ran Expat 1.95.2 against James Clark's test cases version 1998-11-18. There are two files in the directory .../valid/not-sa, which are supposed to be valid, but Expat returns an "illegal parameter entity reference" error. Here is how it looks for the first file: File 004.xml: File 004-1.ent: --> Expat reports error here %e1; File 0004-2.ent: And the second file: File 003.xml: File 003-1.ent: --> Expat error here File 003-2.ent: empty file Expat's behaviour seems to *not* conform to this XML 1.0 rule: Well-formedness constraint: PEs in Internal Subset In the internal DTD subset, parameter-entity references can occur only where markup declarations can occur, not within markup declarations. (This does not apply to references that occur in external parameter entities or to the external subset.) That is, Expat reports an error for external parameter entities too. This might be because a child parser in Expat does not know that it is a child parser - and therefore that it is processing an external entity. Karl ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-18 14:33 Message: Logged In: YES user_id=290026 Expat 1.95.2 had various problems with external PE references, among them that it simply would not pass them to the ExternalEntityRefHandler, when encountering them within entity values, and that it would not pass the entity declaration to the EntityDeclHandler. This has been fixed with patch # 551599 which has been checked in. Let's wait until more testing has been done, before we close this one. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-04-27 09:25 Message: Logged In: YES user_id=290026 Related to bug # 548690. Check comments there. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=544679&group_id=10127 From noreply@sourceforge.net Sat May 18 13:56:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat May 18 12:56:01 2002 Subject: [ expat-Bugs-557739 ] make fails on IRIX 6.2 Message-ID: Bugs item #557739, was opened at 2002-05-18 12:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=557739&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: make fails on IRIX 6.2 Initial Comment: # make cd lib && make make[1]: Entering directory `/usr/people/michaelg/expat-1.95.2/lib' /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H - DPACKAGE='"expat"' -DVERSION='"expat_1.95.2"' -I. -I. - I.. -O2 -Wall -Wmissing-prototypes -Wstrict- prototypes -fexceptions -c xmlparse.c mkdir .libs gcc -DHAVE_CONFIG_H -DPACKAGE=\expat\ - DVERSION=\expat_1.95.2\ -I. -I. -I.. -O2 -Wall - Wmissing-prototypes -Wstrict-prototypes -fexceptions - c xmlparse.c -DPIC -o .libs/xmlparse.lo cc1: Invalid option `-fexceptions' In file included from xmlparse.c:26: /usr/include/string.h:57: warning: conflicting types for built-in function `memcpy' /usr/include/string.h:58: parse error before `;' /usr/include/string.h:58: warning: data definition has no type or storage class /usr/include/string.h:59: warning: conflicting types for built-in function `strcpy' /usr/include/string.h:64: warning: conflicting types for built-in function `memcmp' /usr/include/string.h:65: warning: conflicting types for built-in function `strcmp' xmlparse.c: In function `XML_GetBuffer': xmlparse.c:1178: `punting' undeclared (first use this function) xmlparse.c:1178: (Each undeclared identifier is reported only once xmlparse.c:1178: for each function it appears in.) xmlparse.c:1178: parse error before `on' make[1]: *** [xmlparse.lo] Error 1 make[1]: Leaving directory `/usr/people/michaelg/expat- 1.95.2/lib' make: *** [lib] Error 2 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=557739&group_id=10127 From gp@familiehaase.de Sun May 19 13:21:04 2002 From: gp@familiehaase.de (Gerrit P. Haase) Date: Sun May 19 12:21:04 2002 Subject: Latest CVS expat sources on Cygwin Message-ID: <67899145693.20020519212023@familiehaase.de> Hallo expat-bugs, building expat (from a checkout today) works without problems. Only doing make install doesn't work if building oputside of the sourcedir which is a requirement to be 'modern';) These hardcoded targets in Makefile.in doesn't allow doing a 'make install' outside the sourcedir: install: xmlwf/xmlwf lib/$(LIBRARY) lib/$(APIHEADER) $(mkinstalldirs) $(bindir) $(libdir) $(includedir) $(LIBTOOL) --mode=install $(INSTALL_PROGRAM) xmlwf/xmlwf $(bindir)/xmlwf $(LIBTOOL) --mode=install $(INSTALL) lib/$(LIBRARY) $(libdir)/$(LIBRARY) $(INSTALL_DATA) lib/$(APIHEADER) $(includedir) $(INSTALL_DATA) doc/xmlwf.1 $(prefix)/man/man1 And also it is not possible to install into a special directory Should look more like this: install: xmlwf/xmlwf lib/$(LIBRARY) $(srcdir)/lib/$(APIHEADER) $(mkinstalldirs) $(DESTDIR)$(bindir) $(DESTDIR)$(libdir) \ $(DESTDIR)$(includedir) $(DESTDIR)$(mandir) $(LIBTOOL) --mode=install $(INSTALL_PROGRAM) xmlwf/xmlwf $(DESTDIR)$(bindir)/xmlwf $(LIBTOOL) --mode=install $(INSTALL) lib/$(LIBRARY) $(DESTDIR)$(libdir)/$(LIBRARY) $(INSTALL_DATA) $(srcdir)/lib/$(APIHEADER) $(DESTDIR)$(includedir) $(INSTALL_DATA) $(srcdir)/doc/xmlwf.1 $(DESTDIR)$(mandir)/man/man1 You're already using autoconf and libtool, why don't you use automake too? That would handle all that stuff. Gerrit -- =^..^= -- From gp@familiehaase.de Sun May 19 13:33:02 2002 From: gp@familiehaase.de (Gerrit P. Haase) Date: Sun May 19 12:33:02 2002 Subject: [Expat-discuss] Latest CVS expat sources on Cygwin In-Reply-To: <67899145693.20020519212023@familiehaase.de> References: <67899145693.20020519212023@familiehaase.de> Message-ID: <77899858317.20020519213216@familiehaase.de> > building expat (from a checkout today) works without problems. > Doing make install doesn't work if building outside of the > sourcedir which is a requirement to be 'modern';) > These hardcoded targets in Makefile.in doesn't allow doing a > 'make install' outside the sourcedir: > install: xmlwf/xmlwf lib/$(LIBRARY) lib/$(APIHEADER) > $(mkinstalldirs) $(bindir) $(libdir) $(includedir) > $(LIBTOOL) --mode=install $(INSTALL_PROGRAM) xmlwf/xmlwf $(bindir)/xmlwf > $(LIBTOOL) --mode=install $(INSTALL) lib/$(LIBRARY) $(libdir)/$(LIBRARY) > $(INSTALL_DATA) lib/$(APIHEADER) $(includedir) > $(INSTALL_DATA) doc/xmlwf.1 $(prefix)/man/man1 > And also it is not possible to install into a special directory > Should look more like this: > install: xmlwf/xmlwf lib/$(LIBRARY) $(srcdir)/lib/$(APIHEADER) > $(mkinstalldirs) $(DESTDIR)$(bindir) $(DESTDIR)$(libdir) \ > $(DESTDIR)$(includedir) $(DESTDIR)$(mandir) > $(LIBTOOL) --mode=install $(INSTALL_PROGRAM) xmlwf/xmlwf $(DESTDIR)$(bindir)/xmlwf > $(LIBTOOL) --mode=install $(INSTALL) lib/$(LIBRARY) $(DESTDIR)$(libdir)/$(LIBRARY) > $(INSTALL_DATA) $(srcdir)/lib/$(APIHEADER) $(DESTDIR)$(includedir) > $(INSTALL_DATA) $(srcdir)/doc/xmlwf.1 $(DESTDIR)$(mandir)/man/man1 Naah, this is completely wrong, ok: define in the Makefile: bindir = ${exec_prefix}/bin libdir = ${prefix}/lib includedir = ${prefix}/include mandir = ${prefix}/man/man1 and then the last line of install target: $(INSTALL_DATA) $(srcdir)/doc/xmlwf.1 $(mandir) The $(DESTDIR) isn't needed then if I use: make install prefix=/blah/usr exec_prefix=/blah/user > You're already using autoconf and libtool, why don't you use automake > too? That would handle all that stuff. > Gerrit -- =^..^= -- From noreply@sourceforge.net Sun May 19 15:10:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun May 19 14:10:02 2002 Subject: [ expat-Patches-551599 ] Patch for # 544679, 548690, 549014, 551852, 553318 Message-ID: Patches item #551599, was opened at 2002-05-02 20:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=551599&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for # 544679, 548690, 549014, 551852, 553318 Initial Comment: This is an extensive patch, and needs not only testing, but also a review by my fellow developers! It addresses these issues: # 483514 (default handler reports too much from DTD): only the following data are reported now: - ignored DTD sections - unhandled external parameter entity references - top level whitespace This may not be what is needed, but more would have been a lot of work # 544679, 548690 (DTD handling of external entities): - the storeEntityValue function has been modified to call the external entity reference handler, since it did not handle external PE references at all - a new STRING_POOL has been added that gets passed from a parent to a child parser (member of DTD structure), so that entity values can be built across parsers - new functions entityValueInitProcessor and entityValueProcessor have been added - the old usage of dtd.complete was completely changed - I never understood how it worked, and it didn't work properly anyway; therefore there is a danger now that some logic will not work anymore - please review and check - the usage of hadExternalDoctype was modified too - there have been changes in xmlrole.c too - the chain of state handlers was extended from entity9 to entity10 - in analogy to how general entities - please review the diff file - as a result, this patch now processes all of James Clark's test cases in the /valid/not-sa and /valid/ext-sa directories properly * I have also made some fixes to the recently introduced XML_ParserReset function (incl. changing it's return type), and one fix that prevents a null pointer error The patch is based on these revisions: - expat.h rev. 1.17 - xmlparse.c rev. 1.31 - xmlrole.c rev. 1.5 - xmlrole.h rev. 1.3 I have included the full patch files, an annotated version of xmlparse.c - good to understand my changes, and the diff files. Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-19 21:10 Message: Logged In: YES user_id=13222 I've done a lot of testing, with expat CVS HEAD and this patch applied (and had some pleasant mail conversation with Karl, about the nifty details and the findings.) Let me first confirm, that I was able to reproduce the following bugs related to this patch: 548690 and 544679 (They describe the same behavior.) 549014 (I've already submitted comments to this bug) 544679 There's also a known bug (for which I wasn't able to find the bug nr, sorry), about XML_EntityDeclHandler() is not reporting declarations of external PE references. This I also have to confirm (examples are xmltest/valid/not-sa/005.xml, 011.xml, 012.xml, 026.xml out of the below mentioned test suite). Can't say something about the bugs 553318 and 549014 because I haven't tried to confirm the described bugs. Summary of my findings: The patch seems to fix at least 548690, 544679, 549014, 544679 and the problem with not reported declaration of external PE references. I doesn't found any new problem introduced by the patch. See below for a description of what I've done. That said, I still have an objection. With this patch applied, there is no way to detect, if a parameter entity is not declared, even if you read all external parameter entities, because now expat skip silently all not resolvable entities, if a document has an external subset or external parameter entities. Bug 552297 would be a way, to handle this. What I've done: I've mainly used the OASIS XML test suite, second edtion. You'll find it at http://www.oasis-open.org/committees/xml-conformance/suite-v1se/xmlconf-20010315.htm This testsuite includes several testpackages, contributed by different parties. Most of them split the tests in not-wellformed, valid, and in-valid tests. With a few simple shell scripts and xmlwf (with the option -p), I've checked all not-wellformed tests (all should produce an error) and all valid test (since they are a valid, the must be well-formed and therefor should all pass without an error.) Only in single cases I've checked, if the error reason, given by xmlwf is the one, the OASIS test suite expects; for most of the not-wellformed tests, I could only claim, that xmlwf does report an error, but could not say, if it's the 'right' error. I've run my test scripts with expat-1.92, with expat CVS HEAD, and with expat CVS HEAD with Karl's patch added. Expat 1.95.2 and expat CVS HEAD had the same results: xmltest/valid/not-sa/003.xml xmltest/valid/not-sa/004.xml xmltest/valid/not-sa/031.xml ibm/not-wf/misc/432gewf.xml sun/not-wf/uri01.xml where wrong. 003.xml, 004.xml and 031.xml are examples for bug 544679. The problem with 432gwf.xml is, that this file includes the entity declaration "> The replace text does not conform to production 79 (see XML rec 4.3.2). The entity isn't actually used, in the document (if it would be used, expat would report an error. It seems to me, expat does not check the replace text angainst production 79 at declaration time. This is a real problem, but more a minor one. The problem with uri01.xml is, that this document uses a fragment identifier in the SYSTEM of an external entity declaration. This is in deed not allowed (see XML rec 4.2.2), but the rec say: "[A]n XML processor may signal an error if a fragment identifier is given as part of a system identifier". So, first, this is "may" and not "must" and, second, since you have to provide your external entity resolver by yourself, with the expat library, this could be handled at application level, if the programmer want this. Therefor I would rank this as a very minor problem, if ever. Expat with Karl's patch had the results: xmltest/not-wf/not-sa/005.xml ibm/not-wf/misc/432gewf.xml sun/not-wf/uri01.xml 003.xml, 004.xml and 031.xml from above are fixed. 005.xml is a questionable test. It uses in an external parameter entity a not declared parameter entity. The test suite expects the parser, to claim about this. But since this is a well-formedness test and the document has references to external parameter entities, the "Well-Formedness Constraint: Entity Declared" of production 68 does not apply. Therefor, Karl argues that this test tests the "Validity Constraint: Entity Declared" of production 68 and 69. He has already written a mail about this to the OASIS XML compliance group about this. (I personally still feel a bit uncomfortable about this. Since Karl has the spec on his side (if you read it literal, The oasis testpackage of the testsuite is not organized along this not-wf, valid and not-valid scheme. Instead, there are a couple of "fail" and "pass" tests. All "pass" tests passes xmlwf without error. The "fail" tests p06fail1.xml p08fail1.xml p08fail2.xml p16fail3.xml doesn't trigger an error. But all four tests are testing problems, that are only detected by validating parsers (the test files notices that explicitly). Additional, I've compared the output produced by xmlwf, if you use -d option for all valid tests, for which an expected output was given. Due to a few differences between the canonical output, expected by the OASIS test suite, and the canonnical XML output, produced by xmlwf (which is, I suspect, 'James Clark canonical XML', see http://jclark.com/xml/canonxml.html), I had to check some cases by hand. Expat-1.95.2, expat HEAD and expat with Karl's patch produced byte-identical output. While comparing the expat output with what the OASIS test suites expect, I found three interesting cases. xmltest/valid/sa/098.xml This test includes a processing instruction with a DOS end-of-line sequence (0d 0a). In the expat output this end-of-line marker is 'normalized' to the XML standard (only 0a). The expected output still has the 0d 0a from the document. ibm/valid/P02/ibm02v01.xml This is a crazy case. I argue, that this test is not well-formed XML, because it includes an illegal UTF-8 sequenz. xmlwf passes the document, but the xmlwf result differs from the expected result. I'm not surprised, that expat does not detect the ill-formed UTF-8 (see bug 477667). (Well, I'm a bit surprised, that the test is included als valid test..) sun/valid/sa02.xml The problem is a difference in attribute value normalization (interesting enought, expat seems to follow E70 of http://www.w3.org/XML/xml-19980210-errata for the handling of #xD and #xA.) To check the mentioned problem with the reporting of declaration of external parameter entity references, I've used the expat binding from http://sdf.lonestar.org/~loewerj/tdom.cgi xmltest/valid/not-sa/005.xml xmltest/valid/not-sa/011.xml xmltest/valid/not-sa/012.xml xmltest/valid/not-sa/026.xml are examples which showed, that expat 1.95.2 and expat CVS sometimes doesn't report entity declarations via XML_EntityDeclHandler. With Karls patch applied, the declarations get reported. I've an application, that is able to trigger the bug 549014. Using the memory debugger mpatrol ( http://www.cbmamiga.demon.co.uk/mpatrol/ ) I could show, that the seg fault happens at the place, the analysis to 549014 explains. After applying Karl's patch, the seg fault is vanished. Don't hesitate to ask, If you need more info about one of the discussed points. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-13 00:23 Message: Logged In: YES user_id=290026 There were only a few modifications necessary to make this patch perform well under testing: - It did not compile when XML_DTD was not defined - fixed - forgot to adjust the appendAttribute() function for the modifications in DTD handling logic - fixed This is the final version of the patch - check the new file xmlparse_final.c (and the diff created from it). So, to get the full final patch, download expat.h, xmlrole.h, xmlrole.c and xmlparse_final.c from the set of attached files. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-07 15:53 Message: Logged In: YES user_id=290026 This is the second improvement and probably the final version of the patch. If there should be more changes, a new patch will be entered, since it might get confusing otherwise. The following changes have been made: - some improvements on external PE reference handling - a better fix (hopefully) for bug # 549014 - the changes to DefaultHandler calls for DTDs have been undone - I realized that more extensive changes (also to xmlrole.c and xmlrole.h) would be necessary, so the old behaviour is back: everything for DTDs is reported, even if handlers are set, except for PIs, Comments and XML text declarations. This patch now applies to the following bugs: - # 553318 - # 551852 - # 549014 - # 548690 - # 544679 Uploaded as files xmlparse_2.c and xmlparse_2.c.diff. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 17:13 Message: Logged In: YES user_id=290026 I improved the patch to cover one more problem: I found that bug # 551852 (BOM problem with small buffers), that was reported for general external entities, also applied to external parameter entities. This problem only applied to this patch, since the current release of Expat simply ignores external PEs (which causes bug # 548690). Included is also a fix for bug # 549014 (dtdCopy problem). The attached file are xmlparse_1.c, xmlparse_1.c.annotated and xmlparse_1.diff (against rev. 1.31). Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 14:09 Message: Logged In: YES user_id=290026 Forgot to add: the fix for bug # 551852 is included too. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=551599&group_id=10127 From noreply@sourceforge.net Mon May 20 05:13:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon May 20 04:13:02 2002 Subject: [ expat-Bugs-462960 ] configure fails on OSX Message-ID: Bugs item #462960, was opened at 2001-09-19 12:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=462960&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: configure fails on OSX Initial Comment: [mda@IDRG401 expat-1.95.2]$ ./configure -- prefix=/opt creating cache ./config.cache checking host system type... Invalid configuration `unknown-apple-darwin1.3.7': machine `unknown- apple' not recognized checking build system type... Invalid configuration `unknown-apple-darwin1.3.7': machine `unknown- apple' not recognized checking for ranlib... ranlib checking for gcc... no checking for cc... cc checking whether the C compiler (cc ) works... yes checking whether the C compiler (cc ) is a cross- compiler... no checking whether we are using GNU C... yes checking whether cc accepts -g... yes checking for ld used by GCC... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for BSD-compatible nm... /usr/bin/nm -p checking whether ln -s works... yes updating cache ./config.cache ltconfig: you must specify a host type if you use `-- no-verify' Try `ltconfig --help' for more information. configure: error: libtool configure failed [mda@IDRG401 expat-1.95.2]$ ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2002-05-20 04:12 Message: Logged In: YES user_id=6501 Thanks for the additional clarifications. Your comments about patching libtool are exactly what I was referring to: plain old libtool 1.4.2 isn't going to help the MacOS X users. Note that *we* run libtool when creating a distribution. Since that isn't the "good" libtool, the resulting distribution will not be usable by MacOS X users :-( That said, until libtool gets their act together with the submitted patches, then we can/should point people at the fink package instead. After we release 1.95.3, we should try to get the fink pkg updated to that. Regarding config.sub/.guess, I am planning to pull the most recent copies of those from Apache. They have additional fixes (including MacOS X fixes) that improve them over any of the standard distro'd versions. (if we check them into source control, and tweak our libtoolize call, then it shouldn't overwrite them) ---------------------------------------------------------------------- Comment By: Max Horn (fingolfin) Date: 2002-05-18 09:32 Message: Logged In: YES user_id=12935 I disagree, being somebody who has ported several dozen Unix packages using libtool to OS X. First off, the problem in this bug report is caused by the fact that the configure script is not checking for the HOST type as it should; adding a simple statment to it would fix that, provided you made sure to use current versions of config.sub / config.guess. For hints on libtool patches on OS X, check out http:// fink.sourceforge.net/doc/porting/libtool.php All of these fixes have been cleaned up and submitted to the libtool team by us, and most should be in the next version (I really hope they make a 1.4.3 some day soon with these bugs fixed). For Fink, we also have an expat package: http:// fink.sourceforge.net/pdb/package.php/expat I see that it's not the current expat version, though I doubt that there are fundamental problems; I will contact the author. ---------------------------------------------------------------------- Comment By: Greg Stein (gstein) Date: 2002-05-17 17:53 Message: Logged In: YES user_id=6501 Mac OS X is notoriously problematic w.r.t libtool. Even if we generated the scripts with libtool 1.4.2, additional patches are needed. I believe the only answer is that Mac OS X users would need to get the source, install the properly-patched libtool, and run buildconf to generate new config stuff. With some additional work, I think we can get this fixed up, but it'll take some more investigation that I don't have right now. [ I believe the patched libtool stuff has been posted on the 'net by Pier Fumagalli; need to look that up ] ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-10 14:40 Message: Logged In: NO After copying the files from /usr/share/libtool, and also trying to copy the files from an alternate GNU version of libtool that I have, the exact same error results. What now? ---------------------------------------------------------------------- Comment By: Max Horn (fingolfin) Date: 2001-10-31 13:37 Message: Logged In: YES user_id=12935 This problem is due to old version of config.guess and config.sub being used. In OS X, you can usually copy the ones from /usr/share/libtool/ over the ones supplied in the source to be compiled. The package maintainers can easily fix this issue by updating to the latest versions of the files (and/or also to newer version of autoconf/automake) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=462960&group_id=10127 From noreply@sourceforge.net Tue May 21 18:40:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue May 21 17:40:04 2002 Subject: [ expat-Bugs-432456 ] DLL name 'expat.dll' causes problems Message-ID: Bugs item #432456, was opened at 2001-06-12 09:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=432456&group_id=10127 Category: None Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Kevin Gilpin (kgilpin) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: DLL name 'expat.dll' causes problems Initial Comment: On Win32, when attempting to build the XML::Parser Perl module with expat, the name 'expat.dll' is used by both projects. This causes problems when running XML::Parser, because only one of the 2 dlls can be loaded. By changing the output target of expat to 'libexpat.dll' (and generating and linking against the corresponding libexpat.lib) I was able to get XML::Parser successfully built and running on Win NT. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-21 17:39 Message: Logged In: NO It took a coule of hours to get things working on my machine (Win2k sp2), so I thought I'd post what I did so others won't waste time. I'm not sure if what I did was the correct method, but it worked for me. 1) Download and extract the XML::Parser ZIP from CPAN. 3) Replace all occurances of "expat" with "libexpat" in all files. 3) Rename the Expat directory to libexpat. 4) Rename the expat.pm and expat.xs files accordingly. 5) Open libexpat.xs and change the #include back to #include 6) Build the make files (perl makefile.pl) 7) Open the libexpat makefile and change the PERLARCHIVE line to read (note, I put expat.h, dll, and lib in my perl\lib\CORE directory): PERL_ARCHIVE = $(PERL_INC)\perl56.lib $(PERL_INC) \expat.lib" 8) Run namke 9) Copy the PERL\lib\CORE\expat.dll to blib\arch\xml\parser\libexpat and run 'nmake test'. ---------------------------------------------------------------------- Comment By: Greg Stein (gstein) Date: 2002-05-17 17:55 Message: Logged In: YES user_id=6501 Calling the library expat2.dll would be fine with me. libexpat.dll might also be fine. But also note: *we* are Expat, not the Perl extension. We have more "right" to expat.dll if that is what we choose to do. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-10-01 15:08 Message: Logged In: YES user_id=3066 So this appearantly never worked with Expat 1.95+. Sigh. We could go back to xmlparse.dll I suppose, but I don't really like that. I don't know that we've retained enough compatibility with that. Perhaps "expat2" would be good enough, since the real target right now is a stable Expat 2.0. I'll think about this a little more, but I'd like to have it solved in Expat 1.95.3. Assigning to me since Clark has been abducted by aliens. ---------------------------------------------------------------------- Comment By: Kevin Gilpin (kgilpin) Date: 2001-10-01 14:51 Message: Logged In: YES user_id=44882 The problem is that the Perl extension consists of 2 dlls: 1) the expat DLL, which does not contain any perl references 2) the perl -> expat DLL, which references both the Perl APIs and the Expat APIs Both of these DLLs are called 'expat.dll', which is a problem b/c Windows will cannot tell the difference between them when the Perl program is run ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-10-01 13:26 Message: Logged In: YES user_id=3066 Thinking about this again, I realize I don't know enough about the Perl extension machinery and mod_perl to be sure of this. Is mod_perl providing an expat.dll which is something different, or is it a different version of that mod_perl uses? We need a mod_perl/XML::Parser expert to answer reports like this one! Leaving this one assigned to Clark until we have such a person with available time. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-25 09:39 Message: Logged In: YES user_id=3066 This relates to having multiple versions of the library being made available in the same process. Assigned to Clark since he might have more of the context information related to XML::Parser. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=432456&group_id=10127 From noreply@sourceforge.net Tue May 21 20:36:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue May 21 19:36:05 2002 Subject: [ expat-Bugs-558977 ] Avoid breaking PCDATA at line ends Message-ID: Bugs item #558977, was opened at 2002-05-21 22:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=558977&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 4 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Nobody/Anonymous (nobody) Summary: Avoid breaking PCDATA at line ends Initial Comment: Many applications are poorly served by the line-breaking behavior in which a separate call to the character data handler is made for line content and the line terminator. (Others probably rely on it, even though they shouldn't.) An option to attempt to use the smallest possible number of calls to the character data handler (without changing the buffer management) would be welcome, especially to the implementors and users of scripting-language bindings to Expat. (This in particular is interesting since the call overhead tends to be much higher than plain C callbacks primarily due to the construction of temporary data structures.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=558977&group_id=10127 From noreply@sourceforge.net Tue May 21 21:29:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue May 21 20:29:01 2002 Subject: [ expat-Bugs-477667 ] illegal utf-8 seqs do not throw error Message-ID: Bugs item #477667, was opened at 2001-11-02 17:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=477667&group_id=10127 Category: None Group: None Status: Open Resolution: Works For Me Priority: 6 Submitted By: Patrick McCormick (patrickmc) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: illegal utf-8 seqs do not throw error Initial Comment: I have a problem where users like to use iso-8859-1 without declaring it in the prolog, like this: abécdef expat properly defaults to utf-8 in this case. As I understand utf-8, the é character (0xE7) has a bitfield that looks like the start of a three byte sequence. A 3-byte sequence is supposed to look like this: bytes | bits | representation 3 | 16 | 1110vvvv 10vvvvvv 10vvvvvv the above two bytes (c and d) don't match the 10vvvvvv mask, so écd is an illegal utf-8 sequence. But expat doesn't throw a well-formedness error. Expat uses this macro in xmltok.c to figure out what's illegal: #define UTF8_INVALID3(p) \ ((*p) == 0xED \ ? (((p)[1] & 0x20) != 0) \ : ((*p) == 0xEF \ ? ((p)[1] == 0xBF && ((p)[2] == 0xBF || (p)[2] == 0xBE)) \ : 0)) but this doesn't seem strict enough. I wrote a patch that makes expat check UTF-8 sequences against the Table 3.1B of the Unicode 3.1 standard: http://www.unicode.org/unicode/reports/tr27/ as originally clarified in this Corrigendum: http://www.unicode.org/unicode/uni2errata/UTF- 8_Corrigendum.html and it's attached. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-21 23:27 Message: Logged In: YES user_id=3066 The corrected test is now checked in as tests/runtests.c revision 1.19. ---------------------------------------------------------------------- Comment By: Patrick McCormick (patrickmc) Date: 2002-05-17 15:25 Message: Logged In: YES user_id=363812 actually NORMAL_VTABLE *initializes* the struct, it doesn't define it; that's done at "struct normal_encoding". so that's how the functions are hooked up. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-17 15:24 Message: Logged In: YES user_id=3066 Aargh! This is why I hate token pasting! "grep" doesn't like it either. It gets glued in in four "struct normal_encoding" structures statically defined, starting with "utf8_encoding_ns". Ok, I'll keep digging. ---------------------------------------------------------------------- Comment By: Patrick McCormick (patrickmc) Date: 2002-05-17 15:18 Message: Logged In: YES user_id=363812 not referenced? sure it is! you have to tap into the crazy zen of expat's vtables-without-C++. look at the struct utf8_encoding. at the bottom, it uses the macro NORMAL_VTABLE(utf8_), which creates a struct entry "utf8_invalid3". the macro IS_INVALID_CHAR turns into a function call to the appropriate utf8_invalidN struct member. at some point the struct members are hooked up to the functions, but I'm not sure where. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-17 13:58 Message: Logged In: YES user_id=3066 It's not just that the UTF8_INVALID3() macro is wrong, but that it isn't used at all! The macro is referenced from utf8_isInvalid3(), but that function is not referenced. ;-( ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-17 12:31 Message: Logged In: YES user_id=3066 Ok, I've found a bug in the test case (re-using the parser without resetting it); I've fixed that in my copy and can now reproduce the error. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-17 12:20 Message: Logged In: YES user_id=290026 I am using the library directly - with my own code. Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-17 11:52 Message: Logged In: YES user_id=3066 This is strange. Using the CVS version of Expat, the test case (in tests/runtests.c:test_illegal_utf8) sees the error properly reported. xmlwf doesn't report it, however. Are you using the library directly or going through xmlwf? I'll see what I can figure out. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-09 10:44 Message: Logged In: YES user_id=290026 There is official conversion code at unicode.org. Download the files ConvertUTF.c and ConvertUTF.h from ftp://www.unicode.org/Public/PROGRAMS/CVTUTF/ and then look at the function static Boolean isLegalUTF8(UTF8 *source, int length) Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-09 10:24 Message: Logged In: YES user_id=290026 I can confirm that the current CVS does indeed not report an error against: abécdef Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-08 17:40 Message: Logged In: YES user_id=13222 I'm not happy with closing this bug report without action. Contrary to Fred's test result, I still find, that the described bug is still there (as it was at the time, the bug was reported). I've tested this with the current CVS HEAD. The bug is in deed easly demonstrable with the example out of the bug report. I use: abécdef The third character of the PCDATA is a small e with acute, that's 0xe9 in the iso-8859-1 char table (and the unicode char 00e9), if there may be an encoding problem throu the web interface. xmlwf passes this test file, without any error report, which is, to the best of my knowledge, wrong. rxp and libxml (i.e. xmllint) confirm, that the test file is not proper UTF-8. IHMO, this is a real _crucial_ bug. Please, __Please__, re-check this. rolf ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-19 15:19 Message: Logged In: YES user_id=3066 Added a test (tests/runtests.c revision 1.9) that shows this bug does not exist in the CVS version. You did not state which version of Expat you're using. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=477667&group_id=10127 From noreply@sourceforge.net Tue May 21 21:38:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue May 21 20:38:02 2002 Subject: [ expat-Bugs-557531 ] "make check" fails Message-ID: Bugs item #557531, was opened at 2002-05-17 22:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=557531&group_id=10127 Category: None >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Chad Austin (aegis) Assigned to: Nobody/Anonymous (nobody) >Summary: "make check" fails Initial Comment: $ make check gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -Ilib - I. -o tests/runtests.o -c tests/runtests.c tests/runtests.c:2: check.h: No such file or directory make: *** [tests/runtests.o] Error 1 ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-21 23:37 Message: Logged In: YES user_id=3066 The test harness uses the "check" library, which is appearantly not installed on your system. This library is not (yet) as widely ported as Expat. See http://check.sourceforge.net/ for more information on the check library. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=557531&group_id=10127 From noreply@sourceforge.net Wed May 22 07:56:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed May 22 06:56:02 2002 Subject: [ expat-Bugs-552297 ] Request for skippedEntity handler Message-ID: Bugs item #552297, was opened at 2002-05-04 13:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=552297&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) Summary: Request for skippedEntity handler Initial Comment: It would be very useful if Expat reported skipped entities, like in the SAX2 specification. I have identified the following situations for that: B) External Entities are reported as skipped: - if no external entity ref handler is set - if the entity ref handler returns a special value (e.g. we can define 2 as meaning: "skip this one") B) Internal Entities are reported as skipped: - SetDefaultHandler was called (which turns off expansion of internal general entities) C) Any entity reference is reported as skipped - if no declaration is found & that is not an error (otherwise return a well-formedness error) Karl ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-22 09:55 Message: Logged In: YES user_id=290026 Thinking some more about it, I believe that the signature I proposed is overkill, and we can get away with his: typedef void (*XML_SkippedEntityHandler) (void *userData, const XML_Char *entityName, int is_parameter_entity); Reasons: In the old proposal there were two cases when PublicId and SystemId would have been reported: 1) The application decided to skip the entity and passed a return value of 2 from the ExternalEntityRefHandler 2) No ExternalEntityRefHandler was installed I think both of them don't need a skippedEntityHandler, because For 1) It is of no particular usefulness if the application code in the ExternalEntityRefHandler delegates the skip-notification back to Expat. This can be done directly from the handler at least as easily and efficiently, and Expat itself does not need this information, since the very fact of nothing being parsed is all that is important to it. For 2) If no ExternalEntityRefHandler is installed, then why install a skippedEntityHandler? They would have essentially the same signature, and in the end that would mean the same as in 1) - telling Expat we want to skip the entity. Again, that can already be easily achieved with the exisiting API. So, which events then remain that would require a skippedEntityHandler? Only when entity refs are encountered for which no declaration was read, *and* when this is not an error. Now, as far as Fred's suggestion of combining this with some InternalEntityRefHandler, is concerned: In that case we should also report the entity value. Would we not be mixing two different problems here? Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-16 19:44 Message: Logged In: YES user_id=3066 This feature description and proposed callback interface sounds good to me. We might want to think about how such a handler would interact with (or be combined with) a handler so that defined general entities (including "standard" ones like < and friends) can be reported, for applications that need to produce output with minimal changes. (This is commonly needed if the output is going to land in front of a human rather than another processing tool.) Let's target this for 1.95.4. Assigning to Karl since he's indicated specific interest. ;-) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-09 09:35 Message: Logged In: YES user_id=290026 I propose the following signature for the handler: enum XML_Skip_Reason { XML_SKIP_UNDEFINED, XML_SKIP_NOHANDLER, XML_SKIP_REQUESTED }; typedef void (*XML_SkippedEntityHandler) (void *userData, const XML_Char *entityName, int is_parameter_entity, const XML_Char *systemId, const XML_Char *publicId, enum XML_Skip_Reason skipReason); where the values of skipReason have the following meanings: - XML_SKIP_UNDEFINED: entity was skipped because no declaration was found, and this was not an error - XML_SKIP_NOHANDLER: entity was skipped because there was no ExternalEntityRefHandler installed - XML_SKIP_REQUESTED: the ExternalEntityRefHandler returned a value of 2, which means the handler requested the entity to be skipped I hope this makes sense. Comments welcome! Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=552297&group_id=10127 From noreply@sourceforge.net Wed May 22 13:52:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed May 22 12:52:05 2002 Subject: [ expat-Bugs-552297 ] Request for skippedEntity handler Message-ID: Bugs item #552297, was opened at 2002-05-04 13:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=552297&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) Summary: Request for skippedEntity handler Initial Comment: It would be very useful if Expat reported skipped entities, like in the SAX2 specification. I have identified the following situations for that: B) External Entities are reported as skipped: - if no external entity ref handler is set - if the entity ref handler returns a special value (e.g. we can define 2 as meaning: "skip this one") B) Internal Entities are reported as skipped: - SetDefaultHandler was called (which turns off expansion of internal general entities) C) Any entity reference is reported as skipped - if no declaration is found & that is not an error (otherwise return a well-formedness error) Karl ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-22 15:51 Message: Logged In: YES user_id=290026 I forgot case B) from the initial request. This would, of course, still be valid, but would also not require more than the simple callback interface I proposed. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-22 09:55 Message: Logged In: YES user_id=290026 Thinking some more about it, I believe that the signature I proposed is overkill, and we can get away with his: typedef void (*XML_SkippedEntityHandler) (void *userData, const XML_Char *entityName, int is_parameter_entity); Reasons: In the old proposal there were two cases when PublicId and SystemId would have been reported: 1) The application decided to skip the entity and passed a return value of 2 from the ExternalEntityRefHandler 2) No ExternalEntityRefHandler was installed I think both of them don't need a skippedEntityHandler, because For 1) It is of no particular usefulness if the application code in the ExternalEntityRefHandler delegates the skip-notification back to Expat. This can be done directly from the handler at least as easily and efficiently, and Expat itself does not need this information, since the very fact of nothing being parsed is all that is important to it. For 2) If no ExternalEntityRefHandler is installed, then why install a skippedEntityHandler? They would have essentially the same signature, and in the end that would mean the same as in 1) - telling Expat we want to skip the entity. Again, that can already be easily achieved with the exisiting API. So, which events then remain that would require a skippedEntityHandler? Only when entity refs are encountered for which no declaration was read, *and* when this is not an error. Now, as far as Fred's suggestion of combining this with some InternalEntityRefHandler, is concerned: In that case we should also report the entity value. Would we not be mixing two different problems here? Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-16 19:44 Message: Logged In: YES user_id=3066 This feature description and proposed callback interface sounds good to me. We might want to think about how such a handler would interact with (or be combined with) a handler so that defined general entities (including "standard" ones like < and friends) can be reported, for applications that need to produce output with minimal changes. (This is commonly needed if the output is going to land in front of a human rather than another processing tool.) Let's target this for 1.95.4. Assigning to Karl since he's indicated specific interest. ;-) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-09 09:35 Message: Logged In: YES user_id=290026 I propose the following signature for the handler: enum XML_Skip_Reason { XML_SKIP_UNDEFINED, XML_SKIP_NOHANDLER, XML_SKIP_REQUESTED }; typedef void (*XML_SkippedEntityHandler) (void *userData, const XML_Char *entityName, int is_parameter_entity, const XML_Char *systemId, const XML_Char *publicId, enum XML_Skip_Reason skipReason); where the values of skipReason have the following meanings: - XML_SKIP_UNDEFINED: entity was skipped because no declaration was found, and this was not an error - XML_SKIP_NOHANDLER: entity was skipped because there was no ExternalEntityRefHandler installed - XML_SKIP_REQUESTED: the ExternalEntityRefHandler returned a value of 2, which means the handler requested the entity to be skipped I hope this makes sense. Comments welcome! Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=552297&group_id=10127 From Alex.Gray@rbos.com Thu May 23 07:32:05 2002 From: Alex.Gray@rbos.com (GRAY, Alex, FM) Date: Thu May 23 06:32:05 2002 Subject: Compile question Message-ID: <410BB8BE8D1FD5118C9300508BB8B20305337F3D@lon3002xns.fm.rbsgrp.net> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ---------------------- multipart/mixed attachment Hi Expat Support, I was wondering if someone could help me with a compile problem (actually a configure problem before the make). I have tried using both GNU binaries and SUN binaries, but cannot get past the following problem when I try to configure a Makefile for the compilation of this program : <> Am I doing something woefully wrong here ? The machine is a Solaris 8 server. Rgds, Alex. ---------------------------------------------------------------------------- ------------ Alex Gray UNIX Server Support RBS Financial Markets 135, Bishopsgate London EC2M 3UR Telephone : +44.(0)20.7334.1637 (direct) Fax : +44.(0)20.7375.6114 Email : alex.gray@rbos.com ---------------------------------------------------------------------------- ------------ ******************************************************************** Visit our Internet site at http://www.rbsmarkets.com This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. ******************************************************************** ---------------------- multipart/mixed attachment root:lon0610xus# ./configure creating cache ./config.cache checking host system type... sparc-sun-solaris2.8 checking build system type... sparc-sun-solaris2.8 checking for ranlib... ranlib checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... yes checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking for ld used by GCC... /usr/local/bin/ld checking if the linker (/usr/local/bin/ld) is GNU ld... yes checking for BSD-compatible nm... /usr/ccs/bin/nm -p checking whether ln -s works... yes updating cache ./config.cache checking for object suffix... o checking for executable suffix... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC 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 if gcc static flag -static works... -static checking if the linker (/usr/local/bin/ld) is GNU ld... yes checking whether the linker (/usr/local/bin/ld) supports shared libraries... yes checking command to parse /usr/ccs/bin/nm -p output... ok checking how to hardcode library paths into programs... immediate checking for /usr/local/bin/ld option to reload object files... -r 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 checking for objdir... .libs creating libtool loading cache ./config.cache checking for gcc... (cached) gcc checking whether the C compiler (gcc -g -O2 ) works... yes checking whether the C compiler (gcc -g -O2 ) is a cross-compiler... yes checking whether we are using GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes checking for a BSD compatible install... conftools/install-sh -c checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for fcntl.h... yes checking for unistd.h... yes checking whether byte ordering is bigendian... cross-compiling... unknown checking to probe for byte ordering... guessing bigendian ... unknown configure: error: unknown endianess - sorry ---------------------- multipart/mixed attachment-- From gstein@lyra.org Thu May 23 11:35:05 2002 From: gstein@lyra.org (Greg Stein) Date: Thu May 23 10:35:05 2002 Subject: Compile question In-Reply-To: <410BB8BE8D1FD5118C9300508BB8B20305337F3D@lon3002xns.fm.rbsgrp.net>; from Alex.Gray@rbos.com on Thu, May 23, 2002 at 02:31:14PM +0100 References: <410BB8BE8D1FD5118C9300508BB8B20305337F3D@lon3002xns.fm.rbsgrp.net> Message-ID: <20020523103757.C21588@lyra.org> On Thu, May 23, 2002 at 02:31:14PM +0100, GRAY, Alex, FM wrote: >... > Hi Expat Support, > > I was wondering if someone could help me with a compile problem (actually a > configure problem before the make). > > I have tried using both GNU binaries and SUN binaries, but cannot get past > the following problem when I try to configure a Makefile for the compilation > of this program : > > <> > > Am I doing something woefully wrong here ? The machine is a Solaris 8 > server. I don't see anything in the configure output that would indicate the problem. Could you please attach your config.log file? (it gets produced when you run ./configure) Cheers, -g -- Greg Stein, http://www.lyra.org/ From Alex.Gray@rbos.com Thu May 23 11:42:03 2002 From: Alex.Gray@rbos.com (GRAY, Alex, FM) Date: Thu May 23 10:42:03 2002 Subject: Compile question Message-ID: <410BB8BE8D1FD5118C9300508BB8B20305337F41@lon3002xns.fm.rbsgrp.net> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ---------------------- multipart/mixed attachment Greg, Thank you very much for your reply. I was referring in my email to the last line : configure: error: unknown endianess - sorry but I also enclose the config.log file with this email. Is this really an error ? Rgds, Alex. -----Original Message----- From: Greg Stein [mailto:gstein@lyra.org] Sent: 23 May 2002 18:38 To: GRAY, Alex, FM Cc: 'expat-bugs@lists.sourceforge.net' Subject: Re: Compile question On Thu, May 23, 2002 at 02:31:14PM +0100, GRAY, Alex, FM wrote: >... > Hi Expat Support, > > I was wondering if someone could help me with a compile problem (actually a > configure problem before the make). > > I have tried using both GNU binaries and SUN binaries, but cannot get past > the following problem when I try to configure a Makefile for the compilation > of this program : > > <> > > Am I doing something woefully wrong here ? The machine is a Solaris 8 > server. I don't see anything in the configure output that would indicate the problem. Could you please attach your config.log file? (it gets produced when you run ./configure) Cheers, -g -- Greg Stein, http://www.lyra.org/ ******************************************************************** Visit our Internet site at http://www.rbsmarkets.com This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. ******************************************************************** ---------------------- multipart/mixed attachment This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. configure:648: checking host system type configure:669: checking build system type configure:689: checking for ranlib configure:719: checking for gcc configure:832: checking whether the C compiler (gcc ) works configure:848: gcc -o conftest conftest.c 1>&5 configure:874: checking whether the C compiler (gcc ) is a = cross-compiler configure:879: checking whether we are using GNU C configure:888: gcc -E conftest.c configure:907: checking whether gcc accepts -g configure:950: checking for ld used by GCC configure:1012: checking if the linker (/usr/local/bin/ld) is GNU ld GNU ld version 2.11 (with BFD 2.11) configure:1028: checking for BSD-compatible nm configure:1064: checking whether ln -s works ltconfig:603: checking for object suffix ltconfig:604: gcc -c -g -O2 conftest.c 1>&5 ltconfig:629: checking for executable suffix ltconfig:630: gcc -o conftest -g -O2 conftest.c 1>&5 ltconfig:776: checking if gcc PIC flag -fPIC works ltconfig:777: gcc -c -g -O2 -fPIC -DPIC conftest.c 1>&5 ltconfig:829: checking if gcc supports -c -o file.o ltconfig:830: gcc -c -g -O2 -o out/conftest2.o conftest.c 1>&5 ltconfig:862: checking if gcc supports -c -o file.lo ltconfig:863: gcc -c -g -O2 -c -o conftest.lo conftest.c 1>&5 ltconfig:914: checking if gcc supports -fno-rtti -fno-exceptions ltconfig:915: gcc -c -g -O2 -fno-rtti -fno-exceptions -c conftest.c = conftest.c 1>&5 ltconfig:958: checking if gcc static flag -static works ltconfig:959: gcc -o conftest -g -O2 -static conftest.c 1>&5 GNU ld version 2.11 (with BFD 2.11) ltconfig:1653: checking if global_symbol_pipe works ltconfig:1654: gcc -c -g -O2 conftest.c 1>&5 ltconfig:1657: eval "/usr/local/bin/nm -B conftest.o | sed -n -e = 's/^.*[ ]\([ABCDGISTW]\)[ ][ ]*\(\)\([_A-Za-z][_A-Za-z0-9]*\)$/\1 = \2\3 \3/p' > conftest.nm" ltconfig:1709: gcc -o conftest -g -O2 -fno-builtin -fno-rtti = -fno-exceptions conftest.c conftstm.o 1>&5 configure:1476: checking for gcc configure:1589: checking whether the C compiler (gcc -g -O2 ) works configure:1605: gcc -o conftest -g -O2 conftest.c 1>&5 configure:1631: checking whether the C compiler (gcc -g -O2 ) is a = cross-compiler configure:1636: checking whether we are using GNU C configure:1664: checking whether gcc accepts -g configure:1707: checking for a BSD compatible install configure:1766: checking how to run the C preprocessor configure:1787: gcc -E conftest.c >/dev/null 2>conftest.out configure:1846: checking for ANSI C header files configure:1859: gcc -E conftest.c >/dev/null 2>conftest.out configure:1953: checking for fcntl.h configure:1963: gcc -E conftest.c >/dev/null 2>conftest.out configure:1953: checking for unistd.h configure:1963: gcc -E conftest.c >/dev/null 2>conftest.out configure:1992: checking whether byte ordering is bigendian configure:2010: gcc -c -g -O2 -Wall -Wmissing-prototypes = -Wstrict-prototypes -fexceptions conftest.c 1>&5 configure:2002: warning: function declaration isn't a prototype configure: In function `main': configure:2005: `bogus' undeclared (first use in this function) configure:2005: (Each undeclared identifier is reported only once configure:2005: for each function it appears in.) configure:2005: parse error before "endian" configure: failed program was: #line 1999 "configure" #include "confdefs.h" #include #include int main() { #if !BYTE_ORDER || !BIG_ENDIAN || !LITTLE_ENDIAN bogus endian macros #endif ; return 0; } configure:2076: checking to probe for byte ordering ---------------------- multipart/mixed attachment-- From noreply@sourceforge.net Thu May 23 13:15:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu May 23 12:15:12 2002 Subject: [ expat-Bugs-432456 ] DLL name 'expat.dll' causes problems Message-ID: Bugs item #432456, was opened at 2001-06-12 12:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=432456&group_id=10127 Category: None Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Kevin Gilpin (kgilpin) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: DLL name 'expat.dll' causes problems Initial Comment: On Win32, when attempting to build the XML::Parser Perl module with expat, the name 'expat.dll' is used by both projects. This causes problems when running XML::Parser, because only one of the 2 dlls can be loaded. By changing the output target of expat to 'libexpat.dll' (and generating and linking against the corresponding libexpat.lib) I was able to get XML::Parser successfully built and running on Win NT. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-23 15:14 Message: Logged In: YES user_id=3066 While we may have some "right" to the name "expat" for the DLL, older versions of expat used "xmlparse" and "xmltok", and the Perl module started using "expat" (perhaps for some technical reason, since the Perl module is XML::Parser::Expat). I'll vote that we should call our DLL "libexpatutf8" when compiled for UTF-8 output, and "libexpatutf16" when compiled for UTF-16 output. Yeah, that's new for everyone, and annoying as hell, but beats making Expat support both output encodings in one compiled version. (Well, except when you really want both.) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-21 20:39 Message: Logged In: NO It took a coule of hours to get things working on my machine (Win2k sp2), so I thought I'd post what I did so others won't waste time. I'm not sure if what I did was the correct method, but it worked for me. 1) Download and extract the XML::Parser ZIP from CPAN. 3) Replace all occurances of "expat" with "libexpat" in all files. 3) Rename the Expat directory to libexpat. 4) Rename the expat.pm and expat.xs files accordingly. 5) Open libexpat.xs and change the #include back to #include 6) Build the make files (perl makefile.pl) 7) Open the libexpat makefile and change the PERLARCHIVE line to read (note, I put expat.h, dll, and lib in my perl\lib\CORE directory): PERL_ARCHIVE = $(PERL_INC)\perl56.lib $(PERL_INC) \expat.lib" 8) Run namke 9) Copy the PERL\lib\CORE\expat.dll to blib\arch\xml\parser\libexpat and run 'nmake test'. ---------------------------------------------------------------------- Comment By: Greg Stein (gstein) Date: 2002-05-17 20:55 Message: Logged In: YES user_id=6501 Calling the library expat2.dll would be fine with me. libexpat.dll might also be fine. But also note: *we* are Expat, not the Perl extension. We have more "right" to expat.dll if that is what we choose to do. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-10-01 18:08 Message: Logged In: YES user_id=3066 So this appearantly never worked with Expat 1.95+. Sigh. We could go back to xmlparse.dll I suppose, but I don't really like that. I don't know that we've retained enough compatibility with that. Perhaps "expat2" would be good enough, since the real target right now is a stable Expat 2.0. I'll think about this a little more, but I'd like to have it solved in Expat 1.95.3. Assigning to me since Clark has been abducted by aliens. ---------------------------------------------------------------------- Comment By: Kevin Gilpin (kgilpin) Date: 2001-10-01 17:51 Message: Logged In: YES user_id=44882 The problem is that the Perl extension consists of 2 dlls: 1) the expat DLL, which does not contain any perl references 2) the perl -> expat DLL, which references both the Perl APIs and the Expat APIs Both of these DLLs are called 'expat.dll', which is a problem b/c Windows will cannot tell the difference between them when the Perl program is run ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-10-01 16:26 Message: Logged In: YES user_id=3066 Thinking about this again, I realize I don't know enough about the Perl extension machinery and mod_perl to be sure of this. Is mod_perl providing an expat.dll which is something different, or is it a different version of that mod_perl uses? We need a mod_perl/XML::Parser expert to answer reports like this one! Leaving this one assigned to Clark until we have such a person with available time. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-25 12:39 Message: Logged In: YES user_id=3066 This relates to having multiple versions of the library being made available in the same process. Assigned to Clark since he might have more of the context information related to XML::Parser. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=432456&group_id=10127 From noreply@sourceforge.net Thu May 23 13:36:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu May 23 12:36:01 2002 Subject: [ expat-Patches-551599 ] Patch for # 544679, 548690, 549014, 551852, 553318 Message-ID: Patches item #551599, was opened at 2002-05-02 16:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=551599&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for # 544679, 548690, 549014, 551852, 553318 Initial Comment: This is an extensive patch, and needs not only testing, but also a review by my fellow developers! It addresses these issues: # 483514 (default handler reports too much from DTD): only the following data are reported now: - ignored DTD sections - unhandled external parameter entity references - top level whitespace This may not be what is needed, but more would have been a lot of work # 544679, 548690 (DTD handling of external entities): - the storeEntityValue function has been modified to call the external entity reference handler, since it did not handle external PE references at all - a new STRING_POOL has been added that gets passed from a parent to a child parser (member of DTD structure), so that entity values can be built across parsers - new functions entityValueInitProcessor and entityValueProcessor have been added - the old usage of dtd.complete was completely changed - I never understood how it worked, and it didn't work properly anyway; therefore there is a danger now that some logic will not work anymore - please review and check - the usage of hadExternalDoctype was modified too - there have been changes in xmlrole.c too - the chain of state handlers was extended from entity9 to entity10 - in analogy to how general entities - please review the diff file - as a result, this patch now processes all of James Clark's test cases in the /valid/not-sa and /valid/ext-sa directories properly * I have also made some fixes to the recently introduced XML_ParserReset function (incl. changing it's return type), and one fix that prevents a null pointer error The patch is based on these revisions: - expat.h rev. 1.17 - xmlparse.c rev. 1.31 - xmlrole.c rev. 1.5 - xmlrole.h rev. 1.3 I have included the full patch files, an annotated version of xmlparse.c - good to understand my changes, and the diff files. Karl ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-23 15:35 Message: Logged In: YES user_id=3066 Karl, can you delete the attachments that are no longer current? There are just too many to filter through! Thanks! Does your CVS client not allow you to create a single patch file with diffs for all changed files? The typical command-line client let's me say "cvs diff" at the top of the tree and I get a single patch output on standard output. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-19 17:10 Message: Logged In: YES user_id=13222 I've done a lot of testing, with expat CVS HEAD and this patch applied (and had some pleasant mail conversation with Karl, about the nifty details and the findings.) Let me first confirm, that I was able to reproduce the following bugs related to this patch: 548690 and 544679 (They describe the same behavior.) 549014 (I've already submitted comments to this bug) 544679 There's also a known bug (for which I wasn't able to find the bug nr, sorry), about XML_EntityDeclHandler() is not reporting declarations of external PE references. This I also have to confirm (examples are xmltest/valid/not-sa/005.xml, 011.xml, 012.xml, 026.xml out of the below mentioned test suite). Can't say something about the bugs 553318 and 549014 because I haven't tried to confirm the described bugs. Summary of my findings: The patch seems to fix at least 548690, 544679, 549014, 544679 and the problem with not reported declaration of external PE references. I doesn't found any new problem introduced by the patch. See below for a description of what I've done. That said, I still have an objection. With this patch applied, there is no way to detect, if a parameter entity is not declared, even if you read all external parameter entities, because now expat skip silently all not resolvable entities, if a document has an external subset or external parameter entities. Bug 552297 would be a way, to handle this. What I've done: I've mainly used the OASIS XML test suite, second edtion. You'll find it at http://www.oasis-open.org/committees/xml-conformance/suite-v1se/xmlconf-20010315.htm This testsuite includes several testpackages, contributed by different parties. Most of them split the tests in not-wellformed, valid, and in-valid tests. With a few simple shell scripts and xmlwf (with the option -p), I've checked all not-wellformed tests (all should produce an error) and all valid test (since they are a valid, the must be well-formed and therefor should all pass without an error.) Only in single cases I've checked, if the error reason, given by xmlwf is the one, the OASIS test suite expects; for most of the not-wellformed tests, I could only claim, that xmlwf does report an error, but could not say, if it's the 'right' error. I've run my test scripts with expat-1.92, with expat CVS HEAD, and with expat CVS HEAD with Karl's patch added. Expat 1.95.2 and expat CVS HEAD had the same results: xmltest/valid/not-sa/003.xml xmltest/valid/not-sa/004.xml xmltest/valid/not-sa/031.xml ibm/not-wf/misc/432gewf.xml sun/not-wf/uri01.xml where wrong. 003.xml, 004.xml and 031.xml are examples for bug 544679. The problem with 432gwf.xml is, that this file includes the entity declaration "> The replace text does not conform to production 79 (see XML rec 4.3.2). The entity isn't actually used, in the document (if it would be used, expat would report an error. It seems to me, expat does not check the replace text angainst production 79 at declaration time. This is a real problem, but more a minor one. The problem with uri01.xml is, that this document uses a fragment identifier in the SYSTEM of an external entity declaration. This is in deed not allowed (see XML rec 4.2.2), but the rec say: "[A]n XML processor may signal an error if a fragment identifier is given as part of a system identifier". So, first, this is "may" and not "must" and, second, since you have to provide your external entity resolver by yourself, with the expat library, this could be handled at application level, if the programmer want this. Therefor I would rank this as a very minor problem, if ever. Expat with Karl's patch had the results: xmltest/not-wf/not-sa/005.xml ibm/not-wf/misc/432gewf.xml sun/not-wf/uri01.xml 003.xml, 004.xml and 031.xml from above are fixed. 005.xml is a questionable test. It uses in an external parameter entity a not declared parameter entity. The test suite expects the parser, to claim about this. But since this is a well-formedness test and the document has references to external parameter entities, the "Well-Formedness Constraint: Entity Declared" of production 68 does not apply. Therefor, Karl argues that this test tests the "Validity Constraint: Entity Declared" of production 68 and 69. He has already written a mail about this to the OASIS XML compliance group about this. (I personally still feel a bit uncomfortable about this. Since Karl has the spec on his side (if you read it literal, The oasis testpackage of the testsuite is not organized along this not-wf, valid and not-valid scheme. Instead, there are a couple of "fail" and "pass" tests. All "pass" tests passes xmlwf without error. The "fail" tests p06fail1.xml p08fail1.xml p08fail2.xml p16fail3.xml doesn't trigger an error. But all four tests are testing problems, that are only detected by validating parsers (the test files notices that explicitly). Additional, I've compared the output produced by xmlwf, if you use -d option for all valid tests, for which an expected output was given. Due to a few differences between the canonical output, expected by the OASIS test suite, and the canonnical XML output, produced by xmlwf (which is, I suspect, 'James Clark canonical XML', see http://jclark.com/xml/canonxml.html), I had to check some cases by hand. Expat-1.95.2, expat HEAD and expat with Karl's patch produced byte-identical output. While comparing the expat output with what the OASIS test suites expect, I found three interesting cases. xmltest/valid/sa/098.xml This test includes a processing instruction with a DOS end-of-line sequence (0d 0a). In the expat output this end-of-line marker is 'normalized' to the XML standard (only 0a). The expected output still has the 0d 0a from the document. ibm/valid/P02/ibm02v01.xml This is a crazy case. I argue, that this test is not well-formed XML, because it includes an illegal UTF-8 sequenz. xmlwf passes the document, but the xmlwf result differs from the expected result. I'm not surprised, that expat does not detect the ill-formed UTF-8 (see bug 477667). (Well, I'm a bit surprised, that the test is included als valid test..) sun/valid/sa02.xml The problem is a difference in attribute value normalization (interesting enought, expat seems to follow E70 of http://www.w3.org/XML/xml-19980210-errata for the handling of #xD and #xA.) To check the mentioned problem with the reporting of declaration of external parameter entity references, I've used the expat binding from http://sdf.lonestar.org/~loewerj/tdom.cgi xmltest/valid/not-sa/005.xml xmltest/valid/not-sa/011.xml xmltest/valid/not-sa/012.xml xmltest/valid/not-sa/026.xml are examples which showed, that expat 1.95.2 and expat CVS sometimes doesn't report entity declarations via XML_EntityDeclHandler. With Karls patch applied, the declarations get reported. I've an application, that is able to trigger the bug 549014. Using the memory debugger mpatrol ( http://www.cbmamiga.demon.co.uk/mpatrol/ ) I could show, that the seg fault happens at the place, the analysis to 549014 explains. After applying Karl's patch, the seg fault is vanished. Don't hesitate to ask, If you need more info about one of the discussed points. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-12 20:23 Message: Logged In: YES user_id=290026 There were only a few modifications necessary to make this patch perform well under testing: - It did not compile when XML_DTD was not defined - fixed - forgot to adjust the appendAttribute() function for the modifications in DTD handling logic - fixed This is the final version of the patch - check the new file xmlparse_final.c (and the diff created from it). So, to get the full final patch, download expat.h, xmlrole.h, xmlrole.c and xmlparse_final.c from the set of attached files. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-07 11:53 Message: Logged In: YES user_id=290026 This is the second improvement and probably the final version of the patch. If there should be more changes, a new patch will be entered, since it might get confusing otherwise. The following changes have been made: - some improvements on external PE reference handling - a better fix (hopefully) for bug # 549014 - the changes to DefaultHandler calls for DTDs have been undone - I realized that more extensive changes (also to xmlrole.c and xmlrole.h) would be necessary, so the old behaviour is back: everything for DTDs is reported, even if handlers are set, except for PIs, Comments and XML text declarations. This patch now applies to the following bugs: - # 553318 - # 551852 - # 549014 - # 548690 - # 544679 Uploaded as files xmlparse_2.c and xmlparse_2.c.diff. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 13:13 Message: Logged In: YES user_id=290026 I improved the patch to cover one more problem: I found that bug # 551852 (BOM problem with small buffers), that was reported for general external entities, also applied to external parameter entities. This problem only applied to this patch, since the current release of Expat simply ignores external PEs (which causes bug # 548690). Included is also a fix for bug # 549014 (dtdCopy problem). The attached file are xmlparse_1.c, xmlparse_1.c.annotated and xmlparse_1.diff (against rev. 1.31). Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 10:09 Message: Logged In: YES user_id=290026 Forgot to add: the fix for bug # 551852 is included too. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=551599&group_id=10127 From noreply@sourceforge.net Thu May 23 13:47:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu May 23 12:47:05 2002 Subject: [ expat-Patches-551599 ] Patch for # 544679, 548690, 549014, 551852, 553318 Message-ID: Patches item #551599, was opened at 2002-05-02 16:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=551599&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for # 544679, 548690, 549014, 551852, 553318 Initial Comment: This is an extensive patch, and needs not only testing, but also a review by my fellow developers! It addresses these issues: # 483514 (default handler reports too much from DTD): only the following data are reported now: - ignored DTD sections - unhandled external parameter entity references - top level whitespace This may not be what is needed, but more would have been a lot of work # 544679, 548690 (DTD handling of external entities): - the storeEntityValue function has been modified to call the external entity reference handler, since it did not handle external PE references at all - a new STRING_POOL has been added that gets passed from a parent to a child parser (member of DTD structure), so that entity values can be built across parsers - new functions entityValueInitProcessor and entityValueProcessor have been added - the old usage of dtd.complete was completely changed - I never understood how it worked, and it didn't work properly anyway; therefore there is a danger now that some logic will not work anymore - please review and check - the usage of hadExternalDoctype was modified too - there have been changes in xmlrole.c too - the chain of state handlers was extended from entity9 to entity10 - in analogy to how general entities - please review the diff file - as a result, this patch now processes all of James Clark's test cases in the /valid/not-sa and /valid/ext-sa directories properly * I have also made some fixes to the recently introduced XML_ParserReset function (incl. changing it's return type), and one fix that prevents a null pointer error The patch is based on these revisions: - expat.h rev. 1.17 - xmlparse.c rev. 1.31 - xmlrole.c rev. 1.5 - xmlrole.h rev. 1.3 I have included the full patch files, an annotated version of xmlparse.c - good to understand my changes, and the diff files. Karl ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-23 15:46 Message: Logged In: YES user_id=290026 OK, I deleted a few, but not all. I think it is important to be able to trace through the changes I made. (at least for me, this is where I would go to check what I did and why I did it) Also, the annotated versions explain a lot of the patch, and these explanations are not present in the final files. Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-23 15:35 Message: Logged In: YES user_id=3066 Karl, can you delete the attachments that are no longer current? There are just too many to filter through! Thanks! Does your CVS client not allow you to create a single patch file with diffs for all changed files? The typical command-line client let's me say "cvs diff" at the top of the tree and I get a single patch output on standard output. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-19 17:10 Message: Logged In: YES user_id=13222 I've done a lot of testing, with expat CVS HEAD and this patch applied (and had some pleasant mail conversation with Karl, about the nifty details and the findings.) Let me first confirm, that I was able to reproduce the following bugs related to this patch: 548690 and 544679 (They describe the same behavior.) 549014 (I've already submitted comments to this bug) 544679 There's also a known bug (for which I wasn't able to find the bug nr, sorry), about XML_EntityDeclHandler() is not reporting declarations of external PE references. This I also have to confirm (examples are xmltest/valid/not-sa/005.xml, 011.xml, 012.xml, 026.xml out of the below mentioned test suite). Can't say something about the bugs 553318 and 549014 because I haven't tried to confirm the described bugs. Summary of my findings: The patch seems to fix at least 548690, 544679, 549014, 544679 and the problem with not reported declaration of external PE references. I doesn't found any new problem introduced by the patch. See below for a description of what I've done. That said, I still have an objection. With this patch applied, there is no way to detect, if a parameter entity is not declared, even if you read all external parameter entities, because now expat skip silently all not resolvable entities, if a document has an external subset or external parameter entities. Bug 552297 would be a way, to handle this. What I've done: I've mainly used the OASIS XML test suite, second edtion. You'll find it at http://www.oasis-open.org/committees/xml-conformance/suite-v1se/xmlconf-20010315.htm This testsuite includes several testpackages, contributed by different parties. Most of them split the tests in not-wellformed, valid, and in-valid tests. With a few simple shell scripts and xmlwf (with the option -p), I've checked all not-wellformed tests (all should produce an error) and all valid test (since they are a valid, the must be well-formed and therefor should all pass without an error.) Only in single cases I've checked, if the error reason, given by xmlwf is the one, the OASIS test suite expects; for most of the not-wellformed tests, I could only claim, that xmlwf does report an error, but could not say, if it's the 'right' error. I've run my test scripts with expat-1.92, with expat CVS HEAD, and with expat CVS HEAD with Karl's patch added. Expat 1.95.2 and expat CVS HEAD had the same results: xmltest/valid/not-sa/003.xml xmltest/valid/not-sa/004.xml xmltest/valid/not-sa/031.xml ibm/not-wf/misc/432gewf.xml sun/not-wf/uri01.xml where wrong. 003.xml, 004.xml and 031.xml are examples for bug 544679. The problem with 432gwf.xml is, that this file includes the entity declaration "> The replace text does not conform to production 79 (see XML rec 4.3.2). The entity isn't actually used, in the document (if it would be used, expat would report an error. It seems to me, expat does not check the replace text angainst production 79 at declaration time. This is a real problem, but more a minor one. The problem with uri01.xml is, that this document uses a fragment identifier in the SYSTEM of an external entity declaration. This is in deed not allowed (see XML rec 4.2.2), but the rec say: "[A]n XML processor may signal an error if a fragment identifier is given as part of a system identifier". So, first, this is "may" and not "must" and, second, since you have to provide your external entity resolver by yourself, with the expat library, this could be handled at application level, if the programmer want this. Therefor I would rank this as a very minor problem, if ever. Expat with Karl's patch had the results: xmltest/not-wf/not-sa/005.xml ibm/not-wf/misc/432gewf.xml sun/not-wf/uri01.xml 003.xml, 004.xml and 031.xml from above are fixed. 005.xml is a questionable test. It uses in an external parameter entity a not declared parameter entity. The test suite expects the parser, to claim about this. But since this is a well-formedness test and the document has references to external parameter entities, the "Well-Formedness Constraint: Entity Declared" of production 68 does not apply. Therefor, Karl argues that this test tests the "Validity Constraint: Entity Declared" of production 68 and 69. He has already written a mail about this to the OASIS XML compliance group about this. (I personally still feel a bit uncomfortable about this. Since Karl has the spec on his side (if you read it literal, The oasis testpackage of the testsuite is not organized along this not-wf, valid and not-valid scheme. Instead, there are a couple of "fail" and "pass" tests. All "pass" tests passes xmlwf without error. The "fail" tests p06fail1.xml p08fail1.xml p08fail2.xml p16fail3.xml doesn't trigger an error. But all four tests are testing problems, that are only detected by validating parsers (the test files notices that explicitly). Additional, I've compared the output produced by xmlwf, if you use -d option for all valid tests, for which an expected output was given. Due to a few differences between the canonical output, expected by the OASIS test suite, and the canonnical XML output, produced by xmlwf (which is, I suspect, 'James Clark canonical XML', see http://jclark.com/xml/canonxml.html), I had to check some cases by hand. Expat-1.95.2, expat HEAD and expat with Karl's patch produced byte-identical output. While comparing the expat output with what the OASIS test suites expect, I found three interesting cases. xmltest/valid/sa/098.xml This test includes a processing instruction with a DOS end-of-line sequence (0d 0a). In the expat output this end-of-line marker is 'normalized' to the XML standard (only 0a). The expected output still has the 0d 0a from the document. ibm/valid/P02/ibm02v01.xml This is a crazy case. I argue, that this test is not well-formed XML, because it includes an illegal UTF-8 sequenz. xmlwf passes the document, but the xmlwf result differs from the expected result. I'm not surprised, that expat does not detect the ill-formed UTF-8 (see bug 477667). (Well, I'm a bit surprised, that the test is included als valid test..) sun/valid/sa02.xml The problem is a difference in attribute value normalization (interesting enought, expat seems to follow E70 of http://www.w3.org/XML/xml-19980210-errata for the handling of #xD and #xA.) To check the mentioned problem with the reporting of declaration of external parameter entity references, I've used the expat binding from http://sdf.lonestar.org/~loewerj/tdom.cgi xmltest/valid/not-sa/005.xml xmltest/valid/not-sa/011.xml xmltest/valid/not-sa/012.xml xmltest/valid/not-sa/026.xml are examples which showed, that expat 1.95.2 and expat CVS sometimes doesn't report entity declarations via XML_EntityDeclHandler. With Karls patch applied, the declarations get reported. I've an application, that is able to trigger the bug 549014. Using the memory debugger mpatrol ( http://www.cbmamiga.demon.co.uk/mpatrol/ ) I could show, that the seg fault happens at the place, the analysis to 549014 explains. After applying Karl's patch, the seg fault is vanished. Don't hesitate to ask, If you need more info about one of the discussed points. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-12 20:23 Message: Logged In: YES user_id=290026 There were only a few modifications necessary to make this patch perform well under testing: - It did not compile when XML_DTD was not defined - fixed - forgot to adjust the appendAttribute() function for the modifications in DTD handling logic - fixed This is the final version of the patch - check the new file xmlparse_final.c (and the diff created from it). So, to get the full final patch, download expat.h, xmlrole.h, xmlrole.c and xmlparse_final.c from the set of attached files. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-07 11:53 Message: Logged In: YES user_id=290026 This is the second improvement and probably the final version of the patch. If there should be more changes, a new patch will be entered, since it might get confusing otherwise. The following changes have been made: - some improvements on external PE reference handling - a better fix (hopefully) for bug # 549014 - the changes to DefaultHandler calls for DTDs have been undone - I realized that more extensive changes (also to xmlrole.c and xmlrole.h) would be necessary, so the old behaviour is back: everything for DTDs is reported, even if handlers are set, except for PIs, Comments and XML text declarations. This patch now applies to the following bugs: - # 553318 - # 551852 - # 549014 - # 548690 - # 544679 Uploaded as files xmlparse_2.c and xmlparse_2.c.diff. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 13:13 Message: Logged In: YES user_id=290026 I improved the patch to cover one more problem: I found that bug # 551852 (BOM problem with small buffers), that was reported for general external entities, also applied to external parameter entities. This problem only applied to this patch, since the current release of Expat simply ignores external PEs (which causes bug # 548690). Included is also a fix for bug # 549014 (dtdCopy problem). The attached file are xmlparse_1.c, xmlparse_1.c.annotated and xmlparse_1.diff (against rev. 1.31). Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 10:09 Message: Logged In: YES user_id=290026 Forgot to add: the fix for bug # 551852 is included too. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=551599&group_id=10127 From noreply@sourceforge.net Thu May 23 19:07:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu May 23 18:07:03 2002 Subject: [ expat-Patches-559910 ] SkippedEntityHandler added Message-ID: Patches item #559910, was opened at 2002-05-23 21:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=559910&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) Summary: SkippedEntityHandler added Initial Comment: This patch is an implementation of bug/feature request # 552297. It implements the simplified version of the original proposal. The skippedEntityHandler is called in two situations: 1) An entity reference is encountered for which no declaration has been read *and* this is not an error. 2) An internal entity reference is read, but not expanded, because XML_SetDefaultHandler has been called. The attached Diff file is based on expat.h rev. 1.22 and xmlparse.c rev. 1.41. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=559910&group_id=10127 From noreply@sourceforge.net Thu May 23 19:10:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu May 23 18:10:05 2002 Subject: [ expat-Bugs-552297 ] Request for skippedEntity handler Message-ID: Bugs item #552297, was opened at 2002-05-04 13:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=552297&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) Summary: Request for skippedEntity handler Initial Comment: It would be very useful if Expat reported skipped entities, like in the SAX2 specification. I have identified the following situations for that: B) External Entities are reported as skipped: - if no external entity ref handler is set - if the entity ref handler returns a special value (e.g. we can define 2 as meaning: "skip this one") B) Internal Entities are reported as skipped: - SetDefaultHandler was called (which turns off expansion of internal general entities) C) Any entity reference is reported as skipped - if no declaration is found & that is not an error (otherwise return a well-formedness error) Karl ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-23 21:09 Message: Logged In: YES user_id=290026 Have a look at patch # 559910, where the latest, simplified proposal is implemented. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-22 15:51 Message: Logged In: YES user_id=290026 I forgot case B) from the initial request. This would, of course, still be valid, but would also not require more than the simple callback interface I proposed. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-22 09:55 Message: Logged In: YES user_id=290026 Thinking some more about it, I believe that the signature I proposed is overkill, and we can get away with his: typedef void (*XML_SkippedEntityHandler) (void *userData, const XML_Char *entityName, int is_parameter_entity); Reasons: In the old proposal there were two cases when PublicId and SystemId would have been reported: 1) The application decided to skip the entity and passed a return value of 2 from the ExternalEntityRefHandler 2) No ExternalEntityRefHandler was installed I think both of them don't need a skippedEntityHandler, because For 1) It is of no particular usefulness if the application code in the ExternalEntityRefHandler delegates the skip-notification back to Expat. This can be done directly from the handler at least as easily and efficiently, and Expat itself does not need this information, since the very fact of nothing being parsed is all that is important to it. For 2) If no ExternalEntityRefHandler is installed, then why install a skippedEntityHandler? They would have essentially the same signature, and in the end that would mean the same as in 1) - telling Expat we want to skip the entity. Again, that can already be easily achieved with the exisiting API. So, which events then remain that would require a skippedEntityHandler? Only when entity refs are encountered for which no declaration was read, *and* when this is not an error. Now, as far as Fred's suggestion of combining this with some InternalEntityRefHandler, is concerned: In that case we should also report the entity value. Would we not be mixing two different problems here? Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-16 19:44 Message: Logged In: YES user_id=3066 This feature description and proposed callback interface sounds good to me. We might want to think about how such a handler would interact with (or be combined with) a handler so that defined general entities (including "standard" ones like < and friends) can be reported, for applications that need to produce output with minimal changes. (This is commonly needed if the output is going to land in front of a human rather than another processing tool.) Let's target this for 1.95.4. Assigning to Karl since he's indicated specific interest. ;-) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-09 09:35 Message: Logged In: YES user_id=290026 I propose the following signature for the handler: enum XML_Skip_Reason { XML_SKIP_UNDEFINED, XML_SKIP_NOHANDLER, XML_SKIP_REQUESTED }; typedef void (*XML_SkippedEntityHandler) (void *userData, const XML_Char *entityName, int is_parameter_entity, const XML_Char *systemId, const XML_Char *publicId, enum XML_Skip_Reason skipReason); where the values of skipReason have the following meanings: - XML_SKIP_UNDEFINED: entity was skipped because no declaration was found, and this was not an error - XML_SKIP_NOHANDLER: entity was skipped because there was no ExternalEntityRefHandler installed - XML_SKIP_REQUESTED: the ExternalEntityRefHandler returned a value of 2, which means the handler requested the entity to be skipped I hope this makes sense. Comments welcome! Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=552297&group_id=10127 From noreply@sourceforge.net Fri May 24 10:34:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 24 09:34:02 2002 Subject: [ expat-Bugs-557530 ] Cygwin install fails Message-ID: Bugs item #557530, was opened at 2002-05-17 22:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=557530&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None >Priority: 6 Submitted By: Chad Austin (aegis) Assigned to: Greg Stein (gstein) Summary: Cygwin install fails Initial Comment: Building expat within Cygwin succeeds now, but 'make install' fails. $ gmake install /bin/sh ./conftools/mkinstalldirs /usr/local/bin /usr/local/lib /usr/local/inclu de /bin/sh ./libtool --mode=install /usr/bin/install -c xmlwf/xmlwf /usr/local/bin/ xmlwf libtool: install: warning: `lib/libexpat.la' has not been installed in `/usr/loc al/lib' /usr/bin/install -c xmlwf/.libs/xmlwf /usr/local/bin/xmlwf /bin/sh ./libtool --mode=install /usr/bin/install -c lib/libexpat.la /usr/local/ lib/libexpat.la /usr/bin/install -c lib/.libs/libexpat.dll.a /usr/local/lib/libexpat.dll.a dlpath=`bash 2>&1 -c '. lib/.libs/lib/libexpat.lai;echo $dlname'` dldir=/usr/local/lib/`dirname $dlpath` dirname: too many arguments Try `dirname --help' for more information. make: *** [install] Error 1 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=557530&group_id=10127 From noreply@sourceforge.net Fri May 24 10:34:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 24 09:34:05 2002 Subject: [ expat-Bugs-484233 ] libexpat.so major version Message-ID: Bugs item #484233, was opened at 2001-11-21 11:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=484233&group_id=10127 Category: Build control Group: None Status: Open Resolution: None >Priority: 6 Submitted By: Ed Avis (epaepa) Assigned to: Greg Stein (gstein) Summary: libexpat.so major version Initial Comment: The newer expat releases build a shared library, but they decide to call it libexpat.so.0. Surely since the expat version itself is 1.95, the library should be installed as libexpat.so.1.95 and libexpat.so.1? It is certainly a bit odd to pick the major number zero; third parties who have built shared libraries from older expat distributions probably chose 1, so it looks like the version number is going downwards. Suggest making the shared library version match the expat version, and increasing the major soname when backwards-incompatible API changes are introduced. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=484233&group_id=10127 From noreply@sourceforge.net Fri May 24 13:19:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 24 12:19:03 2002 Subject: [ expat-Patches-559910 ] SkippedEntityHandler added Message-ID: Patches item #559910, was opened at 2002-05-23 21:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=559910&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) Summary: SkippedEntityHandler added Initial Comment: This patch is an implementation of bug/feature request # 552297. It implements the simplified version of the original proposal. The skippedEntityHandler is called in two situations: 1) An entity reference is encountered for which no declaration has been read *and* this is not an error. 2) An internal entity reference is read, but not expanded, because XML_SetDefaultHandler has been called. The attached Diff file is based on expat.h rev. 1.22 and xmlparse.c rev. 1.41. Karl ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-24 15:18 Message: Logged In: YES user_id=290026 Added the full files for those non-Unix people (like me) that are not used to diff and patch Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=559910&group_id=10127 From noreply@sourceforge.net Fri May 24 22:07:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 24 21:07:02 2002 Subject: [ expat-Bugs-432456 ] DLL name 'expat.dll' causes problems Message-ID: Bugs item #432456, was opened at 2001-06-12 12:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=432456&group_id=10127 Category: None Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Kevin Gilpin (kgilpin) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: DLL name 'expat.dll' causes problems Initial Comment: On Win32, when attempting to build the XML::Parser Perl module with expat, the name 'expat.dll' is used by both projects. This causes problems when running XML::Parser, because only one of the 2 dlls can be loaded. By changing the output target of expat to 'libexpat.dll' (and generating and linking against the corresponding libexpat.lib) I was able to get XML::Parser successfully built and running on Win NT. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-25 00:06 Message: Logged In: YES user_id=290026 On Linux I was already using libexpat.so and libexpatw.so (w stands for "wide"). So, why not use libexpat.dll and libexpatw.dll? Just to create confusion, Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-23 15:14 Message: Logged In: YES user_id=3066 While we may have some "right" to the name "expat" for the DLL, older versions of expat used "xmlparse" and "xmltok", and the Perl module started using "expat" (perhaps for some technical reason, since the Perl module is XML::Parser::Expat). I'll vote that we should call our DLL "libexpatutf8" when compiled for UTF-8 output, and "libexpatutf16" when compiled for UTF-16 output. Yeah, that's new for everyone, and annoying as hell, but beats making Expat support both output encodings in one compiled version. (Well, except when you really want both.) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-21 20:39 Message: Logged In: NO It took a coule of hours to get things working on my machine (Win2k sp2), so I thought I'd post what I did so others won't waste time. I'm not sure if what I did was the correct method, but it worked for me. 1) Download and extract the XML::Parser ZIP from CPAN. 3) Replace all occurances of "expat" with "libexpat" in all files. 3) Rename the Expat directory to libexpat. 4) Rename the expat.pm and expat.xs files accordingly. 5) Open libexpat.xs and change the #include back to #include 6) Build the make files (perl makefile.pl) 7) Open the libexpat makefile and change the PERLARCHIVE line to read (note, I put expat.h, dll, and lib in my perl\lib\CORE directory): PERL_ARCHIVE = $(PERL_INC)\perl56.lib $(PERL_INC) \expat.lib" 8) Run namke 9) Copy the PERL\lib\CORE\expat.dll to blib\arch\xml\parser\libexpat and run 'nmake test'. ---------------------------------------------------------------------- Comment By: Greg Stein (gstein) Date: 2002-05-17 20:55 Message: Logged In: YES user_id=6501 Calling the library expat2.dll would be fine with me. libexpat.dll might also be fine. But also note: *we* are Expat, not the Perl extension. We have more "right" to expat.dll if that is what we choose to do. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-10-01 18:08 Message: Logged In: YES user_id=3066 So this appearantly never worked with Expat 1.95+. Sigh. We could go back to xmlparse.dll I suppose, but I don't really like that. I don't know that we've retained enough compatibility with that. Perhaps "expat2" would be good enough, since the real target right now is a stable Expat 2.0. I'll think about this a little more, but I'd like to have it solved in Expat 1.95.3. Assigning to me since Clark has been abducted by aliens. ---------------------------------------------------------------------- Comment By: Kevin Gilpin (kgilpin) Date: 2001-10-01 17:51 Message: Logged In: YES user_id=44882 The problem is that the Perl extension consists of 2 dlls: 1) the expat DLL, which does not contain any perl references 2) the perl -> expat DLL, which references both the Perl APIs and the Expat APIs Both of these DLLs are called 'expat.dll', which is a problem b/c Windows will cannot tell the difference between them when the Perl program is run ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-10-01 16:26 Message: Logged In: YES user_id=3066 Thinking about this again, I realize I don't know enough about the Perl extension machinery and mod_perl to be sure of this. Is mod_perl providing an expat.dll which is something different, or is it a different version of that mod_perl uses? We need a mod_perl/XML::Parser expert to answer reports like this one! Leaving this one assigned to Clark until we have such a person with available time. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-25 12:39 Message: Logged In: YES user_id=3066 This relates to having multiple versions of the library being made available in the same process. Assigned to Clark since he might have more of the context information related to XML::Parser. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=432456&group_id=10127 From noreply@sourceforge.net Fri May 24 22:12:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 24 21:12:01 2002 Subject: [ expat-Bugs-558977 ] Avoid breaking PCDATA at line ends Message-ID: Bugs item #558977, was opened at 2002-05-21 22:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=558977&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 4 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Nobody/Anonymous (nobody) Summary: Avoid breaking PCDATA at line ends Initial Comment: Many applications are poorly served by the line-breaking behavior in which a separate call to the character data handler is made for line content and the line terminator. (Others probably rely on it, even though they shouldn't.) An option to attempt to use the smallest possible number of calls to the character data handler (without changing the buffer management) would be welcome, especially to the implementors and users of scripting-language bindings to Expat. (This in particular is interesting since the call overhead tends to be much higher than plain C callbacks primarily due to the construction of temporary data structures.) ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-25 00:11 Message: Logged In: YES user_id=290026 I don't think that is trivial. Another option could be to accumulate character data from adjacent character handler calls, and only call out to the scripting language when another handler "interrupts" the character data. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=558977&group_id=10127 From noreply@sourceforge.net Sat May 25 04:02:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat May 25 03:02:01 2002 Subject: [ expat-Bugs-432456 ] DLL name 'expat.dll' causes problems Message-ID: Bugs item #432456, was opened at 2001-06-12 18:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=432456&group_id=10127 Category: None Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Kevin Gilpin (kgilpin) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: DLL name 'expat.dll' causes problems Initial Comment: On Win32, when attempting to build the XML::Parser Perl module with expat, the name 'expat.dll' is used by both projects. This causes problems when running XML::Parser, because only one of the 2 dlls can be loaded. By changing the output target of expat to 'libexpat.dll' (and generating and linking against the corresponding libexpat.lib) I was able to get XML::Parser successfully built and running on Win NT. ---------------------------------------------------------------------- Comment By: Gerrit Haase (siebenschlaefer) Date: 2002-05-25 12:01 Message: Logged In: YES user_id=76037 On Cygwin we use libtoll which manages the naming. If you would use automake too... (yes I know...). Libtool names the lib cygexpat-0.dll since there is no versioning which is compatible with libtool. If the API changes it would be named cygexpat-1.dll so both versions may coexist. It would be very easy to transfer this to the Windows version. Just name it winexpat-0.dll and so on, so every conflict can be avoided, e.g. using expat on windows in three versions (cygwin, native windows, perl). Just my 2c. Gerrit ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-25 06:06 Message: Logged In: YES user_id=290026 On Linux I was already using libexpat.so and libexpatw.so (w stands for "wide"). So, why not use libexpat.dll and libexpatw.dll? Just to create confusion, Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-23 21:14 Message: Logged In: YES user_id=3066 While we may have some "right" to the name "expat" for the DLL, older versions of expat used "xmlparse" and "xmltok", and the Perl module started using "expat" (perhaps for some technical reason, since the Perl module is XML::Parser::Expat). I'll vote that we should call our DLL "libexpatutf8" when compiled for UTF-8 output, and "libexpatutf16" when compiled for UTF-16 output. Yeah, that's new for everyone, and annoying as hell, but beats making Expat support both output encodings in one compiled version. (Well, except when you really want both.) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-22 02:39 Message: Logged In: NO It took a coule of hours to get things working on my machine (Win2k sp2), so I thought I'd post what I did so others won't waste time. I'm not sure if what I did was the correct method, but it worked for me. 1) Download and extract the XML::Parser ZIP from CPAN. 3) Replace all occurances of "expat" with "libexpat" in all files. 3) Rename the Expat directory to libexpat. 4) Rename the expat.pm and expat.xs files accordingly. 5) Open libexpat.xs and change the #include back to #include 6) Build the make files (perl makefile.pl) 7) Open the libexpat makefile and change the PERLARCHIVE line to read (note, I put expat.h, dll, and lib in my perl\lib\CORE directory): PERL_ARCHIVE = $(PERL_INC)\perl56.lib $(PERL_INC) \expat.lib" 8) Run namke 9) Copy the PERL\lib\CORE\expat.dll to blib\arch\xml\parser\libexpat and run 'nmake test'. ---------------------------------------------------------------------- Comment By: Greg Stein (gstein) Date: 2002-05-18 02:55 Message: Logged In: YES user_id=6501 Calling the library expat2.dll would be fine with me. libexpat.dll might also be fine. But also note: *we* are Expat, not the Perl extension. We have more "right" to expat.dll if that is what we choose to do. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-10-02 00:08 Message: Logged In: YES user_id=3066 So this appearantly never worked with Expat 1.95+. Sigh. We could go back to xmlparse.dll I suppose, but I don't really like that. I don't know that we've retained enough compatibility with that. Perhaps "expat2" would be good enough, since the real target right now is a stable Expat 2.0. I'll think about this a little more, but I'd like to have it solved in Expat 1.95.3. Assigning to me since Clark has been abducted by aliens. ---------------------------------------------------------------------- Comment By: Kevin Gilpin (kgilpin) Date: 2001-10-01 23:51 Message: Logged In: YES user_id=44882 The problem is that the Perl extension consists of 2 dlls: 1) the expat DLL, which does not contain any perl references 2) the perl -> expat DLL, which references both the Perl APIs and the Expat APIs Both of these DLLs are called 'expat.dll', which is a problem b/c Windows will cannot tell the difference between them when the Perl program is run ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-10-01 22:26 Message: Logged In: YES user_id=3066 Thinking about this again, I realize I don't know enough about the Perl extension machinery and mod_perl to be sure of this. Is mod_perl providing an expat.dll which is something different, or is it a different version of that mod_perl uses? We need a mod_perl/XML::Parser expert to answer reports like this one! Leaving this one assigned to Clark until we have such a person with available time. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-25 18:39 Message: Logged In: YES user_id=3066 This relates to having multiple versions of the library being made available in the same process. Assigned to Clark since he might have more of the context information related to XML::Parser. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=432456&group_id=10127 From noreply@sourceforge.net Sat May 25 04:06:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat May 25 03:06:04 2002 Subject: [ expat-Bugs-557530 ] Cygwin install fails Message-ID: Bugs item #557530, was opened at 2002-05-18 04:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=557530&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 6 Submitted By: Chad Austin (aegis) Assigned to: Greg Stein (gstein) Summary: Cygwin install fails Initial Comment: Building expat within Cygwin succeeds now, but 'make install' fails. $ gmake install /bin/sh ./conftools/mkinstalldirs /usr/local/bin /usr/local/lib /usr/local/inclu de /bin/sh ./libtool --mode=install /usr/bin/install -c xmlwf/xmlwf /usr/local/bin/ xmlwf libtool: install: warning: `lib/libexpat.la' has not been installed in `/usr/loc al/lib' /usr/bin/install -c xmlwf/.libs/xmlwf /usr/local/bin/xmlwf /bin/sh ./libtool --mode=install /usr/bin/install -c lib/libexpat.la /usr/local/ lib/libexpat.la /usr/bin/install -c lib/.libs/libexpat.dll.a /usr/local/lib/libexpat.dll.a dlpath=`bash 2>&1 -c '. lib/.libs/lib/libexpat.lai;echo $dlname'` dldir=/usr/local/lib/`dirname $dlpath` dirname: too many arguments Try `dirname --help' for more information. make: *** [install] Error 1 ---------------------------------------------------------------------- Comment By: Gerrit Haase (siebenschlaefer) Date: 2002-05-25 12:06 Message: Logged In: YES user_id=76037 I saw this too. Probably a bug in libtool? Though it works ok. with 1.95.2 after updating the libtool and other parts. Gerrit ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=557530&group_id=10127 From noreply@sourceforge.net Mon May 27 04:42:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon May 27 03:42:05 2002 Subject: [ expat-Bugs-561020 ] segmentation fault on using ISO-8859-15 Message-ID: Bugs item #561020, was opened at 2002-05-27 03:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=561020&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: segmentation fault on using ISO-8859-15 Initial Comment: 1.95.1 and 1.95.2 dll's fails with segmentation faults if this encoding is used: If replaced -15 with -1 above, file parses correctly. I am using expat with exml (prerel 0.2.0). Full xml file attached. Any advice on a quick fix appreciated. Ståle A. Olsen ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=561020&group_id=10127 From noreply@sourceforge.net Mon May 27 04:45:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon May 27 03:45:03 2002 Subject: [ expat-Bugs-561020 ] segmentation fault on using ISO-8859-15 Message-ID: Bugs item #561020, was opened at 2002-05-27 03:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=561020&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: segmentation fault on using ISO-8859-15 Initial Comment: 1.95.1 and 1.95.2 dll's fails with segmentation faults if this encoding is used: If replaced -15 with -1 above, file parses correctly. I am using expat with exml (prerel 0.2.0). Full xml file attached. Any advice on a quick fix appreciated. Ståle A. Olsen ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-27 03:44 Message: Logged In: NO file upload borked, so cut below for file: ]> Announcements Hugin 860467 Contracts Text 08:37 27-05-2002 Tekla Oyj Finland TLA1V HEX FI0009008833 Manufacturing en TEKLA AQUA SOFTWARE SUPPORTS THE CUSTOMER MANAGEMENT OF THE WATER UTILITIES OF FINNISH CITIES ESPOO, VANTAA AND TAMPERE Tekla Corporation Press Release 27.5.2002 at 9.30 TEKLA AQUA SOFTWARE SUPPORTS THE CUSTOMER MANAGEMENT OF THE WATER UTILITIES OF FINNISH CITIES ESPOO, VANTAA AND TAMPERE Espoo Water, Vantaa Water and Tampere Water have jointly acquired Tekla Aqua. Tekla's system supports water utilities' customer management, especially invoicing and payment control. This is an extensive project, and the utilities issued an EU- wide invitation to tender. Tekla's system was considered superior to the alternatives. - Tekla Aqua is a complete system, and thus we won't have to allocate resources for customizing it. Tekla's system met our needs best, comments Tuija Räty, Development Director of Espoo Water. The system supports the customer management of the water utilities, and it is used to send tens of thousands of invoices each year. - The system helps us serve our customers better. Also, its reporting features enable utilizing different kinds of data in daily business operations and management, reports Esko Haume, Managing Director of Tampere Water. - Ease of use, versatility and technical properties that make our work easier were the major factors in our decision in favor of Tekla, crystallizes Pertti Heinonen, Managing Director of Vantaa Water. The implementation plan of the water utilities' system project will be ready in July, and the system will be implemented at the beginning of 2003 at the latest.
For additional information, please contact: Tekla Corporation, Account Manager Are Kivelä, Tel. +358 9 8879 500 http://www.tekla.com Espoo Water, Development Director Tuija Räty, Tel. +358 9 8162 5513 Vantaa Water, Managing Director Pertti Heinonen, Tel +358 9 839 11 Tampere Water, Managing Director Esko Haume, Tel +358 3 3146 3640 Distribution: Main media For Information: Helsinki Exchanges Tekla in Brief Tekla Corporation is pioneer of infrastructure management globally. Software products developed by Tekla improve commercial and operative efficiency and are used in energy sales and distribution, building and construction and public infra. Tekla Group´s net sales for 2001 reached 39.2 million euros, increasing by 48% compared with the previous year. International operations accounted for 57% of net sales. In August 2001 Tekla acquired from Enfo Group Plc (previously Tietosavo Plc) its two business units: Enfo Soft (research and development of information systems) and Enfo Systems (delivery and integration of information systems). Enfo Group Plc´s Swedish subsidiary Enfo AB´s business operations were also included in the deal. At the moment Tekla Group employs approximately 470 persons, of whom nearly every fifth outside Finland.
Copyright © Hugin ASA . All rights reserved. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=561020&group_id=10127 From noreply@sourceforge.net Mon May 27 04:49:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon May 27 03:49:02 2002 Subject: [ expat-Bugs-561020 ] segmentation fault on using ISO-8859-15 Message-ID: Bugs item #561020, was opened at 2002-05-27 03:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=561020&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: segmentation fault on using ISO-8859-15 Initial Comment: 1.95.1 and 1.95.2 dll's fails with segmentation faults if this encoding is used: If replaced -15 with -1 above, file parses correctly. I am using expat with exml (prerel 0.2.0). Full xml file attached. Any advice on a quick fix appreciated. Ståle A. Olsen ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-27 03:48 Message: Logged In: NO file upload failed, contact me (sao@pvv.org) for an example file. SAO. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-27 03:44 Message: Logged In: NO file upload borked, so cut below for file: ]> Announcements Hugin 860467 Contracts Text 08:37 27-05-2002 Tekla Oyj Finland TLA1V HEX FI0009008833 Manufacturing en TEKLA AQUA SOFTWARE SUPPORTS THE CUSTOMER MANAGEMENT OF THE WATER UTILITIES OF FINNISH CITIES ESPOO, VANTAA AND TAMPERE Tekla Corporation Press Release 27.5.2002 at 9.30 TEKLA AQUA SOFTWARE SUPPORTS THE CUSTOMER MANAGEMENT OF THE WATER UTILITIES OF FINNISH CITIES ESPOO, VANTAA AND TAMPERE Espoo Water, Vantaa Water and Tampere Water have jointly acquired Tekla Aqua. Tekla's system supports water utilities' customer management, especially invoicing and payment control. This is an extensive project, and the utilities issued an EU- wide invitation to tender. Tekla's system was considered superior to the alternatives. - Tekla Aqua is a complete system, and thus we won't have to allocate resources for customizing it. Tekla's system met our needs best, comments Tuija Räty, Development Director of Espoo Water. The system supports the customer management of the water utilities, and it is used to send tens of thousands of invoices each year. - The system helps us serve our customers better. Also, its reporting features enable utilizing different kinds of data in daily business operations and management, reports Esko Haume, Managing Director of Tampere Water. - Ease of use, versatility and technical properties that make our work easier were the major factors in our decision in favor of Tekla, crystallizes Pertti Heinonen, Managing Director of Vantaa Water. The implementation plan of the water utilities' system project will be ready in July, and the system will be implemented at the beginning of 2003 at the latest.
For additional information, please contact: Tekla Corporation, Account Manager Are Kivelä, Tel. +358 9 8879 500 http://www.tekla.com Espoo Water, Development Director Tuija Räty, Tel. +358 9 8162 5513 Vantaa Water, Managing Director Pertti Heinonen, Tel +358 9 839 11 Tampere Water, Managing Director Esko Haume, Tel +358 3 3146 3640 Distribution: Main media For Information: Helsinki Exchanges Tekla in Brief Tekla Corporation is pioneer of infrastructure management globally. Software products developed by Tekla improve commercial and operative efficiency and are used in energy sales and distribution, building and construction and public infra. Tekla Group´s net sales for 2001 reached 39.2 million euros, increasing by 48% compared with the previous year. International operations accounted for 57% of net sales. In August 2001 Tekla acquired from Enfo Group Plc (previously Tietosavo Plc) its two business units: Enfo Soft (research and development of information systems) and Enfo Systems (delivery and integration of information systems). Enfo Group Plc´s Swedish subsidiary Enfo AB´s business operations were also included in the deal. At the moment Tekla Group employs approximately 470 persons, of whom nearly every fifth outside Finland.
Copyright © Hugin ASA . All rights reserved. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=561020&group_id=10127 From noreply@sourceforge.net Mon May 27 04:50:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon May 27 03:50:01 2002 Subject: [ expat-Bugs-561020 ] segmentation fault on using ISO-8859-15 Message-ID: Bugs item #561020, was opened at 2002-05-27 03:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=561020&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: segmentation fault on using ISO-8859-15 Initial Comment: 1.95.1 and 1.95.2 dll's fails with segmentation faults if this encoding is used: If replaced -15 with -1 above, file parses correctly. I am using expat with exml (prerel 0.2.0). Full xml file attached. Any advice on a quick fix appreciated. Ståle A. Olsen ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-27 03:49 Message: Logged In: NO file upload failed, contact me (sao@pvv.org) for an example file. SAO. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-27 03:48 Message: Logged In: NO file upload failed, contact me (sao@pvv.org) for an example file. SAO. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-27 03:44 Message: Logged In: NO file upload borked, so cut below for file: ]> Announcements Hugin 860467 Contracts Text 08:37 27-05-2002 Tekla Oyj Finland TLA1V HEX FI0009008833 Manufacturing en TEKLA AQUA SOFTWARE SUPPORTS THE CUSTOMER MANAGEMENT OF THE WATER UTILITIES OF FINNISH CITIES ESPOO, VANTAA AND TAMPERE Tekla Corporation Press Release 27.5.2002 at 9.30 TEKLA AQUA SOFTWARE SUPPORTS THE CUSTOMER MANAGEMENT OF THE WATER UTILITIES OF FINNISH CITIES ESPOO, VANTAA AND TAMPERE Espoo Water, Vantaa Water and Tampere Water have jointly acquired Tekla Aqua. Tekla's system supports water utilities' customer management, especially invoicing and payment control. This is an extensive project, and the utilities issued an EU- wide invitation to tender. Tekla's system was considered superior to the alternatives. - Tekla Aqua is a complete system, and thus we won't have to allocate resources for customizing it. Tekla's system met our needs best, comments Tuija Räty, Development Director of Espoo Water. The system supports the customer management of the water utilities, and it is used to send tens of thousands of invoices each year. - The system helps us serve our customers better. Also, its reporting features enable utilizing different kinds of data in daily business operations and management, reports Esko Haume, Managing Director of Tampere Water. - Ease of use, versatility and technical properties that make our work easier were the major factors in our decision in favor of Tekla, crystallizes Pertti Heinonen, Managing Director of Vantaa Water. The implementation plan of the water utilities' system project will be ready in July, and the system will be implemented at the beginning of 2003 at the latest.
For additional information, please contact: Tekla Corporation, Account Manager Are Kivelä, Tel. +358 9 8879 500 http://www.tekla.com Espoo Water, Development Director Tuija Räty, Tel. +358 9 8162 5513 Vantaa Water, Managing Director Pertti Heinonen, Tel +358 9 839 11 Tampere Water, Managing Director Esko Haume, Tel +358 3 3146 3640 Distribution: Main media For Information: Helsinki Exchanges Tekla in Brief Tekla Corporation is pioneer of infrastructure management globally. Software products developed by Tekla improve commercial and operative efficiency and are used in energy sales and distribution, building and construction and public infra. Tekla Group´s net sales for 2001 reached 39.2 million euros, increasing by 48% compared with the previous year. International operations accounted for 57% of net sales. In August 2001 Tekla acquired from Enfo Group Plc (previously Tietosavo Plc) its two business units: Enfo Soft (research and development of information systems) and Enfo Systems (delivery and integration of information systems). Enfo Group Plc´s Swedish subsidiary Enfo AB´s business operations were also included in the deal. At the moment Tekla Group employs approximately 470 persons, of whom nearly every fifth outside Finland.
Copyright © Hugin ASA . All rights reserved. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=561020&group_id=10127 From noreply@sourceforge.net Mon May 27 11:30:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon May 27 10:30:03 2002 Subject: [ expat-Bugs-561020 ] segmentation fault on using ISO-8859-15 Message-ID: Bugs item #561020, was opened at 2002-05-27 06:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=561020&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: segmentation fault on using ISO-8859-15 Initial Comment: 1.95.1 and 1.95.2 dll's fails with segmentation faults if this encoding is used: If replaced -15 with -1 above, file parses correctly. I am using expat with exml (prerel 0.2.0). Full xml file attached. Any advice on a quick fix appreciated. Ståle A. Olsen ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-27 13:29 Message: Logged In: YES user_id=290026 I can't reproduce this with the current HEAD in CVS. Could you try this one? Karl ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-27 06:49 Message: Logged In: NO file upload failed, contact me (sao@pvv.org) for an example file. SAO. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-27 06:48 Message: Logged In: NO file upload failed, contact me (sao@pvv.org) for an example file. SAO. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-27 06:44 Message: Logged In: NO file upload borked, so cut below for file: ]> Announcements Hugin 860467 Contracts Text 08:37 27-05-2002 Tekla Oyj Finland TLA1V HEX FI0009008833 Manufacturing en TEKLA AQUA SOFTWARE SUPPORTS THE CUSTOMER MANAGEMENT OF THE WATER UTILITIES OF FINNISH CITIES ESPOO, VANTAA AND TAMPERE Tekla Corporation Press Release 27.5.2002 at 9.30 TEKLA AQUA SOFTWARE SUPPORTS THE CUSTOMER MANAGEMENT OF THE WATER UTILITIES OF FINNISH CITIES ESPOO, VANTAA AND TAMPERE Espoo Water, Vantaa Water and Tampere Water have jointly acquired Tekla Aqua. Tekla's system supports water utilities' customer management, especially invoicing and payment control. This is an extensive project, and the utilities issued an EU- wide invitation to tender. Tekla's system was considered superior to the alternatives. - Tekla Aqua is a complete system, and thus we won't have to allocate resources for customizing it. Tekla's system met our needs best, comments Tuija Räty, Development Director of Espoo Water. The system supports the customer management of the water utilities, and it is used to send tens of thousands of invoices each year. - The system helps us serve our customers better. Also, its reporting features enable utilizing different kinds of data in daily business operations and management, reports Esko Haume, Managing Director of Tampere Water. - Ease of use, versatility and technical properties that make our work easier were the major factors in our decision in favor of Tekla, crystallizes Pertti Heinonen, Managing Director of Vantaa Water. The implementation plan of the water utilities' system project will be ready in July, and the system will be implemented at the beginning of 2003 at the latest.
For additional information, please contact: Tekla Corporation, Account Manager Are Kivelä, Tel. +358 9 8879 500 http://www.tekla.com Espoo Water, Development Director Tuija Räty, Tel. +358 9 8162 5513 Vantaa Water, Managing Director Pertti Heinonen, Tel +358 9 839 11 Tampere Water, Managing Director Esko Haume, Tel +358 3 3146 3640 Distribution: Main media For Information: Helsinki Exchanges Tekla in Brief Tekla Corporation is pioneer of infrastructure management globally. Software products developed by Tekla improve commercial and operative efficiency and are used in energy sales and distribution, building and construction and public infra. Tekla Group´s net sales for 2001 reached 39.2 million euros, increasing by 48% compared with the previous year. International operations accounted for 57% of net sales. In August 2001 Tekla acquired from Enfo Group Plc (previously Tietosavo Plc) its two business units: Enfo Soft (research and development of information systems) and Enfo Systems (delivery and integration of information systems). Enfo Group Plc´s Swedish subsidiary Enfo AB´s business operations were also included in the deal. At the moment Tekla Group employs approximately 470 persons, of whom nearly every fifth outside Finland.
Copyright © Hugin ASA . All rights reserved. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=561020&group_id=10127 From noreply@sourceforge.net Tue May 28 03:18:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue May 28 02:18:02 2002 Subject: [ expat-Bugs-561020 ] segmentation fault on using ISO-8859-15 Message-ID: Bugs item #561020, was opened at 2002-05-27 03:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=561020&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: segmentation fault on using ISO-8859-15 Initial Comment: 1.95.1 and 1.95.2 dll's fails with segmentation faults if this encoding is used: If replaced -15 with -1 above, file parses correctly. I am using expat with exml (prerel 0.2.0). Full xml file attached. Any advice on a quick fix appreciated. Ståle A. Olsen ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-28 02:17 Message: Logged In: NO I did a build with the latest from CVS (except MSDEV project which didn't work for me, so nicked that from 95.2 version), also built exml.lib from that. Still getting then same error... Ståle A. Olsen ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-27 10:29 Message: Logged In: YES user_id=290026 I can't reproduce this with the current HEAD in CVS. Could you try this one? Karl ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-27 03:49 Message: Logged In: NO file upload failed, contact me (sao@pvv.org) for an example file. SAO. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-27 03:48 Message: Logged In: NO file upload failed, contact me (sao@pvv.org) for an example file. SAO. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-27 03:44 Message: Logged In: NO file upload borked, so cut below for file: ]> Announcements Hugin 860467 Contracts Text 08:37 27-05-2002 Tekla Oyj Finland TLA1V HEX FI0009008833 Manufacturing en TEKLA AQUA SOFTWARE SUPPORTS THE CUSTOMER MANAGEMENT OF THE WATER UTILITIES OF FINNISH CITIES ESPOO, VANTAA AND TAMPERE Tekla Corporation Press Release 27.5.2002 at 9.30 TEKLA AQUA SOFTWARE SUPPORTS THE CUSTOMER MANAGEMENT OF THE WATER UTILITIES OF FINNISH CITIES ESPOO, VANTAA AND TAMPERE Espoo Water, Vantaa Water and Tampere Water have jointly acquired Tekla Aqua. Tekla's system supports water utilities' customer management, especially invoicing and payment control. This is an extensive project, and the utilities issued an EU- wide invitation to tender. Tekla's system was considered superior to the alternatives. - Tekla Aqua is a complete system, and thus we won't have to allocate resources for customizing it. Tekla's system met our needs best, comments Tuija Räty, Development Director of Espoo Water. The system supports the customer management of the water utilities, and it is used to send tens of thousands of invoices each year. - The system helps us serve our customers better. Also, its reporting features enable utilizing different kinds of data in daily business operations and management, reports Esko Haume, Managing Director of Tampere Water. - Ease of use, versatility and technical properties that make our work easier were the major factors in our decision in favor of Tekla, crystallizes Pertti Heinonen, Managing Director of Vantaa Water. The implementation plan of the water utilities' system project will be ready in July, and the system will be implemented at the beginning of 2003 at the latest.
For additional information, please contact: Tekla Corporation, Account Manager Are Kivelä, Tel. +358 9 8879 500 http://www.tekla.com Espoo Water, Development Director Tuija Räty, Tel. +358 9 8162 5513 Vantaa Water, Managing Director Pertti Heinonen, Tel +358 9 839 11 Tampere Water, Managing Director Esko Haume, Tel +358 3 3146 3640 Distribution: Main media For Information: Helsinki Exchanges Tekla in Brief Tekla Corporation is pioneer of infrastructure management globally. Software products developed by Tekla improve commercial and operative efficiency and are used in energy sales and distribution, building and construction and public infra. Tekla Group´s net sales for 2001 reached 39.2 million euros, increasing by 48% compared with the previous year. International operations accounted for 57% of net sales. In August 2001 Tekla acquired from Enfo Group Plc (previously Tietosavo Plc) its two business units: Enfo Soft (research and development of information systems) and Enfo Systems (delivery and integration of information systems). Enfo Group Plc´s Swedish subsidiary Enfo AB´s business operations were also included in the deal. At the moment Tekla Group employs approximately 470 persons, of whom nearly every fifth outside Finland.
Copyright © Hugin ASA . All rights reserved. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=561020&group_id=10127 From noreply@sourceforge.net Tue May 28 09:40:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue May 28 08:40:04 2002 Subject: [ expat-Bugs-561575 ] "configure" fails Message-ID: Bugs item #561575, was opened at 2002-05-28 08:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=561575&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: "configure" fails Initial Comment: When installing expat, the command "./configure" fails. Here's what appears a the end of the log: creating Makefile creating lib/Makefile sed: Cannot find or open file ./lib/Makefile.in. creating lib/expat.h sed: Cannot find or open file ./lib/expat.h.in. creating config.h config.h is unchanged Neither lib/Makefile.in, nor lib/expat.h.in exists; however lib/Makefile and lib/expat.h do. The value of variable CONFIG_FILES is "Makefile lib/Makefile lib/expat.h". ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=561575&group_id=10127 From noreply@sourceforge.net Tue May 28 09:41:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue May 28 08:41:02 2002 Subject: [ expat-Bugs-561576 ] "configure" fails Message-ID: Bugs item #561576, was opened at 2002-05-28 08:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=561576&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: "configure" fails Initial Comment: When installing expat, the command "./configure" fails. Here's what appears a the end of the log: creating Makefile creating lib/Makefile sed: Cannot find or open file ./lib/Makefile.in. creating lib/expat.h sed: Cannot find or open file ./lib/expat.h.in. creating config.h config.h is unchanged Neither lib/Makefile.in, nor lib/expat.h.in exists; however lib/Makefile and lib/expat.h do. The value of variable CONFIG_FILES is "Makefile lib/Makefile lib/expat.h". ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=561576&group_id=10127 From noreply@sourceforge.net Tue May 28 12:27:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue May 28 11:27:29 2002 Subject: [ expat-Bugs-561576 ] "configure" fails Message-ID: Bugs item #561576, was opened at 2002-05-28 11:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=561576&group_id=10127 Category: None Group: None >Status: Deleted >Resolution: Duplicate Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) >Summary: "configure" fails Initial Comment: When installing expat, the command "./configure" fails. Here's what appears a the end of the log: creating Makefile creating lib/Makefile sed: Cannot find or open file ./lib/Makefile.in. creating lib/expat.h sed: Cannot find or open file ./lib/expat.h.in. creating config.h config.h is unchanged Neither lib/Makefile.in, nor lib/expat.h.in exists; however lib/Makefile and lib/expat.h do. The value of variable CONFIG_FILES is "Makefile lib/Makefile lib/expat.h". ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-28 13:26 Message: Logged In: YES user_id=290026 Duplicate of bug # 561575. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=561576&group_id=10127 From noreply@sourceforge.net Tue May 28 12:27:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue May 28 11:27:32 2002 Subject: [ expat-Bugs-561020 ] segmentation fault on using ISO-8859-15 Message-ID: Bugs item #561020, was opened at 2002-05-27 06:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=561020&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: segmentation fault on using ISO-8859-15 Initial Comment: 1.95.1 and 1.95.2 dll's fails with segmentation faults if this encoding is used: If replaced -15 with -1 above, file parses correctly. I am using expat with exml (prerel 0.2.0). Full xml file attached. Any advice on a quick fix appreciated. Ståle A. Olsen ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-28 13:27 Message: Logged In: YES user_id=290026 Ståle, please post a small reproducible example. Karl ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-28 05:17 Message: Logged In: NO I did a build with the latest from CVS (except MSDEV project which didn't work for me, so nicked that from 95.2 version), also built exml.lib from that. Still getting then same error... Ståle A. Olsen ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-27 13:29 Message: Logged In: YES user_id=290026 I can't reproduce this with the current HEAD in CVS. Could you try this one? Karl ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-27 06:49 Message: Logged In: NO file upload failed, contact me (sao@pvv.org) for an example file. SAO. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-27 06:48 Message: Logged In: NO file upload failed, contact me (sao@pvv.org) for an example file. SAO. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-27 06:44 Message: Logged In: NO file upload borked, so cut below for file: ]> Announcements Hugin 860467 Contracts Text 08:37 27-05-2002 Tekla Oyj Finland TLA1V HEX FI0009008833 Manufacturing en TEKLA AQUA SOFTWARE SUPPORTS THE CUSTOMER MANAGEMENT OF THE WATER UTILITIES OF FINNISH CITIES ESPOO, VANTAA AND TAMPERE Tekla Corporation Press Release 27.5.2002 at 9.30 TEKLA AQUA SOFTWARE SUPPORTS THE CUSTOMER MANAGEMENT OF THE WATER UTILITIES OF FINNISH CITIES ESPOO, VANTAA AND TAMPERE Espoo Water, Vantaa Water and Tampere Water have jointly acquired Tekla Aqua. Tekla's system supports water utilities' customer management, especially invoicing and payment control. This is an extensive project, and the utilities issued an EU- wide invitation to tender. Tekla's system was considered superior to the alternatives. - Tekla Aqua is a complete system, and thus we won't have to allocate resources for customizing it. Tekla's system met our needs best, comments Tuija Räty, Development Director of Espoo Water. The system supports the customer management of the water utilities, and it is used to send tens of thousands of invoices each year. - The system helps us serve our customers better. Also, its reporting features enable utilizing different kinds of data in daily business operations and management, reports Esko Haume, Managing Director of Tampere Water. - Ease of use, versatility and technical properties that make our work easier were the major factors in our decision in favor of Tekla, crystallizes Pertti Heinonen, Managing Director of Vantaa Water. The implementation plan of the water utilities' system project will be ready in July, and the system will be implemented at the beginning of 2003 at the latest.
For additional information, please contact: Tekla Corporation, Account Manager Are Kivelä, Tel. +358 9 8879 500 http://www.tekla.com Espoo Water, Development Director Tuija Räty, Tel. +358 9 8162 5513 Vantaa Water, Managing Director Pertti Heinonen, Tel +358 9 839 11 Tampere Water, Managing Director Esko Haume, Tel +358 3 3146 3640 Distribution: Main media For Information: Helsinki Exchanges Tekla in Brief Tekla Corporation is pioneer of infrastructure management globally. Software products developed by Tekla improve commercial and operative efficiency and are used in energy sales and distribution, building and construction and public infra. Tekla Group´s net sales for 2001 reached 39.2 million euros, increasing by 48% compared with the previous year. International operations accounted for 57% of net sales. In August 2001 Tekla acquired from Enfo Group Plc (previously Tietosavo Plc) its two business units: Enfo Soft (research and development of information systems) and Enfo Systems (delivery and integration of information systems). Enfo Group Plc´s Swedish subsidiary Enfo AB´s business operations were also included in the deal. At the moment Tekla Group employs approximately 470 persons, of whom nearly every fifth outside Finland.
Copyright © Hugin ASA . All rights reserved. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=561020&group_id=10127 From noreply@sourceforge.net Wed May 29 08:41:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed May 29 07:41:05 2002 Subject: [ expat-Bugs-561020 ] segmentation fault on using ISO-8859-15 Message-ID: Bugs item #561020, was opened at 2002-05-27 03:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=561020&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: segmentation fault on using ISO-8859-15 Initial Comment: 1.95.1 and 1.95.2 dll's fails with segmentation faults if this encoding is used: If replaced -15 with -1 above, file parses correctly. I am using expat with exml (prerel 0.2.0). Full xml file attached. Any advice on a quick fix appreciated. Ståle A. Olsen ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-29 07:40 Message: Logged In: NO test If you send me an email at sao@pvv.org, I can send you the binary that fails too. Ståle A. Olsen ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-28 10:27 Message: Logged In: YES user_id=290026 Ståle, please post a small reproducible example. Karl ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-28 02:17 Message: Logged In: NO I did a build with the latest from CVS (except MSDEV project which didn't work for me, so nicked that from 95.2 version), also built exml.lib from that. Still getting then same error... Ståle A. Olsen ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-27 10:29 Message: Logged In: YES user_id=290026 I can't reproduce this with the current HEAD in CVS. Could you try this one? Karl ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-27 03:49 Message: Logged In: NO file upload failed, contact me (sao@pvv.org) for an example file. SAO. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-27 03:48 Message: Logged In: NO file upload failed, contact me (sao@pvv.org) for an example file. SAO. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-27 03:44 Message: Logged In: NO file upload borked, so cut below for file: ]> Announcements Hugin 860467 Contracts Text 08:37 27-05-2002 Tekla Oyj Finland TLA1V HEX FI0009008833 Manufacturing en TEKLA AQUA SOFTWARE SUPPORTS THE CUSTOMER MANAGEMENT OF THE WATER UTILITIES OF FINNISH CITIES ESPOO, VANTAA AND TAMPERE Tekla Corporation Press Release 27.5.2002 at 9.30 TEKLA AQUA SOFTWARE SUPPORTS THE CUSTOMER MANAGEMENT OF THE WATER UTILITIES OF FINNISH CITIES ESPOO, VANTAA AND TAMPERE Espoo Water, Vantaa Water and Tampere Water have jointly acquired Tekla Aqua. Tekla's system supports water utilities' customer management, especially invoicing and payment control. This is an extensive project, and the utilities issued an EU- wide invitation to tender. Tekla's system was considered superior to the alternatives. - Tekla Aqua is a complete system, and thus we won't have to allocate resources for customizing it. Tekla's system met our needs best, comments Tuija Räty, Development Director of Espoo Water. The system supports the customer management of the water utilities, and it is used to send tens of thousands of invoices each year. - The system helps us serve our customers better. Also, its reporting features enable utilizing different kinds of data in daily business operations and management, reports Esko Haume, Managing Director of Tampere Water. - Ease of use, versatility and technical properties that make our work easier were the major factors in our decision in favor of Tekla, crystallizes Pertti Heinonen, Managing Director of Vantaa Water. The implementation plan of the water utilities' system project will be ready in July, and the system will be implemented at the beginning of 2003 at the latest.
For additional information, please contact: Tekla Corporation, Account Manager Are Kivelä, Tel. +358 9 8879 500 http://www.tekla.com Espoo Water, Development Director Tuija Räty, Tel. +358 9 8162 5513 Vantaa Water, Managing Director Pertti Heinonen, Tel +358 9 839 11 Tampere Water, Managing Director Esko Haume, Tel +358 3 3146 3640 Distribution: Main media For Information: Helsinki Exchanges Tekla in Brief Tekla Corporation is pioneer of infrastructure management globally. Software products developed by Tekla improve commercial and operative efficiency and are used in energy sales and distribution, building and construction and public infra. Tekla Group´s net sales for 2001 reached 39.2 million euros, increasing by 48% compared with the previous year. International operations accounted for 57% of net sales. In August 2001 Tekla acquired from Enfo Group Plc (previously Tietosavo Plc) its two business units: Enfo Soft (research and development of information systems) and Enfo Systems (delivery and integration of information systems). Enfo Group Plc´s Swedish subsidiary Enfo AB´s business operations were also included in the deal. At the moment Tekla Group employs approximately 470 persons, of whom nearly every fifth outside Finland.
Copyright © Hugin ASA . All rights reserved. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=561020&group_id=10127 From noreply@sourceforge.net Wed May 29 09:40:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed May 29 08:40:03 2002 Subject: [ expat-Bugs-561020 ] segmentation fault on using ISO-8859-15 Message-ID: Bugs item #561020, was opened at 2002-05-27 06:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=561020&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: segmentation fault on using ISO-8859-15 Initial Comment: 1.95.1 and 1.95.2 dll's fails with segmentation faults if this encoding is used: If replaced -15 with -1 above, file parses correctly. I am using expat with exml (prerel 0.2.0). Full xml file attached. Any advice on a quick fix appreciated. Ståle A. Olsen ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-29 11:39 Message: Logged In: YES user_id=290026 Ståle, I have no problems with your file. Expat returns an "Unknown encoding error" as it should. Before you send anything: Who is calling Expat, your code or exml? How does the calling code look like? Karl ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-29 10:40 Message: Logged In: NO test If you send me an email at sao@pvv.org, I can send you the binary that fails too. Ståle A. Olsen ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-28 13:27 Message: Logged In: YES user_id=290026 Ståle, please post a small reproducible example. Karl ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-28 05:17 Message: Logged In: NO I did a build with the latest from CVS (except MSDEV project which didn't work for me, so nicked that from 95.2 version), also built exml.lib from that. Still getting then same error... Ståle A. Olsen ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-27 13:29 Message: Logged In: YES user_id=290026 I can't reproduce this with the current HEAD in CVS. Could you try this one? Karl ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-27 06:49 Message: Logged In: NO file upload failed, contact me (sao@pvv.org) for an example file. SAO. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-27 06:48 Message: Logged In: NO file upload failed, contact me (sao@pvv.org) for an example file. SAO. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-27 06:44 Message: Logged In: NO file upload borked, so cut below for file: ]> Announcements Hugin 860467 Contracts Text 08:37 27-05-2002 Tekla Oyj Finland TLA1V HEX FI0009008833 Manufacturing en TEKLA AQUA SOFTWARE SUPPORTS THE CUSTOMER MANAGEMENT OF THE WATER UTILITIES OF FINNISH CITIES ESPOO, VANTAA AND TAMPERE Tekla Corporation Press Release 27.5.2002 at 9.30 TEKLA AQUA SOFTWARE SUPPORTS THE CUSTOMER MANAGEMENT OF THE WATER UTILITIES OF FINNISH CITIES ESPOO, VANTAA AND TAMPERE Espoo Water, Vantaa Water and Tampere Water have jointly acquired Tekla Aqua. Tekla's system supports water utilities' customer management, especially invoicing and payment control. This is an extensive project, and the utilities issued an EU- wide invitation to tender. Tekla's system was considered superior to the alternatives. - Tekla Aqua is a complete system, and thus we won't have to allocate resources for customizing it. Tekla's system met our needs best, comments Tuija Räty, Development Director of Espoo Water. The system supports the customer management of the water utilities, and it is used to send tens of thousands of invoices each year. - The system helps us serve our customers better. Also, its reporting features enable utilizing different kinds of data in daily business operations and management, reports Esko Haume, Managing Director of Tampere Water. - Ease of use, versatility and technical properties that make our work easier were the major factors in our decision in favor of Tekla, crystallizes Pertti Heinonen, Managing Director of Vantaa Water. The implementation plan of the water utilities' system project will be ready in July, and the system will be implemented at the beginning of 2003 at the latest.
For additional information, please contact: Tekla Corporation, Account Manager Are Kivelä, Tel. +358 9 8879 500 http://www.tekla.com Espoo Water, Development Director Tuija Räty, Tel. +358 9 8162 5513 Vantaa Water, Managing Director Pertti Heinonen, Tel +358 9 839 11 Tampere Water, Managing Director Esko Haume, Tel +358 3 3146 3640 Distribution: Main media For Information: Helsinki Exchanges Tekla in Brief Tekla Corporation is pioneer of infrastructure management globally. Software products developed by Tekla improve commercial and operative efficiency and are used in energy sales and distribution, building and construction and public infra. Tekla Group´s net sales for 2001 reached 39.2 million euros, increasing by 48% compared with the previous year. International operations accounted for 57% of net sales. In August 2001 Tekla acquired from Enfo Group Plc (previously Tietosavo Plc) its two business units: Enfo Soft (research and development of information systems) and Enfo Systems (delivery and integration of information systems). Enfo Group Plc´s Swedish subsidiary Enfo AB´s business operations were also included in the deal. At the moment Tekla Group employs approximately 470 persons, of whom nearly every fifth outside Finland.
Copyright © Hugin ASA . All rights reserved. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=561020&group_id=10127 From noreply@sourceforge.net Wed May 29 09:56:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed May 29 08:56:03 2002 Subject: [ expat-Bugs-561020 ] segmentation fault on using ISO-8859-15 Message-ID: Bugs item #561020, was opened at 2002-05-27 03:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=561020&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: segmentation fault on using ISO-8859-15 Initial Comment: 1.95.1 and 1.95.2 dll's fails with segmentation faults if this encoding is used: If replaced -15 with -1 above, file parses correctly. I am using expat with exml (prerel 0.2.0). Full xml file attached. Any advice on a quick fix appreciated. Ståle A. Olsen ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-29 08:55 Message: Logged In: NO >I have no problems with your file. >Expat returns an "Unknown encoding error" as it should. Then it is the exml wrapper that does not handle the error msg returned gracefully :) I was not sure if expat did fail or if it still tried to parse the document when it encountered an unknown encoding. Anyway, we've worked around the problem by changing the encoding declaration on the documents. SAO. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-29 08:39 Message: Logged In: YES user_id=290026 Ståle, I have no problems with your file. Expat returns an "Unknown encoding error" as it should. Before you send anything: Who is calling Expat, your code or exml? How does the calling code look like? Karl ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-29 07:40 Message: Logged In: NO test If you send me an email at sao@pvv.org, I can send you the binary that fails too. Ståle A. Olsen ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-28 10:27 Message: Logged In: YES user_id=290026 Ståle, please post a small reproducible example. Karl ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-28 02:17 Message: Logged In: NO I did a build with the latest from CVS (except MSDEV project which didn't work for me, so nicked that from 95.2 version), also built exml.lib from that. Still getting then same error... Ståle A. Olsen ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-27 10:29 Message: Logged In: YES user_id=290026 I can't reproduce this with the current HEAD in CVS. Could you try this one? Karl ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-27 03:49 Message: Logged In: NO file upload failed, contact me (sao@pvv.org) for an example file. SAO. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-27 03:48 Message: Logged In: NO file upload failed, contact me (sao@pvv.org) for an example file. SAO. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-27 03:44 Message: Logged In: NO file upload borked, so cut below for file: ]> Announcements Hugin 860467 Contracts Text 08:37 27-05-2002 Tekla Oyj Finland TLA1V HEX FI0009008833 Manufacturing en TEKLA AQUA SOFTWARE SUPPORTS THE CUSTOMER MANAGEMENT OF THE WATER UTILITIES OF FINNISH CITIES ESPOO, VANTAA AND TAMPERE Tekla Corporation Press Release 27.5.2002 at 9.30 TEKLA AQUA SOFTWARE SUPPORTS THE CUSTOMER MANAGEMENT OF THE WATER UTILITIES OF FINNISH CITIES ESPOO, VANTAA AND TAMPERE Espoo Water, Vantaa Water and Tampere Water have jointly acquired Tekla Aqua. Tekla's system supports water utilities' customer management, especially invoicing and payment control. This is an extensive project, and the utilities issued an EU- wide invitation to tender. Tekla's system was considered superior to the alternatives. - Tekla Aqua is a complete system, and thus we won't have to allocate resources for customizing it. Tekla's system met our needs best, comments Tuija Räty, Development Director of Espoo Water. The system supports the customer management of the water utilities, and it is used to send tens of thousands of invoices each year. - The system helps us serve our customers better. Also, its reporting features enable utilizing different kinds of data in daily business operations and management, reports Esko Haume, Managing Director of Tampere Water. - Ease of use, versatility and technical properties that make our work easier were the major factors in our decision in favor of Tekla, crystallizes Pertti Heinonen, Managing Director of Vantaa Water. The implementation plan of the water utilities' system project will be ready in July, and the system will be implemented at the beginning of 2003 at the latest.
For additional information, please contact: Tekla Corporation, Account Manager Are Kivelä, Tel. +358 9 8879 500 http://www.tekla.com Espoo Water, Development Director Tuija Räty, Tel. +358 9 8162 5513 Vantaa Water, Managing Director Pertti Heinonen, Tel +358 9 839 11 Tampere Water, Managing Director Esko Haume, Tel +358 3 3146 3640 Distribution: Main media For Information: Helsinki Exchanges Tekla in Brief Tekla Corporation is pioneer of infrastructure management globally. Software products developed by Tekla improve commercial and operative efficiency and are used in energy sales and distribution, building and construction and public infra. Tekla Group´s net sales for 2001 reached 39.2 million euros, increasing by 48% compared with the previous year. International operations accounted for 57% of net sales. In August 2001 Tekla acquired from Enfo Group Plc (previously Tietosavo Plc) its two business units: Enfo Soft (research and development of information systems) and Enfo Systems (delivery and integration of information systems). Enfo Group Plc´s Swedish subsidiary Enfo AB´s business operations were also included in the deal. At the moment Tekla Group employs approximately 470 persons, of whom nearly every fifth outside Finland.
Copyright © Hugin ASA . All rights reserved. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=561020&group_id=10127 From noreply@sourceforge.net Wed May 29 12:15:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed May 29 11:15:04 2002 Subject: [ expat-Patches-562005 ] Detect invalid UTF-8 sequences Message-ID: Patches item #562005, was opened at 2002-05-29 14:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=562005&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) Summary: Detect invalid UTF-8 sequences Initial Comment: This patch is based on the patch attached to bug # 477667. I have updated the patch to Unicode 3.2 and made some optimizing (hopefully) modifications to the code. This is the table it is now based on: Table 3.1B. Legal UTF-8 Byte Sequences in Unicode 3.2 Code Points 1st Byte 2nd 3rd 4th U+0000..U+007F 00..7F U+0080..U+07FF C2..DF 80..BF U+0800..U+0FFF E0 A0..BF 80..BF U+1000..U+CFFF E1..EC 80..BF 80..BF U+D000..U+D7FF ED 80..9F 80..BF U+D800..U+DFFF ill-formed U+E000..U+FFFF EE..EF 80..BF 80..BF U+10000..U+3FFFF F0 90..BF 80..BF 80..BF U+40000..U+FFFFF F1..F3 80..BF 80..BF 80..BF U+100000..U+10FFFF F4 80..8F 80..BF 80..BF Optimization 1) Analyzing the code in xmltok.c, I found that the functions utf8_isInvalid2,3,4 are called only when the first byte of the UTF-8 sequence maps to BT_LEAD2,3,4 respectively in the table in utf8tab.h (I looked at the pre-processed output for that). This means for the first byte p[0]: BT_LEAD2 <==> p[0] >= 0xC0 and p[0] <= 0xDF, therefore we don't have to check for p[0] > 0xDF BT_LEAD3 <==> p[0] >= 0xE0 and p[0] <= 0xEF, therefore we don't have to check for p[0] < 0xE0 and p[0] > 0xEF BT_LEAD4 <==> p[0] >= 0xF0 and p[0] <= 0xF4, therefore we don't have to check for p[0] < 0xF0 and p[0] > 0xF4 so, our checks for an invalid UTF-8 sequence are: BT_LEAD2: p[0] < 0xC2 || p[1] < 0x80 || p[1] > 0xBF BT_LEAD3: p[2] < 0x80 || p[2] > 0xBF || if p[0] == 0xE0 then p[1] < 0xA0 || p[1] > 0xBF if p[0] == 0xED then p[1] < 0x80 || p[1] > 0x9F otherwise p[1] < 0x80 || p[1] > 0xBF BT_LEAD4: p[3] < 0x80 || p[3] > 0xBF || p[2] < 0x80 || p[2] > 0xBF || if p[0] == 0xF0 then p[1] < 0x90 || p[1] > 0xBF if p[0] == 0xF4 then p[1] < 0x80 || p[1] > 0x8F otherwise p[1] < 0x80 || p[1] > 0xBF Optimization 2) Use conditional expressions, i.e. ( ? : ) Optimization 3) In theory, it should be more efficient to write (A & 0x80) == 0 instead of A < 0x80 and (A & 0xC0) == 0xC0 instead of A > 0xBF Check the attached file xmltok.c for the actual implementation. The patch is based on revision 1.15 of xmltok.c. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=562005&group_id=10127 From noreply@sourceforge.net Wed May 29 12:22:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed May 29 11:22:03 2002 Subject: [ expat-Bugs-477667 ] illegal utf-8 seqs do not throw error Message-ID: Bugs item #477667, was opened at 2001-11-02 17:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=477667&group_id=10127 Category: None Group: None Status: Open Resolution: Works For Me Priority: 6 Submitted By: Patrick McCormick (patrickmc) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: illegal utf-8 seqs do not throw error Initial Comment: I have a problem where users like to use iso-8859-1 without declaring it in the prolog, like this: abécdef expat properly defaults to utf-8 in this case. As I understand utf-8, the é character (0xE7) has a bitfield that looks like the start of a three byte sequence. A 3-byte sequence is supposed to look like this: bytes | bits | representation 3 | 16 | 1110vvvv 10vvvvvv 10vvvvvv the above two bytes (c and d) don't match the 10vvvvvv mask, so écd is an illegal utf-8 sequence. But expat doesn't throw a well-formedness error. Expat uses this macro in xmltok.c to figure out what's illegal: #define UTF8_INVALID3(p) \ ((*p) == 0xED \ ? (((p)[1] & 0x20) != 0) \ : ((*p) == 0xEF \ ? ((p)[1] == 0xBF && ((p)[2] == 0xBF || (p)[2] == 0xBE)) \ : 0)) but this doesn't seem strict enough. I wrote a patch that makes expat check UTF-8 sequences against the Table 3.1B of the Unicode 3.1 standard: http://www.unicode.org/unicode/reports/tr27/ as originally clarified in this Corrigendum: http://www.unicode.org/unicode/uni2errata/UTF- 8_Corrigendum.html and it's attached. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-29 14:21 Message: Logged In: YES user_id=290026 I think that Patrick's patch is essentially correct. Btw, the UTF-8 checking code one can download from Unicode.org is actually not 100% conforming to their own rules. Patrick's direct approach made me check that. Thanks, Patrick. I have submitted patch # 562005, which is based on Unicode 3.2, where the definition of legal UTF-8 sequences has been changed slightly. Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-21 23:27 Message: Logged In: YES user_id=3066 The corrected test is now checked in as tests/runtests.c revision 1.19. ---------------------------------------------------------------------- Comment By: Patrick McCormick (patrickmc) Date: 2002-05-17 15:25 Message: Logged In: YES user_id=363812 actually NORMAL_VTABLE *initializes* the struct, it doesn't define it; that's done at "struct normal_encoding". so that's how the functions are hooked up. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-17 15:24 Message: Logged In: YES user_id=3066 Aargh! This is why I hate token pasting! "grep" doesn't like it either. It gets glued in in four "struct normal_encoding" structures statically defined, starting with "utf8_encoding_ns". Ok, I'll keep digging. ---------------------------------------------------------------------- Comment By: Patrick McCormick (patrickmc) Date: 2002-05-17 15:18 Message: Logged In: YES user_id=363812 not referenced? sure it is! you have to tap into the crazy zen of expat's vtables-without-C++. look at the struct utf8_encoding. at the bottom, it uses the macro NORMAL_VTABLE(utf8_), which creates a struct entry "utf8_invalid3". the macro IS_INVALID_CHAR turns into a function call to the appropriate utf8_invalidN struct member. at some point the struct members are hooked up to the functions, but I'm not sure where. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-17 13:58 Message: Logged In: YES user_id=3066 It's not just that the UTF8_INVALID3() macro is wrong, but that it isn't used at all! The macro is referenced from utf8_isInvalid3(), but that function is not referenced. ;-( ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-17 12:31 Message: Logged In: YES user_id=3066 Ok, I've found a bug in the test case (re-using the parser without resetting it); I've fixed that in my copy and can now reproduce the error. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-17 12:20 Message: Logged In: YES user_id=290026 I am using the library directly - with my own code. Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-17 11:52 Message: Logged In: YES user_id=3066 This is strange. Using the CVS version of Expat, the test case (in tests/runtests.c:test_illegal_utf8) sees the error properly reported. xmlwf doesn't report it, however. Are you using the library directly or going through xmlwf? I'll see what I can figure out. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-09 10:44 Message: Logged In: YES user_id=290026 There is official conversion code at unicode.org. Download the files ConvertUTF.c and ConvertUTF.h from ftp://www.unicode.org/Public/PROGRAMS/CVTUTF/ and then look at the function static Boolean isLegalUTF8(UTF8 *source, int length) Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-09 10:24 Message: Logged In: YES user_id=290026 I can confirm that the current CVS does indeed not report an error against: abécdef Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-08 17:40 Message: Logged In: YES user_id=13222 I'm not happy with closing this bug report without action. Contrary to Fred's test result, I still find, that the described bug is still there (as it was at the time, the bug was reported). I've tested this with the current CVS HEAD. The bug is in deed easly demonstrable with the example out of the bug report. I use: abécdef The third character of the PCDATA is a small e with acute, that's 0xe9 in the iso-8859-1 char table (and the unicode char 00e9), if there may be an encoding problem throu the web interface. xmlwf passes this test file, without any error report, which is, to the best of my knowledge, wrong. rxp and libxml (i.e. xmllint) confirm, that the test file is not proper UTF-8. IHMO, this is a real _crucial_ bug. Please, __Please__, re-check this. rolf ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-19 15:19 Message: Logged In: YES user_id=3066 Added a test (tests/runtests.c revision 1.9) that shows this bug does not exist in the CVS version. You did not state which version of Expat you're using. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=477667&group_id=10127 From noreply@sourceforge.net Wed May 29 13:43:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed May 29 12:43:03 2002 Subject: [ expat-Bugs-561020 ] segmentation fault on using ISO-8859-15 Message-ID: Bugs item #561020, was opened at 2002-05-27 03:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=561020&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: segmentation fault on using ISO-8859-15 Initial Comment: 1.95.1 and 1.95.2 dll's fails with segmentation faults if this encoding is used: If replaced -15 with -1 above, file parses correctly. I am using expat with exml (prerel 0.2.0). Full xml file attached. Any advice on a quick fix appreciated. Ståle A. Olsen ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2002-05-29 12:42 Message: Logged In: YES user_id=6501 Closing as invalid. This wasn't Expat itself causing a problem. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-29 08:55 Message: Logged In: NO >I have no problems with your file. >Expat returns an "Unknown encoding error" as it should. Then it is the exml wrapper that does not handle the error msg returned gracefully :) I was not sure if expat did fail or if it still tried to parse the document when it encountered an unknown encoding. Anyway, we've worked around the problem by changing the encoding declaration on the documents. SAO. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-29 08:39 Message: Logged In: YES user_id=290026 Ståle, I have no problems with your file. Expat returns an "Unknown encoding error" as it should. Before you send anything: Who is calling Expat, your code or exml? How does the calling code look like? Karl ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-29 07:40 Message: Logged In: NO test If you send me an email at sao@pvv.org, I can send you the binary that fails too. Ståle A. Olsen ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-28 10:27 Message: Logged In: YES user_id=290026 Ståle, please post a small reproducible example. Karl ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-28 02:17 Message: Logged In: NO I did a build with the latest from CVS (except MSDEV project which didn't work for me, so nicked that from 95.2 version), also built exml.lib from that. Still getting then same error... Ståle A. Olsen ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-27 10:29 Message: Logged In: YES user_id=290026 I can't reproduce this with the current HEAD in CVS. Could you try this one? Karl ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-27 03:49 Message: Logged In: NO file upload failed, contact me (sao@pvv.org) for an example file. SAO. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-27 03:48 Message: Logged In: NO file upload failed, contact me (sao@pvv.org) for an example file. SAO. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-27 03:44 Message: Logged In: NO file upload borked, so cut below for file: ]> Announcements Hugin 860467 Contracts Text 08:37 27-05-2002 Tekla Oyj Finland TLA1V HEX FI0009008833 Manufacturing en TEKLA AQUA SOFTWARE SUPPORTS THE CUSTOMER MANAGEMENT OF THE WATER UTILITIES OF FINNISH CITIES ESPOO, VANTAA AND TAMPERE Tekla Corporation Press Release 27.5.2002 at 9.30 TEKLA AQUA SOFTWARE SUPPORTS THE CUSTOMER MANAGEMENT OF THE WATER UTILITIES OF FINNISH CITIES ESPOO, VANTAA AND TAMPERE Espoo Water, Vantaa Water and Tampere Water have jointly acquired Tekla Aqua. Tekla's system supports water utilities' customer management, especially invoicing and payment control. This is an extensive project, and the utilities issued an EU- wide invitation to tender. Tekla's system was considered superior to the alternatives. - Tekla Aqua is a complete system, and thus we won't have to allocate resources for customizing it. Tekla's system met our needs best, comments Tuija Räty, Development Director of Espoo Water. The system supports the customer management of the water utilities, and it is used to send tens of thousands of invoices each year. - The system helps us serve our customers better. Also, its reporting features enable utilizing different kinds of data in daily business operations and management, reports Esko Haume, Managing Director of Tampere Water. - Ease of use, versatility and technical properties that make our work easier were the major factors in our decision in favor of Tekla, crystallizes Pertti Heinonen, Managing Director of Vantaa Water. The implementation plan of the water utilities' system project will be ready in July, and the system will be implemented at the beginning of 2003 at the latest.
For additional information, please contact: Tekla Corporation, Account Manager Are Kivelä, Tel. +358 9 8879 500 http://www.tekla.com Espoo Water, Development Director Tuija Räty, Tel. +358 9 8162 5513 Vantaa Water, Managing Director Pertti Heinonen, Tel +358 9 839 11 Tampere Water, Managing Director Esko Haume, Tel +358 3 3146 3640 Distribution: Main media For Information: Helsinki Exchanges Tekla in Brief Tekla Corporation is pioneer of infrastructure management globally. Software products developed by Tekla improve commercial and operative efficiency and are used in energy sales and distribution, building and construction and public infra. Tekla Group´s net sales for 2001 reached 39.2 million euros, increasing by 48% compared with the previous year. International operations accounted for 57% of net sales. In August 2001 Tekla acquired from Enfo Group Plc (previously Tietosavo Plc) its two business units: Enfo Soft (research and development of information systems) and Enfo Systems (delivery and integration of information systems). Enfo Group Plc´s Swedish subsidiary Enfo AB´s business operations were also included in the deal. At the moment Tekla Group employs approximately 470 persons, of whom nearly every fifth outside Finland.
Copyright © Hugin ASA . All rights reserved. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=561020&group_id=10127 From noreply@sourceforge.net Wed May 29 13:56:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed May 29 12:56:04 2002 Subject: [ expat-Bugs-557739 ] make fails on IRIX 6.2 Message-ID: Bugs item #557739, was opened at 2002-05-18 12:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=557739&group_id=10127 >Category: Build control Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Greg Stein (gstein) Summary: make fails on IRIX 6.2 Initial Comment: # make cd lib && make make[1]: Entering directory `/usr/people/michaelg/expat-1.95.2/lib' /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H - DPACKAGE='"expat"' -DVERSION='"expat_1.95.2"' -I. -I. - I.. -O2 -Wall -Wmissing-prototypes -Wstrict- prototypes -fexceptions -c xmlparse.c mkdir .libs gcc -DHAVE_CONFIG_H -DPACKAGE=\expat\ - DVERSION=\expat_1.95.2\ -I. -I. -I.. -O2 -Wall - Wmissing-prototypes -Wstrict-prototypes -fexceptions - c xmlparse.c -DPIC -o .libs/xmlparse.lo cc1: Invalid option `-fexceptions' In file included from xmlparse.c:26: /usr/include/string.h:57: warning: conflicting types for built-in function `memcpy' /usr/include/string.h:58: parse error before `;' /usr/include/string.h:58: warning: data definition has no type or storage class /usr/include/string.h:59: warning: conflicting types for built-in function `strcpy' /usr/include/string.h:64: warning: conflicting types for built-in function `memcmp' /usr/include/string.h:65: warning: conflicting types for built-in function `strcmp' xmlparse.c: In function `XML_GetBuffer': xmlparse.c:1178: `punting' undeclared (first use this function) xmlparse.c:1178: (Each undeclared identifier is reported only once xmlparse.c:1178: for each function it appears in.) xmlparse.c:1178: parse error before `on' make[1]: *** [xmlparse.lo] Error 1 make[1]: Leaving directory `/usr/people/michaelg/expat- 1.95.2/lib' make: *** [lib] Error 2 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=557739&group_id=10127 From noreply@sourceforge.net Wed May 29 13:57:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed May 29 12:57:02 2002 Subject: [ expat-Bugs-524247 ] linking problems Message-ID: Bugs item #524247, was opened at 2002-03-01 01:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=524247&group_id=10127 >Category: Build control Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Greg Stein (gstein) Summary: linking problems Initial Comment: i've downloaded and installed (succesfully) the last version of expat (expat-1.95.2) on a linux red hat 7.1 machine - g++ version is (gcc version 2.96 20000731) i create a lib (.a) that uses expat whenever i want to use this lib i get the following error message ../expat/lib/libexpat.a(xmlparse.o): In function `XML_ParserCreate_MM': /users/xxx/tmp/expat-1.95.2/lib/xmlparse.c:589: undefined reference to `XmlPrologStateInit' ../expat/lib/libexpat.a(xmlparse.o): In function `XML_ExternalEntityParserCreate': /users/xxx/tmp/expat-1.95.2/lib/xmlparse.c:794: undefined reference to `XmlPrologStateInitExternalEntity' collect2: ld returned 1 exit status (right before this one i had /usr/bin/ld: xmlrole.o: invalid string offset 2090860544 >= 0 for section `.shstrtab' /usr/bin/ld: xmlrole.o: invalid string offset 3407872 >= 0 for section `' /usr/bin/ld: xmlrole.o: invalid string offset 2090860544 >= 0 for section `.shstrtab' /usr/bin/ld: xmlrole.o: invalid string offset 2297954304 >= 0 for section `' /usr/bin/ld: xmlrole.o: invalid string offset 2090860544 >= 0 for section `.shstrtab' .... then i tried to use the -O option and it seems to have solved the 1st problem) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=524247&group_id=10127 From noreply@sourceforge.net Wed May 29 13:57:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed May 29 12:57:02 2002 Subject: [ expat-Bugs-561575 ] "configure" fails Message-ID: Bugs item #561575, was opened at 2002-05-28 08:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=561575&group_id=10127 >Category: Build control Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Greg Stein (gstein) >Summary: "configure" fails Initial Comment: When installing expat, the command "./configure" fails. Here's what appears a the end of the log: creating Makefile creating lib/Makefile sed: Cannot find or open file ./lib/Makefile.in. creating lib/expat.h sed: Cannot find or open file ./lib/expat.h.in. creating config.h config.h is unchanged Neither lib/Makefile.in, nor lib/expat.h.in exists; however lib/Makefile and lib/expat.h do. The value of variable CONFIG_FILES is "Makefile lib/Makefile lib/expat.h". ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=561575&group_id=10127 From noreply@sourceforge.net Thu May 30 11:02:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu May 30 10:02:02 2002 Subject: [ expat-Patches-562005 ] Detect invalid UTF-8 sequences Message-ID: Patches item #562005, was opened at 2002-05-29 14:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=562005&group_id=10127 Category: None Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Karl Waclawek (kwaclaw) >Assigned to: Karl Waclawek (kwaclaw) Summary: Detect invalid UTF-8 sequences Initial Comment: This patch is based on the patch attached to bug # 477667. I have updated the patch to Unicode 3.2 and made some optimizing (hopefully) modifications to the code. This is the table it is now based on: Table 3.1B. Legal UTF-8 Byte Sequences in Unicode 3.2 Code Points 1st Byte 2nd 3rd 4th U+0000..U+007F 00..7F U+0080..U+07FF C2..DF 80..BF U+0800..U+0FFF E0 A0..BF 80..BF U+1000..U+CFFF E1..EC 80..BF 80..BF U+D000..U+D7FF ED 80..9F 80..BF U+D800..U+DFFF ill-formed U+E000..U+FFFF EE..EF 80..BF 80..BF U+10000..U+3FFFF F0 90..BF 80..BF 80..BF U+40000..U+FFFFF F1..F3 80..BF 80..BF 80..BF U+100000..U+10FFFF F4 80..8F 80..BF 80..BF Optimization 1) Analyzing the code in xmltok.c, I found that the functions utf8_isInvalid2,3,4 are called only when the first byte of the UTF-8 sequence maps to BT_LEAD2,3,4 respectively in the table in utf8tab.h (I looked at the pre-processed output for that). This means for the first byte p[0]: BT_LEAD2 <==> p[0] >= 0xC0 and p[0] <= 0xDF, therefore we don't have to check for p[0] > 0xDF BT_LEAD3 <==> p[0] >= 0xE0 and p[0] <= 0xEF, therefore we don't have to check for p[0] < 0xE0 and p[0] > 0xEF BT_LEAD4 <==> p[0] >= 0xF0 and p[0] <= 0xF4, therefore we don't have to check for p[0] < 0xF0 and p[0] > 0xF4 so, our checks for an invalid UTF-8 sequence are: BT_LEAD2: p[0] < 0xC2 || p[1] < 0x80 || p[1] > 0xBF BT_LEAD3: p[2] < 0x80 || p[2] > 0xBF || if p[0] == 0xE0 then p[1] < 0xA0 || p[1] > 0xBF if p[0] == 0xED then p[1] < 0x80 || p[1] > 0x9F otherwise p[1] < 0x80 || p[1] > 0xBF BT_LEAD4: p[3] < 0x80 || p[3] > 0xBF || p[2] < 0x80 || p[2] > 0xBF || if p[0] == 0xF0 then p[1] < 0x90 || p[1] > 0xBF if p[0] == 0xF4 then p[1] < 0x80 || p[1] > 0x8F otherwise p[1] < 0x80 || p[1] > 0xBF Optimization 2) Use conditional expressions, i.e. ( ? : ) Optimization 3) In theory, it should be more efficient to write (A & 0x80) == 0 instead of A < 0x80 and (A & 0xC0) == 0xC0 instead of A > 0xBF Check the attached file xmltok.c for the actual implementation. The patch is based on revision 1.15 of xmltok.c. Karl ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-30 13:01 Message: Logged In: YES user_id=3066 Works for me and causes the checked-in tests to pass again. Check it in & close the bug & patch reports! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=562005&group_id=10127 From noreply@sourceforge.net Thu May 30 12:27:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu May 30 11:27:04 2002 Subject: [ expat-Patches-562005 ] Detect invalid UTF-8 sequences Message-ID: Patches item #562005, was opened at 2002-05-29 14:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=562005&group_id=10127 Category: None Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) Summary: Detect invalid UTF-8 sequences Initial Comment: This patch is based on the patch attached to bug # 477667. I have updated the patch to Unicode 3.2 and made some optimizing (hopefully) modifications to the code. This is the table it is now based on: Table 3.1B. Legal UTF-8 Byte Sequences in Unicode 3.2 Code Points 1st Byte 2nd 3rd 4th U+0000..U+007F 00..7F U+0080..U+07FF C2..DF 80..BF U+0800..U+0FFF E0 A0..BF 80..BF U+1000..U+CFFF E1..EC 80..BF 80..BF U+D000..U+D7FF ED 80..9F 80..BF U+D800..U+DFFF ill-formed U+E000..U+FFFF EE..EF 80..BF 80..BF U+10000..U+3FFFF F0 90..BF 80..BF 80..BF U+40000..U+FFFFF F1..F3 80..BF 80..BF 80..BF U+100000..U+10FFFF F4 80..8F 80..BF 80..BF Optimization 1) Analyzing the code in xmltok.c, I found that the functions utf8_isInvalid2,3,4 are called only when the first byte of the UTF-8 sequence maps to BT_LEAD2,3,4 respectively in the table in utf8tab.h (I looked at the pre-processed output for that). This means for the first byte p[0]: BT_LEAD2 <==> p[0] >= 0xC0 and p[0] <= 0xDF, therefore we don't have to check for p[0] > 0xDF BT_LEAD3 <==> p[0] >= 0xE0 and p[0] <= 0xEF, therefore we don't have to check for p[0] < 0xE0 and p[0] > 0xEF BT_LEAD4 <==> p[0] >= 0xF0 and p[0] <= 0xF4, therefore we don't have to check for p[0] < 0xF0 and p[0] > 0xF4 so, our checks for an invalid UTF-8 sequence are: BT_LEAD2: p[0] < 0xC2 || p[1] < 0x80 || p[1] > 0xBF BT_LEAD3: p[2] < 0x80 || p[2] > 0xBF || if p[0] == 0xE0 then p[1] < 0xA0 || p[1] > 0xBF if p[0] == 0xED then p[1] < 0x80 || p[1] > 0x9F otherwise p[1] < 0x80 || p[1] > 0xBF BT_LEAD4: p[3] < 0x80 || p[3] > 0xBF || p[2] < 0x80 || p[2] > 0xBF || if p[0] == 0xF0 then p[1] < 0x90 || p[1] > 0xBF if p[0] == 0xF4 then p[1] < 0x80 || p[1] > 0x8F otherwise p[1] < 0x80 || p[1] > 0xBF Optimization 2) Use conditional expressions, i.e. ( ? : ) Optimization 3) In theory, it should be more efficient to write (A & 0x80) == 0 instead of A < 0x80 and (A & 0xC0) == 0xC0 instead of A > 0xBF Check the attached file xmltok.c for the actual implementation. The patch is based on revision 1.15 of xmltok.c. Karl ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-30 14:26 Message: Logged In: YES user_id=290026 Patch checked in - rev. 1.16 of xmltok.c Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-30 13:01 Message: Logged In: YES user_id=3066 Works for me and causes the checked-in tests to pass again. Check it in & close the bug & patch reports! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=562005&group_id=10127 From noreply@sourceforge.net Thu May 30 12:34:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu May 30 11:34:05 2002 Subject: [ expat-Patches-551599 ] Patch for # 544679, 548690, 549014, 551852, 553318 Message-ID: Patches item #551599, was opened at 2002-05-02 16:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=551599&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for # 544679, 548690, 549014, 551852, 553318 Initial Comment: This is an extensive patch, and needs not only testing, but also a review by my fellow developers! It addresses these issues: # 483514 (default handler reports too much from DTD): only the following data are reported now: - ignored DTD sections - unhandled external parameter entity references - top level whitespace This may not be what is needed, but more would have been a lot of work # 544679, 548690 (DTD handling of external entities): - the storeEntityValue function has been modified to call the external entity reference handler, since it did not handle external PE references at all - a new STRING_POOL has been added that gets passed from a parent to a child parser (member of DTD structure), so that entity values can be built across parsers - new functions entityValueInitProcessor and entityValueProcessor have been added - the old usage of dtd.complete was completely changed - I never understood how it worked, and it didn't work properly anyway; therefore there is a danger now that some logic will not work anymore - please review and check - the usage of hadExternalDoctype was modified too - there have been changes in xmlrole.c too - the chain of state handlers was extended from entity9 to entity10 - in analogy to how general entities - please review the diff file - as a result, this patch now processes all of James Clark's test cases in the /valid/not-sa and /valid/ext-sa directories properly * I have also made some fixes to the recently introduced XML_ParserReset function (incl. changing it's return type), and one fix that prevents a null pointer error The patch is based on these revisions: - expat.h rev. 1.17 - xmlparse.c rev. 1.31 - xmlrole.c rev. 1.5 - xmlrole.h rev. 1.3 I have included the full patch files, an annotated version of xmlparse.c - good to understand my changes, and the diff files. Karl ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-30 14:33 Message: Logged In: YES user_id=290026 This patch has been checked in. Closed, since no complaints have been received. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-23 15:46 Message: Logged In: YES user_id=290026 OK, I deleted a few, but not all. I think it is important to be able to trace through the changes I made. (at least for me, this is where I would go to check what I did and why I did it) Also, the annotated versions explain a lot of the patch, and these explanations are not present in the final files. Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-23 15:35 Message: Logged In: YES user_id=3066 Karl, can you delete the attachments that are no longer current? There are just too many to filter through! Thanks! Does your CVS client not allow you to create a single patch file with diffs for all changed files? The typical command-line client let's me say "cvs diff" at the top of the tree and I get a single patch output on standard output. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-19 17:10 Message: Logged In: YES user_id=13222 I've done a lot of testing, with expat CVS HEAD and this patch applied (and had some pleasant mail conversation with Karl, about the nifty details and the findings.) Let me first confirm, that I was able to reproduce the following bugs related to this patch: 548690 and 544679 (They describe the same behavior.) 549014 (I've already submitted comments to this bug) 544679 There's also a known bug (for which I wasn't able to find the bug nr, sorry), about XML_EntityDeclHandler() is not reporting declarations of external PE references. This I also have to confirm (examples are xmltest/valid/not-sa/005.xml, 011.xml, 012.xml, 026.xml out of the below mentioned test suite). Can't say something about the bugs 553318 and 549014 because I haven't tried to confirm the described bugs. Summary of my findings: The patch seems to fix at least 548690, 544679, 549014, 544679 and the problem with not reported declaration of external PE references. I doesn't found any new problem introduced by the patch. See below for a description of what I've done. That said, I still have an objection. With this patch applied, there is no way to detect, if a parameter entity is not declared, even if you read all external parameter entities, because now expat skip silently all not resolvable entities, if a document has an external subset or external parameter entities. Bug 552297 would be a way, to handle this. What I've done: I've mainly used the OASIS XML test suite, second edtion. You'll find it at http://www.oasis-open.org/committees/xml-conformance/suite-v1se/xmlconf-20010315.htm This testsuite includes several testpackages, contributed by different parties. Most of them split the tests in not-wellformed, valid, and in-valid tests. With a few simple shell scripts and xmlwf (with the option -p), I've checked all not-wellformed tests (all should produce an error) and all valid test (since they are a valid, the must be well-formed and therefor should all pass without an error.) Only in single cases I've checked, if the error reason, given by xmlwf is the one, the OASIS test suite expects; for most of the not-wellformed tests, I could only claim, that xmlwf does report an error, but could not say, if it's the 'right' error. I've run my test scripts with expat-1.92, with expat CVS HEAD, and with expat CVS HEAD with Karl's patch added. Expat 1.95.2 and expat CVS HEAD had the same results: xmltest/valid/not-sa/003.xml xmltest/valid/not-sa/004.xml xmltest/valid/not-sa/031.xml ibm/not-wf/misc/432gewf.xml sun/not-wf/uri01.xml where wrong. 003.xml, 004.xml and 031.xml are examples for bug 544679. The problem with 432gwf.xml is, that this file includes the entity declaration "> The replace text does not conform to production 79 (see XML rec 4.3.2). The entity isn't actually used, in the document (if it would be used, expat would report an error. It seems to me, expat does not check the replace text angainst production 79 at declaration time. This is a real problem, but more a minor one. The problem with uri01.xml is, that this document uses a fragment identifier in the SYSTEM of an external entity declaration. This is in deed not allowed (see XML rec 4.2.2), but the rec say: "[A]n XML processor may signal an error if a fragment identifier is given as part of a system identifier". So, first, this is "may" and not "must" and, second, since you have to provide your external entity resolver by yourself, with the expat library, this could be handled at application level, if the programmer want this. Therefor I would rank this as a very minor problem, if ever. Expat with Karl's patch had the results: xmltest/not-wf/not-sa/005.xml ibm/not-wf/misc/432gewf.xml sun/not-wf/uri01.xml 003.xml, 004.xml and 031.xml from above are fixed. 005.xml is a questionable test. It uses in an external parameter entity a not declared parameter entity. The test suite expects the parser, to claim about this. But since this is a well-formedness test and the document has references to external parameter entities, the "Well-Formedness Constraint: Entity Declared" of production 68 does not apply. Therefor, Karl argues that this test tests the "Validity Constraint: Entity Declared" of production 68 and 69. He has already written a mail about this to the OASIS XML compliance group about this. (I personally still feel a bit uncomfortable about this. Since Karl has the spec on his side (if you read it literal, The oasis testpackage of the testsuite is not organized along this not-wf, valid and not-valid scheme. Instead, there are a couple of "fail" and "pass" tests. All "pass" tests passes xmlwf without error. The "fail" tests p06fail1.xml p08fail1.xml p08fail2.xml p16fail3.xml doesn't trigger an error. But all four tests are testing problems, that are only detected by validating parsers (the test files notices that explicitly). Additional, I've compared the output produced by xmlwf, if you use -d option for all valid tests, for which an expected output was given. Due to a few differences between the canonical output, expected by the OASIS test suite, and the canonnical XML output, produced by xmlwf (which is, I suspect, 'James Clark canonical XML', see http://jclark.com/xml/canonxml.html), I had to check some cases by hand. Expat-1.95.2, expat HEAD and expat with Karl's patch produced byte-identical output. While comparing the expat output with what the OASIS test suites expect, I found three interesting cases. xmltest/valid/sa/098.xml This test includes a processing instruction with a DOS end-of-line sequence (0d 0a). In the expat output this end-of-line marker is 'normalized' to the XML standard (only 0a). The expected output still has the 0d 0a from the document. ibm/valid/P02/ibm02v01.xml This is a crazy case. I argue, that this test is not well-formed XML, because it includes an illegal UTF-8 sequenz. xmlwf passes the document, but the xmlwf result differs from the expected result. I'm not surprised, that expat does not detect the ill-formed UTF-8 (see bug 477667). (Well, I'm a bit surprised, that the test is included als valid test..) sun/valid/sa02.xml The problem is a difference in attribute value normalization (interesting enought, expat seems to follow E70 of http://www.w3.org/XML/xml-19980210-errata for the handling of #xD and #xA.) To check the mentioned problem with the reporting of declaration of external parameter entity references, I've used the expat binding from http://sdf.lonestar.org/~loewerj/tdom.cgi xmltest/valid/not-sa/005.xml xmltest/valid/not-sa/011.xml xmltest/valid/not-sa/012.xml xmltest/valid/not-sa/026.xml are examples which showed, that expat 1.95.2 and expat CVS sometimes doesn't report entity declarations via XML_EntityDeclHandler. With Karls patch applied, the declarations get reported. I've an application, that is able to trigger the bug 549014. Using the memory debugger mpatrol ( http://www.cbmamiga.demon.co.uk/mpatrol/ ) I could show, that the seg fault happens at the place, the analysis to 549014 explains. After applying Karl's patch, the seg fault is vanished. Don't hesitate to ask, If you need more info about one of the discussed points. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-12 20:23 Message: Logged In: YES user_id=290026 There were only a few modifications necessary to make this patch perform well under testing: - It did not compile when XML_DTD was not defined - fixed - forgot to adjust the appendAttribute() function for the modifications in DTD handling logic - fixed This is the final version of the patch - check the new file xmlparse_final.c (and the diff created from it). So, to get the full final patch, download expat.h, xmlrole.h, xmlrole.c and xmlparse_final.c from the set of attached files. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-07 11:53 Message: Logged In: YES user_id=290026 This is the second improvement and probably the final version of the patch. If there should be more changes, a new patch will be entered, since it might get confusing otherwise. The following changes have been made: - some improvements on external PE reference handling - a better fix (hopefully) for bug # 549014 - the changes to DefaultHandler calls for DTDs have been undone - I realized that more extensive changes (also to xmlrole.c and xmlrole.h) would be necessary, so the old behaviour is back: everything for DTDs is reported, even if handlers are set, except for PIs, Comments and XML text declarations. This patch now applies to the following bugs: - # 553318 - # 551852 - # 549014 - # 548690 - # 544679 Uploaded as files xmlparse_2.c and xmlparse_2.c.diff. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-04 13:13 Message: Logged In: YES user_id=290026 I improved the patch to cover one more problem: I found that bug # 551852 (BOM problem with small buffers), that was reported for general external entities, also applied to external parameter entities. This problem only applied to this patch, since the current release of Expat simply ignores external PEs (which causes bug # 548690). Included is also a fix for bug # 549014 (dtdCopy problem). The attached file are xmlparse_1.c, xmlparse_1.c.annotated and xmlparse_1.diff (against rev. 1.31). Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-03 10:09 Message: Logged In: YES user_id=290026 Forgot to add: the fix for bug # 551852 is included too. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=551599&group_id=10127 From noreply@sourceforge.net Thu May 30 13:03:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu May 30 12:03:02 2002 Subject: [ expat-Bugs-477667 ] illegal utf-8 seqs do not throw error Message-ID: Bugs item #477667, was opened at 2001-11-02 17:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=477667&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Patrick McCormick (patrickmc) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: illegal utf-8 seqs do not throw error Initial Comment: I have a problem where users like to use iso-8859-1 without declaring it in the prolog, like this: abécdef expat properly defaults to utf-8 in this case. As I understand utf-8, the é character (0xE7) has a bitfield that looks like the start of a three byte sequence. A 3-byte sequence is supposed to look like this: bytes | bits | representation 3 | 16 | 1110vvvv 10vvvvvv 10vvvvvv the above two bytes (c and d) don't match the 10vvvvvv mask, so écd is an illegal utf-8 sequence. But expat doesn't throw a well-formedness error. Expat uses this macro in xmltok.c to figure out what's illegal: #define UTF8_INVALID3(p) \ ((*p) == 0xED \ ? (((p)[1] & 0x20) != 0) \ : ((*p) == 0xEF \ ? ((p)[1] == 0xBF && ((p)[2] == 0xBF || (p)[2] == 0xBE)) \ : 0)) but this doesn't seem strict enough. I wrote a patch that makes expat check UTF-8 sequences against the Table 3.1B of the Unicode 3.1 standard: http://www.unicode.org/unicode/reports/tr27/ as originally clarified in this Corrigendum: http://www.unicode.org/unicode/uni2errata/UTF- 8_Corrigendum.html and it's attached. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-30 14:25 Message: Logged In: YES user_id=290026 Patch # 562005 seems to fix the problem and was checked in. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-29 14:21 Message: Logged In: YES user_id=290026 I think that Patrick's patch is essentially correct. Btw, the UTF-8 checking code one can download from Unicode.org is actually not 100% conforming to their own rules. Patrick's direct approach made me check that. Thanks, Patrick. I have submitted patch # 562005, which is based on Unicode 3.2, where the definition of legal UTF-8 sequences has been changed slightly. Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-21 23:27 Message: Logged In: YES user_id=3066 The corrected test is now checked in as tests/runtests.c revision 1.19. ---------------------------------------------------------------------- Comment By: Patrick McCormick (patrickmc) Date: 2002-05-17 15:25 Message: Logged In: YES user_id=363812 actually NORMAL_VTABLE *initializes* the struct, it doesn't define it; that's done at "struct normal_encoding". so that's how the functions are hooked up. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-17 15:24 Message: Logged In: YES user_id=3066 Aargh! This is why I hate token pasting! "grep" doesn't like it either. It gets glued in in four "struct normal_encoding" structures statically defined, starting with "utf8_encoding_ns". Ok, I'll keep digging. ---------------------------------------------------------------------- Comment By: Patrick McCormick (patrickmc) Date: 2002-05-17 15:18 Message: Logged In: YES user_id=363812 not referenced? sure it is! you have to tap into the crazy zen of expat's vtables-without-C++. look at the struct utf8_encoding. at the bottom, it uses the macro NORMAL_VTABLE(utf8_), which creates a struct entry "utf8_invalid3". the macro IS_INVALID_CHAR turns into a function call to the appropriate utf8_invalidN struct member. at some point the struct members are hooked up to the functions, but I'm not sure where. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-17 13:58 Message: Logged In: YES user_id=3066 It's not just that the UTF8_INVALID3() macro is wrong, but that it isn't used at all! The macro is referenced from utf8_isInvalid3(), but that function is not referenced. ;-( ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-17 12:31 Message: Logged In: YES user_id=3066 Ok, I've found a bug in the test case (re-using the parser without resetting it); I've fixed that in my copy and can now reproduce the error. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-17 12:20 Message: Logged In: YES user_id=290026 I am using the library directly - with my own code. Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-17 11:52 Message: Logged In: YES user_id=3066 This is strange. Using the CVS version of Expat, the test case (in tests/runtests.c:test_illegal_utf8) sees the error properly reported. xmlwf doesn't report it, however. Are you using the library directly or going through xmlwf? I'll see what I can figure out. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-09 10:44 Message: Logged In: YES user_id=290026 There is official conversion code at unicode.org. Download the files ConvertUTF.c and ConvertUTF.h from ftp://www.unicode.org/Public/PROGRAMS/CVTUTF/ and then look at the function static Boolean isLegalUTF8(UTF8 *source, int length) Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-09 10:24 Message: Logged In: YES user_id=290026 I can confirm that the current CVS does indeed not report an error against: abécdef Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-05-08 17:40 Message: Logged In: YES user_id=13222 I'm not happy with closing this bug report without action. Contrary to Fred's test result, I still find, that the described bug is still there (as it was at the time, the bug was reported). I've tested this with the current CVS HEAD. The bug is in deed easly demonstrable with the example out of the bug report. I use: abécdef The third character of the PCDATA is a small e with acute, that's 0xe9 in the iso-8859-1 char table (and the unicode char 00e9), if there may be an encoding problem throu the web interface. xmlwf passes this test file, without any error report, which is, to the best of my knowledge, wrong. rxp and libxml (i.e. xmllint) confirm, that the test file is not proper UTF-8. IHMO, this is a real _crucial_ bug. Please, __Please__, re-check this. rolf ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-19 15:19 Message: Logged In: YES user_id=3066 Added a test (tests/runtests.c revision 1.9) that shows this bug does not exist in the CVS version. You did not state which version of Expat you're using. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=477667&group_id=10127 From noreply@sourceforge.net Thu May 30 13:55:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu May 30 12:55:04 2002 Subject: [ expat-Bugs-432456 ] DLL name 'expat.dll' causes problems Message-ID: Bugs item #432456, was opened at 2001-06-12 12:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=432456&group_id=10127 Category: None Group: Platform Specific Status: Open Resolution: None >Priority: 7 Submitted By: Kevin Gilpin (kgilpin) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: DLL name 'expat.dll' causes problems Initial Comment: On Win32, when attempting to build the XML::Parser Perl module with expat, the name 'expat.dll' is used by both projects. This causes problems when running XML::Parser, because only one of the 2 dlls can be loaded. By changing the output target of expat to 'libexpat.dll' (and generating and linking against the corresponding libexpat.lib) I was able to get XML::Parser successfully built and running on Win NT. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-30 15:54 Message: Logged In: YES user_id=3066 Bumped priority. ---------------------------------------------------------------------- Comment By: Gerrit Haase (siebenschlaefer) Date: 2002-05-25 06:01 Message: Logged In: YES user_id=76037 On Cygwin we use libtoll which manages the naming. If you would use automake too... (yes I know...). Libtool names the lib cygexpat-0.dll since there is no versioning which is compatible with libtool. If the API changes it would be named cygexpat-1.dll so both versions may coexist. It would be very easy to transfer this to the Windows version. Just name it winexpat-0.dll and so on, so every conflict can be avoided, e.g. using expat on windows in three versions (cygwin, native windows, perl). Just my 2c. Gerrit ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-25 00:06 Message: Logged In: YES user_id=290026 On Linux I was already using libexpat.so and libexpatw.so (w stands for "wide"). So, why not use libexpat.dll and libexpatw.dll? Just to create confusion, Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-23 15:14 Message: Logged In: YES user_id=3066 While we may have some "right" to the name "expat" for the DLL, older versions of expat used "xmlparse" and "xmltok", and the Perl module started using "expat" (perhaps for some technical reason, since the Perl module is XML::Parser::Expat). I'll vote that we should call our DLL "libexpatutf8" when compiled for UTF-8 output, and "libexpatutf16" when compiled for UTF-16 output. Yeah, that's new for everyone, and annoying as hell, but beats making Expat support both output encodings in one compiled version. (Well, except when you really want both.) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-21 20:39 Message: Logged In: NO It took a coule of hours to get things working on my machine (Win2k sp2), so I thought I'd post what I did so others won't waste time. I'm not sure if what I did was the correct method, but it worked for me. 1) Download and extract the XML::Parser ZIP from CPAN. 3) Replace all occurances of "expat" with "libexpat" in all files. 3) Rename the Expat directory to libexpat. 4) Rename the expat.pm and expat.xs files accordingly. 5) Open libexpat.xs and change the #include back to #include 6) Build the make files (perl makefile.pl) 7) Open the libexpat makefile and change the PERLARCHIVE line to read (note, I put expat.h, dll, and lib in my perl\lib\CORE directory): PERL_ARCHIVE = $(PERL_INC)\perl56.lib $(PERL_INC) \expat.lib" 8) Run namke 9) Copy the PERL\lib\CORE\expat.dll to blib\arch\xml\parser\libexpat and run 'nmake test'. ---------------------------------------------------------------------- Comment By: Greg Stein (gstein) Date: 2002-05-17 20:55 Message: Logged In: YES user_id=6501 Calling the library expat2.dll would be fine with me. libexpat.dll might also be fine. But also note: *we* are Expat, not the Perl extension. We have more "right" to expat.dll if that is what we choose to do. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-10-01 18:08 Message: Logged In: YES user_id=3066 So this appearantly never worked with Expat 1.95+. Sigh. We could go back to xmlparse.dll I suppose, but I don't really like that. I don't know that we've retained enough compatibility with that. Perhaps "expat2" would be good enough, since the real target right now is a stable Expat 2.0. I'll think about this a little more, but I'd like to have it solved in Expat 1.95.3. Assigning to me since Clark has been abducted by aliens. ---------------------------------------------------------------------- Comment By: Kevin Gilpin (kgilpin) Date: 2001-10-01 17:51 Message: Logged In: YES user_id=44882 The problem is that the Perl extension consists of 2 dlls: 1) the expat DLL, which does not contain any perl references 2) the perl -> expat DLL, which references both the Perl APIs and the Expat APIs Both of these DLLs are called 'expat.dll', which is a problem b/c Windows will cannot tell the difference between them when the Perl program is run ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-10-01 16:26 Message: Logged In: YES user_id=3066 Thinking about this again, I realize I don't know enough about the Perl extension machinery and mod_perl to be sure of this. Is mod_perl providing an expat.dll which is something different, or is it a different version of that mod_perl uses? We need a mod_perl/XML::Parser expert to answer reports like this one! Leaving this one assigned to Clark until we have such a person with available time. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-25 12:39 Message: Logged In: YES user_id=3066 This relates to having multiple versions of the library being made available in the same process. Assigned to Clark since he might have more of the context information related to XML::Parser. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=432456&group_id=10127 From noreply@sourceforge.net Thu May 30 20:37:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu May 30 19:37:01 2002 Subject: [ expat-Bugs-432456 ] DLL name 'expat.dll' causes problems Message-ID: Bugs item #432456, was opened at 2001-06-12 12:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=432456&group_id=10127 >Category: Build control Group: Platform Specific Status: Open >Resolution: Fixed >Priority: 6 Submitted By: Kevin Gilpin (kgilpin) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: DLL name 'expat.dll' causes problems Initial Comment: On Win32, when attempting to build the XML::Parser Perl module with expat, the name 'expat.dll' is used by both projects. This causes problems when running XML::Parser, because only one of the 2 dlls can be loaded. By changing the output target of expat to 'libexpat.dll' (and generating and linking against the corresponding libexpat.lib) I was able to get XML::Parser successfully built and running on Win NT. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-30 22:36 Message: Logged In: YES user_id=3066 Changed the name of the Expat DLLs on Windows from "expat.dll" to "libexpat.dll", solving the original bug. See lib/expat.dsp 1.8 and examples/elements.dsp 1.3. Creating the "w" version of the DLL is a separate change to the project files; I'll try to do this next. The report is now marked "Fixed" since the bug is fixed; what remains is a new feature, and therefore a slightly lower priority. I'm not sure why the name of the DLL does not appear in the other .dsp files -- if anyone can enlighten me, I'd certainly appreciate it! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-30 15:54 Message: Logged In: YES user_id=3066 Bumped priority. ---------------------------------------------------------------------- Comment By: Gerrit Haase (siebenschlaefer) Date: 2002-05-25 06:01 Message: Logged In: YES user_id=76037 On Cygwin we use libtoll which manages the naming. If you would use automake too... (yes I know...). Libtool names the lib cygexpat-0.dll since there is no versioning which is compatible with libtool. If the API changes it would be named cygexpat-1.dll so both versions may coexist. It would be very easy to transfer this to the Windows version. Just name it winexpat-0.dll and so on, so every conflict can be avoided, e.g. using expat on windows in three versions (cygwin, native windows, perl). Just my 2c. Gerrit ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-25 00:06 Message: Logged In: YES user_id=290026 On Linux I was already using libexpat.so and libexpatw.so (w stands for "wide"). So, why not use libexpat.dll and libexpatw.dll? Just to create confusion, Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-23 15:14 Message: Logged In: YES user_id=3066 While we may have some "right" to the name "expat" for the DLL, older versions of expat used "xmlparse" and "xmltok", and the Perl module started using "expat" (perhaps for some technical reason, since the Perl module is XML::Parser::Expat). I'll vote that we should call our DLL "libexpatutf8" when compiled for UTF-8 output, and "libexpatutf16" when compiled for UTF-16 output. Yeah, that's new for everyone, and annoying as hell, but beats making Expat support both output encodings in one compiled version. (Well, except when you really want both.) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-21 20:39 Message: Logged In: NO It took a coule of hours to get things working on my machine (Win2k sp2), so I thought I'd post what I did so others won't waste time. I'm not sure if what I did was the correct method, but it worked for me. 1) Download and extract the XML::Parser ZIP from CPAN. 3) Replace all occurances of "expat" with "libexpat" in all files. 3) Rename the Expat directory to libexpat. 4) Rename the expat.pm and expat.xs files accordingly. 5) Open libexpat.xs and change the #include back to #include 6) Build the make files (perl makefile.pl) 7) Open the libexpat makefile and change the PERLARCHIVE line to read (note, I put expat.h, dll, and lib in my perl\lib\CORE directory): PERL_ARCHIVE = $(PERL_INC)\perl56.lib $(PERL_INC) \expat.lib" 8) Run namke 9) Copy the PERL\lib\CORE\expat.dll to blib\arch\xml\parser\libexpat and run 'nmake test'. ---------------------------------------------------------------------- Comment By: Greg Stein (gstein) Date: 2002-05-17 20:55 Message: Logged In: YES user_id=6501 Calling the library expat2.dll would be fine with me. libexpat.dll might also be fine. But also note: *we* are Expat, not the Perl extension. We have more "right" to expat.dll if that is what we choose to do. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-10-01 18:08 Message: Logged In: YES user_id=3066 So this appearantly never worked with Expat 1.95+. Sigh. We could go back to xmlparse.dll I suppose, but I don't really like that. I don't know that we've retained enough compatibility with that. Perhaps "expat2" would be good enough, since the real target right now is a stable Expat 2.0. I'll think about this a little more, but I'd like to have it solved in Expat 1.95.3. Assigning to me since Clark has been abducted by aliens. ---------------------------------------------------------------------- Comment By: Kevin Gilpin (kgilpin) Date: 2001-10-01 17:51 Message: Logged In: YES user_id=44882 The problem is that the Perl extension consists of 2 dlls: 1) the expat DLL, which does not contain any perl references 2) the perl -> expat DLL, which references both the Perl APIs and the Expat APIs Both of these DLLs are called 'expat.dll', which is a problem b/c Windows will cannot tell the difference between them when the Perl program is run ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-10-01 16:26 Message: Logged In: YES user_id=3066 Thinking about this again, I realize I don't know enough about the Perl extension machinery and mod_perl to be sure of this. Is mod_perl providing an expat.dll which is something different, or is it a different version of that mod_perl uses? We need a mod_perl/XML::Parser expert to answer reports like this one! Leaving this one assigned to Clark until we have such a person with available time. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-25 12:39 Message: Logged In: YES user_id=3066 This relates to having multiple versions of the library being made available in the same process. Assigned to Clark since he might have more of the context information related to XML::Parser. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=432456&group_id=10127 From noreply@sourceforge.net Thu May 30 21:16:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu May 30 20:16:02 2002 Subject: [ expat-Bugs-432456 ] DLL name 'expat.dll' causes problems Message-ID: Bugs item #432456, was opened at 2001-06-12 12:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=432456&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: Fixed Priority: 6 Submitted By: Kevin Gilpin (kgilpin) >Assigned to: Karl Waclawek (kwaclaw) Summary: DLL name 'expat.dll' causes problems Initial Comment: On Win32, when attempting to build the XML::Parser Perl module with expat, the name 'expat.dll' is used by both projects. This causes problems when running XML::Parser, because only one of the 2 dlls can be loaded. By changing the output target of expat to 'libexpat.dll' (and generating and linking against the corresponding libexpat.lib) I was able to get XML::Parser successfully built and running on Win NT. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-30 23:15 Message: Logged In: YES user_id=3066 Added new project, "expatw", to the Expat MSVC workspace. This *should* be the right change to build a wchar_t version of Expat using the DLL name libexpatw.dll (both Debug and Release versions). Karl, I don't have any code to use the new versions of the library. Could you test and close this report if we're really done? Thanks! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-30 22:36 Message: Logged In: YES user_id=3066 Changed the name of the Expat DLLs on Windows from "expat.dll" to "libexpat.dll", solving the original bug. See lib/expat.dsp 1.8 and examples/elements.dsp 1.3. Creating the "w" version of the DLL is a separate change to the project files; I'll try to do this next. The report is now marked "Fixed" since the bug is fixed; what remains is a new feature, and therefore a slightly lower priority. I'm not sure why the name of the DLL does not appear in the other .dsp files -- if anyone can enlighten me, I'd certainly appreciate it! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-30 15:54 Message: Logged In: YES user_id=3066 Bumped priority. ---------------------------------------------------------------------- Comment By: Gerrit Haase (siebenschlaefer) Date: 2002-05-25 06:01 Message: Logged In: YES user_id=76037 On Cygwin we use libtoll which manages the naming. If you would use automake too... (yes I know...). Libtool names the lib cygexpat-0.dll since there is no versioning which is compatible with libtool. If the API changes it would be named cygexpat-1.dll so both versions may coexist. It would be very easy to transfer this to the Windows version. Just name it winexpat-0.dll and so on, so every conflict can be avoided, e.g. using expat on windows in three versions (cygwin, native windows, perl). Just my 2c. Gerrit ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-25 00:06 Message: Logged In: YES user_id=290026 On Linux I was already using libexpat.so and libexpatw.so (w stands for "wide"). So, why not use libexpat.dll and libexpatw.dll? Just to create confusion, Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-23 15:14 Message: Logged In: YES user_id=3066 While we may have some "right" to the name "expat" for the DLL, older versions of expat used "xmlparse" and "xmltok", and the Perl module started using "expat" (perhaps for some technical reason, since the Perl module is XML::Parser::Expat). I'll vote that we should call our DLL "libexpatutf8" when compiled for UTF-8 output, and "libexpatutf16" when compiled for UTF-16 output. Yeah, that's new for everyone, and annoying as hell, but beats making Expat support both output encodings in one compiled version. (Well, except when you really want both.) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-21 20:39 Message: Logged In: NO It took a coule of hours to get things working on my machine (Win2k sp2), so I thought I'd post what I did so others won't waste time. I'm not sure if what I did was the correct method, but it worked for me. 1) Download and extract the XML::Parser ZIP from CPAN. 3) Replace all occurances of "expat" with "libexpat" in all files. 3) Rename the Expat directory to libexpat. 4) Rename the expat.pm and expat.xs files accordingly. 5) Open libexpat.xs and change the #include back to #include 6) Build the make files (perl makefile.pl) 7) Open the libexpat makefile and change the PERLARCHIVE line to read (note, I put expat.h, dll, and lib in my perl\lib\CORE directory): PERL_ARCHIVE = $(PERL_INC)\perl56.lib $(PERL_INC) \expat.lib" 8) Run namke 9) Copy the PERL\lib\CORE\expat.dll to blib\arch\xml\parser\libexpat and run 'nmake test'. ---------------------------------------------------------------------- Comment By: Greg Stein (gstein) Date: 2002-05-17 20:55 Message: Logged In: YES user_id=6501 Calling the library expat2.dll would be fine with me. libexpat.dll might also be fine. But also note: *we* are Expat, not the Perl extension. We have more "right" to expat.dll if that is what we choose to do. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-10-01 18:08 Message: Logged In: YES user_id=3066 So this appearantly never worked with Expat 1.95+. Sigh. We could go back to xmlparse.dll I suppose, but I don't really like that. I don't know that we've retained enough compatibility with that. Perhaps "expat2" would be good enough, since the real target right now is a stable Expat 2.0. I'll think about this a little more, but I'd like to have it solved in Expat 1.95.3. Assigning to me since Clark has been abducted by aliens. ---------------------------------------------------------------------- Comment By: Kevin Gilpin (kgilpin) Date: 2001-10-01 17:51 Message: Logged In: YES user_id=44882 The problem is that the Perl extension consists of 2 dlls: 1) the expat DLL, which does not contain any perl references 2) the perl -> expat DLL, which references both the Perl APIs and the Expat APIs Both of these DLLs are called 'expat.dll', which is a problem b/c Windows will cannot tell the difference between them when the Perl program is run ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-10-01 16:26 Message: Logged In: YES user_id=3066 Thinking about this again, I realize I don't know enough about the Perl extension machinery and mod_perl to be sure of this. Is mod_perl providing an expat.dll which is something different, or is it a different version of that mod_perl uses? We need a mod_perl/XML::Parser expert to answer reports like this one! Leaving this one assigned to Clark until we have such a person with available time. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-25 12:39 Message: Logged In: YES user_id=3066 This relates to having multiple versions of the library being made available in the same process. Assigned to Clark since he might have more of the context information related to XML::Parser. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=432456&group_id=10127 From noreply@sourceforge.net Thu May 30 21:27:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu May 30 20:27:01 2002 Subject: [ expat-Bugs-414993 ] xmlfile.obj : error LNK2001: unresolved Message-ID: Bugs item #414993, was opened at 2001-04-09 16:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=414993&group_id=10127 Category: Build control Group: None Status: Closed Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: xmlfile.obj : error LNK2001: unresolved Initial Comment: I'm unable to resolve this problem. I don't which file is missing for this error to show up. Here is a sample of the error message. I am compiling with MS VC++ 6.0. I am attempting to create the perl module that incorporates expat. The Perl version is 5.005-3 from ActiveState. Expat.obj : error LNK2001: unresolved external symbol _XML_DefaultCurrent Expat.obj : error LNK2001: unresolved external symbol _XML_GetSpecifiedAttributeCount Expat.obj : error LNK2001: unresolved external symbol _XML_GetCurrentByteCount Expat.obj : error LNK2001: unresolved external symbol _XML_SetStartCdataSectionHandler Expat.obj : error LNK2001: unresolved external symbol _XML_SetEndCdataSectionHandler ..\blib\arch\auto\XML\Parser\Expat\Expat.dll : fatal error LNK1120: 55 unresolved externals NMAKE : fatal error U1077: 'link' : return code '0x460' Stop. NMAKE : fatal error U1077: 'cd' : return code '0x2' Stop. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-30 23:26 Message: Logged In: YES user_id=3066 This appears to be an instance of the DLL name clash "bug" (SF bug #432456). This has been resolved by changing the name of the Expat DLL from "expat.dll" to "libexpat.dll" in Expat 1.95.3. ---------------------------------------------------------------------- Comment By: Greg Stein (gstein) Date: 2002-05-17 21:20 Message: Logged In: YES user_id=6501 This is a problem with the Perl wrappers, not Expat itself. Closing as invalid. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-03-12 08:51 Message: Logged In: NO Hi, I have a similar problem. I would like to run the outline.c file that is given as an example with the expat documentation. I include (I first had to add expat.h to my library, and also xmlparse.h that is used in the c-program) With compiling, everything goes great, (no problems), but to execute it, I receive the following errors: outline.obj : error LNK2001: unresolved external symbol __imp__XML_GetCurrentLineNumber outline.obj : error LNK2001: unresolved external symbol __imp__XML_ErrorString outline.obj : error LNK2001: unresolved external symbol __imp__XML_GetErrorCode outline.obj : error LNK2001: unresolved external symbol __imp__XML_Parse outline.obj : error LNK2001: unresolved external symbol __imp__XML_SetElementHandler outline.obj : error LNK2001: unresolved external symbol __imp__XML_ParserCreate Debug/outline.exe : fatal error LNK1120: 6 unresolved externals Error executing link.exe. outline.exe - 7 error(s), 0 warning(s) I have version 1.95.2 greetings and thanks for your help. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-20 23:56 Message: Logged In: YES user_id=3066 Which version of expat was this using? 1.95.x, or the latest CVS sources? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=414993&group_id=10127 From noreply@sourceforge.net Thu May 30 21:50:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu May 30 20:50:02 2002 Subject: [ expat-Bugs-484233 ] libexpat.so major version Message-ID: Bugs item #484233, was opened at 2001-11-21 11:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=484233&group_id=10127 Category: Build control Group: None Status: Open Resolution: None Priority: 6 Submitted By: Ed Avis (epaepa) Assigned to: Greg Stein (gstein) Summary: libexpat.so major version Initial Comment: The newer expat releases build a shared library, but they decide to call it libexpat.so.0. Surely since the expat version itself is 1.95, the library should be installed as libexpat.so.1.95 and libexpat.so.1? It is certainly a bit odd to pick the major number zero; third parties who have built shared libraries from older expat distributions probably chose 1, so it looks like the version number is going downwards. Suggest making the shared library version match the expat version, and increasing the major soname when backwards-incompatible API changes are introduced. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-30 23:49 Message: Logged In: YES user_id=3066 Greg, can you address this report please? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=484233&group_id=10127 From noreply@sourceforge.net Thu May 30 22:05:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu May 30 21:05:03 2002 Subject: [ expat-Patches-538032 ] Borland Win32 project & makefiles Message-ID: Patches item #538032, was opened at 2002-04-01 16:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=538032&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Patrick McConnell (pmcconnell) Assigned to: Nobody/Anonymous (nobody) Summary: Borland Win32 project & makefiles Initial Comment: Borland C++ Builder project file and make file for the command line compiler to build expat.dll Unzip the patch from the directory above expat, then read the README.borland file for instructions. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-31 00:04 Message: Logged In: YES user_id=3066 Does this need to be updated to reflect the header name change from "config.h" to "expat_config.h"? I don't think I'll have time to look at this before 1.95.3; is this just a few additional files or do other files need changing? I'll try to install the recent C++ Builder demo to try this out. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=538032&group_id=10127 From noreply@sourceforge.net Thu May 30 22:05:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu May 30 21:05:03 2002 Subject: [ expat-Bugs-432456 ] DLL name 'expat.dll' causes problems Message-ID: Bugs item #432456, was opened at 2001-06-12 12:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=432456&group_id=10127 Category: Build control Group: Platform Specific >Status: Closed Resolution: Fixed Priority: 6 Submitted By: Kevin Gilpin (kgilpin) Assigned to: Karl Waclawek (kwaclaw) Summary: DLL name 'expat.dll' causes problems Initial Comment: On Win32, when attempting to build the XML::Parser Perl module with expat, the name 'expat.dll' is used by both projects. This causes problems when running XML::Parser, because only one of the 2 dlls can be loaded. By changing the output target of expat to 'libexpat.dll' (and generating and linking against the corresponding libexpat.lib) I was able to get XML::Parser successfully built and running on Win NT. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-31 00:04 Message: Logged In: YES user_id=290026 Ran your changed MSVC projects. Seems to work for me. All you really needed to do is add the XML_UNICODE_WCHAR_T preprocessor definition (for the libexpatw project), and change the name in the link options. Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-30 23:15 Message: Logged In: YES user_id=3066 Added new project, "expatw", to the Expat MSVC workspace. This *should* be the right change to build a wchar_t version of Expat using the DLL name libexpatw.dll (both Debug and Release versions). Karl, I don't have any code to use the new versions of the library. Could you test and close this report if we're really done? Thanks! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-30 22:36 Message: Logged In: YES user_id=3066 Changed the name of the Expat DLLs on Windows from "expat.dll" to "libexpat.dll", solving the original bug. See lib/expat.dsp 1.8 and examples/elements.dsp 1.3. Creating the "w" version of the DLL is a separate change to the project files; I'll try to do this next. The report is now marked "Fixed" since the bug is fixed; what remains is a new feature, and therefore a slightly lower priority. I'm not sure why the name of the DLL does not appear in the other .dsp files -- if anyone can enlighten me, I'd certainly appreciate it! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-30 15:54 Message: Logged In: YES user_id=3066 Bumped priority. ---------------------------------------------------------------------- Comment By: Gerrit Haase (siebenschlaefer) Date: 2002-05-25 06:01 Message: Logged In: YES user_id=76037 On Cygwin we use libtoll which manages the naming. If you would use automake too... (yes I know...). Libtool names the lib cygexpat-0.dll since there is no versioning which is compatible with libtool. If the API changes it would be named cygexpat-1.dll so both versions may coexist. It would be very easy to transfer this to the Windows version. Just name it winexpat-0.dll and so on, so every conflict can be avoided, e.g. using expat on windows in three versions (cygwin, native windows, perl). Just my 2c. Gerrit ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-25 00:06 Message: Logged In: YES user_id=290026 On Linux I was already using libexpat.so and libexpatw.so (w stands for "wide"). So, why not use libexpat.dll and libexpatw.dll? Just to create confusion, Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-23 15:14 Message: Logged In: YES user_id=3066 While we may have some "right" to the name "expat" for the DLL, older versions of expat used "xmlparse" and "xmltok", and the Perl module started using "expat" (perhaps for some technical reason, since the Perl module is XML::Parser::Expat). I'll vote that we should call our DLL "libexpatutf8" when compiled for UTF-8 output, and "libexpatutf16" when compiled for UTF-16 output. Yeah, that's new for everyone, and annoying as hell, but beats making Expat support both output encodings in one compiled version. (Well, except when you really want both.) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-21 20:39 Message: Logged In: NO It took a coule of hours to get things working on my machine (Win2k sp2), so I thought I'd post what I did so others won't waste time. I'm not sure if what I did was the correct method, but it worked for me. 1) Download and extract the XML::Parser ZIP from CPAN. 3) Replace all occurances of "expat" with "libexpat" in all files. 3) Rename the Expat directory to libexpat. 4) Rename the expat.pm and expat.xs files accordingly. 5) Open libexpat.xs and change the #include back to #include 6) Build the make files (perl makefile.pl) 7) Open the libexpat makefile and change the PERLARCHIVE line to read (note, I put expat.h, dll, and lib in my perl\lib\CORE directory): PERL_ARCHIVE = $(PERL_INC)\perl56.lib $(PERL_INC) \expat.lib" 8) Run namke 9) Copy the PERL\lib\CORE\expat.dll to blib\arch\xml\parser\libexpat and run 'nmake test'. ---------------------------------------------------------------------- Comment By: Greg Stein (gstein) Date: 2002-05-17 20:55 Message: Logged In: YES user_id=6501 Calling the library expat2.dll would be fine with me. libexpat.dll might also be fine. But also note: *we* are Expat, not the Perl extension. We have more "right" to expat.dll if that is what we choose to do. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-10-01 18:08 Message: Logged In: YES user_id=3066 So this appearantly never worked with Expat 1.95+. Sigh. We could go back to xmlparse.dll I suppose, but I don't really like that. I don't know that we've retained enough compatibility with that. Perhaps "expat2" would be good enough, since the real target right now is a stable Expat 2.0. I'll think about this a little more, but I'd like to have it solved in Expat 1.95.3. Assigning to me since Clark has been abducted by aliens. ---------------------------------------------------------------------- Comment By: Kevin Gilpin (kgilpin) Date: 2001-10-01 17:51 Message: Logged In: YES user_id=44882 The problem is that the Perl extension consists of 2 dlls: 1) the expat DLL, which does not contain any perl references 2) the perl -> expat DLL, which references both the Perl APIs and the Expat APIs Both of these DLLs are called 'expat.dll', which is a problem b/c Windows will cannot tell the difference between them when the Perl program is run ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-10-01 16:26 Message: Logged In: YES user_id=3066 Thinking about this again, I realize I don't know enough about the Perl extension machinery and mod_perl to be sure of this. Is mod_perl providing an expat.dll which is something different, or is it a different version of that mod_perl uses? We need a mod_perl/XML::Parser expert to answer reports like this one! Leaving this one assigned to Clark until we have such a person with available time. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-25 12:39 Message: Logged In: YES user_id=3066 This relates to having multiple versions of the library being made available in the same process. Assigned to Clark since he might have more of the context information related to XML::Parser. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=432456&group_id=10127 From noreply@sourceforge.net Thu May 30 22:08:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu May 30 21:08:04 2002 Subject: [ expat-Patches-412072 ] Expat for Codewarrior 6.0 / Win32 Message-ID: Patches item #412072, was opened at 2001-03-28 21:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=412072&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: David Crowley (dcrowley) Assigned to: Greg Stein (gstein) Summary: Expat for Codewarrior 6.0 / Win32 Initial Comment: I am forwarding some patches I got from Aleksander Slominski : . . . now about EXPAT in all files: xmlparse.c, xmlrole.c, xmltok.c add at top following line to make sure to include correct config file: #if defined(__MWERKS__) && defined(__INTEL__) #define COMPILED_FROM_DSP #endif but xmlparse.c must be expanded to contain: #if defined(__MWERKS__) && defined(__INTEL__) #define COMPILED_FROM_DSP #define VERSION "expat_1.95.1" #include #define offsetof(BLOCK, s) (size_t) &(((BLOCK *) 0)->s) #endif and also ELEMENT_TYPE somehow get wrongly declared but as is used only in this file just do search/replace to X_ELEMENT_TYPE also do not include in compilation xmltok_ns* and xmltok_impl.c as those are really include files... i also attach modified files thanks, alek -- Aleksander Slominski, LH 316, IU, http://www.extreme.indiana.edu/~aslom ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-31 00:07 Message: Logged In: YES user_id=3066 Closed due to non-response from the submitter to the previous comment and the changes to the Windows support in recent months. If further changes are needed relative to the CVS version or the upcoming 1.95.3, please comment on this report or open a new report. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-25 17:12 Message: Logged In: YES user_id=3066 You don't say what version of Expat you're using. I've revamped the Windows support a bit, but it may still have problems with the Borland compiler. If the problems persist with the CVS version of Expat or the upcoming 1.95.2 release, please add a comment to that effect on this bug report with as much detail as possible -- thanks! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=412072&group_id=10127 From noreply@sourceforge.net Thu May 30 22:10:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu May 30 21:10:03 2002 Subject: [ expat-Patches-403571 ] Makefile for Win32 nmake Message-ID: Patches item #403571, was opened at 2001-02-02 20:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=403571&group_id=10127 Category: Build Control >Group: Feature Request >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Kurt Stephens (kstep) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Makefile for Win32 nmake Initial Comment: The attached Makefile.nt builds and installs Expat-1.95.1 from the Win32 command line using Microsoft's nmake utility. The makefile uses command line macros to specify the library name and installation directories. These macros are documented in the comment block at the top of the file. The makefile should be installed in and run from the Expat-1.95.1\lib subdirectory. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-31 00:09 Message: Logged In: YES user_id=3066 I'm still really annoyed by the MSVC IDE, but things on Windows have changed enough that the contributed makefile will be out of date. This can be re-opened if an updated makefile can be contributed. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-24 13:26 Message: Logged In: YES user_id=3066 Re-assigned to me, since I seem more likely to do something with it at this point. I'm also getting really annoyed by MSVC's IDE. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-02-14 13:24 Message: Assigned to Clark since he seems to have substantially more Windows experience (& platform access) than I do. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=403571&group_id=10127 From noreply@sourceforge.net Thu May 30 22:11:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu May 30 21:11:04 2002 Subject: [ expat-Patches-458907 ] config.h appears to be unused Message-ID: Patches item #458907, was opened at 2001-09-05 17:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=458907&group_id=10127 Category: Build Control Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Greg Stein (gstein) Summary: config.h appears to be unused Initial Comment: To compile expat as part of another package (e.g. PyXML), the expat configure might not have been run. For that kind of application, it is necessary to wrap each occurrence of config.h into HAVE_CONFIG_H; the attached patch does that. While trying to figure out which of the defines are needed, it appears that none of them are (i.e. HAVE_ is never used). For stand-along compilation, I found that only VERSION, XML_NS, XML_DTD, XML_BYTE_ORDER, and XML_CONTEXT_BYTES must be defined. Is that impression correct? ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-31 00:10 Message: Logged In: YES user_id=3066 Greg, can you please respond to this? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-08 23:48 Message: Logged In: YES user_id=3066 It certainly looks like it can be reduced and possibly removed; I'll read up on a few of the autoconf things before removing it completely. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=458907&group_id=10127 From noreply@sourceforge.net Thu May 30 22:13:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu May 30 21:13:01 2002 Subject: [ expat-Patches-461763 ] BOM and ExternalSubset Message-ID: Patches item #461763, was opened at 2001-09-15 00:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=461763&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 6 Submitted By: Gilles Marichal (gilou) >Assigned to: Karl Waclawek (kwaclaw) Summary: BOM and ExternalSubset Initial Comment: Hello, Expat parsing failed when the file to parse had an external subset starting with a BOM. Adding the following two lines at the start of function externalSubset0 in xmlrole.c fixes the problem: if (tok == XML_TOK_BOM) return XML_ROLE_NONE; Note: while correcting that problem, I looked in the xmlrole.c file the others parts of the code handling the XML_TOK_BOM token. I'd like to know the rationale for handling it in prolog1 (wouldn't it always be handled in prolog0 only?). G. Marichal ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-31 00:12 Message: Logged In: YES user_id=3066 Karl, can this be closed? Do we need a test case? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-09 21:26 Message: Logged In: YES user_id=290026 It seems this is related to bug # 551852. In this bug, as well as in patch #551599, a fix has been proposed as well. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=461763&group_id=10127 From noreply@sourceforge.net Fri May 31 07:39:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 31 06:39:21 2002 Subject: [ expat-Patches-461763 ] BOM and ExternalSubset Message-ID: Patches item #461763, was opened at 2001-09-15 00:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=461763&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 6 Submitted By: Gilles Marichal (gilou) Assigned to: Karl Waclawek (kwaclaw) Summary: BOM and ExternalSubset Initial Comment: Hello, Expat parsing failed when the file to parse had an external subset starting with a BOM. Adding the following two lines at the start of function externalSubset0 in xmlrole.c fixes the problem: if (tok == XML_TOK_BOM) return XML_ROLE_NONE; Note: while correcting that problem, I looked in the xmlrole.c file the others parts of the code handling the XML_TOK_BOM token. I'd like to know the rationale for handling it in prolog1 (wouldn't it always be handled in prolog0 only?). G. Marichal ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-31 09:38 Message: Logged In: YES user_id=290026 Looked at it. It is the same problem as reported in bug # 551852. Patch # 551599 deals with this problem in a more general way, i.e. including general external entities. So when bug # 551852 is closed, we should close this patch too. Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-31 00:12 Message: Logged In: YES user_id=3066 Karl, can this be closed? Do we need a test case? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-09 21:26 Message: Logged In: YES user_id=290026 It seems this is related to bug # 551852. In this bug, as well as in patch #551599, a fix has been proposed as well. Karl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=461763&group_id=10127 From noreply@sourceforge.net Fri May 31 13:38:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 31 12:38:02 2002 Subject: [ expat-Bugs-561575 ] "configure" fails Message-ID: Bugs item #561575, was opened at 2002-05-28 11:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=561575&group_id=10127 Category: Build control Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) >Summary: "configure" fails Initial Comment: When installing expat, the command "./configure" fails. Here's what appears a the end of the log: creating Makefile creating lib/Makefile sed: Cannot find or open file ./lib/Makefile.in. creating lib/expat.h sed: Cannot find or open file ./lib/expat.h.in. creating config.h config.h is unchanged Neither lib/Makefile.in, nor lib/expat.h.in exists; however lib/Makefile and lib/expat.h do. The value of variable CONFIG_FILES is "Makefile lib/Makefile lib/expat.h". ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-31 15:37 Message: Logged In: YES user_id=3066 What version of Expat are you using? The build process has changed a lot over each of the last several releases, and the process for the upcoming 1.95.3 release continues this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=561575&group_id=10127 From noreply@sourceforge.net Fri May 31 15:57:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 31 14:57:03 2002 Subject: [ expat-Bugs-484233 ] libexpat.so major version Message-ID: Bugs item #484233, was opened at 2001-11-21 11:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=484233&group_id=10127 Category: Build control Group: None >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Ed Avis (epaepa) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: libexpat.so major version Initial Comment: The newer expat releases build a shared library, but they decide to call it libexpat.so.0. Surely since the expat version itself is 1.95, the library should be installed as libexpat.so.1.95 and libexpat.so.1? It is certainly a bit odd to pick the major number zero; third parties who have built shared libraries from older expat distributions probably chose 1, so it looks like the version number is going downwards. Suggest making the shared library version match the expat version, and increasing the major soname when backwards-incompatible API changes are introduced. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-31 17:56 Message: Logged In: YES user_id=3066 Ok, I've read up on shared library versioning and the libtool recommendations. The lib version does need to be bumped for Expat 1.95.3 (done in configure.in revision 1.30). The specific recommendation in bug report is not correct for Unix shared libraries; libtool already provides the right functionality to allow the library version to be specified in an abstract manner. Closing the bug as fixed, since a change was needed. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-30 23:49 Message: Logged In: YES user_id=3066 Greg, can you address this report please? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=484233&group_id=10127 From noreply@sourceforge.net Fri May 31 16:40:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 31 15:40:03 2002 Subject: [ expat-Patches-538032 ] Borland Win32 project & makefiles Message-ID: Patches item #538032, was opened at 2002-04-01 16:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=538032&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Patrick McConnell (pmcconnell) Assigned to: Nobody/Anonymous (nobody) Summary: Borland Win32 project & makefiles Initial Comment: Borland C++ Builder project file and make file for the command line compiler to build expat.dll Unzip the patch from the directory above expat, then read the README.borland file for instructions. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-31 18:39 Message: Logged In: YES user_id=3066 Well, I won't be able to install the C++ Builder demo on my Win2K system since I don't have enough space on my system disk. ;-( ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-31 00:04 Message: Logged In: YES user_id=3066 Does this need to be updated to reflect the header name change from "config.h" to "expat_config.h"? I don't think I'll have time to look at this before 1.95.3; is this just a few additional files or do other files need changing? I'll try to install the recent C++ Builder demo to try this out. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=538032&group_id=10127 From noreply@sourceforge.net Fri May 31 19:00:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 31 18:00:02 2002 Subject: [ expat-Patches-429501 ] predefined entities... Message-ID: Patches item #429501, was opened at 2001-06-01 22:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=429501&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David MacCormack (spoorancher) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: predefined entities... Initial Comment: Co-workers and myself have found it useful to be able to disable the expansion of default entities under certain circumstances. For example, in a pipeline such as: app1 | app2 | app3 you only want app3 to actually expand default entities, otherwise you'll get wellformedness (is that a word ?:) errors if you have a character handler installed. A buddy of mine actually hacked the xmltok_impl code and recompiled (which works quite well), but I decided to take a stab at providing a function/runtime means of changing this behavior. The attached patch compiles, runs, and it produces the expected results against my test cases. changes include: * new func decl in expat.h (or expat.h.in I suppose) * a few mods to xmlparse.c Dave ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-05-31 20:59 Message: Logged In: YES user_id=290026 Joining this discussion late: An internal entity reference handler should probably do two things: 1) pass name and entity value 2) allow the application to return a value that indicates: skip that entity The second one is necessary, since - contrary to the external entity ref handler, the entity value is already determined, whereas in the external entity ref handler it is the handler that "creates" that data, so by doing nothing it achieves the effect of skipping automatically. Such a handler would also be needed to make Expat more fully SAX capable. Karl ---------------------------------------------------------------------- Comment By: David MacCormack (spoorancher) Date: 2001-07-21 01:40 Message: Logged In: YES user_id=234615 Hi Fred. So if I'm following you, you'd define an XML_InternalEntityRefHandler callback -- or perhaps deprecate the current XML_ExternalEntityRefHandler and simply define a generic XML_EntityRefHandler, combining them as you did with XML_EntityDeclHandler -- as well as the accompanying XML_Set??? function. And, if the user has set a callback, that will be called for each reference; otherwise, the current behavior will be done (as not to break existing code). Is that the gist? It's far more functionality than we (www.bna.com) need, but if (as you say) you want a generic solution that would allow the user to take any action (such as building a DOM), then it looks good to me... go for it :)! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-20 23:24 Message: Logged In: YES user_id=3066 Assigned to me since I'm interested in something similar. Would you consider is acceptable to get a callback for all references to internal entities? I'd like to have an event for internal entities defined in the internal subset and predefined entities like "lt" & friends. You should be able to use a handler for that to present the output you require as well. This would be useful when building a DOM or generating a SAX event stream that contains all the little niggly details. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=429501&group_id=10127 From noreply@sourceforge.net Fri May 31 20:18:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 31 19:18:06 2002 Subject: [ expat-Bugs-462960 ] configure fails on OSX Message-ID: Bugs item #462960, was opened at 2001-09-19 15:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=462960&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None >Priority: 7 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: configure fails on OSX Initial Comment: [mda@IDRG401 expat-1.95.2]$ ./configure -- prefix=/opt creating cache ./config.cache checking host system type... Invalid configuration `unknown-apple-darwin1.3.7': machine `unknown- apple' not recognized checking build system type... Invalid configuration `unknown-apple-darwin1.3.7': machine `unknown- apple' not recognized checking for ranlib... ranlib checking for gcc... no checking for cc... cc checking whether the C compiler (cc ) works... yes checking whether the C compiler (cc ) is a cross- compiler... no checking whether we are using GNU C... yes checking whether cc accepts -g... yes checking for ld used by GCC... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for BSD-compatible nm... /usr/bin/nm -p checking whether ln -s works... yes updating cache ./config.cache ltconfig: you must specify a host type if you use `-- no-verify' Try `ltconfig --help' for more information. configure: error: libtool configure failed [mda@IDRG401 expat-1.95.2]$ ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-31 22:17 Message: Logged In: YES user_id=3066 Greg, if you can get this done in the next 24 hours, we should be able to include this in Expat 1.95.3. ---------------------------------------------------------------------- Comment By: Greg Stein (gstein) Date: 2002-05-20 07:12 Message: Logged In: YES user_id=6501 Thanks for the additional clarifications. Your comments about patching libtool are exactly what I was referring to: plain old libtool 1.4.2 isn't going to help the MacOS X users. Note that *we* run libtool when creating a distribution. Since that isn't the "good" libtool, the resulting distribution will not be usable by MacOS X users :-( That said, until libtool gets their act together with the submitted patches, then we can/should point people at the fink package instead. After we release 1.95.3, we should try to get the fink pkg updated to that. Regarding config.sub/.guess, I am planning to pull the most recent copies of those from Apache. They have additional fixes (including MacOS X fixes) that improve them over any of the standard distro'd versions. (if we check them into source control, and tweak our libtoolize call, then it shouldn't overwrite them) ---------------------------------------------------------------------- Comment By: Max Horn (fingolfin) Date: 2002-05-18 12:32 Message: Logged In: YES user_id=12935 I disagree, being somebody who has ported several dozen Unix packages using libtool to OS X. First off, the problem in this bug report is caused by the fact that the configure script is not checking for the HOST type as it should; adding a simple statment to it would fix that, provided you made sure to use current versions of config.sub / config.guess. For hints on libtool patches on OS X, check out http:// fink.sourceforge.net/doc/porting/libtool.php All of these fixes have been cleaned up and submitted to the libtool team by us, and most should be in the next version (I really hope they make a 1.4.3 some day soon with these bugs fixed). For Fink, we also have an expat package: http:// fink.sourceforge.net/pdb/package.php/expat I see that it's not the current expat version, though I doubt that there are fundamental problems; I will contact the author. ---------------------------------------------------------------------- Comment By: Greg Stein (gstein) Date: 2002-05-17 20:53 Message: Logged In: YES user_id=6501 Mac OS X is notoriously problematic w.r.t libtool. Even if we generated the scripts with libtool 1.4.2, additional patches are needed. I believe the only answer is that Mac OS X users would need to get the source, install the properly-patched libtool, and run buildconf to generate new config stuff. With some additional work, I think we can get this fixed up, but it'll take some more investigation that I don't have right now. [ I believe the patched libtool stuff has been posted on the 'net by Pier Fumagalli; need to look that up ] ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-10 17:40 Message: Logged In: NO After copying the files from /usr/share/libtool, and also trying to copy the files from an alternate GNU version of libtool that I have, the exact same error results. What now? ---------------------------------------------------------------------- Comment By: Max Horn (fingolfin) Date: 2001-10-31 16:37 Message: Logged In: YES user_id=12935 This problem is due to old version of config.guess and config.sub being used. In OS X, you can usually copy the ones from /usr/share/libtool/ over the ones supplied in the source to be compiled. The package maintainers can easily fix this issue by updating to the latest versions of the files (and/or also to newer version of autoconf/automake) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=462960&group_id=10127 From noreply@sourceforge.net Fri May 31 20:26:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 31 19:26:01 2002 Subject: [ expat-Bugs-445954 ] Make of 1.95.2 fails on MacOS X Server Message-ID: Bugs item #445954, was opened at 2001-07-30 10:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=445954&group_id=10127 Category: Build control >Group: Third-party Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Make of 1.95.2 fails on MacOS X Server Initial Comment: expat 1.95.2.tar.gz distribution On MacOS X Server 1.2 (Rhapsody 5.6) make issues an error and halts: cc -DHAVE_CONFIG_H -DPACKAGE=\expat\ - DVERSION=\expat_1.95.2\ -I. -I. -I.. -g -O2 -Wall - Wmissing-prototypes -Wstrict-prototypes - fexceptions -c xmlparse.c -fPIC -DPIC -o .libs/ xmlparse.lo /System/Library/Frameworks/System.framework/ Headers/bsd/sys/cdefs.h:87: warning: redefinition of macro const ../config.h:5: warning: this is the location of the previous definition xmlparse.c:1178: illegal statement, missing `;' after `punting' make[1]: *** [xmlparse.lo] Error 1 make: *** [lib] Error 2 This does not happen with the older version 1.95.1 ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-31 22:25 Message: Logged In: YES user_id=3066 We no longer use -static in Expat 1.95.3, but rely on libtool. Once libtool works on Mac OS X, everything will be happy. Re-classifying this as a 3rd-party bug (libtool on Mac OS X). ---------------------------------------------------------------------- Comment By: Thomas Engelmeier (tom_e) Date: 2001-12-08 13:20 Message: Logged In: YES user_id=88916 MacOS X doesn't support the -static option for building commandline tools - as licrt0.o is not installed. Solution: in the Makefile in the xmlwf directory, remove the -static from the LDFLAGS line. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=445954&group_id=10127 From noreply@sourceforge.net Fri May 31 20:27:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 31 19:27:02 2002 Subject: [ expat-Bugs-445955 ] Make of 1.95.2 fails on MacOS X 10.0.4 Message-ID: Bugs item #445955, was opened at 2001-07-30 10:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=445955&group_id=10127 Category: Build control >Group: Third-party Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Make of 1.95.2 fails on MacOS X 10.0.4 Initial Comment: expat 1.95.2.tar.gz distribution On MacOS X 10.0.4 (Darwin 1.3.7) make issues an error and halts: cc -o xmlwf -static xmlwf.o xmlfile.o codepage.o unixfilemap.o -L../lib/.libs -lexpat /usr/bin/ld: can't locate file for: -lcrt 0.o make[1]: *** [xmlwf] Error 1 ma ke: *** [xmlwf] Error 2 This does not happen with the older version 1.95.1 ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-31 22:26 Message: Logged In: YES user_id=3066 We no longer use -static in Expat 1.95.3, but rely on libtool. Once libtool works on Mac OS X, everything will be happy. Reclassifying this as a 3rd-party bug (libtool on Mac OS X). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-12-18 08:32 Message: Logged In: NO When not done ./configure, change xmlwf/Makefile.in as follows. ( If configure has done, change xmlwf/Makefile ) #LDFLAGS= -static LDFLAGS= -dynamic I can build successfull and works well. -- Ran Hamada ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-12-05 22:46 Message: Logged In: NO I made the fix Zenzen suggested and it failed again. If this happens check xmlwf/Makefile also for the -static flag in LDFLAGS. ---------------------------------------------------------------------- Comment By: Max Horn (fingolfin) Date: 2001-10-31 16:47 Message: Logged In: YES user_id=12935 I can only agree with zenzen, this should be easy enough to fix with a check in configure.in ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2001-09-23 03:03 Message: Logged In: YES user_id=46639 xmlwf/Makefile.in seems to want to add the -static option to LDFLAGS. This breaks OSX. Removing the -static flag from LDFLAGS fixes the problem and everything appears to build happily. The configure script correctly detects that this option doesn't work under OSX. ---------------------------------------------------------------------- Comment By: Nat Irons (bumppo) Date: 2001-08-22 16:23 Message: Logged In: YES user_id=8138 I also see make breaking on xmlwf with 1.95.2 on Mac OS X 10.0.4, but my symptoms are slightly different: gcc -o xmlwf -static xmlwf.o xmlfile.o codepage.o unixfilemap.o -L../lib/.libs -lexpat /usr/bin/ld: xmlwf.o incompatible, file contains unsupported type of section 5 (__TEXT,__picsymbol_stub) in load command 0 (must specify "-dynamic" to be used) /usr/bin/ld: xmlfile.o incompatible, file contains unsupported type of section 4 (__TEXT,__picsymbol_stub) in load command 0 (must specify "-dynamic" to be used) /usr/bin/ld: unixfilemap.o incompatible, file contains unsupported type of section 4 (__TEXT,__picsymbol_stub) in load command 0 (must specify "-dynamic" to be used) make[1]: *** [xmlwf] Error 1 make: *** [xmlwf] Error 2 If you'd like to follow up with someone having the first problem, it was also reported on the perl-macosx list. Like the original poster, 1.95.1 installs smoothly for me here. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=445955&group_id=10127 From noreply@sourceforge.net Fri May 31 21:20:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 31 20:20:01 2002 Subject: [ expat-Bugs-563184 ] warnings for close/read in xmlfile.c Message-ID: Bugs item #563184, was opened at 2002-05-31 20:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=563184&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Patrick McCormick (patrickmc) Assigned to: Greg Stein (gstein) Summary: warnings for close/read in xmlfile.c Initial Comment: On Solaris 7 with tip of tree, the build throws warnings: gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict- prototypes -fexceptions -Ilib -I. -o xmlwf/xmlfile.o -c xmlwf/xmlfile.c xmlwf/xmlfile.c: In function `processStream': xmlwf/xmlfile.c:155: warning: implicit declaration of function `close' xmlwf/xmlfile.c:160: warning: implicit declaration of function `read' This is because unistd.h isn't included. I see that in xmlfile.c it will be included if _POSIX_SOURCE is defined, but I'm not sure what that means or if the config should be defining that. This is really low priority, and the only warning I see when building expat. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=563184&group_id=10127 From noreply@sourceforge.net Fri May 31 21:21:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri May 31 20:21:02 2002 Subject: [ expat-Bugs-563184 ] warnings for close/read in xmlfile.c Message-ID: Bugs item #563184, was opened at 2002-05-31 20:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=563184&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None >Priority: 2 Submitted By: Patrick McCormick (patrickmc) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: warnings for close/read in xmlfile.c Initial Comment: On Solaris 7 with tip of tree, the build throws warnings: gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict- prototypes -fexceptions -Ilib -I. -o xmlwf/xmlfile.o -c xmlwf/xmlfile.c xmlwf/xmlfile.c: In function `processStream': xmlwf/xmlfile.c:155: warning: implicit declaration of function `close' xmlwf/xmlfile.c:160: warning: implicit declaration of function `read' This is because unistd.h isn't included. I see that in xmlfile.c it will be included if _POSIX_SOURCE is defined, but I'm not sure what that means or if the config should be defining that. This is really low priority, and the only warning I see when building expat. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=563184&group_id=10127