[Patches] [ python-Patches-1703286 ] bug fix: ctypes truncates 64-bit pointers

[SourceForge.net]

Patches item #1703286, was opened at 2007-04-19 00:09
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1703286&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alexander Belopolsky (belopolsky)
Assigned to: Thomas Heller (theller)
Summary: bug fix: ctypes truncates 64-bit pointers

Initial Comment:
At several places _ctypes module converts a python integer to a void* pointer by first extracting an argument into an int.  Attached patch changes int to Py_ssize_t that is guaranteed to be wide enough to hold a pointer. 

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2007-04-20 21:33

Message:
Logged In: YES 
user_id=11105
Originator: NO

The patch is only correct for Python2.5 and later, earlier Python versions
don't have the Py_ssize_t type (or, when it's defined, it has still the
same size as int in these versions).  Unfortunately the 'n' typecode also
isn't available in these versions.

Also the patch has to be extended for Windows, the LoadLibrary function
has the same problem.

Would you like to extend this patch (for Windows, I can do it myself
later)?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-04-19 08:49

Message:
Logged In: YES 
user_id=33168
Originator: NO

Thomas would be the best person to answer you question about where it
should go.  Maybe he has some other ideas how to test this.

----------------------------------------------------------------------

Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-19 08:44

Message:
Logged In: YES 
user_id=835142
Originator: YES

Here are (failing) test cases:

Python 2.5 (r25:51908, Oct  4 2006, 18:25:28) 
[GCC 3.4.4 20050721 (Red Hat 3.4.4-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> dlopen('libc.so.6')
182896775816
>>> dlclose(_)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: signed integer is greater than maximum
>>> dlsym(_, 'printf')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: signed integer is greater than maximum
>>> call_function(_, ()) # pretend that _ is a function pointer
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: signed integer is greater than maximum
>>> call_cdeclfunction(_, ()) # pretend that _ is a function pointer
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: signed integer is greater than maximum


With the patch:

>>> from _ctypes import *
>>> dlopen('libc.so.6')
182894214624
>>> dlclose(_)

I don't know how to meaningfully exercise call_function and
call_cdeclfunction to trigger the bug because in the default (small memory)
model on AMD64 function pointers always fit into 32 bits.  Maybe a
pseudo-function pointer created by an ffi callback can be used for this
purpose.

I am not sure where these test belong in the testsuit.  Maybe in
ctypes/test/test_loading.py? 





----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-04-19 07:56

Message:
Logged In: YES 
user_id=33168
Originator: NO

Thanks for the patch.  The changes look correct, however, can you create a
test for these cases?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1703286&group_id=5470