[Python-Dev] PEP 393 review
Stefan Behnel
stefan_ml at behnel.de
Fri Aug 26 17:55:05 CEST 2011
Stefan Behnel, 25.08.2011 23:30:
> Sadly, a quick look at a couple of recent commits in the pep-393 branch
> suggested that it is not even always obvious to you as the authors which
> macros can be called safely and which cannot. I immediately spotted a bug
> in one of the updated core functions (unicode_repr, IIRC) where
> PyUnicode_GET_LENGTH() is called without a previous call to
> PyUnicode_FAST_READY().
Here is another example from unicodeobject.c, commit 56aaa17fc05e:
+ switch(PyUnicode_KIND(string)) {
+ case PyUnicode_1BYTE_KIND:
+ list = ucs1lib_splitlines(
+ (PyObject*) string, PyUnicode_1BYTE_DATA(string),
+ PyUnicode_GET_LENGTH(string), keepends);
+ break;
+ case PyUnicode_2BYTE_KIND:
+ list = ucs2lib_splitlines(
+ (PyObject*) string, PyUnicode_2BYTE_DATA(string),
+ PyUnicode_GET_LENGTH(string), keepends);
+ break;
+ case PyUnicode_4BYTE_KIND:
+ list = ucs4lib_splitlines(
+ (PyObject*) string, PyUnicode_4BYTE_DATA(string),
+ PyUnicode_GET_LENGTH(string), keepends);
+ break;
+ default:
+ assert(0);
+ list = 0;
+ }
The assert(0) at the end will hit when the system is running out of memory
while working on a wchar string.
Stefan
More information about the Python-Dev
mailing list