[issue29643] --enable-optimizations compiler flag has no effect
Alex Wang added the comment: At least when I last built Python, configure always said that optimizations were not enabled regardless of whether I passed in the flag. >From what it looked like to me, it's because configure uses the $enableval >variable to store the result of the check for --enable-optimizations, but the >script checks $withval -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29643> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29643] --enable-optimizations compiler flag has no effect
Changes by Alex Wang <aw1621...@gmail.com>: -- pull_requests: +253 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29643> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29643] --enable-optimizations compiler flag has no effect
New submission from Alex Wang: PR submitted here: https://github.com/python/cpython/pull/129 -- components: Build messages: 288535 nosy: awang priority: normal severity: normal status: open title: --enable-optimizations compiler flag has no effect type: behavior versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29643> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28698] Python 3.x ctypes c_wchar_p return is different from official documentation example
Alex Wang added the comment:
Hi Eryk,
Thanks a lot for quick reply~
This is about the bug I filed: http://bugs.python.org/issue28698#
I may still need your help to have a look the original case when I caught
this issue:
I am writing some test automation which call C DLL from Python, the C
function is something like:
MEASURE_API int InitTester(char *ipAddress)
So I need to pass an IP address string (for example, 192.168.100.100) from
Python in ctypes to this function. For non-const char in C, I used
c_ipAddress = create_string_buffer(b'192.168.100.100')
lib.InitTester(c_ipAddress)
But error code returned indicate that the parameter passing is incorrect,
then I traced back and found then reported the c_char_p/c_wchar_p issue.
Also tried
c_ipAddress = create_unicode_buffer('192.168.100.100')
c_ipAddress = c_char_p(b'192.168.100.100')
c_ipAddress = c_wchar_p('192.168.100.100')
But none of them working... I had called other function to this C DLL
passing c_int(). c_bool(), c_void_p() and etc. they are all working as
expected, only string related have this issue.
Therefore, any idea how write the correct assignment and pass it to C DLL
for this case in Python 3.5? Any hint would be great helpful.
Thank you in advance~
BR,
Alex
On Tue, Nov 15, 2016 at 10:57 AM, Eryk Sun <rep...@bugs.python.org> wrote:
>
> Changes by Eryk Sun <eryksun+pyb...@gmail.com>:
>
>
> --
> keywords: +easy
> stage: -> needs patch
>
> ___
> Python tracker <rep...@bugs.python.org>
> <http://bugs.python.org/issue28698>
> ___
>
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28698>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28698] Python 3.x ctypes c_wchar_p return is different from official documentation example
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 <rep...@bugs.python.org>
<http://bugs.python.org/issue28698>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
