The way ffi.h #defines the ffi_type_XX equivalents to the standard C types seems bad - they are mixed along with the #defines of the fixed-bit types (e.g. UINT32), but the two issues are orthogonal. This results in ffi_type_ulong, for instance, being #defined to ffi_type_uint64 on (at least) x86, as the following test program indicates: #include <stdio.h> #include <ffi.h> int main () { printf ("&ffi_type_ulong: %p &ffi_type_uint64: %p\n", &ffi_type_ulong, &ffi_type_uint64); } This results in the following output on my Athlon (no, no Athlon64 yet ;-)) &ffi_type_ulong: 0x8049738 &ffi_type_uint64: 0x8049738
Created attachment 5005 [details] Fix ffi_type_X #defines The patch should fix this bug, makes the #ifdef nesting more readable by using #elif and adds #defines for 'long long' and 'unsigned long long'.
*** Bug 9398 has been marked as a duplicate of this bug. ***
Could you patch the one in the sources called ffi.h.in (make sure that it is the mainline sources) in gcc/libffi/include and make a changelog and post the patch with the changelog to gcc- patches@gcc.gnu.org. Note GCC is not the official maintainers of libffi yet.
The ffi.h[.in] file changed a bit since the gcc 3.3.2 release. Now (in CVS) it blatantly says: #define ffi_type_ulong ffi_type_uint64 #define ffi_type_slong ffi_type_sint64 without any condition (the other types seem OK now). I cannot image that this is intended behavior -- there should be ffi_type_[us]long _and_ ffi_type_[us]long_long types; how would you else describe a function that takes (or returns) a 'long' -- you cannot tell for sure that long is a specific size...
Yes, this is wrong. We should use tests to define ffi_type_[us]long like the other types descriptors above it.
Created attachment 10159 [details] A patch I think the attached patch will fix.
I believe the patch for this was checked in a long time ago.