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.

classification
Title: Inconsistency with PyLong_FromVoidPtr() and PyLong_AsVoidPtr()
Type: behavior Stage:
Components: Interpreter Core Versions: Python 3.2, Python 3.3, Python 3.4, Python 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: mark.dickinson Nosy List: mark.dickinson, python-dev, serhiy.storchaka
Priority: normal Keywords:

Created on 2012-10-18 20:36 by serhiy.storchaka, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (3)
msg173295 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2012-10-18 20:36
This issue is taken out of the discussion of issue16277.

PyLong_FromVoidPtr() has special case which maps null pointer to zero integer.

On platforms where (uintptr_t)(void *)0 is 0, this code has no effect and is redundant.  But on hypothetic platforms where (uintptr_t)(void *)0 is not 0, PyLong_FromVoidPtr() maps NULL to 0 and then PyLong_AsVoidPtr() maps 0 to non-NULL. Also PyLong_FromVoidPtr() is multivalued, it maps to 0 NULL and may be some other pointer.

PyLong_FromVoidPtr() in 2.7 has special case only on platform where sizeof(void*) > sizeof(long). It commented as "optimize null pointers". In 3.x branch such optimization non needed because PyLong_FromUnsignedLongLong() already has special case for short integers.

The solution of this issue is getting rid of a special case, or adding a special case in PyLong_FromVoidPtr(). It is desirable to make it avoiding multivaluedity.
msg173297 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2012-10-18 21:30
New changeset 5ae4ff03b35f by Mark Dickinson in branch 'default':
Issue 16280: Drop questionable special-casing of null pointer in PyLong_FromVoidPtr.
http://hg.python.org/cpython/rev/5ae4ff03b35f
msg173298 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2012-10-18 21:31
Dropped the special case for 3.4.  I'm leaving the code as-is for the maintenance branches, as discussed in issue16277.
History
Date User Action Args
2022-04-11 14:57:37adminsetgithub: 60484
2012-10-18 21:31:56mark.dickinsonsetstatus: open -> closed
resolution: fixed
messages: + msg173298

assignee: mark.dickinson
type: resource usage -> behavior
2012-10-18 21:30:18python-devsetnosy: + python-dev
messages: + msg173297
2012-10-18 20:36:45serhiy.storchakacreate