Marc-Andre Lemburg <m...@egenix.com> added the comment: Antoine Pitrou wrote: > > 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().
... and Python has for years made sure that PyMem_Malloc() et al. return a non-NULL pointer when passed a size 0 value (see pymem.h for details), since the above was a really poor design choice. A lot of Python code relies on those functions returning NULL only in case of an error. > 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. Nope. Your suggestion would be a new feature and those are not allowed in patch level releases. I'm -1 on the idea for the reasons already stated. ---------- 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
