[Fredrik Lundh] > any reason why the > > #ifdef MALLOC_ZERO_RETURNS_NULL > > macro (in pyport.h) isn't set / doesn't take care of this? The code uses PyMem_MALLOC, which after a chain of umpteen #defines ends up being plain malloc. As Michael noted in the bug report, it could have used PyMem_Malloc() instead and avoided the problem. But I chose not to do that, since special-casing a result of 0 was more efficient for reasons other than malloc. However: > (and is it just me, or does the strop.replace function allocate > a buffer, copy the result to that buffer, only to copy it into a > string and throw the buffer away? Yes. And I'm returning something now that musn't be free()'ed when the result length is 0. Will fix. > no wonder u"".replace() is 30% faster than "".replace() ;-) For a given number of characters or bytes <wink>?
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4