]> granicus.if.org Git - python/commit
Double-fix of crash in Unicode freelist handling.
authorJeremy Hylton <jeremy@alum.mit.edu>
Tue, 16 Sep 2003 19:41:39 +0000 (19:41 +0000)
committerJeremy Hylton <jeremy@alum.mit.edu>
Tue, 16 Sep 2003 19:41:39 +0000 (19:41 +0000)
commitd808279be3850f085b02a5a612246f90daf31ecc
tree70a2b87244ac2f7b9434d41744d1a69703bd47c1
parenta9e14b70150d5bc064afd3144097ec0095869f10
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.
Misc/NEWS
Objects/unicodeobject.c