Serhiy Storchaka added the comment:
> This doesn't seem very likely, since then the C implementation wouldn't
> roundtrip when converting that other pointer to an integer and back to a
> pointer. (C99 6.3.2.3 says that (void *)0 is a null pointer constant.)
"0" lexeme is not 0 integer. In expression "(void*)0" "0" means null pointer.
You can't do printf("%p", 0), because in this case compiler does not know what
0 you have in mind.
> The code you removed is not undefined behaviour, and is not just an
> optimization---removing it would change the semantics of
> PyLong_FromVoidPtr. There may be code that depends on
> PyLong_FromVoidPtr(NULL) being 0. I believe the code should stay.
I think it was wrong implementation, even if only in theoretical
considerations. I believe Python does not support platforms where it matters.
The removed code creates the impression that the problem is solved, but in
fact it is not. Yes, we can leave it, but it doesn't make sense.
> > What about (Py_uintptr_t)p - (Py_uintptr_t)(void *)NULL?
> What about it? What's the relevance to this issue?
This provides the invariant PyLong_FromVoidPtr(NULL) == PyLong_FromLong(0) and
does not cost anything on platforms where (Py_uintptr_t)(void *)NULL == 0.
----------
_______________________________________
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
