-
-
Notifications
You must be signed in to change notification settings - Fork 31.8k
gh-117968: Make the test for closed file more safe in the C API tests #118230
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
… tests The behavior of fileno() after fclose() is undefined, but it is the only practical way to check whether the file was closed. Only test this on the known platforms (Linux, Windows, macOS), where we already tested that it works.
!buildbot wasi |
🤖 New build scheduled with the buildbot fleet by @serhiy-storchaka for commit e30956b 🤖 The command will test the builders whose names match following regular expression: The builders matched are:
|
Thanks @serhiy-storchaka for the PR 🌮🎉.. I'm working now to backport this PR to: 3.12. |
… tests (pythonGH-118230) The behavior of fileno() after fclose() is undefined, but it is the only practical way to check whether the file was closed. Only test this on the known platforms (Linux, Windows, macOS), where we already tested that it works. (cherry picked from commit 546cbcf) Co-authored-by: Serhiy Storchaka <[email protected]>
GH-118266 is a backport of this pull request to the 3.12 branch. |
…I tests (GH-118230) (GH-118266) The behavior of fileno() after fclose() is undefined, but it is the only practical way to check whether the file was closed. Only test this on the known platforms (Linux, Windows, macOS), where we already tested that it works. (cherry picked from commit 546cbcf) Co-authored-by: Serhiy Storchaka <[email protected]>
|
The behavior of fileno() after fclose() is undefined, but it is the only practical way to check whether the file was closed. Only test this on the known platforms (Linux, Windows, macOS), where we already tested that it works.