почему ctypes.addressof() дает разные результаты, используя python2 и python3

Недавно я пытаюсь перейти с python2 на python3, в моих кодах есть некоторая работа по чтению аппаратного обеспечения формы данных, у которого есть файл интерфейса .py, вызывающий внешнюю библиотеку .dll. Данные распределяются по памяти между .dll и процедурой python, в частности, ctypes.creat_string_buffer() и ctypes.addressof(), которые правильно работают в среде python2.7, но дают неожиданный результат в python3.6, причина, по-видимому, может быть, ctypes.addressof() дает огромное значение разницы адресов, интересно, в чем причина?

'''python2.7 вывод addressof()

(base) C:\Users\Administrator>python
Python 2.7.15 |Anaconda, Inc.| (default, May  1 2018, 18:37:09) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from ctypes import *
>>> s = 128
>>> p = create_string_buffer(s)
>>> print(addressof(p))
50341488
>>> hex(addressof(p))
'0x3002670L'

'''

'''python3.6 вывод addressof()

(base) C:\Users\Administrator>conda activate py36

(py36) C:\Users\Administrator>python
Python 3.6.8 |Anaconda, Inc.| (default, Feb 21 2019, 18:30:04) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from ctypes import *
>>> s = 128
>>> p = create_string_buffer(s)
>>> print(addressof(p))
>>> 2241150277680
>>> hex(addressof(p))
>>> '0x209cef75830'

'''

На мой взгляд, вывод функции addressof() в python2 и python3 должен быть приблизительным, но на самом деле это не так. Кто-то, кто может помочь мне указать, что не так с подпрограммой, или со мной, с благодарностью!


person loren    schedule 19.07.2019    source источник


Ответы (1)


[Python 3.Docs]: ctypes — внешняя библиотека функций для Python< /а>.

ctypes.addressof не имеет ничего общего со значениями, он просто сообщает адрес базового буфера C для объекта ctypes.

Это о:

Вывод:

[cfati@CFATI-5510-0:C:\WINDOWS\system32]> sopr.bat
*** Set shorter prompt to better fit when pasted in StackOverflow (or other) pages ***

[prompt]>
[prompt]> set _PYTHON2="e:\Work\Dev\VEnvs\py_064_02.07.15_test0\Scripts\python.exe"

[prompt]> set _PYTHON3="e:\Work\Dev\VEnvs\py_064_03.07.03_test0\Scripts\python.exe"

[prompt]> rem PYTHON 3 - CTYPES

[prompt]> %_PYTHON3% -c "from ctypes import *; print(hex(addressof(create_string_buffer(128))))"
0x25652521230

[prompt]> %_PYTHON3% -c "from ctypes import *; print(hex(addressof(create_string_buffer(128))))"
0x25c61371230

[prompt]> %_PYTHON3% -c "from ctypes import *; print(hex(addressof(create_string_buffer(128))))"
0x20a3dfd1230

[prompt]> rem PYTHON 2 - CTYPES

[prompt]> %_PYTHON2% -c "from ctypes import *; print(hex(addressof(create_string_buffer(128))))"
0x2f5f3b0L

[prompt]> %_PYTHON2% -c "from ctypes import *; print(hex(addressof(create_string_buffer(128))))"
0x262f3b0L

[prompt]> %_PYTHON2% -c "from ctypes import *; print(hex(addressof(create_string_buffer(128))))"
0x313f3b0L

[prompt]>
[prompt]> rem PYTHON 3 - REGULAR

[prompt]> %_PYTHON3% -c "print(hex(id(1234567)))"
0x1df0d6af5b0

[prompt]> %_PYTHON3% -c "print(hex(id(1234567)))"
0x14f39e7f5b0

[prompt]> %_PYTHON3% -c "print(hex(id(1234567)))"
0x1f61453f5b0

[prompt]> rem PYTHON 2 - REGULAR

[prompt]> %_PYTHON2% -c "print(hex(id(1234567)))"
0x2a2ca90L

[prompt]> %_PYTHON2% -c "print(hex(id(1234567)))"
0x325c6a0L

[prompt]> %_PYTHON2% -c "print(hex(id(1234567)))"
0x28bbec0L

Как видно, шаблон адресов памяти связан не с объектами ctypes, а со всеми (и адрес каждый раз разный).

Обратите внимание, что полагаться на тот факт, что адрес, указывающий на некоторую память, которая была выделена malloc (или друзьями), равен (или близок) некоторому значению, это плохая идея. Код, основанный на таких предположениях, плохой (можно сказать, что это эквивалент неопределенного поведения).

person CristiFati    schedule 19.07.2019
comment
@loren: это ответило на ваш вопрос? Если да, пожалуйста, примите ответ, чтобы другие тоже могли подтвердить его ([SO]: что мне делать, когда кто-то отвечает мой вопрос?). - person CristiFati; 13.08.2019