This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Add Py_errno to work around multiple CRT issue
Type: enhancement Stage: resolved
Components: Build, Extension Modules, Interpreter Core, Windows Versions: Python 3.5
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: BreamoreBoy, christian.heimes, georg.brandl, jcea, loewis, pitrou, ronaldoussoren, steve.dower, tim.golden, zach.ware
Priority: normal Keywords: patch

Created on 2012-09-08 13:35 by christian.heimes, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
pyerrno.patch christian.heimes, 2012-09-08 13:35 review
Messages (7)
msg170050 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2012-09-08 13:35
errno is usually implemented as thread local variable, more precisely as a macro that calls a function which returns the memory address of a thread local variable. Each C runtime library has its own function and TLS which introduces an issue when a Python extension uses a different CRT than the core. AFAIK that an issue only an issue on Windows with other versions of Visual Studio.

This means that mixed CRTs break the three PyErr_SetFromErrno* functions as they always access the errno of the core's CRT. The patch adds a Py_errno macro that must be used in extensions before a PyErr_SetFromErrno() function is used.

Example:
fd = open(filename, O_RDONLY);
if (fd == -1) {
    Py_errno = errno;
    return PyErr_SetFromErrnoWithFilename(PyExc_OSError, filename);
}

The issue was discovered by me a about two weeks ago and further analyzed by Martin. http://mail.python.org/pipermail/python-dev/2012-August/121460.html
msg170053 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2012-09-08 14:05
Since this is a new feature, it needs to go into 3.4.
msg191117 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2013-06-14 11:32
I'd prefer to have new variants of the PyErr_SetFromErrno* functions where the errno value is explicitly passed in instead of adding a side-channel for passing in the value.
msg191118 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-06-14 11:36
Agreed with Ronald.
msg222820 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2014-07-12 01:27
Am I imagining things or have I read that the Windows CRT is going to remain stable in the future, meaning this work would no longer be needed.
msg223036 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2014-07-14 15:38
Also agreed with not exposing a side-channel to set errno.

I'd expect this to no longer be an issue with the stable CRT, but I'm not 100% confident about saying that yet. In theory, there will only ever be one CRT loaded in the future, but there's probably going to still be situations where explicitly providing errno is necessary.
msg275701 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2016-09-10 21:30
It's no longer a problem with new VS.
History
Date User Action Args
2022-04-11 14:57:35adminsetgithub: 60087
2016-09-10 21:30:07christian.heimessetstatus: open -> closed
resolution: wont fix
messages: + msg275701

stage: patch review -> resolved
2014-07-14 15:38:15steve.dowersetmessages: + msg223036
2014-07-12 01:27:19BreamoreBoysetstatus: pending -> open

nosy: + tim.golden, BreamoreBoy, zach.ware, steve.dower
messages: + msg222820

components: + Windows
2013-12-04 07:21:12christian.heimessetstatus: open -> pending
versions: + Python 3.5, - Python 3.4
2013-06-14 11:36:31pitrousetmessages: + msg191118
2013-06-14 11:32:06ronaldoussorensetnosy: + ronaldoussoren
messages: + msg191117
2012-09-14 17:49:39terry.reedysettype: behavior -> enhancement
2012-09-10 02:17:59jceasetnosy: + jcea
2012-09-08 14:05:59loewissetmessages: + msg170053
versions: - Python 3.3
2012-09-08 13:35:02christian.heimescreate