<cdata 'char *(*)()' 0x66E452E0>

[anatoly techtonik]

Hi,

I am trying to build a wrapped for PDCurses:

const char *curses_version(void);

And calling print(api.curses_version) gives:

<cdata 'char *(*)()' 0x66E452E0>

How to convert that to Python string? Shouldn't CFFI do that automatically?

[anatoly techtonik]

Ok. I need to call print(api.curses_version()), but it still not a string:

<cdata 'char *' 0x66E4E19C>

Why?

The code is here https://bitbucket.org/techtonik/python-pdcurses/src/e6fa528dcfa953d7349f618c7813ef1adb4bf195/pdcurses.py?at=default

[Ryan]

Use ffi.string(s).

--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Check out my website: http://kirbyfan64.github.io/

[anatoly techtonik]

That works, thanks. Why it can not be done automatically? Explicitly
converting every return result makes the API ugly:

https://bitbucket.org/techtonik/python-pdcurses/commits/c9a25506f308f5dc847fef8d2e5af7fcb8b231c2

--
anatoly t.

[Armin Rigo]

Hi,

On 30 January 2015 at 05:26, anatoly techtonik <tech...@gmail.com> wrote:
> That works, thanks. Why it can not be done automatically?

Because nothing says that a `const char *` must point to a
null-terminated string. There are cases where you want to get a real
pointer to one character.

The "CFFI way" differs from the "ctypes way" in that CFFI has much
less bells and whistles. For any CFFI project that is supposed to be
used more than once, you are supposed to wrap the cffi-provided API
into some custom API of your choice in pure Python, like functions or
classes-and-methods that expose to the user some really Pythonic API
instead of the cdata objects.

You can disagree with the approach, of course; then ctypes is better for you :-)


A bientôt,

Armin.

[anatoly techtonik]

On Friday, January 30, 2015 at 1:38:15 PM UTC+3, Armin Rigo wrote:

On 30 January 2015 at 05:26, anatoly techtonik <tech...@gmail.com> wrote:
> That works, thanks. Why it can not be done automatically?

Because nothing says that a `const char *` must point to a
null-terminated string.  There are cases where you want to get a real
pointer to one character.

Does that mean that CFFI doesn't protect from memory violation errors?

Could I use result[1024] to overwrite some memory that is not exposed

in API? Can it be used to write stack buffer overflow exploits?

The "CFFI way" differs from the "ctypes way" in that CFFI has much
less bells and whistles.  For any CFFI project that is supposed to be
used more than once, you are supposed to wrap the cffi-provided API
into some custom API of your choice in pure Python, like functions or
classes-and-methods that expose to the user some really Pythonic API
instead of the cdata objects.

Doesn't it degrade performance? I thought that maximum performance is

only achievable on a C level. Or can PyPy optimize it better at run-time?

You can disagree with the approach, of course; then ctypes is better for you :-) 

I am still trying to figure out what CFFI is and what it really does

(without knowing much C details, such as how long its longlong is). =)

[Armin Rigo]

Hi,

On 6 February 2015 at 15:09, anatoly techtonik <tech...@gmail.com> wrote:
> Does that mean that CFFI doesn't protect from memory violation errors?

Yes, it's like writing C code.

>> into some custom API of your choice in pure Python, like functions or
>> classes-and-methods that expose to the user some really Pythonic API
>> instead of the cdata objects.
>
> Doesn't it degrade performance?

If you're interested only about CPython and want the top performance
available, then CFFI is typically slower than writing a custom C
extension module. If you're interested about performance without
being attached to CPython only, then PyPy is likely a better choice
anyway.


A bientôt,

Armin.