Double-fix of crash in Unicode freelist handling.
If a length-1 Unicode string was in the freelist and it was
uninitialized or pointed to a very large (magnitude) negative number,
the check
unicode_latin1[unicode->str[0]] == unicode
could cause a segmentation violation, e.g. unicode->str[0] is 0xcbcbcbcb.
Fix this in two ways:
1. Change guard befor unicode_latin1[] to test against 256U. If I
understand correctly, the unsigned long used to store UCS4 on my
box was getting converted to a signed long to compare with the
signed constant 256.
2. Change _PyUnicode_New() to make sure the first element of str is
always initialized to zero. There are several places in the code
where the caller can exit with an error before initializing any
of str, which would leave junk in str[0].
Also, silence a compiler warning on pointer vs. int arithmetic.
Bug fix candidate.
diff --git a/Misc/NEWS b/Misc/NEWS
index 6f9855c..7ffe521 100644
--- a/Misc/NEWS
+++ b/Misc/NEWS
@@ -12,6 +12,11 @@
Core and builtins
-----------------
+- Fixed a bug in the cache of length-one Unicode strings that could
+ lead to a seg fault. The specific problem occurred when an earlier,
+ non-fatal error left an uninitialized Unicode object in the
+ freelist.
+
- The % formatting operator now supports '%F' which is equivalent to
'%f'. This has always been documented but never implemented.