Jeremy Hylton <jeremy at zope.com> writes: > > Still, it doesn't look to me like the code *expected* that str could contain > > uninitialized heap trash at this point, so I'd like someone who thinks they > > understand this code to think about how that could happen (it apparently is > > happening, so "beats me" isn't good enough <wink>). > > I certainly don't understand the code yet. The code you quote is about the "singleton" Unicode character (i.e. those with code points < 256). If you create a Unicode object S with len(S)==1, and ord(S) < 256, you don't necessarily get a new object, but you may get an existing (cached) one. If you then apply PyUnicde_Resize to that object, you get an error because resizing that object would require changing all shared copies, which is bad because Unicode object are immutable. 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. Regards, Martin
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