[Martin v. Löwis]
> ...
> I agree with Tim that, in no case, resize should be called for a
> garbage string - only valid strings (i.e. with truly allocated memory)
> should ever be resized.
unicode->str pointed to properly allocated memory in the failing cases, but
to uninitialized allocated memory. So str[0] was just some random
collection of bits from the heap, and checking
random bits < 256
wasn't enough to weed out the cases where the random bits happened to look
like a negative integer. For Jeremy, str[0] was 0xcbcbcbcb (for me it was
0xcbcb), and using that as an index blew up.
...
[Tim]
>> Or is there an implicit assumption that Py_UNICODE is always an
>> unsigned type (in which case, why isn't the literal 256U?
[Martin]
> Likely, the author of the code was subconsciously assuming
> so. However, that assumption is invalid, and sharing should only
> happen for ordinals in range(256).
I've since patched Jeremy's patch to try to live with that Py_UNICODE may be
a signed type too.
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