* sturlamolden, on 06.07.2010 19:35:
On 6 Jul, 19:09, Thomas Jollans<tho...@jollans.com> wrote:
Okay, you need to be careful with FILE*s. But malloc and free? You'd
normally only alloc& free something within the same module, using the
same functions (ie not mixing PyMem_Malloc and malloc), would you not?
You have to be sure PyMem_Malloc is not an preprocessor alias for
malloc (I haven't chaecked).
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...
Perhaps (if it isn't intentional) this is a bug of the oversight type, that
nobody remembered to update the macro?
***
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.
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.
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. Then
when installing an extension the installer (distutils package functionality)
could just check whether the required runtime is present, and if not give the
user the choice of automatically downloading from python.org, or perhaps direct
from Microsoft. This scheme would support dependencies on new runtime lib
versions not yet conceived when the user's version of Python was installed.
Cheers,
- Alf
--
blog at <url: http://alfps.wordpress.com>
--
http://mail.python.org/mailman/listinfo/python-list
