➜

This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mark.dickinson
Recipients mark.dickinson, serhiy.storchaka
Date 2012-10-18.14:03:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1350569013.6.0.550534957781.issue16277@psf.upfronthosting.co.za>
In-reply-to
Content 
> If on some platform (uintptr_t)NULL != 0, then some other address can be 
> reflected to 0.

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.)

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.

> What about (Py_uintptr_t)p - (Py_uintptr_t)(void *)NULL?

What about it?  What's the relevance to this issue?
History
Date User Action Args
2012-10-18 14:03:33mark.dickinsonsetrecipients: + mark.dickinson, serhiy.storchaka
2012-10-18 14:03:33mark.dickinsonsetmessageid: <1350569013.6.0.550534957781.issue16277@psf.upfronthosting.co.za>
2012-10-18 14:03:33mark.dickinsonlinkissue16277 messages
2012-10-18 14:03:33mark.dickinsoncreate