This is the mail archive of the
mailing list for the libffi project.
Re: libffi - the 10th Anniversary Release
Thomas Heller wrote:
Dalibor Topic schrieb:
Tom Tromey wrote:
Dalibor also pointed out this patch:As ctypes is theller's code, and he seems to have a bunch of different
libffi patches stuck away in branches,
This adds Win64 support.
I figured it's best to ping theller himself what to merge. I'd love to
see the arm-wince stuff go in, but I have
nothing to test it myself.
Well, the libffi_msvc directory is a branch of the libffi sources, adapted
so that they can be compiled with the MS compilers. Both for win32/x86 and
win64/amd64. Both the cdecl and stdcall calling conventions are supported,
also for closures. The ffi_call function has been changed to return an integer
which informs about the stack pointer difference before and after the function call;
this is to detect wrong calling convention or wrong number of parameters passed (in stdcall).
The libffi_asm_wince directory is for MS compilers and windows ce/arm, with
Very cool. How hard would it be to adapt those for cegcc?
http://cegcc.sourceforge.net/ ... I guess the assembler syntax is quite
The changes to the libffi directory that I remember are these:
- New configure system (this was not written by me). The goal was
to have no GPL'd files in the Python svn repo. Also the libffi sources
are not compiled into a shared library, instead they are linked into
the Python ctypes extension that uses it.
- We changed the libffi sources to use proper function prototypes
since we have a zero-compiler-warning policy. For example:
-extern void ffi_call_osf(void *, unsigned long, unsigned, void *, void (*)())
+extern void ffi_call_osf(void *, unsigned long, unsigned, void *, void (*)(void))
Sounds useful to me.
Is there a reason to keep these 'void (*)()' constructs?
I don't think so, Tom?