Antoine Pitrou <pit...@free.fr> added the comment:
> 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.
----------
title: Some "trivial" python 2.x pickles fails to load in Python 3.2 ->
Some "trivial" python 2.x pickles fails to load in Python 3.2
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
