martin at v
Aug 25, 2012, 10:02 AM
Post #9 of 12
> Compatibility issues may lead to other strange bugs, too. IIRC each
> msvcrt has its own thread local storage and therefore its own errno
> handling. An extension compiled with VS 2010 won't be able to use the
> PyErr_SetFromErrno*() function correctly. That's much harder to debug
> than a FILE pointer mismatch because it usually doesn't cause a segfault.
Interesting point. This somewhat breaks the stable ABI, which does
include three SetFromErrno functions. So I guess we need to warn users
of the stable ABI against using these functions.
A solution would then be to add an additional set of functions which
expect errno as a parameter, although this is quite some complication.
Another solution is to introduce a Py_errno macro (and _Py_errno
function) which exposes Python's view of errno, so code that might
be confronted with this issue would write
Py_errno = errno;
before calling any of these functions.
Except for the FILE* issue, I never considered any of the other issues
really relevant for Python extensions, namely:
- each CRT has its own heap, allocating on one heap and releasing to
the other can leak. Not an issue for Python, since no Python API
involves malloc/free pairs across DLL boundaries.
- each CRT has its own timezone. This isn't really an issue, as they
still get initialized consistently when the process starts (I guess
except when the process starts before the DST change, but imports
the extension after the DST change).
- each CRT has its own locale. This may be an issue if an extension
module relies on the CRT locale for data formatting; I just think
this is unlikely to occur in practice (and when it does, it's easily
Anything else that you are aware of?
Python-Dev mailing list
Python-Dev [at] python