Marc-Andre Lemburg <m...@egenix.com> added the comment: Antoine Pitrou wrote: > > Antoine Pitrou <pit...@free.fr> added the comment: > >> * Unicode objects are NUL-terminated, but only very external APIs >> rely on this (e.g. code using the Windows Unicode API). Please >> don't make the code in unicodeobject.c itself rely on this >> subtle detail. > > That's wishful thinking, don't you think? *I* am not making code in > unicodeobject.c rely on this. It has been so for years, long before I > was here. You should check who made that design decision in the first > place instead of putting the blame on me.
I'm not blaming you for this. However, I don't want more code to rely on this behavior. The NUL-termination has never been documented and my decision to use NUL-termination on the PyUnicodeObject buffers was merely a safety measure. > Besides, the fact that external APIs rely on it make it much more > unchangeable than if it were an implementation detail. It's an undocumented implementation detail. We can certainly deprecate it's use using the standard approach we have for this. But all that is off-topic for this ticket, since codecs operate on Py_UNICODE* buffers together with a size parameter and relying on those buffers being NUL-terminated is bound to cause problems. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue8821> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
