[issue28698] Python 3.x ctypes c_wchar_p return is different from official documentation example

Alex Wang report at bugs.python.org
Tue Nov 15 12:23:56 EST 2016


New submission from Alex Wang:

- Python Version

Python 3.5.2

- Issue

I found that the c_wchar_p and c_char_p return results behaves different from what it is based on ctypes doc. From the ctypes doc of Python 3.5:

>>> c_wchar_p("Hello, World")
c_wchar_p('Hello, World')

It return the ctypes string. But my results of execute the same cmd in Python3.5 console:

>>> from ctypes import *
>>> c_wchar_p("Hello, World")
c_wchar_p(1374004842736)
>>> c_wchar_p("Hello, World")
c_wchar_p(1374004841680)
>>> c_wchar_p("Hello, World")
c_wchar_p(1374004842736)

So seems like the orignial string part replaced by memory address. Digged in more, and found out if it is Python 2.x, then the return shows the string like the Python 3.5 ctypes doc shows. But in Python 3.x, it always return these numbers. Checked on multiple PCs, all seen the same thing. And understood the part that, we can use .value to return the original string. Same thing observed on create_string_buffer() and create_unicode_buffer(). Meanwhile, for other data types like c_int(), c_bool, c_void_p etc., not see this.

- Question

Can anyone provide a explaination about this behavior of ctypes?
And is there any way to fix the Python3.x return resuls as the same as what is doc wrote? (It seems that when it behave like this, I had issue with passing Python string to C function, when I interact with a C DLL.)

- Repro

This can be reproduce in python.org/shell easily.

Thanks a lot in advance~

----------
components: ctypes
messages: 280869
nosy: Alex Wang
priority: normal
severity: normal
status: open
title: Python 3.x ctypes c_wchar_p return is different from official documentation example
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28698>
_______________________________________


More information about the Python-bugs-list mailing list