[issue29720] potential silent truncation in PyLong_AsVoidPtr

2017-03-27 Thread STINNER Victor

STINNER Victor added the comment:

I closed the issue.

@Oren: Please reopen the issue with a pull request if you consider that the 
assertion is worth it.

--
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29720] potential silent truncation in PyLong_AsVoidPtr

2017-03-27 Thread Serhiy Storchaka

Serhiy Storchaka added the comment:

Ah, you are right. I don't know whether Python supports such platform after 
dropping support of DOS.

But in any case I don't see any issue here.

Oren will be not active until August, so we should make the decision about 
closing the issue or changing the code without him.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29720] potential silent truncation in PyLong_AsVoidPtr

2017-03-27 Thread STINNER Victor

STINNER Victor added the comment:

> Did you meant 64-bit Windows? ;-)

On Windows 64-bit, sizeof(void*) > sizeof(long), not the opposite.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29720] potential silent truncation in PyLong_AsVoidPtr

2017-03-27 Thread Serhiy Storchaka

Serhiy Storchaka added the comment:

> I'm suite sure that every C function of CPython breaks if this assumption 
> becomes wrong :-) Such platform doesn't exist.

Did you meant 64-bit Windows? ;-)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29720] potential silent truncation in PyLong_AsVoidPtr

2017-03-27 Thread STINNER Victor

STINNER Victor added the comment:

"I am not sure whether such a platform exists, but on a platform where 
SIZEOF_VOID_P < SIZEOF_LONG, PyLong_AsVoidPtr ..."

I'm suite sure that every C function of CPython breaks if this assumption 
becomes wrong :-) Such platform doesn't exist.

You can add the build assertion if it makes you more confortable ;-)

--
nosy: +haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29720] potential silent truncation in PyLong_AsVoidPtr

2017-03-25 Thread Serhiy Storchaka

Serhiy Storchaka added the comment:

I don't think there is a bug. There are several ways to get the integer 
representation of the pointer. PyLong_FromVoidPtr() is the most 
straightforward. From Python side id() uses it. printf("%p") is a way of 
getting string representation of the pointer, that string can be converted to 
integer. This way is used in object.__repr__(). Usually %p formats the pointer 
as hexadecimal, but the sign is not defined. Therefore when the pointer is 
converted to the integer it can be interpreted as either signed or unsigned 
integer. PyLong_AsVoidPtr() should accept both representations.

--
nosy: +mark.dickinson, serhiy.storchaka
resolution:  -> not a bug

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29720] potential silent truncation in PyLong_AsVoidPtr

2017-03-04 Thread Oren Milman

New submission from Oren Milman:

I am not sure whether such a platform exists, but on a platform where
SIZEOF_VOID_P < SIZEOF_LONG, PyLong_AsVoidPtr (which is in
Objects/longobject.c) is:
long x;
if (PyLong_Check(vv) && _PyLong_Sign(vv) < 0)
x = PyLong_AsLong(vv);
else
x = PyLong_AsUnsignedLong(vv);
if (x == -1 && PyErr_Occurred())
return NULL;
return (void *)x;
Thus, for example, 'PyLong_AsVoidPtr(PyLong_FromUnsignedLong(ULONG_MAX))'
would silently truncate ULONG_MAX, and return without an error.

An easy fix would be (mainly) to add to PyLong_AsVoidPtr
'Py_BUILD_ASSERT(SIZEOF_LONG <= SIZEOF_VOID_P);', but I am not sure we can
make that assumption.

Note that a compile time error is already raised:
- by Objects/longobject.h, in case SIZEOF_VOID_P is different from
  SIZEOF_INT, SIZEOF_LONG and SIZEOF_LONG_LONG
- by Modules/_multiprocessing/multiprocessing.h, in case SIZEOF_VOID_P is
  different from SIZEOF_LONG and SIZEOF_LONG_LONG

--
components: Interpreter Core
messages: 288984
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: potential silent truncation in PyLong_AsVoidPtr
type: behavior
versions: Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com