Serhiy Storchaka added the comment: > For the second part, I don't see any undefined behaviour here. Can you > explain where the undefined behaviour comes from? And are you sure that > this is really just an optimization? It looks as though it might be > deliberately there to make sure that the conversion still produces a > Python 0 even on systems where the NULL pointer *doesn't* give 0 when > converted to an integer.
If on some platform (uintptr_t)NULL != 0, then some other address can be reflected to 0. In shuch case PyLong_FromVoidPtr() returns zero integer for both NULL and this non-NULL addresses. Of course this is a hypothetic situation. What about (Py_uintptr_t)p - (Py_uintptr_t)(void *)NULL? Then we should change PyLong_AsVoidPtr() too. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16277> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
