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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com