GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
GeezerVison is showing github.com — gh-120754: Ensure _stat_atopen is cleared on fd change by cmaloney · Pull Request #125166 · python/cpython Conversation
|
| if (internal_close(self) < 0) | ||
| /* Have to close the existing file first. | ||
|
|
||
| This leaves the stat so we can reuse the memory. */ |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
I don't think that this optimization is worth it, I would prefer to always clear the cache in close().
Sorry, something went wrong.
There was an error while loading. Please reload this page.
| #endif | ||
| } | ||
|
|
||
| PyMem_Free(self->stat_atopen); |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Not sure which is preferred here. The Free + New back to back feels weird, but version with the conditional feels like "extra work/code that should never be executed" (but that the compiler / tools that run currently won't validate...).
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Maybe if (ptr != NULL) free(ptr) would be more regular and avoid the 4 lines long comment.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Moved to that, dropped comment and simplified / back to always calling PyMem_New
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
There are compiler warnings that you can see in the review tab.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
|
I think the latest commit fixes the compiler warnings (was a testing/debugging assert I accidentally committed with a missing |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
|
CI "Tests / Ubuntu SSL tests with OpenSSL" failed because of what looks like a network hang / not these changes: |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
| } | ||
| } | ||
| PyMem_Free(self->stat_atopen); | ||
| self->stat_atopen = NULL; |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
internal_close() already does the same, so it's redundant, no?
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Tradeoff for matching what _pyio does which does os.close() in these cases vs an internal_close that does the OS close + other cleanup. Happy to drop though / definitely feels redundant to me in these two cases.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
| #endif | ||
| if (self->fd >= 0) { | ||
| PyMem_Free(self->stat_atopen); | ||
| self->stat_atopen = NULL; |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
internal_close() already does the same, so it's redundant, no?
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Moderately, in the self->closefd is false case behavior would differ from _pyio, but that will be caught by the PyMem_Free + PyMem_New below, so think this is always redundant / not needed
Sorry, something went wrong.
There was an error while loading. Please reload this page.
| } | ||
|
|
||
| PyMem_Free(self->stat_atopen); | ||
| if (self->stat_atopen != NULL) { |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
PyMem_Free(NULL) is well defined: it does nothing, so you might omit the if (stat_atopen != NULL) test.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
Merged, thank you. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
…n#125166) Performed an audit of `fileio.c` and `_pyio` and made sure anytime the fd changes the stat result, if set, is also cleared/changed. There's one case where it's not cleared, if code would clear it in __init__, keep the memory allocated and just do another fstat with the existing memory.
…n#125166) Performed an audit of `fileio.c` and `_pyio` and made sure anytime the fd changes the stat result, if set, is also cleared/changed. There's one case where it's not cleared, if code would clear it in __init__, keep the memory allocated and just do another fstat with the existing memory.
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
There was an error while loading. Please reload this page.