Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou@free.fr> added the comment:
> 
>> Antoine Pitrou wrote:
>>>
>>> Antoine Pitrou <pitrou@free.fr> added the comment:
>>>
>>>>> I am not sure PyUnicode_Decode() should treat NULL as an empty string.
>>>>
>>>> Definitely not. That would hide programming errors.
>>>
>>> Well, this could break some third-party code.
>>
>> If that code passes NULL in as buffer s, that 3rd party code is
>> already broken and the patch would hide this fact.
> 
> Why broken? Passing NULL as a pointer and 0 as the length doesn't sound
> "broken".
> Other APIs such as PyString_FromStringAndSize() allow exactly this
> convention.

Right. They allow for this because those are object constructors
that allow for creating objects without pre-defined content
(hence the NULL). The 0 length feature is just a side-effect,
not the main reason why we allow NULLs to be passed in as
content buffer to those constructors.

PyUnicode_Decode() et al. are conversion functions and these
require valid content to work on. Passing in a NULL pointer
does not fit that specification and so allowing for this
would hide programming errors.

E.g. an application using PyUnicode_Decode()
might have hit a C lib error and forgets to check the pointer
for NULL. It then calls PyUnicode_Decode() and the application
continues happily without reporting the error.

That's a broken application.