Joakim Hove, 18.02.2011 09:46:
Thanks for answering;
I rarely use ctypes
You should :-) Apart from my current struggle I think ctypes is really
good.
I'm well aware that it's a very good solution for the cases where you can
trade performance for minimizing your external dependencies. But being a
Cython developer, those use cases are truly rare for me.
and I actually don't know how this specific case works.
However, you are not providing a function signature for the "print_addr" C
function in the BugTest case, so my guess is that it assumes the standard
signature for C functions, which is "int func(int)". That would explain the
32bit truncation.
Well; I think you are wrong.
Nicely put.
First of all because what I showed in the
Stackoverflow post was just a contrived example - the real code where
the problem initially arose does indeed have the proper function
signature.
Ok, then take care to post proper code next time. Details can be important,
especially when asking about non-obvious problems.
Secondly:<Uncertain>The use function signatures will be
relevant for C-C linkage, but ctypes library only relates to the fully
linked shared librarry lib.so where these signatures have been long
lost anyway; that is why we have to specify the argtypes and restype
attributes of the ctypes function objects?</Uncertain>.
Hmm, so you think that to call a C function, ctypes doesn't need to know
what the exact signature is? That sounds a bit naive to me.
It's correct that all compile time information about function signatures is
gone in the library. So you must provide ctypes with the exact signature to
allow it to convert your input and output data correctly, and to put the
values on the call stack in the correct calling layout.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
