STINNER Victor <victor.stin...@gmail.com> added the comment: "PR 4119 is too complex for a bugfix (especially if backport it to 3.5 and 3.4). It can introduce other regressions."
Which kind of regression do you expect? Something like a crash? "The performance hit is not the only issue. Allocating a temporary buffer can change the structure of "holes" in memory. As result some memory related bugs can be reproducible only in release mode." Can you please elaborate how the exact memory layout can trigger or not bugs in the code? I'm not saying that you are right or wrong. I just fail to see why the memory address and "holes" would trigger or not bugs. What I can understand is a subtle behaviour change if realloc() returns the same memory block or a new memory block. But we cannot control that. I'm not sure that allocating "copy" before realloc() would impact the behaviour of realloc(). The common case is that a memory block is a few bytes smaller, and so the realloc returns the same memory block, but now becomes able to use the unallocated bytes for a new allocation later, no? "Maybe it is enough to erase only few bytes at the start and end of the freed area. The copy can be saved in local variables, without involving the heap. This solution still will be enough complex, and I think it can be applied only to 3.7. But the bug should be fixed in all affected versions." If we must make a choice, I would prefer to keep the current behaviour: make sure that unallocated bytes are erased. Catching code reading unallocated bytes is the most important feature of debug hooks, no? I dislike the idea of only erasing "some" bytes: this change may prevent to detect some bugs. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31626> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
