Serhiy Storchaka added the comment: > Okay, but do you agree that (1) there's no undefined behaviour, and (2) > removing this code has the potential to change results on platforms where > converting NULL to an integer doesn't give zero?
Undefined behavior (or may be just the wrong behavior), we obtain later, when converting in PyLong_AsVoidPtr() zero integer back to pointer. On platforms where converting NULL to an integer doesn't give zero it's a bug. > > I believe Python does not support platforms where it matters. > What's your justification for this belief? Can you show the contrexample? I can not. If such a platform existed, perhaps this bug has been already shown it. > Sorry, but this is making no sense to me. You wrote: "(Py_uintptr_t)p - > (Py_uintptr_t)(void *)NULL". Is that supposed to be existing code that > you're proposing changing? An example to prove some point (what point?) > Code you're proposing to add somewhere? (If so, where are you proposing > to add it?) Why are you subtracting these two pointers? What's p? I'm > finding it hard to make sense of what you're writing. I mean using PyLong_FromUnsignedLongLong((unsigned PY_LONG_LONG) ((Py_uintptr_t)p - (Py_uintptr_t)(void *)NULL)) instead PyLong_FromUnsignedLongLong((unsigned PY_LONG_LONG)(Py_uintptr_t)p). Of course PyLong_AsVoidPtr() should be changed to return (void *)(x + (Py_uintptr_t) (void *)NULL) instead (void *)x. ---------- _______________________________________ 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
