[issue42569] Callers of _Py_fopen/_Py_wfopen may be broken after addition of audit hooks

Alexey Izbyshev added the comment: Great approach :) -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42569] Callers of _Py_fopen/_Py_wfopen may be broken after addition of audit hooks

STINNER Victor added the comment: I wrote PR 23711 (for bpo-32381) which removes half of the problem: it removes _Py_fopen() :-) -- ___ Python tracker ___

[issue42569] Callers of _Py_fopen/_Py_wfopen may be broken after addition of audit hooks

Steve Dower added the comment: Good point, we can make it set errno as well. Any generic error is fine (I don't know them off the top of my head), because it will chain up to the one set by the hook. -- ___ Python tracker

[issue42569] Callers of _Py_fopen/_Py_wfopen may be broken after addition of audit hooks

Alexey Izbyshev added the comment: > So it should be, "if they fail and you're in a context where exceptions are > allowed, raise an exception" (which will chain back to the one raised from an > audit hook". What exception should be raised if _Py_fopen() fails (returns NULL)? We can't just

[issue42569] Callers of _Py_fopen/_Py_wfopen may be broken after addition of audit hooks

STINNER Victor added the comment: > In Windows, the fopen() and _wfopen() calls here should use the non-standard > "N" flag [1] to open a non-inheritable file descriptor and skip calling > set_inheritable(). Interesting. Do you want to propose a PR to enhance the Python implementation?

[issue42569] Callers of _Py_fopen/_Py_wfopen may be broken after addition of audit hooks

Eryk Sun added the comment: > To implement PEP 446: create non-inheritable file descriptors. Side note. That aspect is still wonky in Windows, for which set_inheritable() cannot be implemented reliably since there's no way to change whether an existing CRT file descriptor is inheritable.

[issue42569] Callers of _Py_fopen/_Py_wfopen may be broken after addition of audit hooks

Steve Dower added the comment: If the GIL is not held, no exception should be raised, so the fact that you've got one there means that the GIL is held and the main.c-specific error message is the bit that's wrong. So it should be, "if they fail and you're in a context where exceptions are

[issue42569] Callers of _Py_fopen/_Py_wfopen may be broken after addition of audit hooks

Alexey Izbyshev added the comment: > To implement PEP 446: create non-inheritable file descriptors. Yes, I understand that was the original role. But currently there is no easy way to deal with errors from the helpers because of exception vs. errno conundrum. Maybe they should be split to

[issue42569] Callers of _Py_fopen/_Py_wfopen may be broken after addition of audit hooks

STINNER Victor added the comment: > Understanding that seems to be required to deal with issue 32381. I wrote PR 23642 to fix bpo-32381. -- ___ Python tracker ___

[issue42569] Callers of _Py_fopen/_Py_wfopen may be broken after addition of audit hooks

STINNER Victor added the comment: > Could somebody share the current intended status/role of these helpers? To implement PEP 446: create non-inheritable file descriptors. -- ___ Python tracker

[issue42569] Callers of _Py_fopen/_Py_wfopen may be broken after addition of audit hooks

New submission from Alexey Izbyshev : Before addition of audit hooks in 3.8, _Py_fopen() and _Py_wfopen() were simple wrappers around corresponding C runtime functions. They didn't require GIL, reported errors via errno and could be safely called during early interpreter initialization.