Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

Martin v. Loewis martin at v.loewis.de
Wed Jul 7 15:10:43 EDT 2010


> Python 3.1.1, file [pymem.h]:
> 
> PyAPI_FUNC(void *) PyMem_Malloc(size_t);
> 
> #define PyMem_MALLOC(n)        (((n) < 0 || (n) > PY_SSIZE_T_MAX) ? NULL \
>                 : malloc((n) ? (n) : 1))
> 
> The problem with the latter that it seems that it's intended for safety
> but does the opposite...

Why do you say that? It certainly *does* achieve safety, wrt. to certain
errors, specifically:
- passing sizes that are out-of-range
- supporting malloc(0) on all systems


> Perhaps (if it isn't intentional) this is a bug of the oversight type,
> that nobody remembered to update the macro?

Update in what way?

> Except for the problems with file descriptors I think a practical
> interim solution for extensions implemented in C could be to just link
> the runtime lib statically. For a minimal extension this increased the
> size from 8 KiB to 49 KiB. And generally with MS tools the size is
> acceptably small.

If you think that's fine for your extension module (which may well be
the case), go ahead. But then, you could also just link with a different
DLL version of the CRT instead.

> I think that this would be safe because since the C API has to access
> things in the interpreter I think it's a given that all the relevant
> functions delegate to shared library (DLL) implementations, but I have
> not checked the source code.

There are certainly more cases than the ones mentioned so far, in
particular the time zone and the locale. The CRT carries global
variables for these, so if you set them in the copy of the CRT that
Python links with, you won't see the change in your extension module -
which may or may not be a problem.

> As a more longterm solution, perhaps python.org could make available the
> redistributables for various MSVC versions, and then one could introduce
> some scheme for indicating the runtime lib dependencies of any given
> extension.

My preferred long-term solution is to reduce the usage of the C library
in CPython as much as reasonable, atleast on Windows. Memory management
could directly use the heap functions (or even more directly
VirtualAlloc); filenos could be OS handles, and so on. There are
probably limitations to what you can achieve, but I think it's worth trying.

Regards,
Martin



More information about the Python-list mailing list