> 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.

"Valid content" doesn't mean a lot when the length is 0.
What is a valid 0-length string compared to an invalid one?
What if the pointer is non-NULL but segfaults when trying to dereference
it? Is it "valid"?

Moreover, malloc() is allowed by POSIX to return NULL when called with a
0 length:

        If size is 0, either a null pointer or a unique pointer that can
        be successfully passed to free() shall be returned.

(http://www.opengroup.org/onlinepubs/007904875/functions/malloc.html)

... which means that such a pointer can then, depending on the platform,
get passed (legitimately) to PyUnicode_Decode().

So, IMO, practicality beats purity here. Especially since it is bound to
land in a bugfix release (3.2.1), which users don't expect to produce
regressions in their own code.

OTOH, I agree that a NULL pointer combined with non-0 length could
produce an explicit error.