Martin v. Löwis wrote:
>> You mean if it were fixed it could fail, right? Code calling it should
>> be checking for errors anyway because it allocates memory.
>>
>> Have you tried making this particular change and seeing what fails?
>
> I now tried, and it turned out that bytes.__reduce__ would break
> (again); I fixed it and changed it in r56755.
>
> It turned out that PyUnicode_FromString was even documented to
> accept latin-1.
Yes, that seemed to me to be the most obvious interpretion.
> While I was looking at it, I wondered why PyUnicode_FromStringAndSize
> allows a NULL first argument, creating a null-initialized Unicode
> object.
Because that's what PyString_FromStringAndSize() does.
> This functionality is already available as
> PyUnicode_FromUnicode, and callers who previously wrote
>
> obuf = PyString_FromStringAndSize(NULL, bufsize);
> if (!obuf)return NULL;
> buf = PyString_AsString(buf);
>
> could be tricked into believing that they now can change the
> string object they just created - which they cannot, as
> buf will just be the UTF-8 encoded version of the real string.
True, this will no longer work.
So should NULL support be dropped from PyUnicode_FromStringAndSize()?
Servus,
Walter
_______________________________________________
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
