Mark Dickinson added the comment: > "0" lexeme is not 0 integer.
Ah yes, true. C99 6.3.2.3 specifies an "integer *constant* expression". So I was mistaken in thinking that converting an arbitrary integer-valued expression with value 0 to (void*) must always give a NULL pointer. > I think it was wrong implementation, even if only in theoretical > considerations. 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? If you agree with those two things, then this is a behaviour change, not a bugfix, and you should open a new issue aimed at 3.4 for that. > I believe Python does not support platforms where it matters. What's your justification for this belief? > This provides the invariant PyLong_FromVoidPtr(NULL) == PyLong_FromLong(0) > and does not cost anything on platforms where (Py_uintptr_t)(void *)NULL == 0. 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. ---------- _______________________________________ 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
