Problem with msvcrt60 vs. msvcr71 vs. strdup/free

[abkhd at earth.co.jp]

Martin v. Löwis wrote:
> Indeed, it *will* work most of the time, as you rarely pass resources
> across CRTs in a typical Python extension. However, it is very hard
> to tell from the source code of the extension if such resource
passing
> could ever happen (e.g. what about setlocale(), atexit(), malloc(),
> ...), so if you need something better than "seems to work", you
really
> need to make sure that you understand all the issues, and have a
build
> process that resolves them all.
>
> Regards,
> Martin




You know if I had not tried the example you gave, I'd probably still be
arguing: "but it works." Oh well. Not anymore.

For those who are interested, here is a patch to demo.c of the
\python\dist\src\Demo\embed\demo.c demonstrating what Martin has argued
about above. With such evidence at hand I guess it is safe to say that
the MinGW die-hards will have to improvise. :)

But seriously, and since I don't have the official Python 2.4
distribution yet, and since the pyMinGW compiled Python I use relies on
msvcrt, as opposed to msvcr71, I needed to reverse the roles here to
see the problem first hand: making the "extension" demo use msvcr71 to
see how it reacts with the home-made python24.dll which uses msvcrt.
And sure enough: crash.

Having said that, this seems to me not to be an issue for those who
have or can build Python and/or the extensions they need from sources.
Indeed recompiling the same "demo" to use msvcrt (to use the same
run-time library that my python24.dll uses) instead of msvcr71 yields
the expected correct results without crashes.

And so I suspect this approach (compiling sources yourself) can shield
people from this ugly mess, if they can build Python 2.4 and the
extensions and have them (core and extension) use one and the same
run-time library. But indeed this might be an issue for those who [1]
use MinGW as their first choice and [2] cannot or won't bother to build
their Python and/or extensions from sources, and hence have to rely on
binary distributions.


Regards
Khalid



--- demo.c	Sat Nov 17 08:30:20 2001
+++ demo2.c	Thu Dec 23 02:02:40 2004
@@ -34,6 +34,20 @@
/* Note that you can call any public function of the Python
interpreter here, e.g. call_object(). */

+    FILE *in;
+    int sts;
+
+    if ((in = fopen(argv[1], "rt")) == NULL) {
+      fprintf(stderr, "Cannot open program file.\n");
+      return 1;
+    }
+
+    printf("Working on %s\n", argv[1]);
+    sts = PyRun_AnyFile(in, argv[1]) != 0;
+    printf("sts: %d\n", sts);
+    fclose(in);
+
+
/* Some more application specific code */
printf("\nGoodbye, cruel world\n");