From noreply at sourceforge.net Thu Oct 2 05:38:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 2 05:38:20 2003 Subject: [Expat-bugs] [ expat-Bugs-816447 ] expat-1.95.6 (out of box) fails to compile on Mac OS X 10.2 Message-ID: Bugs item #816447, was opened at 2003-10-02 11:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=816447&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stephan Hradek (ngc) Assigned to: Nobody/Anonymous (nobody) Summary: expat-1.95.6 (out of box) fails to compile on Mac OS X 10.2 Initial Comment: or at least gives many errors which I suspect to be the reason for not being able to make perl XML::Parser and XML::Twig. I'll attach my configure / make session's output ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=816447&group_id=10127 From noreply at sourceforge.net Thu Oct 2 09:01:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 2 09:01:44 2003 Subject: [Expat-bugs] [ expat-Bugs-816447 ] expat-1.95.6 (out of box) fails to compile on Mac OS X 10.2 Message-ID: Bugs item #816447, was opened at 2003-10-02 05:38 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=816447&group_id=10127 Category: None >Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Stephan Hradek (ngc) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: expat-1.95.6 (out of box) fails to compile on Mac OS X 10.2 Initial Comment: or at least gives many errors which I suspect to be the reason for not being able to make perl XML::Parser and XML::Twig. I'll attach my configure / make session's output ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-02 09:01 Message: Logged In: YES user_id=290026 Could this be a duplicate of (closed) bug #765227 ? In any case, please check out from CVS and try again. This might solve your problem. Assigned to Fred, as he claims to have access to a Mac OS X system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=816447&group_id=10127 From noreply at sourceforge.net Thu Oct 2 09:25:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 2 09:25:37 2003 Subject: [Expat-bugs] [ expat-Bugs-816447 ] expat-1.95.6 (out of box) fails to compile on Mac OS X 10.2 Message-ID: Bugs item #816447, was opened at 2003-10-02 11:38 Message generated for change (Comment added) made by ngc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=816447&group_id=10127 Category: None Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Stephan Hradek (ngc) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: expat-1.95.6 (out of box) fails to compile on Mac OS X 10.2 Initial Comment: or at least gives many errors which I suspect to be the reason for not being able to make perl XML::Parser and XML::Twig. I'll attach my configure / make session's output ---------------------------------------------------------------------- >Comment By: Stephan Hradek (ngc) Date: 2003-10-02 15:25 Message: Logged In: YES user_id=864970 I don't know how to check out from CVS (I'm no programmer). I just downloaded the package from sourceforge. I already downloaded the previous version (1.95.5) and it compiled fine. It works (almos) perfectly except that I get a segmentation fault with my perl script on Mac OS while I get none on Intel Solaris with expat 1.95.6. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-02 15:01 Message: Logged In: YES user_id=290026 Could this be a duplicate of (closed) bug #765227 ? In any case, please check out from CVS and try again. This might solve your problem. Assigned to Fred, as he claims to have access to a Mac OS X system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=816447&group_id=10127 From noreply at sourceforge.net Thu Oct 2 10:07:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 2 10:07:44 2003 Subject: [Expat-bugs] [ expat-Bugs-816447 ] expat-1.95.6 (out of box) fails to compile on Mac OS X 10.2 Message-ID: Bugs item #816447, was opened at 2003-10-02 05:38 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=816447&group_id=10127 Category: None Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Stephan Hradek (ngc) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: expat-1.95.6 (out of box) fails to compile on Mac OS X 10.2 Initial Comment: or at least gives many errors which I suspect to be the reason for not being able to make perl XML::Parser and XML::Twig. I'll attach my configure / make session's output ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-02 10:07 Message: Logged In: YES user_id=290026 In that case you will need to ask someone who knows how to check out from CVS, or wait for Expat 1.95.7. ---------------------------------------------------------------------- Comment By: Stephan Hradek (ngc) Date: 2003-10-02 09:25 Message: Logged In: YES user_id=864970 I don't know how to check out from CVS (I'm no programmer). I just downloaded the package from sourceforge. I already downloaded the previous version (1.95.5) and it compiled fine. It works (almos) perfectly except that I get a segmentation fault with my perl script on Mac OS while I get none on Intel Solaris with expat 1.95.6. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-02 09:01 Message: Logged In: YES user_id=290026 Could this be a duplicate of (closed) bug #765227 ? In any case, please check out from CVS and try again. This might solve your problem. Assigned to Fred, as he claims to have access to a Mac OS X system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=816447&group_id=10127 From noreply at sourceforge.net Tue Oct 7 22:04:34 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 7 22:04:37 2003 Subject: [Expat-bugs] [ expat-Patches-808331 ] Faulty code generation in function "lookup" Message-ID: Patches item #808331, was opened at 2003-09-18 01:35 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=808331&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Faulty code generation in function "lookup" Initial Comment: The function "lookup" in source "xmlparse.c" generates faulty code when built for a PocketPC2002 device in eMbedded Visual C++ v3.0. Note that this only occurs for a release build, and not for a debug build. Specifically this block of code at line 5306: for (i = h & (table->size - 1); table->v[i]; i == 0 ? i = table->size - 1 : --i) { if (keyeq(name, table->v[i]->name)) return table->v[i]; } The return statement is generated as a branch to the return statement at the end of the function. The code generation fault is in the failure to shift the index i to account for the size of the elements of v. The alternative is to declare a local variable of type NAMED ** to be assigned in the condition clause of the for loop and return that instead. NAMED **n; for (i = h & (table->size - 1); (n = table->v[i]) != NULL; i == 0 ? i = table->size - 1 : --i) { if (keyeq(name, table->v[i]->name)) return n; } email address: adam@xtreamlok.com ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-07 22:04 Message: Logged In: YES user_id=3066 What version of Expat was this problem found in? The looping construct in the current code has changed from a for-loop to a while-loop; does the problem still show up when using the CVS version of Expat? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-09-24 11:45 Message: Logged In: YES user_id=290026 Thank you for the info. This does not seem to be a bug, but rather a workaround for a faulty compiler. Re-classified as a patch. Assigned to Fred for comment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=808331&group_id=10127 From noreply at sourceforge.net Tue Oct 7 22:26:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 7 22:26:18 2003 Subject: [Expat-bugs] [ expat-Bugs-601978 ] xmlwf should link statically to Expat Message-ID: Bugs item #601978, was opened at 2002-08-29 13:04 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=601978&group_id=10127 Category: Build control Group: Feature Request >Status: Closed >Resolution: Rejected Priority: 6 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Greg Stein (gstein) Summary: xmlwf should link statically to Expat Initial Comment: I'm sure there's a way to link the Expat library into the executables built from the Expat distribution, but I'm not sure what the portable "libtool way" is. I can do this on Linux by building xmlwf using "make LDFLAGS=-static", but doubt this will work cross-platform. Can you add the right magic to the LINK_EXE variable in Makefile.in? Thanks! ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-07 22:26 Message: Logged In: YES user_id=3066 I'm rejecting my own report here, because I still can't remember the answer to Greg's question of "Why?". ---------------------------------------------------------------------- Comment By: Greg Stein (gstein) Date: 2003-01-03 14:20 Message: Logged In: YES user_id=6501 Yes, there is a libtool switch to do this, but I'm not sure why. Why wouldn't we just link to the shared library? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-29 13:10 Message: Logged In: YES user_id=290026 I am not sure I should mention this here: But there is another issue still open, as listed in the requirements for the next release: The build process on Unix should create both libexpat.{a,so} and libexpatw.{a,so} by default. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=601978&group_id=10127 From noreply at sourceforge.net Tue Oct 7 22:29:38 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 7 22:29:42 2003 Subject: [Expat-bugs] [ expat-Bugs-816447 ] expat-1.95.6 (out of box) fails to compile on Mac OS X 10.2 Message-ID: Bugs item #816447, was opened at 2003-10-02 05:38 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=816447&group_id=10127 Category: None Group: Platform Specific Status: Open Resolution: None >Priority: 6 Submitted By: Stephan Hradek (ngc) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: expat-1.95.6 (out of box) fails to compile on Mac OS X 10.2 Initial Comment: or at least gives many errors which I suspect to be the reason for not being able to make perl XML::Parser and XML::Twig. I'll attach my configure / make session's output ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-07 22:29 Message: Logged In: YES user_id=3066 I no longer have really easy access to a Mac OS X box; might be able to get to it from remote. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-02 10:07 Message: Logged In: YES user_id=290026 In that case you will need to ask someone who knows how to check out from CVS, or wait for Expat 1.95.7. ---------------------------------------------------------------------- Comment By: Stephan Hradek (ngc) Date: 2003-10-02 09:25 Message: Logged In: YES user_id=864970 I don't know how to check out from CVS (I'm no programmer). I just downloaded the package from sourceforge. I already downloaded the previous version (1.95.5) and it compiled fine. It works (almos) perfectly except that I get a segmentation fault with my perl script on Mac OS while I get none on Intel Solaris with expat 1.95.6. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-02 09:01 Message: Logged In: YES user_id=290026 Could this be a duplicate of (closed) bug #765227 ? In any case, please check out from CVS and try again. This might solve your problem. Assigned to Fred, as he claims to have access to a Mac OS X system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=816447&group_id=10127 From noreply at sourceforge.net Tue Oct 7 22:31:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 7 22:31:53 2003 Subject: [Expat-bugs] [ expat-Bugs-809235 ] xmlwin32url.cxx Bugs Message-ID: Bugs item #809235, was opened at 2003-09-19 08:45 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=809235&group_id=10127 Category: None Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Thomas Engelmeier (tom_e) >Assigned to: Karl Waclawek (kwaclaw) Summary: xmlwin32url.cxx Bugs Initial Comment: (Yeah, I know that file is deprecated ;-) - processURL doesn't init the QuitInfo.hr field and fails due to that. - Callback::OnDataAvailable sets the XML encoding at least for some UTF-8 testdata to "usascii" which has some undesirable sideffects for umlaut-rich XML. When that block is commented out, it works better. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-07 22:31 Message: Logged In: YES user_id=3066 Assigned to Karl since he normally works on Windows, and my Windows machine is dying. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=809235&group_id=10127 From noreply at sourceforge.net Tue Oct 7 22:35:10 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 7 22:35:14 2003 Subject: [Expat-bugs] [ expat-Bugs-599470 ] (1.95.4) runtests fails on MacOSX Message-ID: Bugs item #599470, was opened at 2002-08-23 20:04 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=599470&group_id=10127 Category: Build control >Group: Third-party Bug >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Jeremy Erwin (jerwin) Assigned to: Nobody/Anonymous (nobody) Summary: (1.95.4) runtests fails on MacOSX Initial Comment: I attempted to run "make check". However, the runtests script is erroneous labeled as a "sh" script. It runs properly under "bash". I'm running MacOSX 10.1. I'm not sure who's to blame for this-- the runtests script is listed as "generated by libtool". ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-07 22:35 Message: Logged In: YES user_id=3066 Rejecting this for two reasons: - a bug in any script generated by libtool is a libtool bug - the reporter didn't bother responding to the request for further information This can be reopened or a new report may be filed if this issue is still a problem and enough information can be provided to determine that this is an Expat problem. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-26 17:26 Message: Logged In: YES user_id=3066 Does it fail to run using sh on Mac OS X? Not sure what the right thing to do is if it doesn't -- libtool is evil. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=599470&group_id=10127 From noreply at sourceforge.net Tue Oct 7 23:35:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 7 23:35:08 2003 Subject: [Expat-bugs] [ expat-Bugs-781755 ] docs for pre-processor defines Message-ID: Bugs item #781755, was opened at 2003-08-01 17:15 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=781755&group_id=10127 Category: Documentation Group: Feature Request >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: docs for pre-processor defines Initial Comment: We need centralized documentation for the C pre-processor defines used to affect the compilation of Expat so people porting to new platforms will be able to understand what each is for and how they relate to each other. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-07 23:35 Message: Logged In: YES user_id=3066 Added documentation for the feature-configuration pre-processor defines in doc/reference.html revision 1.48. The internal macros defined in lib/internal.h don't need to be covered in the general documentation, and are described in that header file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=781755&group_id=10127 From noreply at sourceforge.net Wed Oct 8 14:47:05 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 8 14:47:20 2003 Subject: [Expat-bugs] [ expat-Bugs-676844 ] expat.h compile error: enum XML_Status Message-ID: Bugs item #676844, was opened at 2003-01-29 10:37 Message generated for change (Comment added) made by vbrtrmn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=676844&group_id=10127 Category: Build control Group: None Status: Open Resolution: Fixed Priority: 9 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: expat.h compile error: enum XML_Status Initial Comment: c++ -DHAVE_CONFIG_H -I. -I. -I../../autocfg -g -O2 -c context.cpp -fPIC -DPIC -o .libs/context.lo In file included from parser.h:45, from guard.h:143, from context.cpp:45: /usr/include/expat.h:657: use of enum `XML_Status' without previous declaration /usr/include/expat.h:736: multiple definition of `enum XML_Status' when building sablotron. Hand editing the file to place the def of enum XML_Status before any references to it fixes the problem. ---------------------------------------------------------------------- Comment By: paul jobson (vbrtrmn) Date: 2003-10-08 13:47 Message: Logged In: YES user_id=155212 Platform: OSX Jaguar 10.2 expat version 1.95.6 Sablot ./configure error message: --------------------------------- Truncated --------------------------------- checking where to find xml parser... expat (new) checking expat.h usability... no checking expat.h presence... yes configure: WARNING: expat.h: present but cannot be compiled configure: WARNING: expat.h: check for missing prerequisite headers? configure: WARNING: expat.h: proceeding with the preprocessor's result configure: WARNING: ## -------------------------------- ---- ## configure: WARNING: ## Report this to bug- autoconf@gnu.org. ## configure: WARNING: ## -------------------------------- ---- ## checking for expat.h... yes checking whether expat.h is broken... yes configure: error: You probably have expat version 1.95.6. Please refer to: http://sourceforge.net/tracker/index.php? func=detail&aid=676844&group_id=10127&atid=110127 for a description of the problem. --------------------------------- I downloaded the newest expat.h from the CVS, stuck it in the /lib directory and recompiled expat, Sablot seems to configure correctly, now. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-09-13 15:42 Message: Logged In: YES user_id=290026 We intend to release soon. All that is holding us up is finding the time to actually do it. Fred will be back in a week, and I hope he can find the time then. Now, since your users are expert enough to build Expat from source, what is holding them back from using the current CVS? It is pretty much what we will release, except possibly for minor details, or if someone finds a bug, of course. We do actually want users to build from CVS, as our desire to have stable file releases means that we want our changes to be tested as much as possible. ---------------------------------------------------------------------- Comment By: Jacob Levy (jyljyljyl) Date: 2003-09-13 15:29 Message: Logged In: YES user_id=63723 Are you planning -- please? -- to make another file release containing these fixes? Asking my users to build expat from the current release is not working, because of this bug. As a result, I'm recommending to my users to get/use an older version of expat without the new nifty features. --JYL ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-09-13 11:19 Message: Logged In: YES user_id=290026 Has been fixed in CVS for a long time. Btw, CVS is generally stable, as we are quite careful to commit changes only when they have been tested. No guarantees, of course. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-09-13 09:44 Message: Logged In: NO this is simply a matter of the expat.h file being wrongly organised so that "enum XML_Status" is used several times before it is declared. 30 seconds copying and pasting will fix it. currently nothing using expat.h compiles under gcc 3.2.3 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-07-18 08:16 Message: Logged In: NO After I read all this comments, i saw that u were right. : ) I placed the following definitions enum XML_Status { XML_STATUS_ERROR = 0, #define XML_STATUS_ERROR XML_STATUS_ERROR XML_STATUS_OK = 1 #define XML_STATUS_OK XML_STATUS_OK }; at the beginning of the expat.h file, before any call to it, and it compiled succesfully. After this I compiled sablot with no problems. thank u guys ... : ) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-06-19 10:36 Message: Logged In: NO in configure..:: checking XML::Parser perl module... no: documentation requires XML::Parser module and will not be built. checking whether to build under GPL... no checking whether to build the debugger... no checking where to find xml parser... expat (new) checking expat.h usability... no checking expat.h presence... yes configure: WARNING: expat.h: present but cannot be compiled configure: WARNING: expat.h: check for missing prerequisite headers? configure: WARNING: expat.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug-autoconf@gnu.org. ## configure: WARNING: ## ------------------------------------ ## checking for expat.h... yes checking whether expat.h is broken... yes configure: error: You probably have expat version 1.95.6. Please refer to: http://sourceforge.net/tracker/index.php?func=detail&aid=676844&group_id=10127&atid=110127 for a description of the problem. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-05-30 15:47 Message: Logged In: YES user_id=290026 Yes, the file to fix is expat.h. Two things you can do: 1) get the latest expat.h from CVS, or 2) use your editor to search expat.h for the first location where XML_STATUS is used and then move the definition of XML_STATUS to some location before that point. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-05-30 15:26 Message: Logged In: NO I have the same problem has other senders, but the fix is unclear as you did not indicate which file needs fixing (I assume expat.h) or line number to place the def of enum XML_Status. Please assume people are stupid.. checking expat.h usability... no checking expat.h presence... yes configure: WARNING: expat.h: present but cannot be compiled configure: WARNING: expat.h: check for missing prerequisite headers? configure: WARNING: expat.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug-autoconf@gnu.org. ## configure: WARNING: ## ------------------------------------ ## checking for expat.h... yes checking whether expat.h is broken... yes configure: error: You probably have expat version 1.95.6. Please refer to: http://sourceforge.net/tracker/index.php?func=detail&aid=676844&group_id=10127&atid=110127 for a description of the problem. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-05-08 08:18 Message: Logged In: YES user_id=290026 See above - original submission: Hand editing the file to place the def of enum XML_Status before any references to it fixes the problem. ---------------------------------------------------------------------- Comment By: Donche, Pieter (pdon) Date: 2003-05-08 02:20 Message: Logged In: YES user_id=774177 SUN Sparc Enterprise 2170 Solaris 2.8 gcc 3.2 Downloaded expat-1.95.6.tar.gz ./configure, make, make install OK Downloaded Sablot-0.98.tar.gz (Sablotron package, from www.gingerall.com) ./configure says: ... checking expat.h presence... yes expat.h: present but cannot be compiled expat.h: check for missing prerequisite headers? expat.h: proceeding with the preprocessor's result ##-------------------------------------------------## ## Report this to bug-autoconf@gnu.org ## ##-------------------------------------------------## checking for expat.h... yes checking wether expat.h is broken... yes error: You probably have expat version 1.95.6. Please refer to http://sourceforge.net/tracker/index.php? func=detail&aid=676844&group_id=10127&atid=110127 for a description of the problem -- Looked at that web-page. Don't see a solution there. Wath is the solution ? Pieter.Donche@ua.ac.be ---------------------------------------------------------------------- Comment By: Donche, Pieter (pdon) Date: 2003-05-08 02:20 Message: Logged In: YES user_id=774177 SUN Sparc Enterprise 2170 Solaris 2.8 gcc 3.2 Downloaded expat-1.95.6.tar.gz ./configure, make, make install OK Downloaded Sablot-0.98.tar.gz (Sablotron package, from www.gingerall.com) ./configure says: ... checking expat.h presence... yes expat.h: present but cannot be compiled expat.h: check for missing prerequisite headers? expat.h: proceeding with the preprocessor's result ##-------------------------------------------------## ## Report this to bug-autoconf@gnu.org ## ##-------------------------------------------------## checking for expat.h... yes checking wether expat.h is broken... yes error: You probably have expat version 1.95.6. Please refer to http://sourceforge.net/tracker/index.php? func=detail&aid=676844&group_id=10127&atid=110127 for a description of the problem -- Looked at that web-page. Don't see a solution there. Wath is the solution ? Pieter.Donche@ua.ac.be ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-04-16 08:59 Message: Logged In: YES user_id=290026 Changed priority to highest to make it more visible, so that double reporting incidents occur less frequently. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-03-27 05:42 Message: Logged In: NO Same problem and the same fix under Linux and gcc 2.95.2. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-03-07 06:20 Message: Logged In: NO same problem, same fix when building 1.95.6 on vms (just downloaded .tar.gz & processed - got the rpm, but don't know what to do with it - not an archive type I know how to handle on vms, or windows either) - chris.sharman@ccagroup.co.uk ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-28 21:03 Message: Logged In: YES user_id=290026 Strange - I had no problems with MS VC++ 6.0. Which service pack level have you applied? ---------------------------------------------------------------------- Comment By: Jacob Levy (jyljyljyl) Date: 2003-02-28 20:35 Message: Logged In: YES user_id=63723 This makes Expat 1.95.6 unusable for people who create libraries that depend on Expat but don't include their own copy of Expat. Sure, I can edit expat.h and fix it, but my users should not be expected to do that. For that reason I'm staying with Expat 1.95.5 until this problem is fixed. It'd be really nice if you could make Expat 1.95.7 soon.. In my case GCC 2.95.2 and VC++ 6.0 are complaining. ---------------------------------------------------------------------- Comment By: Melvyn Sopacua (nyvlem) Date: 2003-02-14 02:56 Message: Logged In: YES user_id=212431 Yes, that works. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-06 15:47 Message: Logged In: YES user_id=290026 But current CVS works for you, right? ---------------------------------------------------------------------- Comment By: Melvyn Sopacua (nyvlem) Date: 2003-02-06 15:17 Message: Logged In: YES user_id=212431 > So far only gcc3.2 has complained. Nope: /usr/local/include/expat.h:657: use of enum `XML_Status' without previous declaration /usr/local/include/expat.h:736: multiple definition of `enum XML_Status' gmake[2]: *** [context.lo] Error 1 gmake[2]: Leaving directory `/home/mdev/cvs/sablot/src/engine' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/mdev/cvs/sablot/src' gmake: *** [all-recursive] Error 1 $ gcc --version 2.95.3 ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-01-31 09:43 Message: Logged In: YES user_id=290026 It *is* fixed in CVS. Are you sure you checked out the right version, which is expat.h 1.51? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-01-31 05:34 Message: Logged In: NO I just got the same error, already fixed it. But don't understand why it isn't fixed in CVS ? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-01-29 13:44 Message: Logged In: YES user_id=3066 I've not checked the C89 standard yet, but Expat 1.95.6 is certainly dodgy in this case. ;-( The first draft of the C spec I found online certainly seemed to imply that any use of an incomplete enum is not allowed; I'm not likely to go out and buy a copy of the final spec to check further. ;-) As noted, this has been fixed in CVS. Fixed the summary to better indicate what this report is about, and lowered the priority to get it out of the way for maintainers. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-01-29 10:51 Message: Logged In: YES user_id=290026 So far only gcc3.2 has complained. Not sure if this is a bug, since most compilers accept it, but it has been fixed in CVS already anyway. Set resolution status to fixed, but leave open. There may be other users who would report this as a bug and I want them to see the open report instead of having duplicates created. Assigned to Fred - since he may know more about whether this truly is a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=676844&group_id=10127 From noreply at sourceforge.net Thu Oct 9 09:47:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 9 09:47:58 2003 Subject: [Expat-bugs] [ expat-Bugs-809235 ] xmlwin32url.cxx Bugs Message-ID: Bugs item #809235, was opened at 2003-09-19 08:45 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=809235&group_id=10127 Category: None Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Thomas Engelmeier (tom_e) Assigned to: Karl Waclawek (kwaclaw) Summary: xmlwin32url.cxx Bugs Initial Comment: (Yeah, I know that file is deprecated ;-) - processURL doesn't init the QuitInfo.hr field and fails due to that. - Callback::OnDataAvailable sets the XML encoding at least for some UTF-8 testdata to "usascii" which has some undesirable sideffects for umlaut-rich XML. When that block is commented out, it works better. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-09 09:47 Message: Logged In: YES user_id=290026 Yes, it is deprecated. But if Thomas submits a patch, we will be happy to include it. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-07 22:31 Message: Logged In: YES user_id=3066 Assigned to Karl since he normally works on Windows, and my Windows machine is dying. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=809235&group_id=10127 From robert at riskdev.com Thu Oct 9 15:46:09 2003 From: robert at riskdev.com (Robert S) Date: Thu Oct 9 15:49:33 2003 Subject: [Expat-bugs] [ expat-Bugs-676844 ] expat.h compile error: enum XML_Status Message-ID: <3F85BB01.7040706@riskdev.com> I would like to report that it kills the pwlib compile also, this should certainly piss off a bunch of h323 application builders. In file included from ../../ptclib/pxml.cxx:67: /usr/local/include/expat.h:657: use of enum `XML_Status' without previous declaration /usr/local/include/expat.h:736: multiple definition of `enum XML_Status' make[1]: *** [/home/robert/pwlib/lib/obj_linux_x86_r/pxml.o] Error 1 make[1]: Leaving directory `/home/robert/pwlib/src/ptlib/unix' make: *** [opt] Error 2 From fdrake at acm.org Thu Oct 9 15:51:42 2003 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Thu Oct 9 15:52:03 2003 Subject: [Expat-bugs] [ expat-Bugs-676844 ] expat.h compile error: enum XML_Status In-Reply-To: <3F85BB01.7040706@riskdev.com> References: <3F85BB01.7040706@riskdev.com> Message-ID: <16261.48206.276332.683452@grendel.zope.com> Robert S writes: > I would like to report that it kills the pwlib compile also, this should > certainly piss off a bunch of h323 application builders. Unfortunately, not all compilers reported this error, or it would have been caught before release. I'm hoping to get 1.95.7 out in the next few days. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From noreply at sourceforge.net Thu Oct 9 17:34:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 9 17:34:35 2003 Subject: [Expat-bugs] [ expat-Bugs-664541 ] check.h should be tested by configure Message-ID: Bugs item #664541, was opened at 2003-01-08 10:40 Message generated for change (Comment added) made by gstein You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=664541&group_id=10127 Category: Build control Group: None >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Ed Avis (epaepa) Assigned to: Greg Stein (gstein) Summary: check.h should be tested by configure Initial Comment: The presence of the check library (and check.h) should be checked by 'configure', and if it's not there then 'make check' should print a warning. Otherwise you get some rather alarming errors seeming to come from the test suite :-(. (expat-1.95.5) ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2003-10-09 14:34 Message: Logged In: YES user_id=6501 Fixed in Expat 1.95.7. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-01-21 08:26 Message: Logged In: YES user_id=3066 Bumped priority since this bites a lot of users; the noise level when the check library is not installed is high enough to lead someone to think that something is seriously wrong. ---------------------------------------------------------------------- Comment By: Greg Stein (gstein) Date: 2003-01-08 16:20 Message: Logged In: YES user_id=6501 Good idea. This shouldn't be too hard at all. Thx. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=664541&group_id=10127 From noreply at sourceforge.net Thu Oct 9 18:23:55 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 9 18:24:06 2003 Subject: [Expat-bugs] [ expat-Bugs-626001 ] ld: Mismatched ABI (not an ELF file) for Message-ID: Bugs item #626001, was opened at 2002-10-20 11:43 Message generated for change (Settings changed) made by gstein You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=626001&group_id=10127 Category: Build control Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Sanjay (sanjaywaza) Assigned to: Greg Stein (gstein) Summary: ld: Mismatched ABI (not an ELF file) for Initial Comment: I tried to install the expat1.95.4) on HP-UX 11.0 (64 Bit). Then I tried to build XML::Parser2.31.1 and I am getting the error (ld: Mismatched ABI (not an ELF file). I am getting the following error during make . cp Parser/Encodings/README blib/lib/XML/Parser/Encodings/README cp Parser/Encodings/x-sjis-cp932.enc blib/lib/XML/Parser/Encodings/x-sjis-cp932.enc cp Parser/Encodings/iso-8859-7.enc blib/lib/XML/Parser/Encodings/iso-8859-7.enc cp Parser/Encodings/big5.enc blib/lib/XML/Parser/Encodings/big5.enc cp Parser/Encodings/windows-1250.enc blib/lib/XML/Parser/Encodings/windows-1250.enc cp Parser/Encodings/iso-8859-8.enc blib/lib/XML/Parser/Encodings/iso-8859-8.enc cp Parser/Encodings/iso-8859-2.enc blib/lib/XML/Parser/Encodings/iso-8859-2.enc cp Parser/Encodings/x-euc-jp-jisx0221.enc blib/lib/XML/Parser/Encodings/x-euc-jp-jisx0221.enc cp Parser/Encodings/iso-8859-9.enc blib/lib/XML/Parser/Encodings/iso-8859-9.enc cp Parser/Encodings/x-sjis-unicode.enc blib/lib/XML/Parser/Encodings/x-sjis-unicode.enc cp Parser/Encodings/iso-8859-3.enc blib/lib/XML/Parser/Encodings/iso-8859-3.enc cp Parser/Encodings/x-sjis-jdk117.enc blib/lib/XML/Parser/Encodings/x-sjis-jdk117.enc cp Parser/Encodings/euc-kr.enc blib/lib/XML/Parser/Encodings/euc-kr.enc cp Parser/Encodings/iso-8859-4.enc blib/lib/XML/Parser/Encodings/iso-8859-4.enc cp Parser/Encodings/Japanese_Encodings.msg blib/lib/XML/Parser/Encodings/Japanese_Encodings.msg cp Parser/Encodings/x-sjis-jisx0221.enc blib/lib/XML/Parser/Encodings/x-sjis-jisx0221.enc cp Parser.pm blib/lib/XML/Parser.pm cp Parser/Encodings/iso-8859-5.enc blib/lib/XML/Parser/Encodings/iso-8859-5.enc cp Parser/Encodings/x-euc-jp-unicode.enc blib/lib/XML/Parser/Encodings/x-euc-jp-unicode.enc cp Parser/LWPExternEnt.pl blib/lib/XML/Parser/LWPExternEnt.pl cp Expat.pm ../blib/lib/XML/Parser/Expat.pm /bin/perl -I/opt/perl5.6.1/lib/5.6.1/PA-RISC2.0 - I/opt/perl5.6.1/lib/5.6.1 /opt/perl5.6.1/lib/5.6.1/ExtUtils/x s ubpp -noprotc cc -c +z -D_HPUX_SOURCE +DD64 -Ae - I/usr/local/include -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64 -O -DVERSION=\2.31\c Running Mkbootstrap for XML::Parser::Expat () chmod 644 Expat.bs rm -f ../blib/arch/auto/XML/Parser/Expat/Expat.sl LD_RUN_PATH="/usr/local/lib" /usr/bin/ld -b +vnocompatwarnings -L/usr/local/lib -L/lib/pa20_64 Expat.o -o ../blib/arch/au ld: Mismatched ABI (not an ELF file) for -lexpat Fatal error. *** Error exit code 1 Stop. *** Error exit code 1 Thanks ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2003-10-09 15:23 Message: Logged In: YES user_id=6501 Reading through that output: it is entirely about the Parser::Expat build, and then linking against a system-installed expat library. If the system library was built incorrectly by the Expat build system, then we might have a problem, but I'm not seeing or hearing that. This looks like some consistencies between how people chose to build things on that one box. In any case, this isn't a valid bug to file here, unless it can be determined the system expat library was built wrong. Closing as invalid. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-01-20 21:31 Message: Logged In: YES user_id=3066 Dropping priority substantially. This is an HP-UX bug; someone who can help on that platform needs to figure this out; the current crop of contributors doesn't seem to include anyone with knowledge or information about that platform, and the report doesn't make it clear that this isn't an XML::Parser problem (XML::Parser is *not* part of Expat, nor is it provided by the Expat project). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-11-02 13:29 Message: Logged In: YES user_id=3066 This looks like a build issue to me; I don't know anything about HP-UX, so I might be wrong. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=626001&group_id=10127 From noreply at sourceforge.net Thu Oct 9 19:06:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 9 19:06:32 2003 Subject: [Expat-bugs] [ expat-Patches-820946 ] expat.h not great for MSVC !cdecl deflt calling cnvntn Message-ID: Patches item #820946, was opened at 2003-10-09 16:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=820946&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: expat.h not great for MSVC !cdecl deflt calling cnvntn Initial Comment: OK, well the title I wanted was "expat.h doesn't work cleanly for MSVC with non-cdecl default calling convetion", but there were (reasonable, I guess) length limitations. In any case, if you have a project in MSVC that has its default calling convention set to something other than cdecl (such as stdcall or fastcall), the prototypes for the handler functions don't communicate that the library is compiled to assume cdecl. Things will still compile fine, however odd behavior occurs at runtime (for example, my start element handler was called 5 times with the same name and then the thread crashed). If your callback funcitons are then explicitly declared cdecl (as they should be) then you have to use casts to allow you to assign the address of your cdecl handler functions to the function pointers that the compiler defaults to the different convention. I don't suppose many people bother to change the default calling convention of their projects, but I have seen fastcall give a 5% boost. XML parsing is not a significant part of our apps exection time, so it's not worth recompiling expat to fastcall. It would be nice if it worked out of the box for us. I've supplied a patch, that defines a macro XMLCALLBACK for callbacks, much like the XMLPARSEAPI macro is defined for API functions. I've tested it with MSVC 7.1 projects that default to both stdcall and fastcall. Because the preprocessor tests are set up like the ones for the XMLPARSEAPI macro, I don't think it should affect any non-MSVC compilers. Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=820946&group_id=10127 From noreply at sourceforge.net Fri Oct 10 17:08:38 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 10 17:08:43 2003 Subject: [Expat-bugs] [ expat-Bugs-821481 ] expat 1.95.6 compiles, but fails check on Solaris 2.8 Message-ID: Bugs item #821481, was opened at 2003-10-10 21:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=821481&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gerard Tromp (gtromp) Assigned to: Nobody/Anonymous (nobody) Summary: expat 1.95.6 compiles, but fails check on Solaris 2.8 Initial Comment: Greetings: Compiled the 1.95.6 package using both gcc (3.2) and Sun cc (5.0) compilers. No problem compiling. Both compilations fail "make check" identically (and no, it is not the lack of the check package). The output from the check is attached. Any insights will be appreciated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=821481&group_id=10127 From noreply at sourceforge.net Fri Oct 10 17:22:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 10 17:22:52 2003 Subject: [Expat-bugs] [ expat-Bugs-821481 ] expat 1.95.6 compiles, but fails check on Solaris 2.8 Message-ID: Bugs item #821481, was opened at 2003-10-10 21:08 Message generated for change (Comment added) made by gtromp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=821481&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gerard Tromp (gtromp) Assigned to: Nobody/Anonymous (nobody) Summary: expat 1.95.6 compiles, but fails check on Solaris 2.8 Initial Comment: Greetings: Compiled the 1.95.6 package using both gcc (3.2) and Sun cc (5.0) compilers. No problem compiling. Both compilations fail "make check" identically (and no, it is not the lack of the check package). The output from the check is attached. Any insights will be appreciated. ---------------------------------------------------------------------- >Comment By: Gerard Tromp (gtromp) Date: 2003-10-10 21:22 Message: Logged In: YES user_id=337239 Found the problem. The problem was that the runtests objects were being linked to the old libraries. The hint was that the reported version did not match the current build. Apologies for bothering everyone. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=821481&group_id=10127 From noreply at sourceforge.net Sat Oct 11 15:33:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 11 15:33:30 2003 Subject: [Expat-bugs] [ expat-Bugs-816447 ] expat-1.95.6 (out of box) fails to compile on Mac OS X 10.2 Message-ID: Bugs item #816447, was opened at 2003-10-02 05:38 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=816447&group_id=10127 Category: None Group: Platform Specific Status: Open Resolution: None Priority: 6 Submitted By: Stephan Hradek (ngc) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: expat-1.95.6 (out of box) fails to compile on Mac OS X 10.2 Initial Comment: or at least gives many errors which I suspect to be the reason for not being able to make perl XML::Parser and XML::Twig. I'll attach my configure / make session's output ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-11 15:33 Message: Logged In: YES user_id=3066 There is now a snapshot of the current code from CVS on the Expat website at this URL: http://www.libexpat.org/expat-2003-10-11.tar.gz Stephen, I'd really appreciate it if you could try this package on your platforms; I'd like to release 1.95.7 soon (it's been delayed too many times already). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-07 22:29 Message: Logged In: YES user_id=3066 I no longer have really easy access to a Mac OS X box; might be able to get to it from remote. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-02 10:07 Message: Logged In: YES user_id=290026 In that case you will need to ask someone who knows how to check out from CVS, or wait for Expat 1.95.7. ---------------------------------------------------------------------- Comment By: Stephan Hradek (ngc) Date: 2003-10-02 09:25 Message: Logged In: YES user_id=864970 I don't know how to check out from CVS (I'm no programmer). I just downloaded the package from sourceforge. I already downloaded the previous version (1.95.5) and it compiled fine. It works (almos) perfectly except that I get a segmentation fault with my perl script on Mac OS while I get none on Intel Solaris with expat 1.95.6. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-02 09:01 Message: Logged In: YES user_id=290026 Could this be a duplicate of (closed) bug #765227 ? In any case, please check out from CVS and try again. This might solve your problem. Assigned to Fred, as he claims to have access to a Mac OS X system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=816447&group_id=10127 From noreply at sourceforge.net Sat Oct 11 16:10:17 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 11 16:10:22 2003 Subject: [Expat-bugs] [ expat-Patches-820946 ] expat.h not great for MSVC !cdecl deflt calling cnvntn Message-ID: Patches item #820946, was opened at 2003-10-09 19:06 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=820946&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: expat.h not great for MSVC !cdecl deflt calling cnvntn Initial Comment: OK, well the title I wanted was "expat.h doesn't work cleanly for MSVC with non-cdecl default calling convetion", but there were (reasonable, I guess) length limitations. In any case, if you have a project in MSVC that has its default calling convention set to something other than cdecl (such as stdcall or fastcall), the prototypes for the handler functions don't communicate that the library is compiled to assume cdecl. Things will still compile fine, however odd behavior occurs at runtime (for example, my start element handler was called 5 times with the same name and then the thread crashed). If your callback funcitons are then explicitly declared cdecl (as they should be) then you have to use casts to allow you to assign the address of your cdecl handler functions to the function pointers that the compiler defaults to the different convention. I don't suppose many people bother to change the default calling convention of their projects, but I have seen fastcall give a 5% boost. XML parsing is not a significant part of our apps exection time, so it's not worth recompiling expat to fastcall. It would be nice if it worked out of the box for us. I've supplied a patch, that defines a macro XMLCALLBACK for callbacks, much like the XMLPARSEAPI macro is defined for API functions. I've tested it with MSVC 7.1 projects that default to both stdcall and fastcall. Because the preprocessor tests are set up like the ones for the XMLPARSEAPI macro, I don't think it should affect any non-MSVC compilers. Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-11 16:10 Message: Logged In: YES user_id=290026 How does it work when you build the library with your calling convention? If it works OK then we should not force any calling convention on the callbacks but simply document that the pre-built binaries were compiled with cdecl as default. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=820946&group_id=10127 From noreply at sourceforge.net Mon Oct 13 01:58:59 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 13 01:59:06 2003 Subject: [Expat-bugs] [ expat-Bugs-816447 ] expat-1.95.6 (out of box) fails to compile on Mac OS X 10.2 Message-ID: Bugs item #816447, was opened at 2003-10-02 11:38 Message generated for change (Comment added) made by ngc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=816447&group_id=10127 Category: None Group: Platform Specific Status: Open Resolution: None Priority: 6 Submitted By: Stephan Hradek (ngc) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: expat-1.95.6 (out of box) fails to compile on Mac OS X 10.2 Initial Comment: or at least gives many errors which I suspect to be the reason for not being able to make perl XML::Parser and XML::Twig. I'll attach my configure / make session's output ---------------------------------------------------------------------- >Comment By: Stephan Hradek (ngc) Date: 2003-10-13 07:58 Message: Logged In: YES user_id=864970 I downloaded > http://www.libexpat.org/expat-2003-10-11.tar.gz > Stephen, I'd really appreciate it if you could try this > package on your platforms It compiled fine on Intel Solaris 9 It also compiled fine on Mac OS X 10.2.8 I still get segmentation faults with my perl script on Mac OS. But this might be a problem with perl itself. I don't know how to tell who is to blame: expat, XML::Parser, XML::wig or perl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-11 21:33 Message: Logged In: YES user_id=3066 There is now a snapshot of the current code from CVS on the Expat website at this URL: http://www.libexpat.org/expat-2003-10-11.tar.gz Stephen, I'd really appreciate it if you could try this package on your platforms; I'd like to release 1.95.7 soon (it's been delayed too many times already). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-08 04:29 Message: Logged In: YES user_id=3066 I no longer have really easy access to a Mac OS X box; might be able to get to it from remote. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-02 16:07 Message: Logged In: YES user_id=290026 In that case you will need to ask someone who knows how to check out from CVS, or wait for Expat 1.95.7. ---------------------------------------------------------------------- Comment By: Stephan Hradek (ngc) Date: 2003-10-02 15:25 Message: Logged In: YES user_id=864970 I don't know how to check out from CVS (I'm no programmer). I just downloaded the package from sourceforge. I already downloaded the previous version (1.95.5) and it compiled fine. It works (almos) perfectly except that I get a segmentation fault with my perl script on Mac OS while I get none on Intel Solaris with expat 1.95.6. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-02 15:01 Message: Logged In: YES user_id=290026 Could this be a duplicate of (closed) bug #765227 ? In any case, please check out from CVS and try again. This might solve your problem. Assigned to Fred, as he claims to have access to a Mac OS X system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=816447&group_id=10127 From noreply at sourceforge.net Mon Oct 13 04:29:31 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 13 04:29:40 2003 Subject: [Expat-bugs] [ expat-Bugs-816447 ] expat-1.95.6 (out of box) fails to compile on Mac OS X 10.2 Message-ID: Bugs item #816447, was opened at 2003-10-02 02:38 Message generated for change (Comment added) made by gstein You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=816447&group_id=10127 Category: None Group: Platform Specific >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Stephan Hradek (ngc) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: expat-1.95.6 (out of box) fails to compile on Mac OS X 10.2 Initial Comment: or at least gives many errors which I suspect to be the reason for not being able to make perl XML::Parser and XML::Twig. I'll attach my configure / make session's output ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2003-10-13 01:29 Message: Logged In: YES user_id=6501 Looks like it is working now, so we can close this bug. ---------------------------------------------------------------------- Comment By: Stephan Hradek (ngc) Date: 2003-10-12 22:58 Message: Logged In: YES user_id=864970 I downloaded > http://www.libexpat.org/expat-2003-10-11.tar.gz > Stephen, I'd really appreciate it if you could try this > package on your platforms It compiled fine on Intel Solaris 9 It also compiled fine on Mac OS X 10.2.8 I still get segmentation faults with my perl script on Mac OS. But this might be a problem with perl itself. I don't know how to tell who is to blame: expat, XML::Parser, XML::wig or perl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-11 12:33 Message: Logged In: YES user_id=3066 There is now a snapshot of the current code from CVS on the Expat website at this URL: http://www.libexpat.org/expat-2003-10-11.tar.gz Stephen, I'd really appreciate it if you could try this package on your platforms; I'd like to release 1.95.7 soon (it's been delayed too many times already). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-07 19:29 Message: Logged In: YES user_id=3066 I no longer have really easy access to a Mac OS X box; might be able to get to it from remote. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-02 07:07 Message: Logged In: YES user_id=290026 In that case you will need to ask someone who knows how to check out from CVS, or wait for Expat 1.95.7. ---------------------------------------------------------------------- Comment By: Stephan Hradek (ngc) Date: 2003-10-02 06:25 Message: Logged In: YES user_id=864970 I don't know how to check out from CVS (I'm no programmer). I just downloaded the package from sourceforge. I already downloaded the previous version (1.95.5) and it compiled fine. It works (almos) perfectly except that I get a segmentation fault with my perl script on Mac OS while I get none on Intel Solaris with expat 1.95.6. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-02 06:01 Message: Logged In: YES user_id=290026 Could this be a duplicate of (closed) bug #765227 ? In any case, please check out from CVS and try again. This might solve your problem. Assigned to Fred, as he claims to have access to a Mac OS X system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=816447&group_id=10127 From noreply at sourceforge.net Mon Oct 13 15:43:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 13 15:43:50 2003 Subject: [Expat-bugs] [ expat-Patches-820946 ] expat.h not great for MSVC !cdecl deflt calling cnvntn Message-ID: Patches item #820946, was opened at 2003-10-09 19:06 Message generated for change (Comment added) made by marshray_bs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=820946&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: expat.h not great for MSVC !cdecl deflt calling cnvntn Initial Comment: OK, well the title I wanted was "expat.h doesn't work cleanly for MSVC with non-cdecl default calling convetion", but there were (reasonable, I guess) length limitations. In any case, if you have a project in MSVC that has its default calling convention set to something other than cdecl (such as stdcall or fastcall), the prototypes for the handler functions don't communicate that the library is compiled to assume cdecl. Things will still compile fine, however odd behavior occurs at runtime (for example, my start element handler was called 5 times with the same name and then the thread crashed). If your callback funcitons are then explicitly declared cdecl (as they should be) then you have to use casts to allow you to assign the address of your cdecl handler functions to the function pointers that the compiler defaults to the different convention. I don't suppose many people bother to change the default calling convention of their projects, but I have seen fastcall give a 5% boost. XML parsing is not a significant part of our apps exection time, so it's not worth recompiling expat to fastcall. It would be nice if it worked out of the box for us. I've supplied a patch, that defines a macro XMLCALLBACK for callbacks, much like the XMLPARSEAPI macro is defined for API functions. I've tested it with MSVC 7.1 projects that default to both stdcall and fastcall. Because the preprocessor tests are set up like the ones for the XMLPARSEAPI macro, I don't think it should affect any non-MSVC compilers. Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- Comment By: Marsh Ray (marshray_bs) Date: 2003-10-13 15:43 Message: Logged In: YES user_id=883966 > How does it work when you build the library > with your calling convention? Expat.dll does not compile with not compile with a default calling convention other than __cdecl. It produces 65 errors, here's a sample: --------------------Configuration: expat - Win32 Debug-------------------- Compiling... xmlparse.c c:\expat-1.95.6\source\lib\xmlparse.c(629) : error C2373: 'XML_ParserCreate' : redefinition; different type modifiers c:\expat-1.95.6\source\lib\expat.h(194) : see declaration of 'XML_ParserCreate' These errors correspond 1:1 with the public API functions defined in expat.h. In expat.h the API functions are declared explicitly cdecl with the XMLPARSEAPI macro. Their definitions (in xmlparse.c for example) do not specify a calling convention, so they follow the default for the project. > If it works OK then we should not force any > calling convention on the callbacks but > simply document that the pre-built binaries > were compiled with cdecl as default. Currently, we're using a Perl script to patch 1.95.1 to allow it to be compiled as fastcall and thus be compatible with our code. We'd like to use the newer release, and for obvious reasons, we'd like to get on the official codebase. The "callforward" API functions define a specific calling convention, all we need is to have one specified on the callbacks. Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-11 16:10 Message: Logged In: YES user_id=290026 How does it work when you build the library with your calling convention? If it works OK then we should not force any calling convention on the callbacks but simply document that the pre-built binaries were compiled with cdecl as default. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=820946&group_id=10127 From noreply at sourceforge.net Mon Oct 13 15:53:07 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 13 15:53:13 2003 Subject: [Expat-bugs] [ expat-Patches-820946 ] expat.h not great for MSVC !cdecl deflt calling cnvntn Message-ID: Patches item #820946, was opened at 2003-10-09 19:06 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=820946&group_id=10127 Category: None Group: None Status: Open Resolution: None >Priority: 6 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: expat.h not great for MSVC !cdecl deflt calling cnvntn Initial Comment: OK, well the title I wanted was "expat.h doesn't work cleanly for MSVC with non-cdecl default calling convetion", but there were (reasonable, I guess) length limitations. In any case, if you have a project in MSVC that has its default calling convention set to something other than cdecl (such as stdcall or fastcall), the prototypes for the handler functions don't communicate that the library is compiled to assume cdecl. Things will still compile fine, however odd behavior occurs at runtime (for example, my start element handler was called 5 times with the same name and then the thread crashed). If your callback funcitons are then explicitly declared cdecl (as they should be) then you have to use casts to allow you to assign the address of your cdecl handler functions to the function pointers that the compiler defaults to the different convention. I don't suppose many people bother to change the default calling convention of their projects, but I have seen fastcall give a 5% boost. XML parsing is not a significant part of our apps exection time, so it's not worth recompiling expat to fastcall. It would be nice if it worked out of the box for us. I've supplied a patch, that defines a macro XMLCALLBACK for callbacks, much like the XMLPARSEAPI macro is defined for API functions. I've tested it with MSVC 7.1 projects that default to both stdcall and fastcall. Because the preprocessor tests are set up like the ones for the XMLPARSEAPI macro, I don't think it should affect any non-MSVC compilers. Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 15:53 Message: Logged In: YES user_id=3066 Ok, I think I understand this one now. ;-) Thanks for the careful response. While I think that interaction between libraries and compiler switches will probably always be a source of frustration, we should be able to make this particular problem go away. I'll gladly support a solution which always forces both call directions to always use cdecl. Hopefully I'll be able to fix this in the next couple of days; I know I won't have time tonight, though. ;-( ---------------------------------------------------------------------- Comment By: Marsh Ray (marshray_bs) Date: 2003-10-13 15:43 Message: Logged In: YES user_id=883966 > How does it work when you build the library > with your calling convention? Expat.dll does not compile with not compile with a default calling convention other than __cdecl. It produces 65 errors, here's a sample: --------------------Configuration: expat - Win32 Debug-------------------- Compiling... xmlparse.c c:\expat-1.95.6\source\lib\xmlparse.c(629) : error C2373: 'XML_ParserCreate' : redefinition; different type modifiers c:\expat-1.95.6\source\lib\expat.h(194) : see declaration of 'XML_ParserCreate' These errors correspond 1:1 with the public API functions defined in expat.h. In expat.h the API functions are declared explicitly cdecl with the XMLPARSEAPI macro. Their definitions (in xmlparse.c for example) do not specify a calling convention, so they follow the default for the project. > If it works OK then we should not force any > calling convention on the callbacks but > simply document that the pre-built binaries > were compiled with cdecl as default. Currently, we're using a Perl script to patch 1.95.1 to allow it to be compiled as fastcall and thus be compatible with our code. We'd like to use the newer release, and for obvious reasons, we'd like to get on the official codebase. The "callforward" API functions define a specific calling convention, all we need is to have one specified on the callbacks. Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-11 16:10 Message: Logged In: YES user_id=290026 How does it work when you build the library with your calling convention? If it works OK then we should not force any calling convention on the callbacks but simply document that the pre-built binaries were compiled with cdecl as default. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=820946&group_id=10127 From noreply at sourceforge.net Mon Oct 13 16:50:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 13 16:50:07 2003 Subject: [Expat-bugs] [ expat-Patches-820946 ] expat.h not great for MSVC !cdecl deflt calling cnvntn Message-ID: Patches item #820946, was opened at 2003-10-09 19:06 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=820946&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 6 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: expat.h not great for MSVC !cdecl deflt calling cnvntn Initial Comment: OK, well the title I wanted was "expat.h doesn't work cleanly for MSVC with non-cdecl default calling convetion", but there were (reasonable, I guess) length limitations. In any case, if you have a project in MSVC that has its default calling convention set to something other than cdecl (such as stdcall or fastcall), the prototypes for the handler functions don't communicate that the library is compiled to assume cdecl. Things will still compile fine, however odd behavior occurs at runtime (for example, my start element handler was called 5 times with the same name and then the thread crashed). If your callback funcitons are then explicitly declared cdecl (as they should be) then you have to use casts to allow you to assign the address of your cdecl handler functions to the function pointers that the compiler defaults to the different convention. I don't suppose many people bother to change the default calling convention of their projects, but I have seen fastcall give a 5% boost. XML parsing is not a significant part of our apps exection time, so it's not worth recompiling expat to fastcall. It would be nice if it worked out of the box for us. I've supplied a patch, that defines a macro XMLCALLBACK for callbacks, much like the XMLPARSEAPI macro is defined for API functions. I've tested it with MSVC 7.1 projects that default to both stdcall and fastcall. Because the preprocessor tests are set up like the ones for the XMLPARSEAPI macro, I don't think it should affect any non-MSVC compilers. Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-13 16:50 Message: Logged In: YES user_id=290026 OK, here is what I think: It is OK if you want to compiler with a different default calling convention. The fact that this is a problem with Expat is a bug IMO. We simply should fix xmlparse.c so that those declarations that are frozen in expat.h are also frozen in xmlparse.c. We should look at it as two sets of calling conventions: a) those used internally - they are basically frozen b) those used in the API For the second ones, we again have two groups: performance sensitive and non-sensitive. The callbacks fall into the performance sensitive group, the rest is not really performance sensitive (please correct me if I am missing some). I think we can freeze the non-performance sensitive API without much problems, but we should leave the callbacks open for optimization. So, if we concentrate on the callbacks, then it should work if we make xmlparse.c follow expat.h. I just patched xmlparse.c to use XMLPARSEAPI for all functions that have it in expat.h. Down to three errors when using another default calling convention. The errors now are involving the memory handler callbacks. We should probably define an XMLMEMAPI macro to freeze these as they should follow the calling convention used for the standard memory allocation functions. Btw, why is XMLPARSEAPI undefined in xmlparse.c after inclusion of expat.h? I had to uncomment this to make it compile. Any ideas, Fred. Marsh? Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 15:53 Message: Logged In: YES user_id=3066 Ok, I think I understand this one now. ;-) Thanks for the careful response. While I think that interaction between libraries and compiler switches will probably always be a source of frustration, we should be able to make this particular problem go away. I'll gladly support a solution which always forces both call directions to always use cdecl. Hopefully I'll be able to fix this in the next couple of days; I know I won't have time tonight, though. ;-( ---------------------------------------------------------------------- Comment By: Marsh Ray (marshray_bs) Date: 2003-10-13 15:43 Message: Logged In: YES user_id=883966 > How does it work when you build the library > with your calling convention? Expat.dll does not compile with not compile with a default calling convention other than __cdecl. It produces 65 errors, here's a sample: --------------------Configuration: expat - Win32 Debug-------------------- Compiling... xmlparse.c c:\expat-1.95.6\source\lib\xmlparse.c(629) : error C2373: 'XML_ParserCreate' : redefinition; different type modifiers c:\expat-1.95.6\source\lib\expat.h(194) : see declaration of 'XML_ParserCreate' These errors correspond 1:1 with the public API functions defined in expat.h. In expat.h the API functions are declared explicitly cdecl with the XMLPARSEAPI macro. Their definitions (in xmlparse.c for example) do not specify a calling convention, so they follow the default for the project. > If it works OK then we should not force any > calling convention on the callbacks but > simply document that the pre-built binaries > were compiled with cdecl as default. Currently, we're using a Perl script to patch 1.95.1 to allow it to be compiled as fastcall and thus be compatible with our code. We'd like to use the newer release, and for obvious reasons, we'd like to get on the official codebase. The "callforward" API functions define a specific calling convention, all we need is to have one specified on the callbacks. Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-11 16:10 Message: Logged In: YES user_id=290026 How does it work when you build the library with your calling convention? If it works OK then we should not force any calling convention on the callbacks but simply document that the pre-built binaries were compiled with cdecl as default. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=820946&group_id=10127 From noreply at sourceforge.net Mon Oct 13 17:29:32 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 13 17:29:38 2003 Subject: [Expat-bugs] [ expat-Patches-820946 ] expat.h not great for MSVC !cdecl deflt calling cnvntn Message-ID: Patches item #820946, was opened at 2003-10-09 19:06 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=820946&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 6 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: expat.h not great for MSVC !cdecl deflt calling cnvntn Initial Comment: OK, well the title I wanted was "expat.h doesn't work cleanly for MSVC with non-cdecl default calling convetion", but there were (reasonable, I guess) length limitations. In any case, if you have a project in MSVC that has its default calling convention set to something other than cdecl (such as stdcall or fastcall), the prototypes for the handler functions don't communicate that the library is compiled to assume cdecl. Things will still compile fine, however odd behavior occurs at runtime (for example, my start element handler was called 5 times with the same name and then the thread crashed). If your callback funcitons are then explicitly declared cdecl (as they should be) then you have to use casts to allow you to assign the address of your cdecl handler functions to the function pointers that the compiler defaults to the different convention. I don't suppose many people bother to change the default calling convention of their projects, but I have seen fastcall give a 5% boost. XML parsing is not a significant part of our apps exection time, so it's not worth recompiling expat to fastcall. It would be nice if it worked out of the box for us. I've supplied a patch, that defines a macro XMLCALLBACK for callbacks, much like the XMLPARSEAPI macro is defined for API functions. I've tested it with MSVC 7.1 projects that default to both stdcall and fastcall. Because the preprocessor tests are set up like the ones for the XMLPARSEAPI macro, I don't think it should affect any non-MSVC compilers. Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 17:29 Message: Logged In: YES user_id=3066 Karl, the #undef XMLPARSEAPI is a mystery. I wouldn't be surprised if it's related to the DLL import/export stuff; that may not be needed/desired in the implementation. I suspect that none of it is actually needed in the implementation when cdecl is the default, because explicitly stating cdecl and implicitly using it are probably considered equivalent (questionable practice). I'll bet we can get away with always declaring cdecl; this impacts expat.h as well, since there's a case when the calling convention isn't specified there. I suspect most of the callbacks are not performance sensitive; given that for start/end element we already do a fair bit of work and make many internal calls, there's little impact based on the calling convention for the callback. The only one I'd suspect is particularly sensitive is the characters callback, and there's no specific reason to think the calling convention is going to buy much. I'm inclined to think that everything that crosses the library boundary should be explicitly cdecl. As far as XMLMEMAPI goes, I've no idea how to say "the same calling convention as malloc()". We could define wrapper functions with some explicit convention, but that adds a layer of calls; that's painful. If you know how to pull this one off, I'm open to suggestions! ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-13 16:50 Message: Logged In: YES user_id=290026 OK, here is what I think: It is OK if you want to compiler with a different default calling convention. The fact that this is a problem with Expat is a bug IMO. We simply should fix xmlparse.c so that those declarations that are frozen in expat.h are also frozen in xmlparse.c. We should look at it as two sets of calling conventions: a) those used internally - they are basically frozen b) those used in the API For the second ones, we again have two groups: performance sensitive and non-sensitive. The callbacks fall into the performance sensitive group, the rest is not really performance sensitive (please correct me if I am missing some). I think we can freeze the non-performance sensitive API without much problems, but we should leave the callbacks open for optimization. So, if we concentrate on the callbacks, then it should work if we make xmlparse.c follow expat.h. I just patched xmlparse.c to use XMLPARSEAPI for all functions that have it in expat.h. Down to three errors when using another default calling convention. The errors now are involving the memory handler callbacks. We should probably define an XMLMEMAPI macro to freeze these as they should follow the calling convention used for the standard memory allocation functions. Btw, why is XMLPARSEAPI undefined in xmlparse.c after inclusion of expat.h? I had to uncomment this to make it compile. Any ideas, Fred. Marsh? Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 15:53 Message: Logged In: YES user_id=3066 Ok, I think I understand this one now. ;-) Thanks for the careful response. While I think that interaction between libraries and compiler switches will probably always be a source of frustration, we should be able to make this particular problem go away. I'll gladly support a solution which always forces both call directions to always use cdecl. Hopefully I'll be able to fix this in the next couple of days; I know I won't have time tonight, though. ;-( ---------------------------------------------------------------------- Comment By: Marsh Ray (marshray_bs) Date: 2003-10-13 15:43 Message: Logged In: YES user_id=883966 > How does it work when you build the library > with your calling convention? Expat.dll does not compile with not compile with a default calling convention other than __cdecl. It produces 65 errors, here's a sample: --------------------Configuration: expat - Win32 Debug-------------------- Compiling... xmlparse.c c:\expat-1.95.6\source\lib\xmlparse.c(629) : error C2373: 'XML_ParserCreate' : redefinition; different type modifiers c:\expat-1.95.6\source\lib\expat.h(194) : see declaration of 'XML_ParserCreate' These errors correspond 1:1 with the public API functions defined in expat.h. In expat.h the API functions are declared explicitly cdecl with the XMLPARSEAPI macro. Their definitions (in xmlparse.c for example) do not specify a calling convention, so they follow the default for the project. > If it works OK then we should not force any > calling convention on the callbacks but > simply document that the pre-built binaries > were compiled with cdecl as default. Currently, we're using a Perl script to patch 1.95.1 to allow it to be compiled as fastcall and thus be compatible with our code. We'd like to use the newer release, and for obvious reasons, we'd like to get on the official codebase. The "callforward" API functions define a specific calling convention, all we need is to have one specified on the callbacks. Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-11 16:10 Message: Logged In: YES user_id=290026 How does it work when you build the library with your calling convention? If it works OK then we should not force any calling convention on the callbacks but simply document that the pre-built binaries were compiled with cdecl as default. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=820946&group_id=10127 From noreply at sourceforge.net Mon Oct 13 17:47:20 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 13 17:47:27 2003 Subject: [Expat-bugs] [ expat-Patches-820946 ] expat.h not great for MSVC !cdecl deflt calling cnvntn Message-ID: Patches item #820946, was opened at 2003-10-09 19:06 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=820946&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 6 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: expat.h not great for MSVC !cdecl deflt calling cnvntn Initial Comment: OK, well the title I wanted was "expat.h doesn't work cleanly for MSVC with non-cdecl default calling convetion", but there were (reasonable, I guess) length limitations. In any case, if you have a project in MSVC that has its default calling convention set to something other than cdecl (such as stdcall or fastcall), the prototypes for the handler functions don't communicate that the library is compiled to assume cdecl. Things will still compile fine, however odd behavior occurs at runtime (for example, my start element handler was called 5 times with the same name and then the thread crashed). If your callback funcitons are then explicitly declared cdecl (as they should be) then you have to use casts to allow you to assign the address of your cdecl handler functions to the function pointers that the compiler defaults to the different convention. I don't suppose many people bother to change the default calling convention of their projects, but I have seen fastcall give a 5% boost. XML parsing is not a significant part of our apps exection time, so it's not worth recompiling expat to fastcall. It would be nice if it worked out of the box for us. I've supplied a patch, that defines a macro XMLCALLBACK for callbacks, much like the XMLPARSEAPI macro is defined for API functions. I've tested it with MSVC 7.1 projects that default to both stdcall and fastcall. Because the preprocessor tests are set up like the ones for the XMLPARSEAPI macro, I don't think it should affect any non-MSVC compilers. Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 17:47 Message: Logged In: YES user_id=3066 >From looking through the CVS logs, we did have an XMLCALLBACK macro at one point, used to mark the callback function typedefs with cdecl. This comment from xmlparse.c revision 1.21 is interesting: ---- revision 1.21 date: 2001/07/27 17:17:44; author: fdrake; state: Exp; lines: +0 -4 Remove all traces of the XMLCALLBACK macro -- there appears to be no way to add __cdecl to a typedef of a function type that MSVC does not complain about. Callback implementations may need to add explicit __cdecl annotations in sources not compiled with the C calling convention as the default. ---- XMLCALLBACK had been added (by me) in revision 1.19, which has this comment: ---- Make sure that XMLPARSEAPI specifies the calling convention when building under MSVC -- this is needed when using the pre-compiled DLL with projects built using a different calling convention. XMLPARSEAPI now takes the return type as a parameter and inserts annotations on both sides of the type to make sure the compiler is happy. A new macro, XMLCALLBACK, is used to perform similar annotation of the callback function types, which do not need the dllimport/dllexport annotations but do still need the __cdecl annotation. This closes SF bug #413653. ---- Sigh. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 17:29 Message: Logged In: YES user_id=3066 Karl, the #undef XMLPARSEAPI is a mystery. I wouldn't be surprised if it's related to the DLL import/export stuff; that may not be needed/desired in the implementation. I suspect that none of it is actually needed in the implementation when cdecl is the default, because explicitly stating cdecl and implicitly using it are probably considered equivalent (questionable practice). I'll bet we can get away with always declaring cdecl; this impacts expat.h as well, since there's a case when the calling convention isn't specified there. I suspect most of the callbacks are not performance sensitive; given that for start/end element we already do a fair bit of work and make many internal calls, there's little impact based on the calling convention for the callback. The only one I'd suspect is particularly sensitive is the characters callback, and there's no specific reason to think the calling convention is going to buy much. I'm inclined to think that everything that crosses the library boundary should be explicitly cdecl. As far as XMLMEMAPI goes, I've no idea how to say "the same calling convention as malloc()". We could define wrapper functions with some explicit convention, but that adds a layer of calls; that's painful. If you know how to pull this one off, I'm open to suggestions! ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-13 16:50 Message: Logged In: YES user_id=290026 OK, here is what I think: It is OK if you want to compiler with a different default calling convention. The fact that this is a problem with Expat is a bug IMO. We simply should fix xmlparse.c so that those declarations that are frozen in expat.h are also frozen in xmlparse.c. We should look at it as two sets of calling conventions: a) those used internally - they are basically frozen b) those used in the API For the second ones, we again have two groups: performance sensitive and non-sensitive. The callbacks fall into the performance sensitive group, the rest is not really performance sensitive (please correct me if I am missing some). I think we can freeze the non-performance sensitive API without much problems, but we should leave the callbacks open for optimization. So, if we concentrate on the callbacks, then it should work if we make xmlparse.c follow expat.h. I just patched xmlparse.c to use XMLPARSEAPI for all functions that have it in expat.h. Down to three errors when using another default calling convention. The errors now are involving the memory handler callbacks. We should probably define an XMLMEMAPI macro to freeze these as they should follow the calling convention used for the standard memory allocation functions. Btw, why is XMLPARSEAPI undefined in xmlparse.c after inclusion of expat.h? I had to uncomment this to make it compile. Any ideas, Fred. Marsh? Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 15:53 Message: Logged In: YES user_id=3066 Ok, I think I understand this one now. ;-) Thanks for the careful response. While I think that interaction between libraries and compiler switches will probably always be a source of frustration, we should be able to make this particular problem go away. I'll gladly support a solution which always forces both call directions to always use cdecl. Hopefully I'll be able to fix this in the next couple of days; I know I won't have time tonight, though. ;-( ---------------------------------------------------------------------- Comment By: Marsh Ray (marshray_bs) Date: 2003-10-13 15:43 Message: Logged In: YES user_id=883966 > How does it work when you build the library > with your calling convention? Expat.dll does not compile with not compile with a default calling convention other than __cdecl. It produces 65 errors, here's a sample: --------------------Configuration: expat - Win32 Debug-------------------- Compiling... xmlparse.c c:\expat-1.95.6\source\lib\xmlparse.c(629) : error C2373: 'XML_ParserCreate' : redefinition; different type modifiers c:\expat-1.95.6\source\lib\expat.h(194) : see declaration of 'XML_ParserCreate' These errors correspond 1:1 with the public API functions defined in expat.h. In expat.h the API functions are declared explicitly cdecl with the XMLPARSEAPI macro. Their definitions (in xmlparse.c for example) do not specify a calling convention, so they follow the default for the project. > If it works OK then we should not force any > calling convention on the callbacks but > simply document that the pre-built binaries > were compiled with cdecl as default. Currently, we're using a Perl script to patch 1.95.1 to allow it to be compiled as fastcall and thus be compatible with our code. We'd like to use the newer release, and for obvious reasons, we'd like to get on the official codebase. The "callforward" API functions define a specific calling convention, all we need is to have one specified on the callbacks. Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-11 16:10 Message: Logged In: YES user_id=290026 How does it work when you build the library with your calling convention? If it works OK then we should not force any calling convention on the callbacks but simply document that the pre-built binaries were compiled with cdecl as default. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=820946&group_id=10127 From noreply at sourceforge.net Mon Oct 13 17:54:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 13 17:54:33 2003 Subject: [Expat-bugs] [ expat-Patches-820946 ] expat.h not great for MSVC !cdecl deflt calling cnvntn Message-ID: Patches item #820946, was opened at 2003-10-09 19:06 Message generated for change (Comment added) made by marshray_bs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=820946&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 6 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: expat.h not great for MSVC !cdecl deflt calling cnvntn Initial Comment: OK, well the title I wanted was "expat.h doesn't work cleanly for MSVC with non-cdecl default calling convetion", but there were (reasonable, I guess) length limitations. In any case, if you have a project in MSVC that has its default calling convention set to something other than cdecl (such as stdcall or fastcall), the prototypes for the handler functions don't communicate that the library is compiled to assume cdecl. Things will still compile fine, however odd behavior occurs at runtime (for example, my start element handler was called 5 times with the same name and then the thread crashed). If your callback funcitons are then explicitly declared cdecl (as they should be) then you have to use casts to allow you to assign the address of your cdecl handler functions to the function pointers that the compiler defaults to the different convention. I don't suppose many people bother to change the default calling convention of their projects, but I have seen fastcall give a 5% boost. XML parsing is not a significant part of our apps exection time, so it's not worth recompiling expat to fastcall. It would be nice if it worked out of the box for us. I've supplied a patch, that defines a macro XMLCALLBACK for callbacks, much like the XMLPARSEAPI macro is defined for API functions. I've tested it with MSVC 7.1 projects that default to both stdcall and fastcall. Because the preprocessor tests are set up like the ones for the XMLPARSEAPI macro, I don't think it should affect any non-MSVC compilers. Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- Comment By: Marsh Ray (marshray_bs) Date: 2003-10-13 17:54 Message: Logged In: YES user_id=883966 >Comment By: Karl Waclawek (kwaclaw) >Date: 2003-10-13 16:50 > It is OK if you want to compiler with > a different default calling convention. > The fact that this is a problem with > Expat is a bug IMO. > We simply should fix xmlparse.c so that > those declarations that are frozen in > expat.h are also frozen in xmlparse.c. Agreed, although this is not exactly the problem I was intending to address. We have both cdecl and fastcall default calling conventions being used in our processes. Currently, we're using multiple expat.dll's to handle this. It would be nice to be able to use the same expat.dll everywhere to reduce build-time complexity and run-time footprint. Ridding our code of Xerces is now perhaps another matter . . . :) > We should look at it as two sets of calling conventions: > a) those used internally - they are basically frozen By 'frozen' I assume you mean using the default calling conventions specified at compile time? > b) those used in the API > For the second ones, we again have two groups: > performance sensitive and non-sensitive. > The callbacks fall into the performance > sensitive group, the rest is not really > performance sensitive (please correct mefreeze the > if I am missing some). I think we can non-performancemuch > problems, sensitive API without but we should leave the > callbacks open for optimization. When XML becomes a performance bottleneck, we would typically change our architecture to use faster binary structures. Therefore the ~5% gain in XML parsing we might get by compiling Expat as fastcall is not really significant. Our main goal is to get everyone on the same .dll. > So, if we concentrate on the callbacks, then it should work > if we make xmlparse.c follow expat.h. Sure, if you want to require people to compile a different version of expat.dll for every default calling convention in use. I think the solution for people who want to compile expat as fastcall (if that person exists) would be to allow them to set a #define (in their client code) to specify the calling convention that their custom-compiled dll wants. For example: #define XML_EXPAT_USES_FASTCALL 1 /* or _STDCALL, _CDECL is default */ #include "expat.h" /* be sure to link with expat_fastcall.lib and .dll */ Again, this ability is not particularly useful to us. > I just patched xmlparse.c to use XMLPARSEAPI for all > functions that have it in expat.h. Down to three errors > when using another default calling convention. > The errors now are involving the memory handler callbacks. > We should probably define an XMLMEMAPI macro to freeze > these as they should follow the calling convention used for > the standard memory allocation functions. >Comment By: Fred L. Drake, Jr. (fdrake) > As far as XMLMEMAPI goes, I've no idea how to say "the same > calling convention as malloc()". We could define wrapper > functions with some explicit convention, but that adds a > layer of calls; that's painful. If you know how to pull > this one off, I'm open to suggestions! In my Microsoft headers, I find: _CRTIMP void * __cdecl malloc(size_t); Furthermore, there is not a different C runtime library for each default calling convention. So, it's probably safe to assume malloc is going to be cdecl. Stating that explicitly in the definiton of XML_Memory_Handling_Suite should work, although it looks like there'll be a few places to change in xmlparse.c. #ifndef XMLCDECL #if defined(_MSC_EXTENSIONS) && !defined(__BEOS__) && !defined(__CYGWIN__) #define XMLCDECL __cdecl #else #define XMLCDECL #endif #endif /* not defined XMLCDECL*/ typedef struct { void *(XMLCDECL *malloc_fcn)(size_t size); void *(XMLCDECL *realloc_fcn)(void *ptr, size_t size); void (XMLCDECL *free_fcn)(void *ptr); } XML_Memory_Handling_Suite; >Comment By: Karl Waclawek (kwaclaw) > Btw, why is XMLPARSEAPI undefined in xmlparse.c after > inclusion of expat.h? I had to uncomment this to make > it compile. Any ideas, Fred. Marsh? I would guess the author simply had a habit of being hygenic and didn't want unused defines to propagate out of the inclusing of expat.h. Gee, as I am writing this, you guys keep posting new stuff. > revision 1.21 > date: 2001/07/27 17:17:44; author: fdrake; state: Exp; > lines: +0 -4 > Remove all traces of the XMLCALLBACK macro -- there appears > to be no way to add __cdecl to a typedef of a function type > that MSVC does not complain about. Callback implementations > may need to add explicit __cdecl annotations in sources not > compiled with the C calling convention as the default. I haven't seen any warnings from my patch to expat.h (with the client code and MSVC 7.1). Is it possible that a compiler upgrade has the compiler issue? Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 17:47 Message: Logged In: YES user_id=3066 >From looking through the CVS logs, we did have an XMLCALLBACK macro at one point, used to mark the callback function typedefs with cdecl. This comment from xmlparse.c revision 1.21 is interesting: ---- revision 1.21 date: 2001/07/27 17:17:44; author: fdrake; state: Exp; lines: +0 -4 Remove all traces of the XMLCALLBACK macro -- there appears to be no way to add __cdecl to a typedef of a function type that MSVC does not complain about. Callback implementations may need to add explicit __cdecl annotations in sources not compiled with the C calling convention as the default. ---- XMLCALLBACK had been added (by me) in revision 1.19, which has this comment: ---- Make sure that XMLPARSEAPI specifies the calling convention when building under MSVC -- this is needed when using the pre-compiled DLL with projects built using a different calling convention. XMLPARSEAPI now takes the return type as a parameter and inserts annotations on both sides of the type to make sure the compiler is happy. A new macro, XMLCALLBACK, is used to perform similar annotation of the callback function types, which do not need the dllimport/dllexport annotations but do still need the __cdecl annotation. This closes SF bug #413653. ---- Sigh. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 17:29 Message: Logged In: YES user_id=3066 Karl, the #undef XMLPARSEAPI is a mystery. I wouldn't be surprised if it's related to the DLL import/export stuff; that may not be needed/desired in the implementation. I suspect that none of it is actually needed in the implementation when cdecl is the default, because explicitly stating cdecl and implicitly using it are probably considered equivalent (questionable practice). I'll bet we can get away with always declaring cdecl; this impacts expat.h as well, since there's a case when the calling convention isn't specified there. I suspect most of the callbacks are not performance sensitive; given that for start/end element we already do a fair bit of work and make many internal calls, there's little impact based on the calling convention for the callback. The only one I'd suspect is particularly sensitive is the characters callback, and there's no specific reason to think the calling convention is going to buy much. I'm inclined to think that everything that crosses the library boundary should be explicitly cdecl. As far as XMLMEMAPI goes, I've no idea how to say "the same calling convention as malloc()". We could define wrapper functions with some explicit convention, but that adds a layer of calls; that's painful. If you know how to pull this one off, I'm open to suggestions! ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-13 16:50 Message: Logged In: YES user_id=290026 OK, here is what I think: It is OK if you want to compiler with a different default calling convention. The fact that this is a problem with Expat is a bug IMO. We simply should fix xmlparse.c so that those declarations that are frozen in expat.h are also frozen in xmlparse.c. We should look at it as two sets of calling conventions: a) those used internally - they are basically frozen b) those used in the API For the second ones, we again have two groups: performance sensitive and non-sensitive. The callbacks fall into the performance sensitive group, the rest is not really performance sensitive (please correct me if I am missing some). I think we can freeze the non-performance sensitive API without much problems, but we should leave the callbacks open for optimization. So, if we concentrate on the callbacks, then it should work if we make xmlparse.c follow expat.h. I just patched xmlparse.c to use XMLPARSEAPI for all functions that have it in expat.h. Down to three errors when using another default calling convention. The errors now are involving the memory handler callbacks. We should probably define an XMLMEMAPI macro to freeze these as they should follow the calling convention used for the standard memory allocation functions. Btw, why is XMLPARSEAPI undefined in xmlparse.c after inclusion of expat.h? I had to uncomment this to make it compile. Any ideas, Fred. Marsh? Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 15:53 Message: Logged In: YES user_id=3066 Ok, I think I understand this one now. ;-) Thanks for the careful response. While I think that interaction between libraries and compiler switches will probably always be a source of frustration, we should be able to make this particular problem go away. I'll gladly support a solution which always forces both call directions to always use cdecl. Hopefully I'll be able to fix this in the next couple of days; I know I won't have time tonight, though. ;-( ---------------------------------------------------------------------- Comment By: Marsh Ray (marshray_bs) Date: 2003-10-13 15:43 Message: Logged In: YES user_id=883966 > How does it work when you build the library > with your calling convention? Expat.dll does not compile with not compile with a default calling convention other than __cdecl. It produces 65 errors, here's a sample: --------------------Configuration: expat - Win32 Debug-------------------- Compiling... xmlparse.c c:\expat-1.95.6\source\lib\xmlparse.c(629) : error C2373: 'XML_ParserCreate' : redefinition; different type modifiers c:\expat-1.95.6\source\lib\expat.h(194) : see declaration of 'XML_ParserCreate' These errors correspond 1:1 with the public API functions defined in expat.h. In expat.h the API functions are declared explicitly cdecl with the XMLPARSEAPI macro. Their definitions (in xmlparse.c for example) do not specify a calling convention, so they follow the default for the project. > If it works OK then we should not force any > calling convention on the callbacks but > simply document that the pre-built binaries > were compiled with cdecl as default. Currently, we're using a Perl script to patch 1.95.1 to allow it to be compiled as fastcall and thus be compatible with our code. We'd like to use the newer release, and for obvious reasons, we'd like to get on the official codebase. The "callforward" API functions define a specific calling convention, all we need is to have one specified on the callbacks. Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-11 16:10 Message: Logged In: YES user_id=290026 How does it work when you build the library with your calling convention? If it works OK then we should not force any calling convention on the callbacks but simply document that the pre-built binaries were compiled with cdecl as default. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=820946&group_id=10127 From noreply at sourceforge.net Mon Oct 13 18:06:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 13 18:06:21 2003 Subject: [Expat-bugs] [ expat-Patches-820946 ] expat.h not great for MSVC !cdecl deflt calling cnvntn Message-ID: Patches item #820946, was opened at 2003-10-09 19:06 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=820946&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 6 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: expat.h not great for MSVC !cdecl deflt calling cnvntn Initial Comment: OK, well the title I wanted was "expat.h doesn't work cleanly for MSVC with non-cdecl default calling convetion", but there were (reasonable, I guess) length limitations. In any case, if you have a project in MSVC that has its default calling convention set to something other than cdecl (such as stdcall or fastcall), the prototypes for the handler functions don't communicate that the library is compiled to assume cdecl. Things will still compile fine, however odd behavior occurs at runtime (for example, my start element handler was called 5 times with the same name and then the thread crashed). If your callback funcitons are then explicitly declared cdecl (as they should be) then you have to use casts to allow you to assign the address of your cdecl handler functions to the function pointers that the compiler defaults to the different convention. I don't suppose many people bother to change the default calling convention of their projects, but I have seen fastcall give a 5% boost. XML parsing is not a significant part of our apps exection time, so it's not worth recompiling expat to fastcall. It would be nice if it worked out of the box for us. I've supplied a patch, that defines a macro XMLCALLBACK for callbacks, much like the XMLPARSEAPI macro is defined for API functions. I've tested it with MSVC 7.1 projects that default to both stdcall and fastcall. Because the preprocessor tests are set up like the ones for the XMLPARSEAPI macro, I don't think it should affect any non-MSVC compilers. Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 18:06 Message: Logged In: YES user_id=3066 Marsh: > By 'frozen' I assume you mean using the default calling > conventions specified at compile time? Yes. > I haven't seen any warnings from my patch to expat.h (with > the client code and MSVC 7.1). Is it possible that a > compiler upgrade has the compiler issue? I would have been using MSVC 6, since that's the only MSVC I've had for years. Not sure what service pack, though. Also, I'm no Windows expert, mostly only using MSVC in a mindless, repetitive "did that break something" mode. I'll play with your patch with actual compilers, though, and see how well I survive. ;-) ---------------------------------------------------------------------- Comment By: Marsh Ray (marshray_bs) Date: 2003-10-13 17:54 Message: Logged In: YES user_id=883966 >Comment By: Karl Waclawek (kwaclaw) >Date: 2003-10-13 16:50 > It is OK if you want to compiler with > a different default calling convention. > The fact that this is a problem with > Expat is a bug IMO. > We simply should fix xmlparse.c so that > those declarations that are frozen in > expat.h are also frozen in xmlparse.c. Agreed, although this is not exactly the problem I was intending to address. We have both cdecl and fastcall default calling conventions being used in our processes. Currently, we're using multiple expat.dll's to handle this. It would be nice to be able to use the same expat.dll everywhere to reduce build-time complexity and run-time footprint. Ridding our code of Xerces is now perhaps another matter . . . :) > We should look at it as two sets of calling conventions: > a) those used internally - they are basically frozen By 'frozen' I assume you mean using the default calling conventions specified at compile time? > b) those used in the API > For the second ones, we again have two groups: > performance sensitive and non-sensitive. > The callbacks fall into the performance > sensitive group, the rest is not really > performance sensitive (please correct mefreeze the > if I am missing some). I think we can non-performancemuch > problems, sensitive API without but we should leave the > callbacks open for optimization. When XML becomes a performance bottleneck, we would typically change our architecture to use faster binary structures. Therefore the ~5% gain in XML parsing we might get by compiling Expat as fastcall is not really significant. Our main goal is to get everyone on the same .dll. > So, if we concentrate on the callbacks, then it should work > if we make xmlparse.c follow expat.h. Sure, if you want to require people to compile a different version of expat.dll for every default calling convention in use. I think the solution for people who want to compile expat as fastcall (if that person exists) would be to allow them to set a #define (in their client code) to specify the calling convention that their custom-compiled dll wants. For example: #define XML_EXPAT_USES_FASTCALL 1 /* or _STDCALL, _CDECL is default */ #include "expat.h" /* be sure to link with expat_fastcall.lib and .dll */ Again, this ability is not particularly useful to us. > I just patched xmlparse.c to use XMLPARSEAPI for all > functions that have it in expat.h. Down to three errors > when using another default calling convention. > The errors now are involving the memory handler callbacks. > We should probably define an XMLMEMAPI macro to freeze > these as they should follow the calling convention used for > the standard memory allocation functions. >Comment By: Fred L. Drake, Jr. (fdrake) > As far as XMLMEMAPI goes, I've no idea how to say "the same > calling convention as malloc()". We could define wrapper > functions with some explicit convention, but that adds a > layer of calls; that's painful. If you know how to pull > this one off, I'm open to suggestions! In my Microsoft headers, I find: _CRTIMP void * __cdecl malloc(size_t); Furthermore, there is not a different C runtime library for each default calling convention. So, it's probably safe to assume malloc is going to be cdecl. Stating that explicitly in the definiton of XML_Memory_Handling_Suite should work, although it looks like there'll be a few places to change in xmlparse.c. #ifndef XMLCDECL #if defined(_MSC_EXTENSIONS) && !defined(__BEOS__) && !defined(__CYGWIN__) #define XMLCDECL __cdecl #else #define XMLCDECL #endif #endif /* not defined XMLCDECL*/ typedef struct { void *(XMLCDECL *malloc_fcn)(size_t size); void *(XMLCDECL *realloc_fcn)(void *ptr, size_t size); void (XMLCDECL *free_fcn)(void *ptr); } XML_Memory_Handling_Suite; >Comment By: Karl Waclawek (kwaclaw) > Btw, why is XMLPARSEAPI undefined in xmlparse.c after > inclusion of expat.h? I had to uncomment this to make > it compile. Any ideas, Fred. Marsh? I would guess the author simply had a habit of being hygenic and didn't want unused defines to propagate out of the inclusing of expat.h. Gee, as I am writing this, you guys keep posting new stuff. > revision 1.21 > date: 2001/07/27 17:17:44; author: fdrake; state: Exp; > lines: +0 -4 > Remove all traces of the XMLCALLBACK macro -- there appears > to be no way to add __cdecl to a typedef of a function type > that MSVC does not complain about. Callback implementations > may need to add explicit __cdecl annotations in sources not > compiled with the C calling convention as the default. I haven't seen any warnings from my patch to expat.h (with the client code and MSVC 7.1). Is it possible that a compiler upgrade has the compiler issue? Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 17:47 Message: Logged In: YES user_id=3066 >From looking through the CVS logs, we did have an XMLCALLBACK macro at one point, used to mark the callback function typedefs with cdecl. This comment from xmlparse.c revision 1.21 is interesting: ---- revision 1.21 date: 2001/07/27 17:17:44; author: fdrake; state: Exp; lines: +0 -4 Remove all traces of the XMLCALLBACK macro -- there appears to be no way to add __cdecl to a typedef of a function type that MSVC does not complain about. Callback implementations may need to add explicit __cdecl annotations in sources not compiled with the C calling convention as the default. ---- XMLCALLBACK had been added (by me) in revision 1.19, which has this comment: ---- Make sure that XMLPARSEAPI specifies the calling convention when building under MSVC -- this is needed when using the pre-compiled DLL with projects built using a different calling convention. XMLPARSEAPI now takes the return type as a parameter and inserts annotations on both sides of the type to make sure the compiler is happy. A new macro, XMLCALLBACK, is used to perform similar annotation of the callback function types, which do not need the dllimport/dllexport annotations but do still need the __cdecl annotation. This closes SF bug #413653. ---- Sigh. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 17:29 Message: Logged In: YES user_id=3066 Karl, the #undef XMLPARSEAPI is a mystery. I wouldn't be surprised if it's related to the DLL import/export stuff; that may not be needed/desired in the implementation. I suspect that none of it is actually needed in the implementation when cdecl is the default, because explicitly stating cdecl and implicitly using it are probably considered equivalent (questionable practice). I'll bet we can get away with always declaring cdecl; this impacts expat.h as well, since there's a case when the calling convention isn't specified there. I suspect most of the callbacks are not performance sensitive; given that for start/end element we already do a fair bit of work and make many internal calls, there's little impact based on the calling convention for the callback. The only one I'd suspect is particularly sensitive is the characters callback, and there's no specific reason to think the calling convention is going to buy much. I'm inclined to think that everything that crosses the library boundary should be explicitly cdecl. As far as XMLMEMAPI goes, I've no idea how to say "the same calling convention as malloc()". We could define wrapper functions with some explicit convention, but that adds a layer of calls; that's painful. If you know how to pull this one off, I'm open to suggestions! ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-13 16:50 Message: Logged In: YES user_id=290026 OK, here is what I think: It is OK if you want to compiler with a different default calling convention. The fact that this is a problem with Expat is a bug IMO. We simply should fix xmlparse.c so that those declarations that are frozen in expat.h are also frozen in xmlparse.c. We should look at it as two sets of calling conventions: a) those used internally - they are basically frozen b) those used in the API For the second ones, we again have two groups: performance sensitive and non-sensitive. The callbacks fall into the performance sensitive group, the rest is not really performance sensitive (please correct me if I am missing some). I think we can freeze the non-performance sensitive API without much problems, but we should leave the callbacks open for optimization. So, if we concentrate on the callbacks, then it should work if we make xmlparse.c follow expat.h. I just patched xmlparse.c to use XMLPARSEAPI for all functions that have it in expat.h. Down to three errors when using another default calling convention. The errors now are involving the memory handler callbacks. We should probably define an XMLMEMAPI macro to freeze these as they should follow the calling convention used for the standard memory allocation functions. Btw, why is XMLPARSEAPI undefined in xmlparse.c after inclusion of expat.h? I had to uncomment this to make it compile. Any ideas, Fred. Marsh? Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 15:53 Message: Logged In: YES user_id=3066 Ok, I think I understand this one now. ;-) Thanks for the careful response. While I think that interaction between libraries and compiler switches will probably always be a source of frustration, we should be able to make this particular problem go away. I'll gladly support a solution which always forces both call directions to always use cdecl. Hopefully I'll be able to fix this in the next couple of days; I know I won't have time tonight, though. ;-( ---------------------------------------------------------------------- Comment By: Marsh Ray (marshray_bs) Date: 2003-10-13 15:43 Message: Logged In: YES user_id=883966 > How does it work when you build the library > with your calling convention? Expat.dll does not compile with not compile with a default calling convention other than __cdecl. It produces 65 errors, here's a sample: --------------------Configuration: expat - Win32 Debug-------------------- Compiling... xmlparse.c c:\expat-1.95.6\source\lib\xmlparse.c(629) : error C2373: 'XML_ParserCreate' : redefinition; different type modifiers c:\expat-1.95.6\source\lib\expat.h(194) : see declaration of 'XML_ParserCreate' These errors correspond 1:1 with the public API functions defined in expat.h. In expat.h the API functions are declared explicitly cdecl with the XMLPARSEAPI macro. Their definitions (in xmlparse.c for example) do not specify a calling convention, so they follow the default for the project. > If it works OK then we should not force any > calling convention on the callbacks but > simply document that the pre-built binaries > were compiled with cdecl as default. Currently, we're using a Perl script to patch 1.95.1 to allow it to be compiled as fastcall and thus be compatible with our code. We'd like to use the newer release, and for obvious reasons, we'd like to get on the official codebase. The "callforward" API functions define a specific calling convention, all we need is to have one specified on the callbacks. Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-11 16:10 Message: Logged In: YES user_id=290026 How does it work when you build the library with your calling convention? If it works OK then we should not force any calling convention on the callbacks but simply document that the pre-built binaries were compiled with cdecl as default. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=820946&group_id=10127 From noreply at sourceforge.net Mon Oct 13 19:29:25 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 13 19:29:32 2003 Subject: [Expat-bugs] [ expat-Patches-820946 ] expat.h not great for MSVC !cdecl deflt calling cnvntn Message-ID: Patches item #820946, was opened at 2003-10-09 19:06 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=820946&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 6 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: expat.h not great for MSVC !cdecl deflt calling cnvntn Initial Comment: OK, well the title I wanted was "expat.h doesn't work cleanly for MSVC with non-cdecl default calling convetion", but there were (reasonable, I guess) length limitations. In any case, if you have a project in MSVC that has its default calling convention set to something other than cdecl (such as stdcall or fastcall), the prototypes for the handler functions don't communicate that the library is compiled to assume cdecl. Things will still compile fine, however odd behavior occurs at runtime (for example, my start element handler was called 5 times with the same name and then the thread crashed). If your callback funcitons are then explicitly declared cdecl (as they should be) then you have to use casts to allow you to assign the address of your cdecl handler functions to the function pointers that the compiler defaults to the different convention. I don't suppose many people bother to change the default calling convention of their projects, but I have seen fastcall give a 5% boost. XML parsing is not a significant part of our apps exection time, so it's not worth recompiling expat to fastcall. It would be nice if it worked out of the box for us. I've supplied a patch, that defines a macro XMLCALLBACK for callbacks, much like the XMLPARSEAPI macro is defined for API functions. I've tested it with MSVC 7.1 projects that default to both stdcall and fastcall. Because the preprocessor tests are set up like the ones for the XMLPARSEAPI macro, I don't think it should affect any non-MSVC compilers. Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-13 19:29 Message: Logged In: YES user_id=290026 I am a little late with my replies. So, summarizing I would say: Let's force cdecl on all API calls, call-back or not. About performance: Considering how much work Expat does behind each call-back the calling convention will likely not have a measurable impact. I agree with Fred here. Also, looking back at our own testing with internal calling conventions, cdecl came out ahead. In my opinion, and I think in Fred's opinion too, this was because cdecl allows optimizations for call "clusters" as the caller manages the stack, not the callee. I really don't think fastcall will give any measurable advantage, even for the call-backs. So, using this patch, what else is there to do? Should we be concerned with memory handler calls and whatever else will have an undefined calling convention? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 18:06 Message: Logged In: YES user_id=3066 Marsh: > By 'frozen' I assume you mean using the default calling > conventions specified at compile time? Yes. > I haven't seen any warnings from my patch to expat.h (with > the client code and MSVC 7.1). Is it possible that a > compiler upgrade has the compiler issue? I would have been using MSVC 6, since that's the only MSVC I've had for years. Not sure what service pack, though. Also, I'm no Windows expert, mostly only using MSVC in a mindless, repetitive "did that break something" mode. I'll play with your patch with actual compilers, though, and see how well I survive. ;-) ---------------------------------------------------------------------- Comment By: Marsh Ray (marshray_bs) Date: 2003-10-13 17:54 Message: Logged In: YES user_id=883966 >Comment By: Karl Waclawek (kwaclaw) >Date: 2003-10-13 16:50 > It is OK if you want to compiler with > a different default calling convention. > The fact that this is a problem with > Expat is a bug IMO. > We simply should fix xmlparse.c so that > those declarations that are frozen in > expat.h are also frozen in xmlparse.c. Agreed, although this is not exactly the problem I was intending to address. We have both cdecl and fastcall default calling conventions being used in our processes. Currently, we're using multiple expat.dll's to handle this. It would be nice to be able to use the same expat.dll everywhere to reduce build-time complexity and run-time footprint. Ridding our code of Xerces is now perhaps another matter . . . :) > We should look at it as two sets of calling conventions: > a) those used internally - they are basically frozen By 'frozen' I assume you mean using the default calling conventions specified at compile time? > b) those used in the API > For the second ones, we again have two groups: > performance sensitive and non-sensitive. > The callbacks fall into the performance > sensitive group, the rest is not really > performance sensitive (please correct mefreeze the > if I am missing some). I think we can non-performancemuch > problems, sensitive API without but we should leave the > callbacks open for optimization. When XML becomes a performance bottleneck, we would typically change our architecture to use faster binary structures. Therefore the ~5% gain in XML parsing we might get by compiling Expat as fastcall is not really significant. Our main goal is to get everyone on the same .dll. > So, if we concentrate on the callbacks, then it should work > if we make xmlparse.c follow expat.h. Sure, if you want to require people to compile a different version of expat.dll for every default calling convention in use. I think the solution for people who want to compile expat as fastcall (if that person exists) would be to allow them to set a #define (in their client code) to specify the calling convention that their custom-compiled dll wants. For example: #define XML_EXPAT_USES_FASTCALL 1 /* or _STDCALL, _CDECL is default */ #include "expat.h" /* be sure to link with expat_fastcall.lib and .dll */ Again, this ability is not particularly useful to us. > I just patched xmlparse.c to use XMLPARSEAPI for all > functions that have it in expat.h. Down to three errors > when using another default calling convention. > The errors now are involving the memory handler callbacks. > We should probably define an XMLMEMAPI macro to freeze > these as they should follow the calling convention used for > the standard memory allocation functions. >Comment By: Fred L. Drake, Jr. (fdrake) > As far as XMLMEMAPI goes, I've no idea how to say "the same > calling convention as malloc()". We could define wrapper > functions with some explicit convention, but that adds a > layer of calls; that's painful. If you know how to pull > this one off, I'm open to suggestions! In my Microsoft headers, I find: _CRTIMP void * __cdecl malloc(size_t); Furthermore, there is not a different C runtime library for each default calling convention. So, it's probably safe to assume malloc is going to be cdecl. Stating that explicitly in the definiton of XML_Memory_Handling_Suite should work, although it looks like there'll be a few places to change in xmlparse.c. #ifndef XMLCDECL #if defined(_MSC_EXTENSIONS) && !defined(__BEOS__) && !defined(__CYGWIN__) #define XMLCDECL __cdecl #else #define XMLCDECL #endif #endif /* not defined XMLCDECL*/ typedef struct { void *(XMLCDECL *malloc_fcn)(size_t size); void *(XMLCDECL *realloc_fcn)(void *ptr, size_t size); void (XMLCDECL *free_fcn)(void *ptr); } XML_Memory_Handling_Suite; >Comment By: Karl Waclawek (kwaclaw) > Btw, why is XMLPARSEAPI undefined in xmlparse.c after > inclusion of expat.h? I had to uncomment this to make > it compile. Any ideas, Fred. Marsh? I would guess the author simply had a habit of being hygenic and didn't want unused defines to propagate out of the inclusing of expat.h. Gee, as I am writing this, you guys keep posting new stuff. > revision 1.21 > date: 2001/07/27 17:17:44; author: fdrake; state: Exp; > lines: +0 -4 > Remove all traces of the XMLCALLBACK macro -- there appears > to be no way to add __cdecl to a typedef of a function type > that MSVC does not complain about. Callback implementations > may need to add explicit __cdecl annotations in sources not > compiled with the C calling convention as the default. I haven't seen any warnings from my patch to expat.h (with the client code and MSVC 7.1). Is it possible that a compiler upgrade has the compiler issue? Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 17:47 Message: Logged In: YES user_id=3066 >From looking through the CVS logs, we did have an XMLCALLBACK macro at one point, used to mark the callback function typedefs with cdecl. This comment from xmlparse.c revision 1.21 is interesting: ---- revision 1.21 date: 2001/07/27 17:17:44; author: fdrake; state: Exp; lines: +0 -4 Remove all traces of the XMLCALLBACK macro -- there appears to be no way to add __cdecl to a typedef of a function type that MSVC does not complain about. Callback implementations may need to add explicit __cdecl annotations in sources not compiled with the C calling convention as the default. ---- XMLCALLBACK had been added (by me) in revision 1.19, which has this comment: ---- Make sure that XMLPARSEAPI specifies the calling convention when building under MSVC -- this is needed when using the pre-compiled DLL with projects built using a different calling convention. XMLPARSEAPI now takes the return type as a parameter and inserts annotations on both sides of the type to make sure the compiler is happy. A new macro, XMLCALLBACK, is used to perform similar annotation of the callback function types, which do not need the dllimport/dllexport annotations but do still need the __cdecl annotation. This closes SF bug #413653. ---- Sigh. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 17:29 Message: Logged In: YES user_id=3066 Karl, the #undef XMLPARSEAPI is a mystery. I wouldn't be surprised if it's related to the DLL import/export stuff; that may not be needed/desired in the implementation. I suspect that none of it is actually needed in the implementation when cdecl is the default, because explicitly stating cdecl and implicitly using it are probably considered equivalent (questionable practice). I'll bet we can get away with always declaring cdecl; this impacts expat.h as well, since there's a case when the calling convention isn't specified there. I suspect most of the callbacks are not performance sensitive; given that for start/end element we already do a fair bit of work and make many internal calls, there's little impact based on the calling convention for the callback. The only one I'd suspect is particularly sensitive is the characters callback, and there's no specific reason to think the calling convention is going to buy much. I'm inclined to think that everything that crosses the library boundary should be explicitly cdecl. As far as XMLMEMAPI goes, I've no idea how to say "the same calling convention as malloc()". We could define wrapper functions with some explicit convention, but that adds a layer of calls; that's painful. If you know how to pull this one off, I'm open to suggestions! ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-13 16:50 Message: Logged In: YES user_id=290026 OK, here is what I think: It is OK if you want to compiler with a different default calling convention. The fact that this is a problem with Expat is a bug IMO. We simply should fix xmlparse.c so that those declarations that are frozen in expat.h are also frozen in xmlparse.c. We should look at it as two sets of calling conventions: a) those used internally - they are basically frozen b) those used in the API For the second ones, we again have two groups: performance sensitive and non-sensitive. The callbacks fall into the performance sensitive group, the rest is not really performance sensitive (please correct me if I am missing some). I think we can freeze the non-performance sensitive API without much problems, but we should leave the callbacks open for optimization. So, if we concentrate on the callbacks, then it should work if we make xmlparse.c follow expat.h. I just patched xmlparse.c to use XMLPARSEAPI for all functions that have it in expat.h. Down to three errors when using another default calling convention. The errors now are involving the memory handler callbacks. We should probably define an XMLMEMAPI macro to freeze these as they should follow the calling convention used for the standard memory allocation functions. Btw, why is XMLPARSEAPI undefined in xmlparse.c after inclusion of expat.h? I had to uncomment this to make it compile. Any ideas, Fred. Marsh? Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 15:53 Message: Logged In: YES user_id=3066 Ok, I think I understand this one now. ;-) Thanks for the careful response. While I think that interaction between libraries and compiler switches will probably always be a source of frustration, we should be able to make this particular problem go away. I'll gladly support a solution which always forces both call directions to always use cdecl. Hopefully I'll be able to fix this in the next couple of days; I know I won't have time tonight, though. ;-( ---------------------------------------------------------------------- Comment By: Marsh Ray (marshray_bs) Date: 2003-10-13 15:43 Message: Logged In: YES user_id=883966 > How does it work when you build the library > with your calling convention? Expat.dll does not compile with not compile with a default calling convention other than __cdecl. It produces 65 errors, here's a sample: --------------------Configuration: expat - Win32 Debug-------------------- Compiling... xmlparse.c c:\expat-1.95.6\source\lib\xmlparse.c(629) : error C2373: 'XML_ParserCreate' : redefinition; different type modifiers c:\expat-1.95.6\source\lib\expat.h(194) : see declaration of 'XML_ParserCreate' These errors correspond 1:1 with the public API functions defined in expat.h. In expat.h the API functions are declared explicitly cdecl with the XMLPARSEAPI macro. Their definitions (in xmlparse.c for example) do not specify a calling convention, so they follow the default for the project. > If it works OK then we should not force any > calling convention on the callbacks but > simply document that the pre-built binaries > were compiled with cdecl as default. Currently, we're using a Perl script to patch 1.95.1 to allow it to be compiled as fastcall and thus be compatible with our code. We'd like to use the newer release, and for obvious reasons, we'd like to get on the official codebase. The "callforward" API functions define a specific calling convention, all we need is to have one specified on the callbacks. Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-11 16:10 Message: Logged In: YES user_id=290026 How does it work when you build the library with your calling convention? If it works OK then we should not force any calling convention on the callbacks but simply document that the pre-built binaries were compiled with cdecl as default. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=820946&group_id=10127 From noreply at sourceforge.net Tue Oct 14 13:47:38 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 14 13:47:41 2003 Subject: [Expat-bugs] [ expat-Bugs-823591 ] configure error with expat-1.95.6 Message-ID: Bugs item #823591, was opened at 2003-10-14 17:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=823591&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Free Bird (freebird1963) Assigned to: Nobody/Anonymous (nobody) Summary: configure error with expat-1.95.6 Initial Comment: OS is FreeBSD 4.8 checking expat.h usability... no checking expat.h presence... yes configure: WARNING: expat.h: present but cannot be compiled configure: WARNING: expat.h: check for missing prerequisite headers? configure: WARNING: expat.h: proceeding with the preprocessor's result configure: WARNING: ## --------------------------- --------- ## configure: WARNING: ## Report this to bug- autoconf@gnu.org. ## configure: WARNING: ## --------------------------- --------- ## checking for expat.h... yes checking whether expat.h is broken... yes configure: error: You probably have expat version 1.95.6. Please refer to: http://sourceforge.net/tracker/index.php? func=detail&aid=676844&group_id=10127 &atid=110127 for a description of the problem. configure line used was: ./configure --with-expat-prefix=/usr/local ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=823591&group_id=10127 From noreply at sourceforge.net Tue Oct 14 13:53:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 14 13:53:25 2003 Subject: [Expat-bugs] [ expat-Bugs-823591 ] configure error with expat-1.95.6 Message-ID: Bugs item #823591, was opened at 2003-10-14 13:47 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=823591&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Free Bird (freebird1963) Assigned to: Nobody/Anonymous (nobody) Summary: configure error with expat-1.95.6 Initial Comment: OS is FreeBSD 4.8 checking expat.h usability... no checking expat.h presence... yes configure: WARNING: expat.h: present but cannot be compiled configure: WARNING: expat.h: check for missing prerequisite headers? configure: WARNING: expat.h: proceeding with the preprocessor's result configure: WARNING: ## --------------------------- --------- ## configure: WARNING: ## Report this to bug- autoconf@gnu.org. ## configure: WARNING: ## --------------------------- --------- ## checking for expat.h... yes checking whether expat.h is broken... yes configure: error: You probably have expat version 1.95.6. Please refer to: http://sourceforge.net/tracker/index.php? func=detail&aid=676844&group_id=10127 &atid=110127 for a description of the problem. configure line used was: ./configure --with-expat-prefix=/usr/local ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-14 13:53 Message: Logged In: YES user_id=3066 This is a (very oblique) reference to issue #676844. This is fixed in the CVS repository; Expat 1.95.7 is expected shortly. Marking this as a duplicate and closing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=823591&group_id=10127 From noreply at sourceforge.net Tue Oct 14 13:58:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 14 13:58:43 2003 Subject: [Expat-bugs] [ expat-Bugs-821481 ] expat 1.95.6 compiles, but fails check on Solaris 2.8 Message-ID: Bugs item #821481, was opened at 2003-10-10 17:08 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=821481&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Gerard Tromp (gtromp) Assigned to: Nobody/Anonymous (nobody) Summary: expat 1.95.6 compiles, but fails check on Solaris 2.8 Initial Comment: Greetings: Compiled the 1.95.6 package using both gcc (3.2) and Sun cc (5.0) compilers. No problem compiling. Both compilations fail "make check" identically (and no, it is not the lack of the check package). The output from the check is attached. Any insights will be appreciated. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-14 13:58 Message: Logged In: YES user_id=3066 Closed based on followup from reporter. ---------------------------------------------------------------------- Comment By: Gerard Tromp (gtromp) Date: 2003-10-10 17:22 Message: Logged In: YES user_id=337239 Found the problem. The problem was that the runtests objects were being linked to the old libraries. The hint was that the reported version did not match the current build. Apologies for bothering everyone. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=821481&group_id=10127 From noreply at sourceforge.net Tue Oct 14 15:47:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 14 15:47:36 2003 Subject: [Expat-bugs] [ expat-Bugs-780087 ] bad gcc flag when linking library in Soalris 2.8 Message-ID: Bugs item #780087, was opened at 2003-07-30 04:44 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=780087&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: bad gcc flag when linking library in Soalris 2.8 Initial Comment: expat 1.95.5, 1.95.6 When libtool links the lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo into libexpat.la on Solaris 2.8 when using gcc(3.3 or 3.1), libgcc(3.1 or 3.3) and binutils (2.11.2) ,from SunFreeware.com, it includes the '-no- undefined' flag which causes the make to always fail with a "main not found in crt1.o" error. This of course is silly 'coz a library has no 'main', see gcc discusion http://www.geocrawler.com/mail/msg.php3? msg_id=2903632&list=28. Looking at libtools "link" case statement I see it sets "allow_undefined=yes" but this does not translate to the make line. Could this be a problem? When I manually edited the "make" line, removing the flag '-no-undefined' the library was built without error. As this stops expat building from source on the above platform can I sugest that this is considered an urgent bug to be fixed? Of course I could be wrong :-) Here's an example (I've used 1.95.5 to avoid all those regparm warning messages you get in 1.95.6 on Solaris with gcc 3.1/3.3) snip--- Script started on Wed Jul 30 09:41:53 2003 sh-2.03$ cd expat-1.95.5 sh-2.03$ make distclean ; ./configure ; make cd lib && rm -f libexpat.la *.o *.lo && rm -rf .libs _libs cd xmlwf && rm -f xmlwf *.o *.lo && rm -rf .libs _libs cd examples && rm -f elements outline *.o *.lo && rm - rf .libs _libs cd tests && rm -rf .libs runtests runtests.o chardata.o rm -rf .libs libexpat.la find . -name core | xargs rm -f rm -f expat_config.h config.status config.log config.cache libtool rm -f Makefile checking build system type... sparc-sun-solaris2.8 checking host system type... sparc-sun-solaris2.8 checking for gcc... /usr/local/bin/gcc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /usr/local/bin/gcc accepts -g... yes checking for ld used by GCC... /usr/local/bin/gcc checking if the linker (/usr/local/bin/gcc) is GNU ld... no checking for /usr/local/bin/gcc option to reload object files... -r checking for BSD-compatible nm... /usr/local/bin/nm -B checking whether ln -s works... yes checking how to recognise dependant libraries... pass_all checking command to parse /usr/local/bin/nm -B output... ok checking how to run the C preprocessor... /usr/local/bin/gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... no checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for ranlib... ranlib checking for strip... strip checking for objdir... .libs checking for /usr/local/bin/gcc option to produce PIC... - fPIC checking if /usr/local/bin/gcc PIC flag -fPIC works... yes checking if /usr/local/bin/gcc static flag -static works... yes checking if /usr/local/bin/gcc supports -c -o file.o... yes checking if /usr/local/bin/gcc supports -c -o file.lo... yes checking if /usr/local/bin/gcc supports -fno-rtti -fno- exceptions... yes checking whether the linker (/usr/local/bin/gcc) supports shared libraries... ye s checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking dynamic linker characteristics... solaris2.8 ld.so checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes creating libtool checking for gcc... (cached) /usr/local/bin/gcc checking whether we are using the GNU C compiler... (cached) yes checking whether /usr/local/bin/gcc accepts -g... (cached) yes checking for a BSD-compatible install... conftools/install- sh -c checking whether gcc accepts -fexceptions... yes checking for ANSI C header files... (cached) yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking whether byte ordering is bigendian... yes checking for /usr/local/bin/gcc option to accept ANSI C... none needed checking for an ANSI C-conforming const... yes checking for off_t... yes checking for size_t... yes checking for working memcmp... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... yes checking for memmove... yes checking for bcopy... yes configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h /bin/bash ./libtool --silent -- mode=compile /usr/local/bin/gcc -g -O2 -Wall -Wmi ssing-prototypes -Wstrict-prototypes -fexceptions - I./lib -I. -o lib/xmlparse. lo -c lib/xmlparse.c /bin/bash ./libtool --silent -- mode=compile /usr/local/bin/gcc -g -O2 -Wall -Wmi ssing-prototypes -Wstrict-prototypes -fexceptions - I./lib -I. -o lib/xmltok.lo -c lib/xmltok.c /bin/bash ./libtool --silent -- mode=compile /usr/local/bin/gcc -g -O2 -Wall -Wmi ssing-prototypes -Wstrict-prototypes -fexceptions - I./lib -I. -o lib/xmlrole.l o -c lib/xmlrole.c /bin/bash ./libtool --silent -- mode=link /usr/local/bin/gcc -g -O2 -Wall -Wmissi ng-prototypes -Wstrict-prototypes -fexceptions - I./lib -I. -no-undefined -vers ion-info 4:0:4 -rpath /usr/local/lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo Undefined first referenced symbol in file main /usr/local/lib/gcc-lib/sparc- sun-solaris2.8/ 3.3/crt1.o ld: fatal: Symbol referencing errors. No output written to .libs/libexpat.so.0.4 .0 collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `libexpat.la' sh-2.03$ exit script done on Wed Jul 30 09:43:53 2003 snip--- ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-14 15:47 Message: Logged In: YES user_id=3066 There's a snapshot of the current CVS version at: http://www.libexpat.org/expat-2003-10-11.tar.gz Can anyone reproduce this using this snapshot? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=780087&group_id=10127 From noreply at sourceforge.net Tue Oct 14 17:35:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 14 17:35:49 2003 Subject: [Expat-bugs] [ expat-Patches-820946 ] expat.h not great for MSVC !cdecl deflt calling cnvntn Message-ID: Patches item #820946, was opened at 2003-10-09 19:06 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=820946&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 6 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: expat.h not great for MSVC !cdecl deflt calling cnvntn Initial Comment: OK, well the title I wanted was "expat.h doesn't work cleanly for MSVC with non-cdecl default calling convetion", but there were (reasonable, I guess) length limitations. In any case, if you have a project in MSVC that has its default calling convention set to something other than cdecl (such as stdcall or fastcall), the prototypes for the handler functions don't communicate that the library is compiled to assume cdecl. Things will still compile fine, however odd behavior occurs at runtime (for example, my start element handler was called 5 times with the same name and then the thread crashed). If your callback funcitons are then explicitly declared cdecl (as they should be) then you have to use casts to allow you to assign the address of your cdecl handler functions to the function pointers that the compiler defaults to the different convention. I don't suppose many people bother to change the default calling convention of their projects, but I have seen fastcall give a 5% boost. XML parsing is not a significant part of our apps exection time, so it's not worth recompiling expat to fastcall. It would be nice if it worked out of the box for us. I've supplied a patch, that defines a macro XMLCALLBACK for callbacks, much like the XMLPARSEAPI macro is defined for API functions. I've tested it with MSVC 7.1 projects that default to both stdcall and fastcall. Because the preprocessor tests are set up like the ones for the XMLPARSEAPI macro, I don't think it should affect any non-MSVC compilers. Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-14 17:35 Message: Logged In: YES user_id=3066 Ok, here's what I propose doing: - add a macro, XMLCALL, that expands to whatever is needed to nail down the calling convention for all calls across the library boundary - add the XMLCALLBACK macro, defined to use XMLCALL - add XMLCALL to XMLPARSEAPI - modify all example code to include XMLCALL for definitions of callbacks - document, document, document! Any of these can be overridden before including expat.h, for those who are adventurous. For those who stick to their compiler defaults, there should be no perceivable change. Once done, I'll release another snapshot, with emails sent to relevant lists (expat-discuss, Python's xml-sig; feel free to suggest others, or just pass the word when the snapshot's up). I've started the code changes based on this patch, but I've only tested using GCC 3.2.2 on RedHat 9 so far. Comments? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-13 19:29 Message: Logged In: YES user_id=290026 I am a little late with my replies. So, summarizing I would say: Let's force cdecl on all API calls, call-back or not. About performance: Considering how much work Expat does behind each call-back the calling convention will likely not have a measurable impact. I agree with Fred here. Also, looking back at our own testing with internal calling conventions, cdecl came out ahead. In my opinion, and I think in Fred's opinion too, this was because cdecl allows optimizations for call "clusters" as the caller manages the stack, not the callee. I really don't think fastcall will give any measurable advantage, even for the call-backs. So, using this patch, what else is there to do? Should we be concerned with memory handler calls and whatever else will have an undefined calling convention? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 18:06 Message: Logged In: YES user_id=3066 Marsh: > By 'frozen' I assume you mean using the default calling > conventions specified at compile time? Yes. > I haven't seen any warnings from my patch to expat.h (with > the client code and MSVC 7.1). Is it possible that a > compiler upgrade has the compiler issue? I would have been using MSVC 6, since that's the only MSVC I've had for years. Not sure what service pack, though. Also, I'm no Windows expert, mostly only using MSVC in a mindless, repetitive "did that break something" mode. I'll play with your patch with actual compilers, though, and see how well I survive. ;-) ---------------------------------------------------------------------- Comment By: Marsh Ray (marshray_bs) Date: 2003-10-13 17:54 Message: Logged In: YES user_id=883966 >Comment By: Karl Waclawek (kwaclaw) >Date: 2003-10-13 16:50 > It is OK if you want to compiler with > a different default calling convention. > The fact that this is a problem with > Expat is a bug IMO. > We simply should fix xmlparse.c so that > those declarations that are frozen in > expat.h are also frozen in xmlparse.c. Agreed, although this is not exactly the problem I was intending to address. We have both cdecl and fastcall default calling conventions being used in our processes. Currently, we're using multiple expat.dll's to handle this. It would be nice to be able to use the same expat.dll everywhere to reduce build-time complexity and run-time footprint. Ridding our code of Xerces is now perhaps another matter . . . :) > We should look at it as two sets of calling conventions: > a) those used internally - they are basically frozen By 'frozen' I assume you mean using the default calling conventions specified at compile time? > b) those used in the API > For the second ones, we again have two groups: > performance sensitive and non-sensitive. > The callbacks fall into the performance > sensitive group, the rest is not really > performance sensitive (please correct mefreeze the > if I am missing some). I think we can non-performancemuch > problems, sensitive API without but we should leave the > callbacks open for optimization. When XML becomes a performance bottleneck, we would typically change our architecture to use faster binary structures. Therefore the ~5% gain in XML parsing we might get by compiling Expat as fastcall is not really significant. Our main goal is to get everyone on the same .dll. > So, if we concentrate on the callbacks, then it should work > if we make xmlparse.c follow expat.h. Sure, if you want to require people to compile a different version of expat.dll for every default calling convention in use. I think the solution for people who want to compile expat as fastcall (if that person exists) would be to allow them to set a #define (in their client code) to specify the calling convention that their custom-compiled dll wants. For example: #define XML_EXPAT_USES_FASTCALL 1 /* or _STDCALL, _CDECL is default */ #include "expat.h" /* be sure to link with expat_fastcall.lib and .dll */ Again, this ability is not particularly useful to us. > I just patched xmlparse.c to use XMLPARSEAPI for all > functions that have it in expat.h. Down to three errors > when using another default calling convention. > The errors now are involving the memory handler callbacks. > We should probably define an XMLMEMAPI macro to freeze > these as they should follow the calling convention used for > the standard memory allocation functions. >Comment By: Fred L. Drake, Jr. (fdrake) > As far as XMLMEMAPI goes, I've no idea how to say "the same > calling convention as malloc()". We could define wrapper > functions with some explicit convention, but that adds a > layer of calls; that's painful. If you know how to pull > this one off, I'm open to suggestions! In my Microsoft headers, I find: _CRTIMP void * __cdecl malloc(size_t); Furthermore, there is not a different C runtime library for each default calling convention. So, it's probably safe to assume malloc is going to be cdecl. Stating that explicitly in the definiton of XML_Memory_Handling_Suite should work, although it looks like there'll be a few places to change in xmlparse.c. #ifndef XMLCDECL #if defined(_MSC_EXTENSIONS) && !defined(__BEOS__) && !defined(__CYGWIN__) #define XMLCDECL __cdecl #else #define XMLCDECL #endif #endif /* not defined XMLCDECL*/ typedef struct { void *(XMLCDECL *malloc_fcn)(size_t size); void *(XMLCDECL *realloc_fcn)(void *ptr, size_t size); void (XMLCDECL *free_fcn)(void *ptr); } XML_Memory_Handling_Suite; >Comment By: Karl Waclawek (kwaclaw) > Btw, why is XMLPARSEAPI undefined in xmlparse.c after > inclusion of expat.h? I had to uncomment this to make > it compile. Any ideas, Fred. Marsh? I would guess the author simply had a habit of being hygenic and didn't want unused defines to propagate out of the inclusing of expat.h. Gee, as I am writing this, you guys keep posting new stuff. > revision 1.21 > date: 2001/07/27 17:17:44; author: fdrake; state: Exp; > lines: +0 -4 > Remove all traces of the XMLCALLBACK macro -- there appears > to be no way to add __cdecl to a typedef of a function type > that MSVC does not complain about. Callback implementations > may need to add explicit __cdecl annotations in sources not > compiled with the C calling convention as the default. I haven't seen any warnings from my patch to expat.h (with the client code and MSVC 7.1). Is it possible that a compiler upgrade has the compiler issue? Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 17:47 Message: Logged In: YES user_id=3066 >From looking through the CVS logs, we did have an XMLCALLBACK macro at one point, used to mark the callback function typedefs with cdecl. This comment from xmlparse.c revision 1.21 is interesting: ---- revision 1.21 date: 2001/07/27 17:17:44; author: fdrake; state: Exp; lines: +0 -4 Remove all traces of the XMLCALLBACK macro -- there appears to be no way to add __cdecl to a typedef of a function type that MSVC does not complain about. Callback implementations may need to add explicit __cdecl annotations in sources not compiled with the C calling convention as the default. ---- XMLCALLBACK had been added (by me) in revision 1.19, which has this comment: ---- Make sure that XMLPARSEAPI specifies the calling convention when building under MSVC -- this is needed when using the pre-compiled DLL with projects built using a different calling convention. XMLPARSEAPI now takes the return type as a parameter and inserts annotations on both sides of the type to make sure the compiler is happy. A new macro, XMLCALLBACK, is used to perform similar annotation of the callback function types, which do not need the dllimport/dllexport annotations but do still need the __cdecl annotation. This closes SF bug #413653. ---- Sigh. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 17:29 Message: Logged In: YES user_id=3066 Karl, the #undef XMLPARSEAPI is a mystery. I wouldn't be surprised if it's related to the DLL import/export stuff; that may not be needed/desired in the implementation. I suspect that none of it is actually needed in the implementation when cdecl is the default, because explicitly stating cdecl and implicitly using it are probably considered equivalent (questionable practice). I'll bet we can get away with always declaring cdecl; this impacts expat.h as well, since there's a case when the calling convention isn't specified there. I suspect most of the callbacks are not performance sensitive; given that for start/end element we already do a fair bit of work and make many internal calls, there's little impact based on the calling convention for the callback. The only one I'd suspect is particularly sensitive is the characters callback, and there's no specific reason to think the calling convention is going to buy much. I'm inclined to think that everything that crosses the library boundary should be explicitly cdecl. As far as XMLMEMAPI goes, I've no idea how to say "the same calling convention as malloc()". We could define wrapper functions with some explicit convention, but that adds a layer of calls; that's painful. If you know how to pull this one off, I'm open to suggestions! ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-13 16:50 Message: Logged In: YES user_id=290026 OK, here is what I think: It is OK if you want to compiler with a different default calling convention. The fact that this is a problem with Expat is a bug IMO. We simply should fix xmlparse.c so that those declarations that are frozen in expat.h are also frozen in xmlparse.c. We should look at it as two sets of calling conventions: a) those used internally - they are basically frozen b) those used in the API For the second ones, we again have two groups: performance sensitive and non-sensitive. The callbacks fall into the performance sensitive group, the rest is not really performance sensitive (please correct me if I am missing some). I think we can freeze the non-performance sensitive API without much problems, but we should leave the callbacks open for optimization. So, if we concentrate on the callbacks, then it should work if we make xmlparse.c follow expat.h. I just patched xmlparse.c to use XMLPARSEAPI for all functions that have it in expat.h. Down to three errors when using another default calling convention. The errors now are involving the memory handler callbacks. We should probably define an XMLMEMAPI macro to freeze these as they should follow the calling convention used for the standard memory allocation functions. Btw, why is XMLPARSEAPI undefined in xmlparse.c after inclusion of expat.h? I had to uncomment this to make it compile. Any ideas, Fred. Marsh? Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 15:53 Message: Logged In: YES user_id=3066 Ok, I think I understand this one now. ;-) Thanks for the careful response. While I think that interaction between libraries and compiler switches will probably always be a source of frustration, we should be able to make this particular problem go away. I'll gladly support a solution which always forces both call directions to always use cdecl. Hopefully I'll be able to fix this in the next couple of days; I know I won't have time tonight, though. ;-( ---------------------------------------------------------------------- Comment By: Marsh Ray (marshray_bs) Date: 2003-10-13 15:43 Message: Logged In: YES user_id=883966 > How does it work when you build the library > with your calling convention? Expat.dll does not compile with not compile with a default calling convention other than __cdecl. It produces 65 errors, here's a sample: --------------------Configuration: expat - Win32 Debug-------------------- Compiling... xmlparse.c c:\expat-1.95.6\source\lib\xmlparse.c(629) : error C2373: 'XML_ParserCreate' : redefinition; different type modifiers c:\expat-1.95.6\source\lib\expat.h(194) : see declaration of 'XML_ParserCreate' These errors correspond 1:1 with the public API functions defined in expat.h. In expat.h the API functions are declared explicitly cdecl with the XMLPARSEAPI macro. Their definitions (in xmlparse.c for example) do not specify a calling convention, so they follow the default for the project. > If it works OK then we should not force any > calling convention on the callbacks but > simply document that the pre-built binaries > were compiled with cdecl as default. Currently, we're using a Perl script to patch 1.95.1 to allow it to be compiled as fastcall and thus be compatible with our code. We'd like to use the newer release, and for obvious reasons, we'd like to get on the official codebase. The "callforward" API functions define a specific calling convention, all we need is to have one specified on the callbacks. Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-11 16:10 Message: Logged In: YES user_id=290026 How does it work when you build the library with your calling convention? If it works OK then we should not force any calling convention on the callbacks but simply document that the pre-built binaries were compiled with cdecl as default. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=820946&group_id=10127 From noreply at sourceforge.net Tue Oct 14 17:58:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 14 17:58:14 2003 Subject: [Expat-bugs] [ expat-Patches-820946 ] expat.h not great for MSVC !cdecl deflt calling cnvntn Message-ID: Patches item #820946, was opened at 2003-10-09 19:06 Message generated for change (Comment added) made by marshray_bs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=820946&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 6 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: expat.h not great for MSVC !cdecl deflt calling cnvntn Initial Comment: OK, well the title I wanted was "expat.h doesn't work cleanly for MSVC with non-cdecl default calling convetion", but there were (reasonable, I guess) length limitations. In any case, if you have a project in MSVC that has its default calling convention set to something other than cdecl (such as stdcall or fastcall), the prototypes for the handler functions don't communicate that the library is compiled to assume cdecl. Things will still compile fine, however odd behavior occurs at runtime (for example, my start element handler was called 5 times with the same name and then the thread crashed). If your callback funcitons are then explicitly declared cdecl (as they should be) then you have to use casts to allow you to assign the address of your cdecl handler functions to the function pointers that the compiler defaults to the different convention. I don't suppose many people bother to change the default calling convention of their projects, but I have seen fastcall give a 5% boost. XML parsing is not a significant part of our apps exection time, so it's not worth recompiling expat to fastcall. It would be nice if it worked out of the box for us. I've supplied a patch, that defines a macro XMLCALLBACK for callbacks, much like the XMLPARSEAPI macro is defined for API functions. I've tested it with MSVC 7.1 projects that default to both stdcall and fastcall. Because the preprocessor tests are set up like the ones for the XMLPARSEAPI macro, I don't think it should affect any non-MSVC compilers. Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- Comment By: Marsh Ray (marshray_bs) Date: 2003-10-14 17:58 Message: Logged In: YES user_id=883966 >Comment By: Fred L. Drake, Jr. (fdrake) > - add a macro, XMLCALL, that expands to whatever > is needed to nail down the calling convention > for all calls across the library boundary > - add the XMLCALLBACK macro, defined to use XMLCALL > - add XMLCALL to XMLPARSEAPI > - modify all example code to include XMLCALL for > definitions of callbacks Sounds good to me. > - document, document, document! If the changes are made as described above, it won't affect any previously functioning code. All that needs to be documented is the new functionality. A callback function defined in a module with a default calling convention other than cdecl will now need to explicitly specify the calling convention that is expected by expat (typcially cdecl). For example: void myStartElementHandler( void *userData, const XML_Char *name, const XML_Char **atts); Becomes: void __cdecl myStartElementHandler( void *userData, const XML_Char *name, const XML_Char **atts); ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-14 17:35 Message: Logged In: YES user_id=3066 Ok, here's what I propose doing: - add a macro, XMLCALL, that expands to whatever is needed to nail down the calling convention for all calls across the library boundary - add the XMLCALLBACK macro, defined to use XMLCALL - add XMLCALL to XMLPARSEAPI - modify all example code to include XMLCALL for definitions of callbacks - document, document, document! Any of these can be overridden before including expat.h, for those who are adventurous. For those who stick to their compiler defaults, there should be no perceivable change. Once done, I'll release another snapshot, with emails sent to relevant lists (expat-discuss, Python's xml-sig; feel free to suggest others, or just pass the word when the snapshot's up). I've started the code changes based on this patch, but I've only tested using GCC 3.2.2 on RedHat 9 so far. Comments? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-13 19:29 Message: Logged In: YES user_id=290026 I am a little late with my replies. So, summarizing I would say: Let's force cdecl on all API calls, call-back or not. About performance: Considering how much work Expat does behind each call-back the calling convention will likely not have a measurable impact. I agree with Fred here. Also, looking back at our own testing with internal calling conventions, cdecl came out ahead. In my opinion, and I think in Fred's opinion too, this was because cdecl allows optimizations for call "clusters" as the caller manages the stack, not the callee. I really don't think fastcall will give any measurable advantage, even for the call-backs. So, using this patch, what else is there to do? Should we be concerned with memory handler calls and whatever else will have an undefined calling convention? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 18:06 Message: Logged In: YES user_id=3066 Marsh: > By 'frozen' I assume you mean using the default calling > conventions specified at compile time? Yes. > I haven't seen any warnings from my patch to expat.h (with > the client code and MSVC 7.1). Is it possible that a > compiler upgrade has the compiler issue? I would have been using MSVC 6, since that's the only MSVC I've had for years. Not sure what service pack, though. Also, I'm no Windows expert, mostly only using MSVC in a mindless, repetitive "did that break something" mode. I'll play with your patch with actual compilers, though, and see how well I survive. ;-) ---------------------------------------------------------------------- Comment By: Marsh Ray (marshray_bs) Date: 2003-10-13 17:54 Message: Logged In: YES user_id=883966 >Comment By: Karl Waclawek (kwaclaw) >Date: 2003-10-13 16:50 > It is OK if you want to compiler with > a different default calling convention. > The fact that this is a problem with > Expat is a bug IMO. > We simply should fix xmlparse.c so that > those declarations that are frozen in > expat.h are also frozen in xmlparse.c. Agreed, although this is not exactly the problem I was intending to address. We have both cdecl and fastcall default calling conventions being used in our processes. Currently, we're using multiple expat.dll's to handle this. It would be nice to be able to use the same expat.dll everywhere to reduce build-time complexity and run-time footprint. Ridding our code of Xerces is now perhaps another matter . . . :) > We should look at it as two sets of calling conventions: > a) those used internally - they are basically frozen By 'frozen' I assume you mean using the default calling conventions specified at compile time? > b) those used in the API > For the second ones, we again have two groups: > performance sensitive and non-sensitive. > The callbacks fall into the performance > sensitive group, the rest is not really > performance sensitive (please correct mefreeze the > if I am missing some). I think we can non-performancemuch > problems, sensitive API without but we should leave the > callbacks open for optimization. When XML becomes a performance bottleneck, we would typically change our architecture to use faster binary structures. Therefore the ~5% gain in XML parsing we might get by compiling Expat as fastcall is not really significant. Our main goal is to get everyone on the same .dll. > So, if we concentrate on the callbacks, then it should work > if we make xmlparse.c follow expat.h. Sure, if you want to require people to compile a different version of expat.dll for every default calling convention in use. I think the solution for people who want to compile expat as fastcall (if that person exists) would be to allow them to set a #define (in their client code) to specify the calling convention that their custom-compiled dll wants. For example: #define XML_EXPAT_USES_FASTCALL 1 /* or _STDCALL, _CDECL is default */ #include "expat.h" /* be sure to link with expat_fastcall.lib and .dll */ Again, this ability is not particularly useful to us. > I just patched xmlparse.c to use XMLPARSEAPI for all > functions that have it in expat.h. Down to three errors > when using another default calling convention. > The errors now are involving the memory handler callbacks. > We should probably define an XMLMEMAPI macro to freeze > these as they should follow the calling convention used for > the standard memory allocation functions. >Comment By: Fred L. Drake, Jr. (fdrake) > As far as XMLMEMAPI goes, I've no idea how to say "the same > calling convention as malloc()". We could define wrapper > functions with some explicit convention, but that adds a > layer of calls; that's painful. If you know how to pull > this one off, I'm open to suggestions! In my Microsoft headers, I find: _CRTIMP void * __cdecl malloc(size_t); Furthermore, there is not a different C runtime library for each default calling convention. So, it's probably safe to assume malloc is going to be cdecl. Stating that explicitly in the definiton of XML_Memory_Handling_Suite should work, although it looks like there'll be a few places to change in xmlparse.c. #ifndef XMLCDECL #if defined(_MSC_EXTENSIONS) && !defined(__BEOS__) && !defined(__CYGWIN__) #define XMLCDECL __cdecl #else #define XMLCDECL #endif #endif /* not defined XMLCDECL*/ typedef struct { void *(XMLCDECL *malloc_fcn)(size_t size); void *(XMLCDECL *realloc_fcn)(void *ptr, size_t size); void (XMLCDECL *free_fcn)(void *ptr); } XML_Memory_Handling_Suite; >Comment By: Karl Waclawek (kwaclaw) > Btw, why is XMLPARSEAPI undefined in xmlparse.c after > inclusion of expat.h? I had to uncomment this to make > it compile. Any ideas, Fred. Marsh? I would guess the author simply had a habit of being hygenic and didn't want unused defines to propagate out of the inclusing of expat.h. Gee, as I am writing this, you guys keep posting new stuff. > revision 1.21 > date: 2001/07/27 17:17:44; author: fdrake; state: Exp; > lines: +0 -4 > Remove all traces of the XMLCALLBACK macro -- there appears > to be no way to add __cdecl to a typedef of a function type > that MSVC does not complain about. Callback implementations > may need to add explicit __cdecl annotations in sources not > compiled with the C calling convention as the default. I haven't seen any warnings from my patch to expat.h (with the client code and MSVC 7.1). Is it possible that a compiler upgrade has the compiler issue? Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 17:47 Message: Logged In: YES user_id=3066 >From looking through the CVS logs, we did have an XMLCALLBACK macro at one point, used to mark the callback function typedefs with cdecl. This comment from xmlparse.c revision 1.21 is interesting: ---- revision 1.21 date: 2001/07/27 17:17:44; author: fdrake; state: Exp; lines: +0 -4 Remove all traces of the XMLCALLBACK macro -- there appears to be no way to add __cdecl to a typedef of a function type that MSVC does not complain about. Callback implementations may need to add explicit __cdecl annotations in sources not compiled with the C calling convention as the default. ---- XMLCALLBACK had been added (by me) in revision 1.19, which has this comment: ---- Make sure that XMLPARSEAPI specifies the calling convention when building under MSVC -- this is needed when using the pre-compiled DLL with projects built using a different calling convention. XMLPARSEAPI now takes the return type as a parameter and inserts annotations on both sides of the type to make sure the compiler is happy. A new macro, XMLCALLBACK, is used to perform similar annotation of the callback function types, which do not need the dllimport/dllexport annotations but do still need the __cdecl annotation. This closes SF bug #413653. ---- Sigh. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 17:29 Message: Logged In: YES user_id=3066 Karl, the #undef XMLPARSEAPI is a mystery. I wouldn't be surprised if it's related to the DLL import/export stuff; that may not be needed/desired in the implementation. I suspect that none of it is actually needed in the implementation when cdecl is the default, because explicitly stating cdecl and implicitly using it are probably considered equivalent (questionable practice). I'll bet we can get away with always declaring cdecl; this impacts expat.h as well, since there's a case when the calling convention isn't specified there. I suspect most of the callbacks are not performance sensitive; given that for start/end element we already do a fair bit of work and make many internal calls, there's little impact based on the calling convention for the callback. The only one I'd suspect is particularly sensitive is the characters callback, and there's no specific reason to think the calling convention is going to buy much. I'm inclined to think that everything that crosses the library boundary should be explicitly cdecl. As far as XMLMEMAPI goes, I've no idea how to say "the same calling convention as malloc()". We could define wrapper functions with some explicit convention, but that adds a layer of calls; that's painful. If you know how to pull this one off, I'm open to suggestions! ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-13 16:50 Message: Logged In: YES user_id=290026 OK, here is what I think: It is OK if you want to compiler with a different default calling convention. The fact that this is a problem with Expat is a bug IMO. We simply should fix xmlparse.c so that those declarations that are frozen in expat.h are also frozen in xmlparse.c. We should look at it as two sets of calling conventions: a) those used internally - they are basically frozen b) those used in the API For the second ones, we again have two groups: performance sensitive and non-sensitive. The callbacks fall into the performance sensitive group, the rest is not really performance sensitive (please correct me if I am missing some). I think we can freeze the non-performance sensitive API without much problems, but we should leave the callbacks open for optimization. So, if we concentrate on the callbacks, then it should work if we make xmlparse.c follow expat.h. I just patched xmlparse.c to use XMLPARSEAPI for all functions that have it in expat.h. Down to three errors when using another default calling convention. The errors now are involving the memory handler callbacks. We should probably define an XMLMEMAPI macro to freeze these as they should follow the calling convention used for the standard memory allocation functions. Btw, why is XMLPARSEAPI undefined in xmlparse.c after inclusion of expat.h? I had to uncomment this to make it compile. Any ideas, Fred. Marsh? Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 15:53 Message: Logged In: YES user_id=3066 Ok, I think I understand this one now. ;-) Thanks for the careful response. While I think that interaction between libraries and compiler switches will probably always be a source of frustration, we should be able to make this particular problem go away. I'll gladly support a solution which always forces both call directions to always use cdecl. Hopefully I'll be able to fix this in the next couple of days; I know I won't have time tonight, though. ;-( ---------------------------------------------------------------------- Comment By: Marsh Ray (marshray_bs) Date: 2003-10-13 15:43 Message: Logged In: YES user_id=883966 > How does it work when you build the library > with your calling convention? Expat.dll does not compile with not compile with a default calling convention other than __cdecl. It produces 65 errors, here's a sample: --------------------Configuration: expat - Win32 Debug-------------------- Compiling... xmlparse.c c:\expat-1.95.6\source\lib\xmlparse.c(629) : error C2373: 'XML_ParserCreate' : redefinition; different type modifiers c:\expat-1.95.6\source\lib\expat.h(194) : see declaration of 'XML_ParserCreate' These errors correspond 1:1 with the public API functions defined in expat.h. In expat.h the API functions are declared explicitly cdecl with the XMLPARSEAPI macro. Their definitions (in xmlparse.c for example) do not specify a calling convention, so they follow the default for the project. > If it works OK then we should not force any > calling convention on the callbacks but > simply document that the pre-built binaries > were compiled with cdecl as default. Currently, we're using a Perl script to patch 1.95.1 to allow it to be compiled as fastcall and thus be compatible with our code. We'd like to use the newer release, and for obvious reasons, we'd like to get on the official codebase. The "callforward" API functions define a specific calling convention, all we need is to have one specified on the callbacks. Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-11 16:10 Message: Logged In: YES user_id=290026 How does it work when you build the library with your calling convention? If it works OK then we should not force any calling convention on the callbacks but simply document that the pre-built binaries were compiled with cdecl as default. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=820946&group_id=10127 From noreply at sourceforge.net Tue Oct 14 19:31:25 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 14 19:31:31 2003 Subject: [Expat-bugs] [ expat-Patches-820946 ] expat.h not great for MSVC !cdecl deflt calling cnvntn Message-ID: Patches item #820946, was opened at 2003-10-09 19:06 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=820946&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 6 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: expat.h not great for MSVC !cdecl deflt calling cnvntn Initial Comment: OK, well the title I wanted was "expat.h doesn't work cleanly for MSVC with non-cdecl default calling convetion", but there were (reasonable, I guess) length limitations. In any case, if you have a project in MSVC that has its default calling convention set to something other than cdecl (such as stdcall or fastcall), the prototypes for the handler functions don't communicate that the library is compiled to assume cdecl. Things will still compile fine, however odd behavior occurs at runtime (for example, my start element handler was called 5 times with the same name and then the thread crashed). If your callback funcitons are then explicitly declared cdecl (as they should be) then you have to use casts to allow you to assign the address of your cdecl handler functions to the function pointers that the compiler defaults to the different convention. I don't suppose many people bother to change the default calling convention of their projects, but I have seen fastcall give a 5% boost. XML parsing is not a significant part of our apps exection time, so it's not worth recompiling expat to fastcall. It would be nice if it worked out of the box for us. I've supplied a patch, that defines a macro XMLCALLBACK for callbacks, much like the XMLPARSEAPI macro is defined for API functions. I've tested it with MSVC 7.1 projects that default to both stdcall and fastcall. Because the preprocessor tests are set up like the ones for the XMLPARSEAPI macro, I don't think it should affect any non-MSVC compilers. Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-14 19:31 Message: Logged In: YES user_id=290026 Fine with me, Fred. ---------------------------------------------------------------------- Comment By: Marsh Ray (marshray_bs) Date: 2003-10-14 17:58 Message: Logged In: YES user_id=883966 >Comment By: Fred L. Drake, Jr. (fdrake) > - add a macro, XMLCALL, that expands to whatever > is needed to nail down the calling convention > for all calls across the library boundary > - add the XMLCALLBACK macro, defined to use XMLCALL > - add XMLCALL to XMLPARSEAPI > - modify all example code to include XMLCALL for > definitions of callbacks Sounds good to me. > - document, document, document! If the changes are made as described above, it won't affect any previously functioning code. All that needs to be documented is the new functionality. A callback function defined in a module with a default calling convention other than cdecl will now need to explicitly specify the calling convention that is expected by expat (typcially cdecl). For example: void myStartElementHandler( void *userData, const XML_Char *name, const XML_Char **atts); Becomes: void __cdecl myStartElementHandler( void *userData, const XML_Char *name, const XML_Char **atts); ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-14 17:35 Message: Logged In: YES user_id=3066 Ok, here's what I propose doing: - add a macro, XMLCALL, that expands to whatever is needed to nail down the calling convention for all calls across the library boundary - add the XMLCALLBACK macro, defined to use XMLCALL - add XMLCALL to XMLPARSEAPI - modify all example code to include XMLCALL for definitions of callbacks - document, document, document! Any of these can be overridden before including expat.h, for those who are adventurous. For those who stick to their compiler defaults, there should be no perceivable change. Once done, I'll release another snapshot, with emails sent to relevant lists (expat-discuss, Python's xml-sig; feel free to suggest others, or just pass the word when the snapshot's up). I've started the code changes based on this patch, but I've only tested using GCC 3.2.2 on RedHat 9 so far. Comments? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-13 19:29 Message: Logged In: YES user_id=290026 I am a little late with my replies. So, summarizing I would say: Let's force cdecl on all API calls, call-back or not. About performance: Considering how much work Expat does behind each call-back the calling convention will likely not have a measurable impact. I agree with Fred here. Also, looking back at our own testing with internal calling conventions, cdecl came out ahead. In my opinion, and I think in Fred's opinion too, this was because cdecl allows optimizations for call "clusters" as the caller manages the stack, not the callee. I really don't think fastcall will give any measurable advantage, even for the call-backs. So, using this patch, what else is there to do? Should we be concerned with memory handler calls and whatever else will have an undefined calling convention? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 18:06 Message: Logged In: YES user_id=3066 Marsh: > By 'frozen' I assume you mean using the default calling > conventions specified at compile time? Yes. > I haven't seen any warnings from my patch to expat.h (with > the client code and MSVC 7.1). Is it possible that a > compiler upgrade has the compiler issue? I would have been using MSVC 6, since that's the only MSVC I've had for years. Not sure what service pack, though. Also, I'm no Windows expert, mostly only using MSVC in a mindless, repetitive "did that break something" mode. I'll play with your patch with actual compilers, though, and see how well I survive. ;-) ---------------------------------------------------------------------- Comment By: Marsh Ray (marshray_bs) Date: 2003-10-13 17:54 Message: Logged In: YES user_id=883966 >Comment By: Karl Waclawek (kwaclaw) >Date: 2003-10-13 16:50 > It is OK if you want to compiler with > a different default calling convention. > The fact that this is a problem with > Expat is a bug IMO. > We simply should fix xmlparse.c so that > those declarations that are frozen in > expat.h are also frozen in xmlparse.c. Agreed, although this is not exactly the problem I was intending to address. We have both cdecl and fastcall default calling conventions being used in our processes. Currently, we're using multiple expat.dll's to handle this. It would be nice to be able to use the same expat.dll everywhere to reduce build-time complexity and run-time footprint. Ridding our code of Xerces is now perhaps another matter . . . :) > We should look at it as two sets of calling conventions: > a) those used internally - they are basically frozen By 'frozen' I assume you mean using the default calling conventions specified at compile time? > b) those used in the API > For the second ones, we again have two groups: > performance sensitive and non-sensitive. > The callbacks fall into the performance > sensitive group, the rest is not really > performance sensitive (please correct mefreeze the > if I am missing some). I think we can non-performancemuch > problems, sensitive API without but we should leave the > callbacks open for optimization. When XML becomes a performance bottleneck, we would typically change our architecture to use faster binary structures. Therefore the ~5% gain in XML parsing we might get by compiling Expat as fastcall is not really significant. Our main goal is to get everyone on the same .dll. > So, if we concentrate on the callbacks, then it should work > if we make xmlparse.c follow expat.h. Sure, if you want to require people to compile a different version of expat.dll for every default calling convention in use. I think the solution for people who want to compile expat as fastcall (if that person exists) would be to allow them to set a #define (in their client code) to specify the calling convention that their custom-compiled dll wants. For example: #define XML_EXPAT_USES_FASTCALL 1 /* or _STDCALL, _CDECL is default */ #include "expat.h" /* be sure to link with expat_fastcall.lib and .dll */ Again, this ability is not particularly useful to us. > I just patched xmlparse.c to use XMLPARSEAPI for all > functions that have it in expat.h. Down to three errors > when using another default calling convention. > The errors now are involving the memory handler callbacks. > We should probably define an XMLMEMAPI macro to freeze > these as they should follow the calling convention used for > the standard memory allocation functions. >Comment By: Fred L. Drake, Jr. (fdrake) > As far as XMLMEMAPI goes, I've no idea how to say "the same > calling convention as malloc()". We could define wrapper > functions with some explicit convention, but that adds a > layer of calls; that's painful. If you know how to pull > this one off, I'm open to suggestions! In my Microsoft headers, I find: _CRTIMP void * __cdecl malloc(size_t); Furthermore, there is not a different C runtime library for each default calling convention. So, it's probably safe to assume malloc is going to be cdecl. Stating that explicitly in the definiton of XML_Memory_Handling_Suite should work, although it looks like there'll be a few places to change in xmlparse.c. #ifndef XMLCDECL #if defined(_MSC_EXTENSIONS) && !defined(__BEOS__) && !defined(__CYGWIN__) #define XMLCDECL __cdecl #else #define XMLCDECL #endif #endif /* not defined XMLCDECL*/ typedef struct { void *(XMLCDECL *malloc_fcn)(size_t size); void *(XMLCDECL *realloc_fcn)(void *ptr, size_t size); void (XMLCDECL *free_fcn)(void *ptr); } XML_Memory_Handling_Suite; >Comment By: Karl Waclawek (kwaclaw) > Btw, why is XMLPARSEAPI undefined in xmlparse.c after > inclusion of expat.h? I had to uncomment this to make > it compile. Any ideas, Fred. Marsh? I would guess the author simply had a habit of being hygenic and didn't want unused defines to propagate out of the inclusing of expat.h. Gee, as I am writing this, you guys keep posting new stuff. > revision 1.21 > date: 2001/07/27 17:17:44; author: fdrake; state: Exp; > lines: +0 -4 > Remove all traces of the XMLCALLBACK macro -- there appears > to be no way to add __cdecl to a typedef of a function type > that MSVC does not complain about. Callback implementations > may need to add explicit __cdecl annotations in sources not > compiled with the C calling convention as the default. I haven't seen any warnings from my patch to expat.h (with the client code and MSVC 7.1). Is it possible that a compiler upgrade has the compiler issue? Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 17:47 Message: Logged In: YES user_id=3066 >From looking through the CVS logs, we did have an XMLCALLBACK macro at one point, used to mark the callback function typedefs with cdecl. This comment from xmlparse.c revision 1.21 is interesting: ---- revision 1.21 date: 2001/07/27 17:17:44; author: fdrake; state: Exp; lines: +0 -4 Remove all traces of the XMLCALLBACK macro -- there appears to be no way to add __cdecl to a typedef of a function type that MSVC does not complain about. Callback implementations may need to add explicit __cdecl annotations in sources not compiled with the C calling convention as the default. ---- XMLCALLBACK had been added (by me) in revision 1.19, which has this comment: ---- Make sure that XMLPARSEAPI specifies the calling convention when building under MSVC -- this is needed when using the pre-compiled DLL with projects built using a different calling convention. XMLPARSEAPI now takes the return type as a parameter and inserts annotations on both sides of the type to make sure the compiler is happy. A new macro, XMLCALLBACK, is used to perform similar annotation of the callback function types, which do not need the dllimport/dllexport annotations but do still need the __cdecl annotation. This closes SF bug #413653. ---- Sigh. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 17:29 Message: Logged In: YES user_id=3066 Karl, the #undef XMLPARSEAPI is a mystery. I wouldn't be surprised if it's related to the DLL import/export stuff; that may not be needed/desired in the implementation. I suspect that none of it is actually needed in the implementation when cdecl is the default, because explicitly stating cdecl and implicitly using it are probably considered equivalent (questionable practice). I'll bet we can get away with always declaring cdecl; this impacts expat.h as well, since there's a case when the calling convention isn't specified there. I suspect most of the callbacks are not performance sensitive; given that for start/end element we already do a fair bit of work and make many internal calls, there's little impact based on the calling convention for the callback. The only one I'd suspect is particularly sensitive is the characters callback, and there's no specific reason to think the calling convention is going to buy much. I'm inclined to think that everything that crosses the library boundary should be explicitly cdecl. As far as XMLMEMAPI goes, I've no idea how to say "the same calling convention as malloc()". We could define wrapper functions with some explicit convention, but that adds a layer of calls; that's painful. If you know how to pull this one off, I'm open to suggestions! ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-13 16:50 Message: Logged In: YES user_id=290026 OK, here is what I think: It is OK if you want to compiler with a different default calling convention. The fact that this is a problem with Expat is a bug IMO. We simply should fix xmlparse.c so that those declarations that are frozen in expat.h are also frozen in xmlparse.c. We should look at it as two sets of calling conventions: a) those used internally - they are basically frozen b) those used in the API For the second ones, we again have two groups: performance sensitive and non-sensitive. The callbacks fall into the performance sensitive group, the rest is not really performance sensitive (please correct me if I am missing some). I think we can freeze the non-performance sensitive API without much problems, but we should leave the callbacks open for optimization. So, if we concentrate on the callbacks, then it should work if we make xmlparse.c follow expat.h. I just patched xmlparse.c to use XMLPARSEAPI for all functions that have it in expat.h. Down to three errors when using another default calling convention. The errors now are involving the memory handler callbacks. We should probably define an XMLMEMAPI macro to freeze these as they should follow the calling convention used for the standard memory allocation functions. Btw, why is XMLPARSEAPI undefined in xmlparse.c after inclusion of expat.h? I had to uncomment this to make it compile. Any ideas, Fred. Marsh? Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 15:53 Message: Logged In: YES user_id=3066 Ok, I think I understand this one now. ;-) Thanks for the careful response. While I think that interaction between libraries and compiler switches will probably always be a source of frustration, we should be able to make this particular problem go away. I'll gladly support a solution which always forces both call directions to always use cdecl. Hopefully I'll be able to fix this in the next couple of days; I know I won't have time tonight, though. ;-( ---------------------------------------------------------------------- Comment By: Marsh Ray (marshray_bs) Date: 2003-10-13 15:43 Message: Logged In: YES user_id=883966 > How does it work when you build the library > with your calling convention? Expat.dll does not compile with not compile with a default calling convention other than __cdecl. It produces 65 errors, here's a sample: --------------------Configuration: expat - Win32 Debug-------------------- Compiling... xmlparse.c c:\expat-1.95.6\source\lib\xmlparse.c(629) : error C2373: 'XML_ParserCreate' : redefinition; different type modifiers c:\expat-1.95.6\source\lib\expat.h(194) : see declaration of 'XML_ParserCreate' These errors correspond 1:1 with the public API functions defined in expat.h. In expat.h the API functions are declared explicitly cdecl with the XMLPARSEAPI macro. Their definitions (in xmlparse.c for example) do not specify a calling convention, so they follow the default for the project. > If it works OK then we should not force any > calling convention on the callbacks but > simply document that the pre-built binaries > were compiled with cdecl as default. Currently, we're using a Perl script to patch 1.95.1 to allow it to be compiled as fastcall and thus be compatible with our code. We'd like to use the newer release, and for obvious reasons, we'd like to get on the official codebase. The "callforward" API functions define a specific calling convention, all we need is to have one specified on the callbacks. Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-11 16:10 Message: Logged In: YES user_id=290026 How does it work when you build the library with your calling convention? If it works OK then we should not force any calling convention on the callbacks but simply document that the pre-built binaries were compiled with cdecl as default. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=820946&group_id=10127 From noreply at sourceforge.net Wed Oct 15 00:48:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 15 00:48:41 2003 Subject: [Expat-bugs] [ expat-Patches-820946 ] expat.h not great for MSVC !cdecl deflt calling cnvntn Message-ID: Patches item #820946, was opened at 2003-10-09 19:06 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=820946&group_id=10127 Category: None Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: expat.h not great for MSVC !cdecl deflt calling cnvntn Initial Comment: OK, well the title I wanted was "expat.h doesn't work cleanly for MSVC with non-cdecl default calling convetion", but there were (reasonable, I guess) length limitations. In any case, if you have a project in MSVC that has its default calling convention set to something other than cdecl (such as stdcall or fastcall), the prototypes for the handler functions don't communicate that the library is compiled to assume cdecl. Things will still compile fine, however odd behavior occurs at runtime (for example, my start element handler was called 5 times with the same name and then the thread crashed). If your callback funcitons are then explicitly declared cdecl (as they should be) then you have to use casts to allow you to assign the address of your cdecl handler functions to the function pointers that the compiler defaults to the different convention. I don't suppose many people bother to change the default calling convention of their projects, but I have seen fastcall give a 5% boost. XML parsing is not a significant part of our apps exection time, so it's not worth recompiling expat to fastcall. It would be nice if it worked out of the box for us. I've supplied a patch, that defines a macro XMLCALLBACK for callbacks, much like the XMLPARSEAPI macro is defined for API functions. I've tested it with MSVC 7.1 projects that default to both stdcall and fastcall. Because the preprocessor tests are set up like the ones for the XMLPARSEAPI macro, I don't think it should affect any non-MSVC compilers. Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-15 00:48 Message: Logged In: YES user_id=3066 Assigned to myself; I think I'm almost done with the code, and have started on the documentation. Bumped priority to reflect intention to include this in 1.95.7. At least for some Unix platforms, which use standard headers that assume cdecl calling convention as the default, Expat itself must be compiled with cdecl as the default. (Otherwise malloc() & friends are not cdecl, and specifying cdecl in the mem functions causes type errors at compile time.) This should not affect code outside of Expat itself. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-14 19:31 Message: Logged In: YES user_id=290026 Fine with me, Fred. ---------------------------------------------------------------------- Comment By: Marsh Ray (marshray_bs) Date: 2003-10-14 17:58 Message: Logged In: YES user_id=883966 >Comment By: Fred L. Drake, Jr. (fdrake) > - add a macro, XMLCALL, that expands to whatever > is needed to nail down the calling convention > for all calls across the library boundary > - add the XMLCALLBACK macro, defined to use XMLCALL > - add XMLCALL to XMLPARSEAPI > - modify all example code to include XMLCALL for > definitions of callbacks Sounds good to me. > - document, document, document! If the changes are made as described above, it won't affect any previously functioning code. All that needs to be documented is the new functionality. A callback function defined in a module with a default calling convention other than cdecl will now need to explicitly specify the calling convention that is expected by expat (typcially cdecl). For example: void myStartElementHandler( void *userData, const XML_Char *name, const XML_Char **atts); Becomes: void __cdecl myStartElementHandler( void *userData, const XML_Char *name, const XML_Char **atts); ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-14 17:35 Message: Logged In: YES user_id=3066 Ok, here's what I propose doing: - add a macro, XMLCALL, that expands to whatever is needed to nail down the calling convention for all calls across the library boundary - add the XMLCALLBACK macro, defined to use XMLCALL - add XMLCALL to XMLPARSEAPI - modify all example code to include XMLCALL for definitions of callbacks - document, document, document! Any of these can be overridden before including expat.h, for those who are adventurous. For those who stick to their compiler defaults, there should be no perceivable change. Once done, I'll release another snapshot, with emails sent to relevant lists (expat-discuss, Python's xml-sig; feel free to suggest others, or just pass the word when the snapshot's up). I've started the code changes based on this patch, but I've only tested using GCC 3.2.2 on RedHat 9 so far. Comments? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-13 19:29 Message: Logged In: YES user_id=290026 I am a little late with my replies. So, summarizing I would say: Let's force cdecl on all API calls, call-back or not. About performance: Considering how much work Expat does behind each call-back the calling convention will likely not have a measurable impact. I agree with Fred here. Also, looking back at our own testing with internal calling conventions, cdecl came out ahead. In my opinion, and I think in Fred's opinion too, this was because cdecl allows optimizations for call "clusters" as the caller manages the stack, not the callee. I really don't think fastcall will give any measurable advantage, even for the call-backs. So, using this patch, what else is there to do? Should we be concerned with memory handler calls and whatever else will have an undefined calling convention? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 18:06 Message: Logged In: YES user_id=3066 Marsh: > By 'frozen' I assume you mean using the default calling > conventions specified at compile time? Yes. > I haven't seen any warnings from my patch to expat.h (with > the client code and MSVC 7.1). Is it possible that a > compiler upgrade has the compiler issue? I would have been using MSVC 6, since that's the only MSVC I've had for years. Not sure what service pack, though. Also, I'm no Windows expert, mostly only using MSVC in a mindless, repetitive "did that break something" mode. I'll play with your patch with actual compilers, though, and see how well I survive. ;-) ---------------------------------------------------------------------- Comment By: Marsh Ray (marshray_bs) Date: 2003-10-13 17:54 Message: Logged In: YES user_id=883966 >Comment By: Karl Waclawek (kwaclaw) >Date: 2003-10-13 16:50 > It is OK if you want to compiler with > a different default calling convention. > The fact that this is a problem with > Expat is a bug IMO. > We simply should fix xmlparse.c so that > those declarations that are frozen in > expat.h are also frozen in xmlparse.c. Agreed, although this is not exactly the problem I was intending to address. We have both cdecl and fastcall default calling conventions being used in our processes. Currently, we're using multiple expat.dll's to handle this. It would be nice to be able to use the same expat.dll everywhere to reduce build-time complexity and run-time footprint. Ridding our code of Xerces is now perhaps another matter . . . :) > We should look at it as two sets of calling conventions: > a) those used internally - they are basically frozen By 'frozen' I assume you mean using the default calling conventions specified at compile time? > b) those used in the API > For the second ones, we again have two groups: > performance sensitive and non-sensitive. > The callbacks fall into the performance > sensitive group, the rest is not really > performance sensitive (please correct mefreeze the > if I am missing some). I think we can non-performancemuch > problems, sensitive API without but we should leave the > callbacks open for optimization. When XML becomes a performance bottleneck, we would typically change our architecture to use faster binary structures. Therefore the ~5% gain in XML parsing we might get by compiling Expat as fastcall is not really significant. Our main goal is to get everyone on the same .dll. > So, if we concentrate on the callbacks, then it should work > if we make xmlparse.c follow expat.h. Sure, if you want to require people to compile a different version of expat.dll for every default calling convention in use. I think the solution for people who want to compile expat as fastcall (if that person exists) would be to allow them to set a #define (in their client code) to specify the calling convention that their custom-compiled dll wants. For example: #define XML_EXPAT_USES_FASTCALL 1 /* or _STDCALL, _CDECL is default */ #include "expat.h" /* be sure to link with expat_fastcall.lib and .dll */ Again, this ability is not particularly useful to us. > I just patched xmlparse.c to use XMLPARSEAPI for all > functions that have it in expat.h. Down to three errors > when using another default calling convention. > The errors now are involving the memory handler callbacks. > We should probably define an XMLMEMAPI macro to freeze > these as they should follow the calling convention used for > the standard memory allocation functions. >Comment By: Fred L. Drake, Jr. (fdrake) > As far as XMLMEMAPI goes, I've no idea how to say "the same > calling convention as malloc()". We could define wrapper > functions with some explicit convention, but that adds a > layer of calls; that's painful. If you know how to pull > this one off, I'm open to suggestions! In my Microsoft headers, I find: _CRTIMP void * __cdecl malloc(size_t); Furthermore, there is not a different C runtime library for each default calling convention. So, it's probably safe to assume malloc is going to be cdecl. Stating that explicitly in the definiton of XML_Memory_Handling_Suite should work, although it looks like there'll be a few places to change in xmlparse.c. #ifndef XMLCDECL #if defined(_MSC_EXTENSIONS) && !defined(__BEOS__) && !defined(__CYGWIN__) #define XMLCDECL __cdecl #else #define XMLCDECL #endif #endif /* not defined XMLCDECL*/ typedef struct { void *(XMLCDECL *malloc_fcn)(size_t size); void *(XMLCDECL *realloc_fcn)(void *ptr, size_t size); void (XMLCDECL *free_fcn)(void *ptr); } XML_Memory_Handling_Suite; >Comment By: Karl Waclawek (kwaclaw) > Btw, why is XMLPARSEAPI undefined in xmlparse.c after > inclusion of expat.h? I had to uncomment this to make > it compile. Any ideas, Fred. Marsh? I would guess the author simply had a habit of being hygenic and didn't want unused defines to propagate out of the inclusing of expat.h. Gee, as I am writing this, you guys keep posting new stuff. > revision 1.21 > date: 2001/07/27 17:17:44; author: fdrake; state: Exp; > lines: +0 -4 > Remove all traces of the XMLCALLBACK macro -- there appears > to be no way to add __cdecl to a typedef of a function type > that MSVC does not complain about. Callback implementations > may need to add explicit __cdecl annotations in sources not > compiled with the C calling convention as the default. I haven't seen any warnings from my patch to expat.h (with the client code and MSVC 7.1). Is it possible that a compiler upgrade has the compiler issue? Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 17:47 Message: Logged In: YES user_id=3066 >From looking through the CVS logs, we did have an XMLCALLBACK macro at one point, used to mark the callback function typedefs with cdecl. This comment from xmlparse.c revision 1.21 is interesting: ---- revision 1.21 date: 2001/07/27 17:17:44; author: fdrake; state: Exp; lines: +0 -4 Remove all traces of the XMLCALLBACK macro -- there appears to be no way to add __cdecl to a typedef of a function type that MSVC does not complain about. Callback implementations may need to add explicit __cdecl annotations in sources not compiled with the C calling convention as the default. ---- XMLCALLBACK had been added (by me) in revision 1.19, which has this comment: ---- Make sure that XMLPARSEAPI specifies the calling convention when building under MSVC -- this is needed when using the pre-compiled DLL with projects built using a different calling convention. XMLPARSEAPI now takes the return type as a parameter and inserts annotations on both sides of the type to make sure the compiler is happy. A new macro, XMLCALLBACK, is used to perform similar annotation of the callback function types, which do not need the dllimport/dllexport annotations but do still need the __cdecl annotation. This closes SF bug #413653. ---- Sigh. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 17:29 Message: Logged In: YES user_id=3066 Karl, the #undef XMLPARSEAPI is a mystery. I wouldn't be surprised if it's related to the DLL import/export stuff; that may not be needed/desired in the implementation. I suspect that none of it is actually needed in the implementation when cdecl is the default, because explicitly stating cdecl and implicitly using it are probably considered equivalent (questionable practice). I'll bet we can get away with always declaring cdecl; this impacts expat.h as well, since there's a case when the calling convention isn't specified there. I suspect most of the callbacks are not performance sensitive; given that for start/end element we already do a fair bit of work and make many internal calls, there's little impact based on the calling convention for the callback. The only one I'd suspect is particularly sensitive is the characters callback, and there's no specific reason to think the calling convention is going to buy much. I'm inclined to think that everything that crosses the library boundary should be explicitly cdecl. As far as XMLMEMAPI goes, I've no idea how to say "the same calling convention as malloc()". We could define wrapper functions with some explicit convention, but that adds a layer of calls; that's painful. If you know how to pull this one off, I'm open to suggestions! ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-13 16:50 Message: Logged In: YES user_id=290026 OK, here is what I think: It is OK if you want to compiler with a different default calling convention. The fact that this is a problem with Expat is a bug IMO. We simply should fix xmlparse.c so that those declarations that are frozen in expat.h are also frozen in xmlparse.c. We should look at it as two sets of calling conventions: a) those used internally - they are basically frozen b) those used in the API For the second ones, we again have two groups: performance sensitive and non-sensitive. The callbacks fall into the performance sensitive group, the rest is not really performance sensitive (please correct me if I am missing some). I think we can freeze the non-performance sensitive API without much problems, but we should leave the callbacks open for optimization. So, if we concentrate on the callbacks, then it should work if we make xmlparse.c follow expat.h. I just patched xmlparse.c to use XMLPARSEAPI for all functions that have it in expat.h. Down to three errors when using another default calling convention. The errors now are involving the memory handler callbacks. We should probably define an XMLMEMAPI macro to freeze these as they should follow the calling convention used for the standard memory allocation functions. Btw, why is XMLPARSEAPI undefined in xmlparse.c after inclusion of expat.h? I had to uncomment this to make it compile. Any ideas, Fred. Marsh? Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 15:53 Message: Logged In: YES user_id=3066 Ok, I think I understand this one now. ;-) Thanks for the careful response. While I think that interaction between libraries and compiler switches will probably always be a source of frustration, we should be able to make this particular problem go away. I'll gladly support a solution which always forces both call directions to always use cdecl. Hopefully I'll be able to fix this in the next couple of days; I know I won't have time tonight, though. ;-( ---------------------------------------------------------------------- Comment By: Marsh Ray (marshray_bs) Date: 2003-10-13 15:43 Message: Logged In: YES user_id=883966 > How does it work when you build the library > with your calling convention? Expat.dll does not compile with not compile with a default calling convention other than __cdecl. It produces 65 errors, here's a sample: --------------------Configuration: expat - Win32 Debug-------------------- Compiling... xmlparse.c c:\expat-1.95.6\source\lib\xmlparse.c(629) : error C2373: 'XML_ParserCreate' : redefinition; different type modifiers c:\expat-1.95.6\source\lib\expat.h(194) : see declaration of 'XML_ParserCreate' These errors correspond 1:1 with the public API functions defined in expat.h. In expat.h the API functions are declared explicitly cdecl with the XMLPARSEAPI macro. Their definitions (in xmlparse.c for example) do not specify a calling convention, so they follow the default for the project. > If it works OK then we should not force any > calling convention on the callbacks but > simply document that the pre-built binaries > were compiled with cdecl as default. Currently, we're using a Perl script to patch 1.95.1 to allow it to be compiled as fastcall and thus be compatible with our code. We'd like to use the newer release, and for obvious reasons, we'd like to get on the official codebase. The "callforward" API functions define a specific calling convention, all we need is to have one specified on the callbacks. Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-11 16:10 Message: Logged In: YES user_id=290026 How does it work when you build the library with your calling convention? If it works OK then we should not force any calling convention on the callbacks but simply document that the pre-built binaries were compiled with cdecl as default. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=820946&group_id=10127 From noreply at sourceforge.net Wed Oct 15 11:10:31 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 15 11:10:39 2003 Subject: [Expat-bugs] [ expat-Patches-820946 ] expat.h not great for MSVC !cdecl deflt calling cnvntn Message-ID: Patches item #820946, was opened at 2003-10-09 19:06 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=820946&group_id=10127 Category: None Group: None Status: Open >Resolution: Accepted Priority: 7 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: expat.h not great for MSVC !cdecl deflt calling cnvntn Initial Comment: OK, well the title I wanted was "expat.h doesn't work cleanly for MSVC with non-cdecl default calling convetion", but there were (reasonable, I guess) length limitations. In any case, if you have a project in MSVC that has its default calling convention set to something other than cdecl (such as stdcall or fastcall), the prototypes for the handler functions don't communicate that the library is compiled to assume cdecl. Things will still compile fine, however odd behavior occurs at runtime (for example, my start element handler was called 5 times with the same name and then the thread crashed). If your callback funcitons are then explicitly declared cdecl (as they should be) then you have to use casts to allow you to assign the address of your cdecl handler functions to the function pointers that the compiler defaults to the different convention. I don't suppose many people bother to change the default calling convention of their projects, but I have seen fastcall give a 5% boost. XML parsing is not a significant part of our apps exection time, so it's not worth recompiling expat to fastcall. It would be nice if it worked out of the box for us. I've supplied a patch, that defines a macro XMLCALLBACK for callbacks, much like the XMLPARSEAPI macro is defined for API functions. I've tested it with MSVC 7.1 projects that default to both stdcall and fastcall. Because the preprocessor tests are set up like the ones for the XMLPARSEAPI macro, I don't think it should affect any non-MSVC compilers. Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-15 11:10 Message: Logged In: YES user_id=3066 After working on this some more and trying to explain the macros, I'm going to revise the proposed change a little. - add a macro, XMLCALL, that expands to whatever is needed to nail down the calling convention for all calls across the library boundary - another new macro, XMLIMPORT, defined to be whatever magic is needed to mark an entry point as imported from a dynamically loaded module (.dll, .so, .sl, whatever) - use XMLCALL and XMLIMPORT to define XMLPARSEAPI - modify all example code to include XMLCALL for definitions of callbacks - modify callback typedefs to use XMLCALL - document, document, document! This proves just a bit simpler in the mechanics of it all, and keeps the layers of magic down. Since the XMLCALLBACK really only adds XMLCALL and an asterisk, it can be completely dropped since XMLCALL is available. Marsh: Yes, I agree that no changes are needed for existing, working code. These changes are entirely to benefit people who want to use a default calling convention other than cdecl. No need for followup comments; watch for commits and a new snapshot later today (possibly *much* later). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-15 00:48 Message: Logged In: YES user_id=3066 Assigned to myself; I think I'm almost done with the code, and have started on the documentation. Bumped priority to reflect intention to include this in 1.95.7. At least for some Unix platforms, which use standard headers that assume cdecl calling convention as the default, Expat itself must be compiled with cdecl as the default. (Otherwise malloc() & friends are not cdecl, and specifying cdecl in the mem functions causes type errors at compile time.) This should not affect code outside of Expat itself. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-14 19:31 Message: Logged In: YES user_id=290026 Fine with me, Fred. ---------------------------------------------------------------------- Comment By: Marsh Ray (marshray_bs) Date: 2003-10-14 17:58 Message: Logged In: YES user_id=883966 >Comment By: Fred L. Drake, Jr. (fdrake) > - add a macro, XMLCALL, that expands to whatever > is needed to nail down the calling convention > for all calls across the library boundary > - add the XMLCALLBACK macro, defined to use XMLCALL > - add XMLCALL to XMLPARSEAPI > - modify all example code to include XMLCALL for > definitions of callbacks Sounds good to me. > - document, document, document! If the changes are made as described above, it won't affect any previously functioning code. All that needs to be documented is the new functionality. A callback function defined in a module with a default calling convention other than cdecl will now need to explicitly specify the calling convention that is expected by expat (typcially cdecl). For example: void myStartElementHandler( void *userData, const XML_Char *name, const XML_Char **atts); Becomes: void __cdecl myStartElementHandler( void *userData, const XML_Char *name, const XML_Char **atts); ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-14 17:35 Message: Logged In: YES user_id=3066 Ok, here's what I propose doing: - add a macro, XMLCALL, that expands to whatever is needed to nail down the calling convention for all calls across the library boundary - add the XMLCALLBACK macro, defined to use XMLCALL - add XMLCALL to XMLPARSEAPI - modify all example code to include XMLCALL for definitions of callbacks - document, document, document! Any of these can be overridden before including expat.h, for those who are adventurous. For those who stick to their compiler defaults, there should be no perceivable change. Once done, I'll release another snapshot, with emails sent to relevant lists (expat-discuss, Python's xml-sig; feel free to suggest others, or just pass the word when the snapshot's up). I've started the code changes based on this patch, but I've only tested using GCC 3.2.2 on RedHat 9 so far. Comments? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-13 19:29 Message: Logged In: YES user_id=290026 I am a little late with my replies. So, summarizing I would say: Let's force cdecl on all API calls, call-back or not. About performance: Considering how much work Expat does behind each call-back the calling convention will likely not have a measurable impact. I agree with Fred here. Also, looking back at our own testing with internal calling conventions, cdecl came out ahead. In my opinion, and I think in Fred's opinion too, this was because cdecl allows optimizations for call "clusters" as the caller manages the stack, not the callee. I really don't think fastcall will give any measurable advantage, even for the call-backs. So, using this patch, what else is there to do? Should we be concerned with memory handler calls and whatever else will have an undefined calling convention? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 18:06 Message: Logged In: YES user_id=3066 Marsh: > By 'frozen' I assume you mean using the default calling > conventions specified at compile time? Yes. > I haven't seen any warnings from my patch to expat.h (with > the client code and MSVC 7.1). Is it possible that a > compiler upgrade has the compiler issue? I would have been using MSVC 6, since that's the only MSVC I've had for years. Not sure what service pack, though. Also, I'm no Windows expert, mostly only using MSVC in a mindless, repetitive "did that break something" mode. I'll play with your patch with actual compilers, though, and see how well I survive. ;-) ---------------------------------------------------------------------- Comment By: Marsh Ray (marshray_bs) Date: 2003-10-13 17:54 Message: Logged In: YES user_id=883966 >Comment By: Karl Waclawek (kwaclaw) >Date: 2003-10-13 16:50 > It is OK if you want to compiler with > a different default calling convention. > The fact that this is a problem with > Expat is a bug IMO. > We simply should fix xmlparse.c so that > those declarations that are frozen in > expat.h are also frozen in xmlparse.c. Agreed, although this is not exactly the problem I was intending to address. We have both cdecl and fastcall default calling conventions being used in our processes. Currently, we're using multiple expat.dll's to handle this. It would be nice to be able to use the same expat.dll everywhere to reduce build-time complexity and run-time footprint. Ridding our code of Xerces is now perhaps another matter . . . :) > We should look at it as two sets of calling conventions: > a) those used internally - they are basically frozen By 'frozen' I assume you mean using the default calling conventions specified at compile time? > b) those used in the API > For the second ones, we again have two groups: > performance sensitive and non-sensitive. > The callbacks fall into the performance > sensitive group, the rest is not really > performance sensitive (please correct mefreeze the > if I am missing some). I think we can non-performancemuch > problems, sensitive API without but we should leave the > callbacks open for optimization. When XML becomes a performance bottleneck, we would typically change our architecture to use faster binary structures. Therefore the ~5% gain in XML parsing we might get by compiling Expat as fastcall is not really significant. Our main goal is to get everyone on the same .dll. > So, if we concentrate on the callbacks, then it should work > if we make xmlparse.c follow expat.h. Sure, if you want to require people to compile a different version of expat.dll for every default calling convention in use. I think the solution for people who want to compile expat as fastcall (if that person exists) would be to allow them to set a #define (in their client code) to specify the calling convention that their custom-compiled dll wants. For example: #define XML_EXPAT_USES_FASTCALL 1 /* or _STDCALL, _CDECL is default */ #include "expat.h" /* be sure to link with expat_fastcall.lib and .dll */ Again, this ability is not particularly useful to us. > I just patched xmlparse.c to use XMLPARSEAPI for all > functions that have it in expat.h. Down to three errors > when using another default calling convention. > The errors now are involving the memory handler callbacks. > We should probably define an XMLMEMAPI macro to freeze > these as they should follow the calling convention used for > the standard memory allocation functions. >Comment By: Fred L. Drake, Jr. (fdrake) > As far as XMLMEMAPI goes, I've no idea how to say "the same > calling convention as malloc()". We could define wrapper > functions with some explicit convention, but that adds a > layer of calls; that's painful. If you know how to pull > this one off, I'm open to suggestions! In my Microsoft headers, I find: _CRTIMP void * __cdecl malloc(size_t); Furthermore, there is not a different C runtime library for each default calling convention. So, it's probably safe to assume malloc is going to be cdecl. Stating that explicitly in the definiton of XML_Memory_Handling_Suite should work, although it looks like there'll be a few places to change in xmlparse.c. #ifndef XMLCDECL #if defined(_MSC_EXTENSIONS) && !defined(__BEOS__) && !defined(__CYGWIN__) #define XMLCDECL __cdecl #else #define XMLCDECL #endif #endif /* not defined XMLCDECL*/ typedef struct { void *(XMLCDECL *malloc_fcn)(size_t size); void *(XMLCDECL *realloc_fcn)(void *ptr, size_t size); void (XMLCDECL *free_fcn)(void *ptr); } XML_Memory_Handling_Suite; >Comment By: Karl Waclawek (kwaclaw) > Btw, why is XMLPARSEAPI undefined in xmlparse.c after > inclusion of expat.h? I had to uncomment this to make > it compile. Any ideas, Fred. Marsh? I would guess the author simply had a habit of being hygenic and didn't want unused defines to propagate out of the inclusing of expat.h. Gee, as I am writing this, you guys keep posting new stuff. > revision 1.21 > date: 2001/07/27 17:17:44; author: fdrake; state: Exp; > lines: +0 -4 > Remove all traces of the XMLCALLBACK macro -- there appears > to be no way to add __cdecl to a typedef of a function type > that MSVC does not complain about. Callback implementations > may need to add explicit __cdecl annotations in sources not > compiled with the C calling convention as the default. I haven't seen any warnings from my patch to expat.h (with the client code and MSVC 7.1). Is it possible that a compiler upgrade has the compiler issue? Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 17:47 Message: Logged In: YES user_id=3066 >From looking through the CVS logs, we did have an XMLCALLBACK macro at one point, used to mark the callback function typedefs with cdecl. This comment from xmlparse.c revision 1.21 is interesting: ---- revision 1.21 date: 2001/07/27 17:17:44; author: fdrake; state: Exp; lines: +0 -4 Remove all traces of the XMLCALLBACK macro -- there appears to be no way to add __cdecl to a typedef of a function type that MSVC does not complain about. Callback implementations may need to add explicit __cdecl annotations in sources not compiled with the C calling convention as the default. ---- XMLCALLBACK had been added (by me) in revision 1.19, which has this comment: ---- Make sure that XMLPARSEAPI specifies the calling convention when building under MSVC -- this is needed when using the pre-compiled DLL with projects built using a different calling convention. XMLPARSEAPI now takes the return type as a parameter and inserts annotations on both sides of the type to make sure the compiler is happy. A new macro, XMLCALLBACK, is used to perform similar annotation of the callback function types, which do not need the dllimport/dllexport annotations but do still need the __cdecl annotation. This closes SF bug #413653. ---- Sigh. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 17:29 Message: Logged In: YES user_id=3066 Karl, the #undef XMLPARSEAPI is a mystery. I wouldn't be surprised if it's related to the DLL import/export stuff; that may not be needed/desired in the implementation. I suspect that none of it is actually needed in the implementation when cdecl is the default, because explicitly stating cdecl and implicitly using it are probably considered equivalent (questionable practice). I'll bet we can get away with always declaring cdecl; this impacts expat.h as well, since there's a case when the calling convention isn't specified there. I suspect most of the callbacks are not performance sensitive; given that for start/end element we already do a fair bit of work and make many internal calls, there's little impact based on the calling convention for the callback. The only one I'd suspect is particularly sensitive is the characters callback, and there's no specific reason to think the calling convention is going to buy much. I'm inclined to think that everything that crosses the library boundary should be explicitly cdecl. As far as XMLMEMAPI goes, I've no idea how to say "the same calling convention as malloc()". We could define wrapper functions with some explicit convention, but that adds a layer of calls; that's painful. If you know how to pull this one off, I'm open to suggestions! ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-13 16:50 Message: Logged In: YES user_id=290026 OK, here is what I think: It is OK if you want to compiler with a different default calling convention. The fact that this is a problem with Expat is a bug IMO. We simply should fix xmlparse.c so that those declarations that are frozen in expat.h are also frozen in xmlparse.c. We should look at it as two sets of calling conventions: a) those used internally - they are basically frozen b) those used in the API For the second ones, we again have two groups: performance sensitive and non-sensitive. The callbacks fall into the performance sensitive group, the rest is not really performance sensitive (please correct me if I am missing some). I think we can freeze the non-performance sensitive API without much problems, but we should leave the callbacks open for optimization. So, if we concentrate on the callbacks, then it should work if we make xmlparse.c follow expat.h. I just patched xmlparse.c to use XMLPARSEAPI for all functions that have it in expat.h. Down to three errors when using another default calling convention. The errors now are involving the memory handler callbacks. We should probably define an XMLMEMAPI macro to freeze these as they should follow the calling convention used for the standard memory allocation functions. Btw, why is XMLPARSEAPI undefined in xmlparse.c after inclusion of expat.h? I had to uncomment this to make it compile. Any ideas, Fred. Marsh? Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 15:53 Message: Logged In: YES user_id=3066 Ok, I think I understand this one now. ;-) Thanks for the careful response. While I think that interaction between libraries and compiler switches will probably always be a source of frustration, we should be able to make this particular problem go away. I'll gladly support a solution which always forces both call directions to always use cdecl. Hopefully I'll be able to fix this in the next couple of days; I know I won't have time tonight, though. ;-( ---------------------------------------------------------------------- Comment By: Marsh Ray (marshray_bs) Date: 2003-10-13 15:43 Message: Logged In: YES user_id=883966 > How does it work when you build the library > with your calling convention? Expat.dll does not compile with not compile with a default calling convention other than __cdecl. It produces 65 errors, here's a sample: --------------------Configuration: expat - Win32 Debug-------------------- Compiling... xmlparse.c c:\expat-1.95.6\source\lib\xmlparse.c(629) : error C2373: 'XML_ParserCreate' : redefinition; different type modifiers c:\expat-1.95.6\source\lib\expat.h(194) : see declaration of 'XML_ParserCreate' These errors correspond 1:1 with the public API functions defined in expat.h. In expat.h the API functions are declared explicitly cdecl with the XMLPARSEAPI macro. Their definitions (in xmlparse.c for example) do not specify a calling convention, so they follow the default for the project. > If it works OK then we should not force any > calling convention on the callbacks but > simply document that the pre-built binaries > were compiled with cdecl as default. Currently, we're using a Perl script to patch 1.95.1 to allow it to be compiled as fastcall and thus be compatible with our code. We'd like to use the newer release, and for obvious reasons, we'd like to get on the official codebase. The "callforward" API functions define a specific calling convention, all we need is to have one specified on the callbacks. Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-11 16:10 Message: Logged In: YES user_id=290026 How does it work when you build the library with your calling convention? If it works OK then we should not force any calling convention on the callbacks but simply document that the pre-built binaries were compiled with cdecl as default. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=820946&group_id=10127 From noreply at sourceforge.net Wed Oct 15 12:28:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 15 12:28:35 2003 Subject: [Expat-bugs] [ expat-Patches-820946 ] expat.h not great for MSVC !cdecl deflt calling cnvntn Message-ID: Patches item #820946, was opened at 2003-10-09 19:06 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=820946&group_id=10127 Category: None Group: None >Status: Closed Resolution: Accepted Priority: 7 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: expat.h not great for MSVC !cdecl deflt calling cnvntn Initial Comment: OK, well the title I wanted was "expat.h doesn't work cleanly for MSVC with non-cdecl default calling convetion", but there were (reasonable, I guess) length limitations. In any case, if you have a project in MSVC that has its default calling convention set to something other than cdecl (such as stdcall or fastcall), the prototypes for the handler functions don't communicate that the library is compiled to assume cdecl. Things will still compile fine, however odd behavior occurs at runtime (for example, my start element handler was called 5 times with the same name and then the thread crashed). If your callback funcitons are then explicitly declared cdecl (as they should be) then you have to use casts to allow you to assign the address of your cdecl handler functions to the function pointers that the compiler defaults to the different convention. I don't suppose many people bother to change the default calling convention of their projects, but I have seen fastcall give a 5% boost. XML parsing is not a significant part of our apps exection time, so it's not worth recompiling expat to fastcall. It would be nice if it worked out of the box for us. I've supplied a patch, that defines a macro XMLCALLBACK for callbacks, much like the XMLPARSEAPI macro is defined for API functions. I've tested it with MSVC 7.1 projects that default to both stdcall and fastcall. Because the preprocessor tests are set up like the ones for the XMLPARSEAPI macro, I don't think it should affect any non-MSVC compilers. Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-15 12:28 Message: Logged In: YES user_id=3066 Changes committed as: doc/reference.html 1.49 examples/elements.c 1.4 examples/outline.c 1.5 lib/expat.h 1.55 lib/xmlparse.c 1.112 tests/runtests.c 1.53 xmlwf/xmlwf.c 1.66 Closing this report. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-15 11:10 Message: Logged In: YES user_id=3066 After working on this some more and trying to explain the macros, I'm going to revise the proposed change a little. - add a macro, XMLCALL, that expands to whatever is needed to nail down the calling convention for all calls across the library boundary - another new macro, XMLIMPORT, defined to be whatever magic is needed to mark an entry point as imported from a dynamically loaded module (.dll, .so, .sl, whatever) - use XMLCALL and XMLIMPORT to define XMLPARSEAPI - modify all example code to include XMLCALL for definitions of callbacks - modify callback typedefs to use XMLCALL - document, document, document! This proves just a bit simpler in the mechanics of it all, and keeps the layers of magic down. Since the XMLCALLBACK really only adds XMLCALL and an asterisk, it can be completely dropped since XMLCALL is available. Marsh: Yes, I agree that no changes are needed for existing, working code. These changes are entirely to benefit people who want to use a default calling convention other than cdecl. No need for followup comments; watch for commits and a new snapshot later today (possibly *much* later). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-15 00:48 Message: Logged In: YES user_id=3066 Assigned to myself; I think I'm almost done with the code, and have started on the documentation. Bumped priority to reflect intention to include this in 1.95.7. At least for some Unix platforms, which use standard headers that assume cdecl calling convention as the default, Expat itself must be compiled with cdecl as the default. (Otherwise malloc() & friends are not cdecl, and specifying cdecl in the mem functions causes type errors at compile time.) This should not affect code outside of Expat itself. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-14 19:31 Message: Logged In: YES user_id=290026 Fine with me, Fred. ---------------------------------------------------------------------- Comment By: Marsh Ray (marshray_bs) Date: 2003-10-14 17:58 Message: Logged In: YES user_id=883966 >Comment By: Fred L. Drake, Jr. (fdrake) > - add a macro, XMLCALL, that expands to whatever > is needed to nail down the calling convention > for all calls across the library boundary > - add the XMLCALLBACK macro, defined to use XMLCALL > - add XMLCALL to XMLPARSEAPI > - modify all example code to include XMLCALL for > definitions of callbacks Sounds good to me. > - document, document, document! If the changes are made as described above, it won't affect any previously functioning code. All that needs to be documented is the new functionality. A callback function defined in a module with a default calling convention other than cdecl will now need to explicitly specify the calling convention that is expected by expat (typcially cdecl). For example: void myStartElementHandler( void *userData, const XML_Char *name, const XML_Char **atts); Becomes: void __cdecl myStartElementHandler( void *userData, const XML_Char *name, const XML_Char **atts); ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-14 17:35 Message: Logged In: YES user_id=3066 Ok, here's what I propose doing: - add a macro, XMLCALL, that expands to whatever is needed to nail down the calling convention for all calls across the library boundary - add the XMLCALLBACK macro, defined to use XMLCALL - add XMLCALL to XMLPARSEAPI - modify all example code to include XMLCALL for definitions of callbacks - document, document, document! Any of these can be overridden before including expat.h, for those who are adventurous. For those who stick to their compiler defaults, there should be no perceivable change. Once done, I'll release another snapshot, with emails sent to relevant lists (expat-discuss, Python's xml-sig; feel free to suggest others, or just pass the word when the snapshot's up). I've started the code changes based on this patch, but I've only tested using GCC 3.2.2 on RedHat 9 so far. Comments? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-13 19:29 Message: Logged In: YES user_id=290026 I am a little late with my replies. So, summarizing I would say: Let's force cdecl on all API calls, call-back or not. About performance: Considering how much work Expat does behind each call-back the calling convention will likely not have a measurable impact. I agree with Fred here. Also, looking back at our own testing with internal calling conventions, cdecl came out ahead. In my opinion, and I think in Fred's opinion too, this was because cdecl allows optimizations for call "clusters" as the caller manages the stack, not the callee. I really don't think fastcall will give any measurable advantage, even for the call-backs. So, using this patch, what else is there to do? Should we be concerned with memory handler calls and whatever else will have an undefined calling convention? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 18:06 Message: Logged In: YES user_id=3066 Marsh: > By 'frozen' I assume you mean using the default calling > conventions specified at compile time? Yes. > I haven't seen any warnings from my patch to expat.h (with > the client code and MSVC 7.1). Is it possible that a > compiler upgrade has the compiler issue? I would have been using MSVC 6, since that's the only MSVC I've had for years. Not sure what service pack, though. Also, I'm no Windows expert, mostly only using MSVC in a mindless, repetitive "did that break something" mode. I'll play with your patch with actual compilers, though, and see how well I survive. ;-) ---------------------------------------------------------------------- Comment By: Marsh Ray (marshray_bs) Date: 2003-10-13 17:54 Message: Logged In: YES user_id=883966 >Comment By: Karl Waclawek (kwaclaw) >Date: 2003-10-13 16:50 > It is OK if you want to compiler with > a different default calling convention. > The fact that this is a problem with > Expat is a bug IMO. > We simply should fix xmlparse.c so that > those declarations that are frozen in > expat.h are also frozen in xmlparse.c. Agreed, although this is not exactly the problem I was intending to address. We have both cdecl and fastcall default calling conventions being used in our processes. Currently, we're using multiple expat.dll's to handle this. It would be nice to be able to use the same expat.dll everywhere to reduce build-time complexity and run-time footprint. Ridding our code of Xerces is now perhaps another matter . . . :) > We should look at it as two sets of calling conventions: > a) those used internally - they are basically frozen By 'frozen' I assume you mean using the default calling conventions specified at compile time? > b) those used in the API > For the second ones, we again have two groups: > performance sensitive and non-sensitive. > The callbacks fall into the performance > sensitive group, the rest is not really > performance sensitive (please correct mefreeze the > if I am missing some). I think we can non-performancemuch > problems, sensitive API without but we should leave the > callbacks open for optimization. When XML becomes a performance bottleneck, we would typically change our architecture to use faster binary structures. Therefore the ~5% gain in XML parsing we might get by compiling Expat as fastcall is not really significant. Our main goal is to get everyone on the same .dll. > So, if we concentrate on the callbacks, then it should work > if we make xmlparse.c follow expat.h. Sure, if you want to require people to compile a different version of expat.dll for every default calling convention in use. I think the solution for people who want to compile expat as fastcall (if that person exists) would be to allow them to set a #define (in their client code) to specify the calling convention that their custom-compiled dll wants. For example: #define XML_EXPAT_USES_FASTCALL 1 /* or _STDCALL, _CDECL is default */ #include "expat.h" /* be sure to link with expat_fastcall.lib and .dll */ Again, this ability is not particularly useful to us. > I just patched xmlparse.c to use XMLPARSEAPI for all > functions that have it in expat.h. Down to three errors > when using another default calling convention. > The errors now are involving the memory handler callbacks. > We should probably define an XMLMEMAPI macro to freeze > these as they should follow the calling convention used for > the standard memory allocation functions. >Comment By: Fred L. Drake, Jr. (fdrake) > As far as XMLMEMAPI goes, I've no idea how to say "the same > calling convention as malloc()". We could define wrapper > functions with some explicit convention, but that adds a > layer of calls; that's painful. If you know how to pull > this one off, I'm open to suggestions! In my Microsoft headers, I find: _CRTIMP void * __cdecl malloc(size_t); Furthermore, there is not a different C runtime library for each default calling convention. So, it's probably safe to assume malloc is going to be cdecl. Stating that explicitly in the definiton of XML_Memory_Handling_Suite should work, although it looks like there'll be a few places to change in xmlparse.c. #ifndef XMLCDECL #if defined(_MSC_EXTENSIONS) && !defined(__BEOS__) && !defined(__CYGWIN__) #define XMLCDECL __cdecl #else #define XMLCDECL #endif #endif /* not defined XMLCDECL*/ typedef struct { void *(XMLCDECL *malloc_fcn)(size_t size); void *(XMLCDECL *realloc_fcn)(void *ptr, size_t size); void (XMLCDECL *free_fcn)(void *ptr); } XML_Memory_Handling_Suite; >Comment By: Karl Waclawek (kwaclaw) > Btw, why is XMLPARSEAPI undefined in xmlparse.c after > inclusion of expat.h? I had to uncomment this to make > it compile. Any ideas, Fred. Marsh? I would guess the author simply had a habit of being hygenic and didn't want unused defines to propagate out of the inclusing of expat.h. Gee, as I am writing this, you guys keep posting new stuff. > revision 1.21 > date: 2001/07/27 17:17:44; author: fdrake; state: Exp; > lines: +0 -4 > Remove all traces of the XMLCALLBACK macro -- there appears > to be no way to add __cdecl to a typedef of a function type > that MSVC does not complain about. Callback implementations > may need to add explicit __cdecl annotations in sources not > compiled with the C calling convention as the default. I haven't seen any warnings from my patch to expat.h (with the client code and MSVC 7.1). Is it possible that a compiler upgrade has the compiler issue? Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 17:47 Message: Logged In: YES user_id=3066 >From looking through the CVS logs, we did have an XMLCALLBACK macro at one point, used to mark the callback function typedefs with cdecl. This comment from xmlparse.c revision 1.21 is interesting: ---- revision 1.21 date: 2001/07/27 17:17:44; author: fdrake; state: Exp; lines: +0 -4 Remove all traces of the XMLCALLBACK macro -- there appears to be no way to add __cdecl to a typedef of a function type that MSVC does not complain about. Callback implementations may need to add explicit __cdecl annotations in sources not compiled with the C calling convention as the default. ---- XMLCALLBACK had been added (by me) in revision 1.19, which has this comment: ---- Make sure that XMLPARSEAPI specifies the calling convention when building under MSVC -- this is needed when using the pre-compiled DLL with projects built using a different calling convention. XMLPARSEAPI now takes the return type as a parameter and inserts annotations on both sides of the type to make sure the compiler is happy. A new macro, XMLCALLBACK, is used to perform similar annotation of the callback function types, which do not need the dllimport/dllexport annotations but do still need the __cdecl annotation. This closes SF bug #413653. ---- Sigh. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 17:29 Message: Logged In: YES user_id=3066 Karl, the #undef XMLPARSEAPI is a mystery. I wouldn't be surprised if it's related to the DLL import/export stuff; that may not be needed/desired in the implementation. I suspect that none of it is actually needed in the implementation when cdecl is the default, because explicitly stating cdecl and implicitly using it are probably considered equivalent (questionable practice). I'll bet we can get away with always declaring cdecl; this impacts expat.h as well, since there's a case when the calling convention isn't specified there. I suspect most of the callbacks are not performance sensitive; given that for start/end element we already do a fair bit of work and make many internal calls, there's little impact based on the calling convention for the callback. The only one I'd suspect is particularly sensitive is the characters callback, and there's no specific reason to think the calling convention is going to buy much. I'm inclined to think that everything that crosses the library boundary should be explicitly cdecl. As far as XMLMEMAPI goes, I've no idea how to say "the same calling convention as malloc()". We could define wrapper functions with some explicit convention, but that adds a layer of calls; that's painful. If you know how to pull this one off, I'm open to suggestions! ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-13 16:50 Message: Logged In: YES user_id=290026 OK, here is what I think: It is OK if you want to compiler with a different default calling convention. The fact that this is a problem with Expat is a bug IMO. We simply should fix xmlparse.c so that those declarations that are frozen in expat.h are also frozen in xmlparse.c. We should look at it as two sets of calling conventions: a) those used internally - they are basically frozen b) those used in the API For the second ones, we again have two groups: performance sensitive and non-sensitive. The callbacks fall into the performance sensitive group, the rest is not really performance sensitive (please correct me if I am missing some). I think we can freeze the non-performance sensitive API without much problems, but we should leave the callbacks open for optimization. So, if we concentrate on the callbacks, then it should work if we make xmlparse.c follow expat.h. I just patched xmlparse.c to use XMLPARSEAPI for all functions that have it in expat.h. Down to three errors when using another default calling convention. The errors now are involving the memory handler callbacks. We should probably define an XMLMEMAPI macro to freeze these as they should follow the calling convention used for the standard memory allocation functions. Btw, why is XMLPARSEAPI undefined in xmlparse.c after inclusion of expat.h? I had to uncomment this to make it compile. Any ideas, Fred. Marsh? Karl ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-13 15:53 Message: Logged In: YES user_id=3066 Ok, I think I understand this one now. ;-) Thanks for the careful response. While I think that interaction between libraries and compiler switches will probably always be a source of frustration, we should be able to make this particular problem go away. I'll gladly support a solution which always forces both call directions to always use cdecl. Hopefully I'll be able to fix this in the next couple of days; I know I won't have time tonight, though. ;-( ---------------------------------------------------------------------- Comment By: Marsh Ray (marshray_bs) Date: 2003-10-13 15:43 Message: Logged In: YES user_id=883966 > How does it work when you build the library > with your calling convention? Expat.dll does not compile with not compile with a default calling convention other than __cdecl. It produces 65 errors, here's a sample: --------------------Configuration: expat - Win32 Debug-------------------- Compiling... xmlparse.c c:\expat-1.95.6\source\lib\xmlparse.c(629) : error C2373: 'XML_ParserCreate' : redefinition; different type modifiers c:\expat-1.95.6\source\lib\expat.h(194) : see declaration of 'XML_ParserCreate' These errors correspond 1:1 with the public API functions defined in expat.h. In expat.h the API functions are declared explicitly cdecl with the XMLPARSEAPI macro. Their definitions (in xmlparse.c for example) do not specify a calling convention, so they follow the default for the project. > If it works OK then we should not force any > calling convention on the callbacks but > simply document that the pre-built binaries > were compiled with cdecl as default. Currently, we're using a Perl script to patch 1.95.1 to allow it to be compiled as fastcall and thus be compatible with our code. We'd like to use the newer release, and for obvious reasons, we'd like to get on the official codebase. The "callforward" API functions define a specific calling convention, all we need is to have one specified on the callbacks. Thanks, Marsh Ray marsh *period* ray *atsign* barrsystems *period* com ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-11 16:10 Message: Logged In: YES user_id=290026 How does it work when you build the library with your calling convention? If it works OK then we should not force any calling convention on the callbacks but simply document that the pre-built binaries were compiled with cdecl as default. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=820946&group_id=10127 From noreply at sourceforge.net Wed Oct 15 17:40:12 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 15 17:41:07 2003 Subject: [Expat-bugs] [ expat-Bugs-824420 ] expat-2003-10-15 - something is broken or at least changed Message-ID: Bugs item #824420, was opened at 2003-10-15 21:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=824420&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Nobody/Anonymous (nobody) Summary: expat-2003-10-15 - something is broken or at least changed Initial Comment: (.. err, sorry for steppin' in late, again :-( ) I compiled my expat based project with expat-2003-10-15 and run my test suite. For at least some rare cases, there seems to be something broken. I haven't any deep insights, so far, but since I can't spend much more time at it this night and in face of the upcomming release, I decided to just yell, only with an example. Please download the document http://www.w3.org/TR/1999/REC-xslt-19991116.xml If I run 'xmlwf REC-xslt-19991116.xml' I get REC-xslt-19991116.xml:396:0: unbound prefix This seems wrong to me in two ways. First, without the -n option, xmlwf shouldn't care at all, if a prefix isn't bound to a namespace. At least xmlwf 1.95.6 (and prior versions) didn't care (and I would say, this was right). And second, as far as I can tell, the claim itself is false; there is a xmlns:e namespace declaration in scope of that element. I stumbled over the problem while using the lib and then tried to reproduce the problem with xmlwf, for easy demonstration. So, if there is a problem, it's not with the xmlwf tool, but with the lib itself. rolf ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=824420&group_id=10127 From noreply at sourceforge.net Wed Oct 15 20:41:10 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 15 20:41:27 2003 Subject: [Expat-bugs] [ expat-Bugs-824420 ] expat-2003-10-15 - something is broken or at least changed Message-ID: Bugs item #824420, was opened at 2003-10-15 17:40 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=824420&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Nobody/Anonymous (nobody) Summary: expat-2003-10-15 - something is broken or at least changed Initial Comment: (.. err, sorry for steppin' in late, again :-( ) I compiled my expat based project with expat-2003-10-15 and run my test suite. For at least some rare cases, there seems to be something broken. I haven't any deep insights, so far, but since I can't spend much more time at it this night and in face of the upcomming release, I decided to just yell, only with an example. Please download the document http://www.w3.org/TR/1999/REC-xslt-19991116.xml If I run 'xmlwf REC-xslt-19991116.xml' I get REC-xslt-19991116.xml:396:0: unbound prefix This seems wrong to me in two ways. First, without the -n option, xmlwf shouldn't care at all, if a prefix isn't bound to a namespace. At least xmlwf 1.95.6 (and prior versions) didn't care (and I would say, this was right). And second, as far as I can tell, the claim itself is false; there is a xmlns:e namespace declaration in scope of that element. I stumbled over the problem while using the lib and then tried to reproduce the problem with xmlwf, for easy demonstration. So, if there is a problem, it's not with the xmlwf tool, but with the lib itself. rolf ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-15 20:41 Message: Logged In: YES user_id=290026 Please try the attached fix: prefix_patch.diff. The (old) code was processing prefixes even if namespaces were turned off. Hopefully the changes don't break anything else. Would be nice if you could run it through the test-suite. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=824420&group_id=10127 From noreply at sourceforge.net Wed Oct 15 20:42:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 15 21:34:24 2003 Subject: [Expat-bugs] [ expat-Bugs-824420 ] expat-2003-10-15 - something is broken or at least changed Message-ID: Bugs item #824420, was opened at 2003-10-15 17:40 Message generated for change (Settings changed) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=824420&group_id=10127 Category: None >Group: Test Required Status: Open Resolution: None Priority: 5 Submitted By: Rolf Ade (pointsman) >Assigned to: Karl Waclawek (kwaclaw) Summary: expat-2003-10-15 - something is broken or at least changed Initial Comment: (.. err, sorry for steppin' in late, again :-( ) I compiled my expat based project with expat-2003-10-15 and run my test suite. For at least some rare cases, there seems to be something broken. I haven't any deep insights, so far, but since I can't spend much more time at it this night and in face of the upcomming release, I decided to just yell, only with an example. Please download the document http://www.w3.org/TR/1999/REC-xslt-19991116.xml If I run 'xmlwf REC-xslt-19991116.xml' I get REC-xslt-19991116.xml:396:0: unbound prefix This seems wrong to me in two ways. First, without the -n option, xmlwf shouldn't care at all, if a prefix isn't bound to a namespace. At least xmlwf 1.95.6 (and prior versions) didn't care (and I would say, this was right). And second, as far as I can tell, the claim itself is false; there is a xmlns:e namespace declaration in scope of that element. I stumbled over the problem while using the lib and then tried to reproduce the problem with xmlwf, for easy demonstration. So, if there is a problem, it's not with the xmlwf tool, but with the lib itself. rolf ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-15 20:41 Message: Logged In: YES user_id=290026 Please try the attached fix: prefix_patch.diff. The (old) code was processing prefixes even if namespaces were turned off. Hopefully the changes don't break anything else. Would be nice if you could run it through the test-suite. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=824420&group_id=10127 From noreply at sourceforge.net Thu Oct 16 00:57:43 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 16 00:57:49 2003 Subject: [Expat-bugs] [ expat-Patches-458907 ] config.h appears to be unused Message-ID: Patches item #458907, was opened at 2001-09-05 17:20 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=458907&group_id=10127 Category: Build Control Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Martin v. L?wis (loewis) >Assigned to: Fred L. Drake, Jr. (fdrake) 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: 2003-10-16 00:57 Message: Logged In: YES user_id=3066 Ok, I've added a HAVE_EXPAT_CONFIG_H define that gets added by Expat's Makefile; compiling Expat without expat_config.h is possible, though the (static) winconfig.h and macconfig.h are still needed. The following file revisions commit the changes: Makefile.in 1.43 lib/xmlparse.c 1.115 lib/xmlrole.c 1.15 lib/xmltok.c 1.29 tests/chardata.c 1.6 tests/runtests.c 1.54 xmlwf/xmlfile.c 1.13 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-07-14 03:41 Message: Logged In: YES user_id=21627 Your conclusion is incorrect: that you need the #defines doesn't mean that you need expat_config.h. Instead, the configuration variables could also be passed on the compiler command line. To support configurations without a expat_config.h, you must conditionally include the config.h, like #ifdef HAVE_CONFIG_H #include "expat_config.h" #endif Then, when a configure was run, you define HAVE_CONFIG_H in the makefile; if configure was not run, you don't define it. I could accept a negative test, like #ifndef DONT_HAVE_CONFIG_H #include "expat_config.h" #endif so that I would pass -DDONT_HAVE_CONFIG_H to my compiler invocations. Of all the HAVE_ tests in expat_config, only HAVE_BCOPY and HAVE_MEMMOVE are used in the Expat library; everything else is unneeded. If I can find out whether memmove is defined by other means than running configure, I do not need to run configure (platforms that don't have memmove are of no interest to me, so I could just always define HAVE_MEMMOVE). The HAVE_CONFIG_H feature is *not* to avoid clashes with multiple config.h files; it historically predates the usage of header files. configure would generate billions of -D options into the makefile (and still does, if you tell it that you don't use a config.h file). I want to use a configuration without config.h, so I kindly request the number of defines is reduced to those that are actually used. With autoheader, you do have full control over the set of symbols in config.h: namely those symbols that configure.in checks for. For example, if you modify configure.in to not mention fcntl.h, then autoheader will drop the unused HAVE_FCNTL_H. Unfortunately, libtool.m4 pulls in a number of unneeded defines (like HAVE_DLFCN_H); others (like getpagesize) are pulled in through the test for mmap. So please do consider making expat more friendly for embedding into environments where configure is not run. ---------------------------------------------------------------------- Comment By: Greg Stein (gstein) Date: 2002-07-13 16:59 Message: Logged In: YES user_id=6501 I don't see how we could operate in the "no config" case. We *do* require some of those configuration variables, as you originally pointed out. Thus, you need expat_config.h from somewhere. On the Windows platform, we hand-built the file and include it as winconfig.h. But we *do* have a config header in that case. (and my preference would be to call it expat_config.hw and have the .dsp copy it over to the .h file; thus, we couldn't need to set or test COMPILED_FROM_DSP; just need to get to this at some point (it is now APR, APRUTIL, and SVN handle config on windows)) Further, I don't see how you can avoid running configure. We need to do that to create a Makefile (and expat_config.h, of course). And the precursor to running configure is to run buildconf. When APR or APRUTIL are embedded into apps (Apache httpd or SVN), we run their buildconf (during release packaging) and we run their configure (at end-user config time; we run it from the app's configure). In my mind, if you are creating a library package to be embedded, then it is considered an opaque blob: you interact with it according to its defined mechanism. If you want to shortcut the system, then you're assuming too much knowledge about the library. (I thought xmlwf used the MMAP stuff, but it doesn't; we just select a different .c file at config time; however, it does use HAVE_UNISTD_H and it should be using a lot more, such as HAVE_STRING_H or HAVE_STDDEF_H and whatnot; xmlparse.c and brethren should be, too, for that matter (e.g. some platforms have string.h and others strings.h)) Personally, I don't understand the HAVE_CONFIG_H thing. I'm presuming that is mostly because of past conflicts with everybody naming their file config.h. It meant you couldn't have several config.h files in use. But even then: how could an app get the defines it needs? Did the embedding app have to define a billion things on their CC command line? Man... talk about needing to *really* know about the internals of your embedded library. Our use of expat_config.h solves these historical conflicts. And regarding the elimination of unneeded symbols: those are automatically generated by autoheader. We don't have control over the full set in there. In the past, it was possible to use acconfig.h to have fine-grained control over the contents, but much of that framework is deprecated. And it isn't really needed, in any case, since there isn't any real harm in letting autoheader just build one for us, with whatever it thinks is needed. Let me turn the question around: why is it a problem for the parent application to run buildconf at packaging time, and to run Expat's configure at parent-configure time? It seems to work just fine for me, whenever I embed a library (APR (UTIL), Expat, Neon, and Berkeley DB) into another app. Changing status to Pending. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-07-12 08:09 Message: Logged In: YES user_id=3066 This has come up as still being a problem for a couple of projects on the Python XML-SIG, so this needs to be reconsidered. Hopefully Martin will be interested in checking and updating his proposed patch against 1.95.4. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-06-02 05:15 Message: Logged In: YES user_id=21627 Can you elaborate which defines of expat_config.h is used in xmlwf? I could not find any. Why is it wrong to not run configure? autoconf packages, historically, always supported "manual" configuration, by editing config.h manually. Also, your own build process does not use expat_config.h if COMPILED_FROM_DSP is set. In general, it is not possible to run configure if you don't have /bin/sh on a system; this is a scenario that PyXML needs to support. Also, traditionally, autoconf supports both configuration with and without a config.h; files including config.h would always wrap this with a #ifdef HAVE_CONFIG_H (should be HAVE_EXPAT_CONFIG_H in your case). All I'm asking is that the combination "manual configuration" and "no config.h" is supported. If this is not available, I have to fake-generate a config.h, which is ugly. It would also help if config.h was reduced to the set of defines which are actually used, instead of autoconfiscating every line of the source. ---------------------------------------------------------------------- Comment By: Greg Stein (gstein) Date: 2002-06-01 19:44 Message: Logged In: YES user_id=6501 We may not use most of those (autoconf creates them as part of searching for particular functions and stuff), but xmlwf does use some. That said: if you're going to embed Expat into another application, then you'll need to adjust things accordingly. Note that we've switched to "expat_config.h", so it might be possible to just include that into your own application since a conflict on config.h won't occur any more. Also, note that the premise of "not running configure" is probably quite wrong. Expat is embedded into the ASF's apr-util project, and we *do* run configure for that, and build expat as a sub-library. (heck, we even run expat's buildconf.sh at the appropriate time) Given the change to expat_config.h, and how I believe embedding should work, I'm going to close this patch as rejected. However, even with that said, I'm quite happy to be corrected and/or to make other changes to simplify Expat's ability to be embedded. ---------------------------------------------------------------------- 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: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=458907&group_id=10127 From noreply at sourceforge.net Thu Oct 16 07:15:13 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 16 07:15:26 2003 Subject: [Expat-bugs] [ expat-Bugs-824420 ] expat-2003-10-15 - something is broken or at least changed Message-ID: Bugs item #824420, was opened at 2003-10-15 21:40 Message generated for change (Comment added) made by pointsman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=824420&group_id=10127 Category: None Group: Test Required Status: Open Resolution: None Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Karl Waclawek (kwaclaw) Summary: expat-2003-10-15 - something is broken or at least changed Initial Comment: (.. err, sorry for steppin' in late, again :-( ) I compiled my expat based project with expat-2003-10-15 and run my test suite. For at least some rare cases, there seems to be something broken. I haven't any deep insights, so far, but since I can't spend much more time at it this night and in face of the upcomming release, I decided to just yell, only with an example. Please download the document http://www.w3.org/TR/1999/REC-xslt-19991116.xml If I run 'xmlwf REC-xslt-19991116.xml' I get REC-xslt-19991116.xml:396:0: unbound prefix This seems wrong to me in two ways. First, without the -n option, xmlwf shouldn't care at all, if a prefix isn't bound to a namespace. At least xmlwf 1.95.6 (and prior versions) didn't care (and I would say, this was right). And second, as far as I can tell, the claim itself is false; there is a xmlns:e namespace declaration in scope of that element. I stumbled over the problem while using the lib and then tried to reproduce the problem with xmlwf, for easy demonstration. So, if there is a problem, it's not with the xmlwf tool, but with the lib itself. rolf ---------------------------------------------------------------------- >Comment By: Rolf Ade (pointsman) Date: 2003-10-16 11:15 Message: Logged In: YES user_id=13222 Thanks for the quick patch, Karl! Your patch fixed the problem with the example document REC-xslt-19991116.xml. Well, since you said (and your patch suggests) that up to now expat simply always did ns checking, even if not asked for, I wonder, why it hallucinated, that the prefix binding were missing, which is not the case (as even xmlwf -n itself now - with an appropiate SYSTEM identifierer or no system identifier) - confirms). Anyway. So far, I could not decteced any other problem with the test suite of my expat pased project. I also run xmlwf against the OASIS xml test suite (with the same methodology as in #569461) and found nothing new or alarming. Tests, that are still wrong, as in previous versions are ibm/not-wf/misc/432gewf.xml sun/not-wf/uri01.xml xmltest/not-wf/not-sa/010.xml xmltest/not-wf/not-sa/011.xml And the debatable xmltest/not-wf/not-sa/005.xml which could not counted to the failed tests, because the rec allows well-formedness parser to fail at this test as well as to pass it (as already discussed in #569461) - although I personally feel, that it would be better for the expat users, if expat would signal error in this cases. Even a few preliminary benchmark tests haven't showed a problem (up to now, I don't see any slow down, which would worth mentioning). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-16 00:41 Message: Logged In: YES user_id=290026 Please try the attached fix: prefix_patch.diff. The (old) code was processing prefixes even if namespaces were turned off. Hopefully the changes don't break anything else. Would be nice if you could run it through the test-suite. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=824420&group_id=10127 From noreply at sourceforge.net Thu Oct 16 09:26:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 16 09:27:01 2003 Subject: [Expat-bugs] [ expat-Bugs-824420 ] expat-2003-10-15 - something is broken or at least changed Message-ID: Bugs item #824420, was opened at 2003-10-15 17:40 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=824420&group_id=10127 Category: None Group: Test Required Status: Open Resolution: None Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Karl Waclawek (kwaclaw) Summary: expat-2003-10-15 - something is broken or at least changed Initial Comment: (.. err, sorry for steppin' in late, again :-( ) I compiled my expat based project with expat-2003-10-15 and run my test suite. For at least some rare cases, there seems to be something broken. I haven't any deep insights, so far, but since I can't spend much more time at it this night and in face of the upcomming release, I decided to just yell, only with an example. Please download the document http://www.w3.org/TR/1999/REC-xslt-19991116.xml If I run 'xmlwf REC-xslt-19991116.xml' I get REC-xslt-19991116.xml:396:0: unbound prefix This seems wrong to me in two ways. First, without the -n option, xmlwf shouldn't care at all, if a prefix isn't bound to a namespace. At least xmlwf 1.95.6 (and prior versions) didn't care (and I would say, this was right). And second, as far as I can tell, the claim itself is false; there is a xmlns:e namespace declaration in scope of that element. I stumbled over the problem while using the lib and then tried to reproduce the problem with xmlwf, for easy demonstration. So, if there is a problem, it's not with the xmlwf tool, but with the lib itself. rolf ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-16 09:26 Message: Logged In: YES user_id=290026 Rolf, I think I was wrong when I said that prefix processing was always done - it was really only done when elementType->prefix was non-null despite of ns processing being turned off. This only happened when the element type contained a prefix already in the DTD, as far as I can tell. That fact that there was no error previously was simply that the error code for if (!binding) was XML_ERROR_NONE, which would fail to detect cases in which an error should be returned. Once I changed this then it started to return errors when it should not - as you detected. After looking at that I saw that the if (elementType->prefix) test was sometimes positive even if namespaces were turned off, which led to the error. As a result of the one-line change it should actually run faster now in those rare cases when we have prefixes in the DTD. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2003-10-16 07:15 Message: Logged In: YES user_id=13222 Thanks for the quick patch, Karl! Your patch fixed the problem with the example document REC-xslt-19991116.xml. Well, since you said (and your patch suggests) that up to now expat simply always did ns checking, even if not asked for, I wonder, why it hallucinated, that the prefix binding were missing, which is not the case (as even xmlwf -n itself now - with an appropiate SYSTEM identifierer or no system identifier) - confirms). Anyway. So far, I could not decteced any other problem with the test suite of my expat pased project. I also run xmlwf against the OASIS xml test suite (with the same methodology as in #569461) and found nothing new or alarming. Tests, that are still wrong, as in previous versions are ibm/not-wf/misc/432gewf.xml sun/not-wf/uri01.xml xmltest/not-wf/not-sa/010.xml xmltest/not-wf/not-sa/011.xml And the debatable xmltest/not-wf/not-sa/005.xml which could not counted to the failed tests, because the rec allows well-formedness parser to fail at this test as well as to pass it (as already discussed in #569461) - although I personally feel, that it would be better for the expat users, if expat would signal error in this cases. Even a few preliminary benchmark tests haven't showed a problem (up to now, I don't see any slow down, which would worth mentioning). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-15 20:41 Message: Logged In: YES user_id=290026 Please try the attached fix: prefix_patch.diff. The (old) code was processing prefixes even if namespaces were turned off. Hopefully the changes don't break anything else. Would be nice if you could run it through the test-suite. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=824420&group_id=10127 From noreply at sourceforge.net Thu Oct 16 10:28:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 16 10:28:47 2003 Subject: [Expat-bugs] [ expat-Bugs-824420 ] expat-2003-10-15 - something is broken or at least changed Message-ID: Bugs item #824420, was opened at 2003-10-15 17:40 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=824420&group_id=10127 Category: None Group: Test Required Status: Open >Resolution: Fixed Priority: 5 Submitted By: Rolf Ade (pointsman) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: expat-2003-10-15 - something is broken or at least changed Initial Comment: (.. err, sorry for steppin' in late, again :-( ) I compiled my expat based project with expat-2003-10-15 and run my test suite. For at least some rare cases, there seems to be something broken. I haven't any deep insights, so far, but since I can't spend much more time at it this night and in face of the upcomming release, I decided to just yell, only with an example. Please download the document http://www.w3.org/TR/1999/REC-xslt-19991116.xml If I run 'xmlwf REC-xslt-19991116.xml' I get REC-xslt-19991116.xml:396:0: unbound prefix This seems wrong to me in two ways. First, without the -n option, xmlwf shouldn't care at all, if a prefix isn't bound to a namespace. At least xmlwf 1.95.6 (and prior versions) didn't care (and I would say, this was right). And second, as far as I can tell, the claim itself is false; there is a xmlns:e namespace declaration in scope of that element. I stumbled over the problem while using the lib and then tried to reproduce the problem with xmlwf, for easy demonstration. So, if there is a problem, it's not with the xmlwf tool, but with the lib itself. rolf ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-16 10:28 Message: Logged In: YES user_id=290026 Fix committed as xmlparse.c rev.1.116. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-16 09:26 Message: Logged In: YES user_id=290026 Rolf, I think I was wrong when I said that prefix processing was always done - it was really only done when elementType->prefix was non-null despite of ns processing being turned off. This only happened when the element type contained a prefix already in the DTD, as far as I can tell. That fact that there was no error previously was simply that the error code for if (!binding) was XML_ERROR_NONE, which would fail to detect cases in which an error should be returned. Once I changed this then it started to return errors when it should not - as you detected. After looking at that I saw that the if (elementType->prefix) test was sometimes positive even if namespaces were turned off, which led to the error. As a result of the one-line change it should actually run faster now in those rare cases when we have prefixes in the DTD. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2003-10-16 07:15 Message: Logged In: YES user_id=13222 Thanks for the quick patch, Karl! Your patch fixed the problem with the example document REC-xslt-19991116.xml. Well, since you said (and your patch suggests) that up to now expat simply always did ns checking, even if not asked for, I wonder, why it hallucinated, that the prefix binding were missing, which is not the case (as even xmlwf -n itself now - with an appropiate SYSTEM identifierer or no system identifier) - confirms). Anyway. So far, I could not decteced any other problem with the test suite of my expat pased project. I also run xmlwf against the OASIS xml test suite (with the same methodology as in #569461) and found nothing new or alarming. Tests, that are still wrong, as in previous versions are ibm/not-wf/misc/432gewf.xml sun/not-wf/uri01.xml xmltest/not-wf/not-sa/010.xml xmltest/not-wf/not-sa/011.xml And the debatable xmltest/not-wf/not-sa/005.xml which could not counted to the failed tests, because the rec allows well-formedness parser to fail at this test as well as to pass it (as already discussed in #569461) - although I personally feel, that it would be better for the expat users, if expat would signal error in this cases. Even a few preliminary benchmark tests haven't showed a problem (up to now, I don't see any slow down, which would worth mentioning). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-15 20:41 Message: Logged In: YES user_id=290026 Please try the attached fix: prefix_patch.diff. The (old) code was processing prefixes even if namespaces were turned off. Hopefully the changes don't break anything else. Would be nice if you could run it through the test-suite. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=824420&group_id=10127 From noreply at sourceforge.net Thu Oct 16 23:49:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 16 23:49:50 2003 Subject: [Expat-bugs] [ expat-Bugs-609603 ] v1.95.5 Win32 static lib symbol problem Message-ID: Bugs item #609603, was opened at 2002-09-15 12:28 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=609603&group_id=10127 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: v1.95.5 Win32 static lib symbol problem Initial Comment: I just switched over to using the Win32 static lib version of Expat in my MSVC++ application. Now, it appears that the following line: #define _STATIC is required before #include "expat.h" otherwise, the link fails. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-16 23:49 Message: Logged In: YES user_id=3066 Expat 1.95.7 contains documentation on what's needed to use the static libraries, so the confusion should no longer be present. Closing this report. ---------------------------------------------------------------------- Comment By: Mike Roskanuk (mikerosky) Date: 2003-01-28 13:12 Message: Logged In: YES user_id=698797 That's true, i have no problem with .tar.gz. I just ment Win32 version differs ... (usually it's true for code ported to win32). Don't worry about it, it was just an idea. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-01-28 12:53 Message: Logged In: YES user_id=3066 The current installer includes both libraries and the xmlwf application, but just drops them into place. It also contains sources. Perhaps the right thing for someone who only wants sources is to grab the .tar.gz package? Most of the good archive handlers used for ZIP files also handle .tar.gz quite well (I use WinZip for these on Windows, myself). ---------------------------------------------------------------------- Comment By: Mike Roskanuk (mikerosky) Date: 2003-01-28 12:41 Message: Logged In: YES user_id=698797 Generally, winstaller is used by similiar way as rpm and other pkg systems, it shoud take care of dependencies (correct versions of .dlls), deploy in files, write to windows registry etc. For sources only is IMHO better to use .zip, same as it's .gzipped for unix/linux world. Of course - why not to offer both. Or you can offer zip/rar self-extract archive. It could be "golden middle path" (jeez i hope this idiom exist in english, too ;-) ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-01-28 10:38 Message: Logged In: YES user_id=3066 Added win32/README.txt to the Windows installation in win32/expat.iss 1.16. I still intend to me the other documentation changes described in earlier comments. Glad to hear things work on CE now! I went with the installer mostly because I figured that's how things seem to be done on Windows, but I'm not really a "Windows person" myself. There is an aspect of Expat that non-programmers might install it for, and that's the "xmlwf" application, but I probably don't do the right thing to make that useful out of the box now. For me, the real question is "What would Expat users on Windows expect?" I'll provide whichever makes the most sense; I can provide both if that's the right thing. (This might make sense since xmlwf is targetted to a larger audience than just developers.) ---------------------------------------------------------------------- Comment By: Mike Roskanuk (mikerosky) Date: 2003-01-28 08:58 Message: Logged In: YES user_id=698797 Fine. BTW why you decided to use Windows installer, when it's "just a few files" a you don't need to do anything with system as .dll dependencies, registry modifications etc? IMHO .zip archive should be sufficient ... P.S. FYI: I compiled and use expat on Windows CE 3.0 with no problem. Thanks 4 good job! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-01-28 08:21 Message: Logged In: YES user_id=3066 Looks like that file doesn't get installed by the Windows installer; it only exists in the CVS repository. I'll add the information to the general documentation, or add a separate HTML file as part of the docs with a link from the main reference.html. ---------------------------------------------------------------------- Comment By: Mike Roskanuk (mikerosky) Date: 2003-01-28 05:44 Message: Logged In: YES user_id=698797 Sorry - where is that Readme? I can't find it (in expat_win32bin_1_95_6.exe). Anyway - IMHO it should be mentioned in Doc/reference.html [Building and Installing]. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-01-23 15:53 Message: Logged In: YES user_id=290026 The static linking for Windows is documented in the ReadMe file under the Win32 directory. But is that enough, or should some documentation be added elsewhere - at least the fact that the global macro XML_STATIC needs to be defined? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-01-23 15:39 Message: Logged In: YES user_id=3066 Static linking on Unix is a non-starter -- every platform handles all linking differently, and developers hate their lives if they have to go beyond writing code to actually linking an application together. There's nothing Expat-specific in this sea of misery. I don't know what a Windows programmer needs to be told, so someone will have to tell me, or provide a patch. It sounds like there's a problem there, but I've no idea offhand if that's unique to the static Expat libraries, or endemic to Windows. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-09-15 12:50 Message: Logged In: YES user_id=290026 Either that, or you define _STATIC in the Project Settings. Have a look at the "elements" demo project, it is statically linked. However, I think it is not enough to just have the demo project, we should document this as well. I'll assign this to Fred, since the documentation needs to include static linking instructions for Unix systems too. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-15 12:29 Message: Logged In: NO ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=609603&group_id=10127 From noreply at sourceforge.net Thu Oct 16 23:57:05 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 16 23:57:25 2003 Subject: [Expat-bugs] [ expat-Bugs-615028 ] (expat-1.95.5) Solaris 2.6 make error Message-ID: Bugs item #615028, was opened at 2002-09-26 12:07 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615028&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: (expat-1.95.5) Solaris 2.6 make error Initial Comment: Hi, I am trying to install expat and get the following error when runnng "make" under the expat directory. /bin/ksh ./libtool --silent --mode=link cc -g -I./lib -I. -o xmlwf/xmlwf xmlw f/xmlwf.o xmlwf/xmlfile.o xmlwf/codepage.o xmlwf/unixfilemap.o libexpat.la cc: Can't exec /opt/SUNWspro/bin/../SC4.2/bin/ild *** Error code 100 make: Fatal error: Command failed for target `xmlwf/xmlwf' I have no idea where/what the "ild" command is. Any ideas? Thanks. Alan. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-16 23:57 Message: Logged In: YES user_id=3066 Is there anyone with a Solaris 2.6 box available to test the current Expat on? It would be nice to know if this problem persists. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-10-21 13:59 Message: Logged In: NO I am trying to install expat on a Solaris 2.6 box too and I come up with the following: @everlast:/tmp/tkdnload/expat-1.95.5 > make /bin/ksh ./libtool --silent --mode=link gcc -g -O2 -Wall - Wmissing-prototypes -Wstrict-prototypes -fexceptions -I./lib -I. -no-undefined - version-info 4:0:4 -rpath /usr/local/lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo ./libtool[4119]: ar: not found make: *** [libexpat.la] Error 127 I have checked and ar is in /usr/cs/bin which is in my PATH. Any ideas where I getting off track? Thanks Ken ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615028&group_id=10127 From noreply at sourceforge.net Fri Oct 17 00:13:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 17 00:14:13 2003 Subject: [Expat-bugs] [ expat-Bugs-732794 ] Build issues on Unix platforms Message-ID: Bugs item #732794, was opened at 2003-05-05 12:49 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=732794&group_id=10127 Category: Build control >Group: Third-party Bug >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Greg Stein (gstein) Summary: Build issues on Unix platforms Initial Comment: Nelson Beebe reported a few issues while building Expat 1.95.6 on various Unix platforms. Attached as file beebe.txt. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-17 00:13 Message: Logged In: YES user_id=3066 The availability of check.h is now checked by the configure script. Given the general problem that most of these aspects are controlled by libtool rather than the Expat build process itself, I don't think we can do any more about this without completely replacing the build system. Closing this as 3rd party bug / won't fix. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-08-27 08:55 Message: Logged In: YES user_id=3066 I looked over Nelson's comments, and it looks like most of these issues are related to the way libtool puts command lines together, not things that are directly in the Makefile; Makefile.pre.in looks like it gets these issues right. Greg, can you take a look at this as well? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-07-15 11:42 Message: Logged In: YES user_id=3066 Added notes about the use of check in README revision 1.24. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=732794&group_id=10127 From noreply at sourceforge.net Fri Oct 17 08:56:27 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 17 08:56:31 2003 Subject: [Expat-bugs] [ expat-Bugs-825475 ] Expat can't handle "Father& Son" string Message-ID: Bugs item #825475, was opened at 2003-10-17 12:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=825475&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jouni Virtanen (jouniv) Assigned to: Nobody/Anonymous (nobody) Summary: Expat can't handle "Father&Son" string Initial Comment: Hello! I have got the XML document described belowe: Father&Son When expat calls the handler function: static void characterData ( void *userData, const XML_Char *s, int len ) variable *s contains string "Father" and I am wondering why is the original string "Father&Son" truncated. I have compiled expat lib 1.95.6 in HP-UX with default options. Is there any chances to get this working? Regards Jouni ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=825475&group_id=10127 From noreply at sourceforge.net Fri Oct 17 09:48:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 17 09:48:37 2003 Subject: [Expat-bugs] [ expat-Bugs-825475 ] Expat can't handle "Father& Son" string Message-ID: Bugs item #825475, was opened at 2003-10-17 08:56 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=825475&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jouni Virtanen (jouniv) >Assigned to: Karl Waclawek (kwaclaw) Summary: Expat can't handle "Father&Son" string Initial Comment: Hello! I have got the XML document described belowe: Father&Son When expat calls the handler function: static void characterData ( void *userData, const XML_Char *s, int len ) variable *s contains string "Father" and I am wondering why is the original string "Father&Son" truncated. I have compiled expat lib 1.95.6 in HP-UX with default options. Is there any chances to get this working? Regards Jouni ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-17 09:48 Message: Logged In: YES user_id=290026 Are you aware of this part of the documentation for the character data handler? A single block of contiguous text free of markup may still result in a sequence of calls to this handler. In other words, if you're searching for a pattern in the text, it may be split across calls to this handler. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=825475&group_id=10127 From noreply at sourceforge.net Sat Oct 18 01:54:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 18 01:55:07 2003 Subject: [Expat-bugs] [ expat-Bugs-825475 ] Expat can't handle "Father& Son" string Message-ID: Bugs item #825475, was opened at 2003-10-17 08:56 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=825475&group_id=10127 Category: None >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Jouni Virtanen (jouniv) Assigned to: Karl Waclawek (kwaclaw) Summary: Expat can't handle "Father&Son" string Initial Comment: Hello! I have got the XML document described belowe: Father&Son When expat calls the handler function: static void characterData ( void *userData, const XML_Char *s, int len ) variable *s contains string "Father" and I am wondering why is the original string "Father&Son" truncated. I have compiled expat lib 1.95.6 in HP-UX with default options. Is there any chances to get this working? Regards Jouni ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-18 01:54 Message: Logged In: YES user_id=3066 The documentation covers this; this is normal for a SAX-like parser. Closing this report as not a bug. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-17 09:48 Message: Logged In: YES user_id=290026 Are you aware of this part of the documentation for the character data handler? A single block of contiguous text free of markup may still result in a sequence of calls to this handler. In other words, if you're searching for a pattern in the text, it may be split across calls to this handler. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=825475&group_id=10127 From noreply at sourceforge.net Sat Oct 18 02:27:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 18 02:27:23 2003 Subject: [Expat-bugs] [ expat-Bugs-824420 ] expat-2003-10-15 - something is broken or at least changed Message-ID: Bugs item #824420, was opened at 2003-10-15 17:40 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=824420&group_id=10127 Category: None Group: Test Required Status: Open Resolution: Fixed Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: expat-2003-10-15 - something is broken or at least changed Initial Comment: (.. err, sorry for steppin' in late, again :-( ) I compiled my expat based project with expat-2003-10-15 and run my test suite. For at least some rare cases, there seems to be something broken. I haven't any deep insights, so far, but since I can't spend much more time at it this night and in face of the upcomming release, I decided to just yell, only with an example. Please download the document http://www.w3.org/TR/1999/REC-xslt-19991116.xml If I run 'xmlwf REC-xslt-19991116.xml' I get REC-xslt-19991116.xml:396:0: unbound prefix This seems wrong to me in two ways. First, without the -n option, xmlwf shouldn't care at all, if a prefix isn't bound to a namespace. At least xmlwf 1.95.6 (and prior versions) didn't care (and I would say, this was right). And second, as far as I can tell, the claim itself is false; there is a xmlns:e namespace declaration in scope of that element. I stumbled over the problem while using the lib and then tried to reproduce the problem with xmlwf, for easy demonstration. So, if there is a problem, it's not with the xmlwf tool, but with the lib itself. rolf ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-18 02:27 Message: Logged In: YES user_id=3066 Just for the record, here's a more minimal document that exhibits this problem with the version of Expat before Karl fixed this bug: ]> ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-16 10:28 Message: Logged In: YES user_id=290026 Fix committed as xmlparse.c rev.1.116. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-16 09:26 Message: Logged In: YES user_id=290026 Rolf, I think I was wrong when I said that prefix processing was always done - it was really only done when elementType->prefix was non-null despite of ns processing being turned off. This only happened when the element type contained a prefix already in the DTD, as far as I can tell. That fact that there was no error previously was simply that the error code for if (!binding) was XML_ERROR_NONE, which would fail to detect cases in which an error should be returned. Once I changed this then it started to return errors when it should not - as you detected. After looking at that I saw that the if (elementType->prefix) test was sometimes positive even if namespaces were turned off, which led to the error. As a result of the one-line change it should actually run faster now in those rare cases when we have prefixes in the DTD. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2003-10-16 07:15 Message: Logged In: YES user_id=13222 Thanks for the quick patch, Karl! Your patch fixed the problem with the example document REC-xslt-19991116.xml. Well, since you said (and your patch suggests) that up to now expat simply always did ns checking, even if not asked for, I wonder, why it hallucinated, that the prefix binding were missing, which is not the case (as even xmlwf -n itself now - with an appropiate SYSTEM identifierer or no system identifier) - confirms). Anyway. So far, I could not decteced any other problem with the test suite of my expat pased project. I also run xmlwf against the OASIS xml test suite (with the same methodology as in #569461) and found nothing new or alarming. Tests, that are still wrong, as in previous versions are ibm/not-wf/misc/432gewf.xml sun/not-wf/uri01.xml xmltest/not-wf/not-sa/010.xml xmltest/not-wf/not-sa/011.xml And the debatable xmltest/not-wf/not-sa/005.xml which could not counted to the failed tests, because the rec allows well-formedness parser to fail at this test as well as to pass it (as already discussed in #569461) - although I personally feel, that it would be better for the expat users, if expat would signal error in this cases. Even a few preliminary benchmark tests haven't showed a problem (up to now, I don't see any slow down, which would worth mentioning). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-15 20:41 Message: Logged In: YES user_id=290026 Please try the attached fix: prefix_patch.diff. The (old) code was processing prefixes even if namespaces were turned off. Hopefully the changes don't break anything else. Would be nice if you could run it through the test-suite. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=824420&group_id=10127 From noreply at sourceforge.net Tue Oct 21 00:37:25 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 21 00:37:52 2003 Subject: [Expat-bugs] [ expat-Bugs-676844 ] expat.h compile error: enum XML_Status Message-ID: Bugs item #676844, was opened at 2003-01-29 10:37 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=676844&group_id=10127 >Category: None Group: None >Status: Closed Resolution: Fixed Priority: 9 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: expat.h compile error: enum XML_Status Initial Comment: c++ -DHAVE_CONFIG_H -I. -I. -I../../autocfg -g -O2 -c context.cpp -fPIC -DPIC -o .libs/context.lo In file included from parser.h:45, from guard.h:143, from context.cpp:45: /usr/include/expat.h:657: use of enum `XML_Status' without previous declaration /usr/include/expat.h:736: multiple definition of `enum XML_Status' when building sablotron. Hand editing the file to place the def of enum XML_Status before any references to it fixes the problem. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-21 00:37 Message: Logged In: YES user_id=3066 Expat 1.95.7 has been released and includes the fix for this problem. Please update to Expat 1.95.7 if you're still having problems related to this issue. ---------------------------------------------------------------------- Comment By: paul jobson (vbrtrmn) Date: 2003-10-08 14:47 Message: Logged In: YES user_id=155212 Platform: OSX Jaguar 10.2 expat version 1.95.6 Sablot ./configure error message: --------------------------------- Truncated --------------------------------- checking where to find xml parser... expat (new) checking expat.h usability... no checking expat.h presence... yes configure: WARNING: expat.h: present but cannot be compiled configure: WARNING: expat.h: check for missing prerequisite headers? configure: WARNING: expat.h: proceeding with the preprocessor's result configure: WARNING: ## -------------------------------- ---- ## configure: WARNING: ## Report this to bug- autoconf@gnu.org. ## configure: WARNING: ## -------------------------------- ---- ## checking for expat.h... yes checking whether expat.h is broken... yes configure: error: You probably have expat version 1.95.6. Please refer to: http://sourceforge.net/tracker/index.php? func=detail&aid=676844&group_id=10127&atid=110127 for a description of the problem. --------------------------------- I downloaded the newest expat.h from the CVS, stuck it in the /lib directory and recompiled expat, Sablot seems to configure correctly, now. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-09-13 16:42 Message: Logged In: YES user_id=290026 We intend to release soon. All that is holding us up is finding the time to actually do it. Fred will be back in a week, and I hope he can find the time then. Now, since your users are expert enough to build Expat from source, what is holding them back from using the current CVS? It is pretty much what we will release, except possibly for minor details, or if someone finds a bug, of course. We do actually want users to build from CVS, as our desire to have stable file releases means that we want our changes to be tested as much as possible. ---------------------------------------------------------------------- Comment By: Jacob Levy (jyljyljyl) Date: 2003-09-13 16:29 Message: Logged In: YES user_id=63723 Are you planning -- please? -- to make another file release containing these fixes? Asking my users to build expat from the current release is not working, because of this bug. As a result, I'm recommending to my users to get/use an older version of expat without the new nifty features. --JYL ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-09-13 12:19 Message: Logged In: YES user_id=290026 Has been fixed in CVS for a long time. Btw, CVS is generally stable, as we are quite careful to commit changes only when they have been tested. No guarantees, of course. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-09-13 10:44 Message: Logged In: NO this is simply a matter of the expat.h file being wrongly organised so that "enum XML_Status" is used several times before it is declared. 30 seconds copying and pasting will fix it. currently nothing using expat.h compiles under gcc 3.2.3 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-07-18 09:16 Message: Logged In: NO After I read all this comments, i saw that u were right. : ) I placed the following definitions enum XML_Status { XML_STATUS_ERROR = 0, #define XML_STATUS_ERROR XML_STATUS_ERROR XML_STATUS_OK = 1 #define XML_STATUS_OK XML_STATUS_OK }; at the beginning of the expat.h file, before any call to it, and it compiled succesfully. After this I compiled sablot with no problems. thank u guys ... : ) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-06-19 11:36 Message: Logged In: NO in configure..:: checking XML::Parser perl module... no: documentation requires XML::Parser module and will not be built. checking whether to build under GPL... no checking whether to build the debugger... no checking where to find xml parser... expat (new) checking expat.h usability... no checking expat.h presence... yes configure: WARNING: expat.h: present but cannot be compiled configure: WARNING: expat.h: check for missing prerequisite headers? configure: WARNING: expat.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug-autoconf@gnu.org. ## configure: WARNING: ## ------------------------------------ ## checking for expat.h... yes checking whether expat.h is broken... yes configure: error: You probably have expat version 1.95.6. Please refer to: http://sourceforge.net/tracker/index.php?func=detail&aid=676844&group_id=10127&atid=110127 for a description of the problem. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-05-30 16:47 Message: Logged In: YES user_id=290026 Yes, the file to fix is expat.h. Two things you can do: 1) get the latest expat.h from CVS, or 2) use your editor to search expat.h for the first location where XML_STATUS is used and then move the definition of XML_STATUS to some location before that point. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-05-30 16:26 Message: Logged In: NO I have the same problem has other senders, but the fix is unclear as you did not indicate which file needs fixing (I assume expat.h) or line number to place the def of enum XML_Status. Please assume people are stupid.. checking expat.h usability... no checking expat.h presence... yes configure: WARNING: expat.h: present but cannot be compiled configure: WARNING: expat.h: check for missing prerequisite headers? configure: WARNING: expat.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug-autoconf@gnu.org. ## configure: WARNING: ## ------------------------------------ ## checking for expat.h... yes checking whether expat.h is broken... yes configure: error: You probably have expat version 1.95.6. Please refer to: http://sourceforge.net/tracker/index.php?func=detail&aid=676844&group_id=10127&atid=110127 for a description of the problem. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-05-08 09:18 Message: Logged In: YES user_id=290026 See above - original submission: Hand editing the file to place the def of enum XML_Status before any references to it fixes the problem. ---------------------------------------------------------------------- Comment By: Donche, Pieter (pdon) Date: 2003-05-08 03:20 Message: Logged In: YES user_id=774177 SUN Sparc Enterprise 2170 Solaris 2.8 gcc 3.2 Downloaded expat-1.95.6.tar.gz ./configure, make, make install OK Downloaded Sablot-0.98.tar.gz (Sablotron package, from www.gingerall.com) ./configure says: ... checking expat.h presence... yes expat.h: present but cannot be compiled expat.h: check for missing prerequisite headers? expat.h: proceeding with the preprocessor's result ##-------------------------------------------------## ## Report this to bug-autoconf@gnu.org ## ##-------------------------------------------------## checking for expat.h... yes checking wether expat.h is broken... yes error: You probably have expat version 1.95.6. Please refer to http://sourceforge.net/tracker/index.php? func=detail&aid=676844&group_id=10127&atid=110127 for a description of the problem -- Looked at that web-page. Don't see a solution there. Wath is the solution ? Pieter.Donche@ua.ac.be ---------------------------------------------------------------------- Comment By: Donche, Pieter (pdon) Date: 2003-05-08 03:20 Message: Logged In: YES user_id=774177 SUN Sparc Enterprise 2170 Solaris 2.8 gcc 3.2 Downloaded expat-1.95.6.tar.gz ./configure, make, make install OK Downloaded Sablot-0.98.tar.gz (Sablotron package, from www.gingerall.com) ./configure says: ... checking expat.h presence... yes expat.h: present but cannot be compiled expat.h: check for missing prerequisite headers? expat.h: proceeding with the preprocessor's result ##-------------------------------------------------## ## Report this to bug-autoconf@gnu.org ## ##-------------------------------------------------## checking for expat.h... yes checking wether expat.h is broken... yes error: You probably have expat version 1.95.6. Please refer to http://sourceforge.net/tracker/index.php? func=detail&aid=676844&group_id=10127&atid=110127 for a description of the problem -- Looked at that web-page. Don't see a solution there. Wath is the solution ? Pieter.Donche@ua.ac.be ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-04-16 09:59 Message: Logged In: YES user_id=290026 Changed priority to highest to make it more visible, so that double reporting incidents occur less frequently. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-03-27 05:42 Message: Logged In: NO Same problem and the same fix under Linux and gcc 2.95.2. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-03-07 06:20 Message: Logged In: NO same problem, same fix when building 1.95.6 on vms (just downloaded .tar.gz & processed - got the rpm, but don't know what to do with it - not an archive type I know how to handle on vms, or windows either) - chris.sharman@ccagroup.co.uk ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-28 21:03 Message: Logged In: YES user_id=290026 Strange - I had no problems with MS VC++ 6.0. Which service pack level have you applied? ---------------------------------------------------------------------- Comment By: Jacob Levy (jyljyljyl) Date: 2003-02-28 20:35 Message: Logged In: YES user_id=63723 This makes Expat 1.95.6 unusable for people who create libraries that depend on Expat but don't include their own copy of Expat. Sure, I can edit expat.h and fix it, but my users should not be expected to do that. For that reason I'm staying with Expat 1.95.5 until this problem is fixed. It'd be really nice if you could make Expat 1.95.7 soon.. In my case GCC 2.95.2 and VC++ 6.0 are complaining. ---------------------------------------------------------------------- Comment By: Melvyn Sopacua (nyvlem) Date: 2003-02-14 02:56 Message: Logged In: YES user_id=212431 Yes, that works. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-06 15:47 Message: Logged In: YES user_id=290026 But current CVS works for you, right? ---------------------------------------------------------------------- Comment By: Melvyn Sopacua (nyvlem) Date: 2003-02-06 15:17 Message: Logged In: YES user_id=212431 > So far only gcc3.2 has complained. Nope: /usr/local/include/expat.h:657: use of enum `XML_Status' without previous declaration /usr/local/include/expat.h:736: multiple definition of `enum XML_Status' gmake[2]: *** [context.lo] Error 1 gmake[2]: Leaving directory `/home/mdev/cvs/sablot/src/engine' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/mdev/cvs/sablot/src' gmake: *** [all-recursive] Error 1 $ gcc --version 2.95.3 ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-01-31 09:43 Message: Logged In: YES user_id=290026 It *is* fixed in CVS. Are you sure you checked out the right version, which is expat.h 1.51? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-01-31 05:34 Message: Logged In: NO I just got the same error, already fixed it. But don't understand why it isn't fixed in CVS ? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-01-29 13:44 Message: Logged In: YES user_id=3066 I've not checked the C89 standard yet, but Expat 1.95.6 is certainly dodgy in this case. ;-( The first draft of the C spec I found online certainly seemed to imply that any use of an incomplete enum is not allowed; I'm not likely to go out and buy a copy of the final spec to check further. ;-) As noted, this has been fixed in CVS. Fixed the summary to better indicate what this report is about, and lowered the priority to get it out of the way for maintainers. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-01-29 10:51 Message: Logged In: YES user_id=290026 So far only gcc3.2 has complained. Not sure if this is a bug, since most compilers accept it, but it has been fixed in CVS already anyway. Set resolution status to fixed, but leave open. There may be other users who would report this as a bug and I want them to see the open report instead of having duplicates created. Assigned to Fred - since he may know more about whether this truly is a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=676844&group_id=10127 From noreply at sourceforge.net Tue Oct 21 02:48:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 21 02:48:39 2003 Subject: [Expat-bugs] [ expat-Bugs-827319 ] Makefile.in doesn't let configure set mandir Message-ID: Bugs item #827319, was opened at 2003-10-21 00:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=827319&group_id=10127 Category: Build control Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bryan Blackburn (blb) Assigned to: Greg Stein (gstein) Summary: Makefile.in doesn't let configure set mandir Initial Comment: Makefile.in specifically uses ${prefix}/man/man1 for the mandir variable, instead of allowing configure to override. The attached patch corrects this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=827319&group_id=10127 From noreply at sourceforge.net Wed Oct 22 16:47:34 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 22 16:47:47 2003 Subject: [Expat-bugs] [ expat-Bugs-828485 ] expat_win32 bin built with /MT instead of /MD Message-ID: Bugs item #828485, was opened at 2003-10-22 13:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=828485&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: expat_win32 bin built with /MT instead of /MD Initial Comment: With version 1.95.7, the expat_win32 binaries are built with /MT (multi-threaded libraries linked-in). This is also the default in the expat 1.95.7 Visual Studio project. The README.txt says "By default the Expat Dlls are built to link with the multi-threaded run-time Dll." ... that is /MD, which is also what I'd expect. Bernard bernard@zeroc.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=828485&group_id=10127 From noreply at sourceforge.net Wed Oct 22 20:26:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 22 20:27:19 2003 Subject: [Expat-bugs] [ expat-Bugs-828485 ] expat_win32 bin built with /MT instead of /MD Message-ID: Bugs item #828485, was opened at 2003-10-22 16:47 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=828485&group_id=10127 Category: Build control Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: expat_win32 bin built with /MT instead of /MD Initial Comment: With version 1.95.7, the expat_win32 binaries are built with /MT (multi-threaded libraries linked-in). This is also the default in the expat 1.95.7 Visual Studio project. The README.txt says "By default the Expat Dlls are built to link with the multi-threaded run-time Dll." ... that is /MD, which is also what I'd expect. Bernard bernard@zeroc.com ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-22 20:26 Message: Logged In: YES user_id=290026 Thanks for pointing out these inconsistencies. As far as default options are concerned: I think we should leave it as /MT as this does not force one to include MSVCRTxx.DLL in the distribution. So what should be fixed is the documentation. In any case, it's easy to change for a custom build. Are there good reasons to do it differently? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=828485&group_id=10127 From noreply at sourceforge.net Thu Oct 23 22:03:55 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 23 22:04:14 2003 Subject: [Expat-bugs] [ expat-Bugs-828485 ] expat_win32 bin built with /MT instead of /MD Message-ID: Bugs item #828485, was opened at 2003-10-22 16:47 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=828485&group_id=10127 Category: Build control Group: None Status: Open >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: expat_win32 bin built with /MT instead of /MD Initial Comment: With version 1.95.7, the expat_win32 binaries are built with /MT (multi-threaded libraries linked-in). This is also the default in the expat 1.95.7 Visual Studio project. The README.txt says "By default the Expat Dlls are built to link with the multi-threaded run-time Dll." ... that is /MD, which is also what I'd expect. Bernard bernard@zeroc.com ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-23 22:03 Message: Logged In: YES user_id=290026 Corrected documentation - ReadMe files in BCB5 and Win32 directories. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-22 20:26 Message: Logged In: YES user_id=290026 Thanks for pointing out these inconsistencies. As far as default options are concerned: I think we should leave it as /MT as this does not force one to include MSVCRTxx.DLL in the distribution. So what should be fixed is the documentation. In any case, it's easy to change for a custom build. Are there good reasons to do it differently? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=828485&group_id=10127 From noreply at sourceforge.net Sun Oct 26 01:25:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 26 01:26:30 2003 Subject: [Expat-bugs] [ expat-Bugs-830367 ] Multiple Calls to XML_ParserFree Message-ID: Bugs item #830367, was opened at 2003-10-25 23:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=830367&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Multiple Calls to XML_ParserFree Initial Comment: Version: 1.95.7 Calling XML_ParserFree on the same parser object multiple times causes an access violation error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=830367&group_id=10127 From noreply at sourceforge.net Sun Oct 26 02:54:51 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 26 02:55:05 2003 Subject: [Expat-bugs] [ expat-Bugs-830367 ] Multiple Calls to XML_ParserFree Message-ID: Bugs item #830367, was opened at 2003-10-26 01:25 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=830367&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Multiple Calls to XML_ParserFree Initial Comment: Version: 1.95.7 Calling XML_ParserFree on the same parser object multiple times causes an access violation error. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-26 02:54 Message: Logged In: YES user_id=290026 That is because you are not supposed to do that. Just like you are not supposed to free any allocated memory more than once. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=830367&group_id=10127 From noreply at sourceforge.net Sun Oct 26 03:22:25 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 26 03:24:05 2003 Subject: [Expat-bugs] [ expat-Bugs-830367 ] Multiple Calls to XML_ParserFree Message-ID: Bugs item #830367, was opened at 2003-10-26 01:25 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=830367&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Multiple Calls to XML_ParserFree Initial Comment: Version: 1.95.7 Calling XML_ParserFree on the same parser object multiple times causes an access violation error. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-26 03:22 Message: Logged In: YES user_id=290026 However, your report made me see that XML_ParserFree() is not null-safe, that is, it does not check its argument for Null. Now, this is not the case you described, but if you nulled every pointer that you freed, then you could pass the same pointer variable to XML_ParserFree() again, and the null test would prevent an access violation. I just checked in a fix (xmlparse.c rev. 1.118). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-26 02:54 Message: Logged In: YES user_id=290026 That is because you are not supposed to do that. Just like you are not supposed to free any allocated memory more than once. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=830367&group_id=10127 From noreply at sourceforge.net Sun Oct 26 13:31:50 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 26 13:32:09 2003 Subject: [Expat-bugs] [ expat-Bugs-830367 ] Multiple Calls to XML_ParserFree Message-ID: Bugs item #830367, was opened at 2003-10-26 01:25 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=830367&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Multiple Calls to XML_ParserFree Initial Comment: Version: 1.95.7 Calling XML_ParserFree on the same parser object multiple times causes an access violation error. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-26 13:31 Message: Logged In: YES user_id=290026 Closed - not a bug. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-26 03:22 Message: Logged In: YES user_id=290026 However, your report made me see that XML_ParserFree() is not null-safe, that is, it does not check its argument for Null. Now, this is not the case you described, but if you nulled every pointer that you freed, then you could pass the same pointer variable to XML_ParserFree() again, and the null test would prevent an access violation. I just checked in a fix (xmlparse.c rev. 1.118). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-26 02:54 Message: Logged In: YES user_id=290026 That is because you are not supposed to do that. Just like you are not supposed to free any allocated memory more than once. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=830367&group_id=10127 From macro at ds2.pg.gda.pl Thu Oct 30 11:29:17 2003 From: macro at ds2.pg.gda.pl (Maciej W. Rozycki) Date: Thu Oct 30 11:41:04 2003 Subject: [Expat-bugs] [patch] 1.95.7: --mandir doesn't work Message-ID: Hello, Due to an incorrect use of the mandir autoconf variable, the configure script's --mandir option doesn't work. Here is a trivial patch that fixes the problem for me. Please apply. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + expat-1.95.7-mandir.patch diff -up --recursive --new-file expat-1.95.7.macro/Makefile.in expat-1.95.7/Makefile.in --- expat-1.95.7.macro/Makefile.in 2003-10-16 04:51:11.000000000 +0000 +++ expat-1.95.7/Makefile.in 2003-10-30 16:09:40.000000000 +0000 @@ -30,7 +30,7 @@ exec_prefix = @exec_prefix@ bindir = @bindir@ libdir = @libdir@ includedir = @includedir@ -mandir = ${prefix}/man/man1 +mandir = @mandir@/man1 top_builddir = .