This is the mail archive of the libffi-discuss@sourceware.org mailing list for the libffi project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH libffi win64 support



On Jun 12, 2009, at 10:20 AM, Andrew Haley wrote:


Timothy Wall wrote:
applied.

On Jun 10, 2009, at 5:45 AM, Andrew Haley wrote:

Timothy Wall wrote:
2009-06-08 Timothy Wall <twall@users.sf.net>

   * Makefile.am,
      configure.ac,
      include/ffi.h.in,
      include/ffi_common.h,
      src/closures.c,
      src/dlmalloc.c,
      src/x86/ffi.c,
      src/x86/ffitarget.h,
      src/x86/win64.S (new),
   README: Added win64 support (mingw or MSVC)
      * ltcf-c.sh: properly escape cygwin/w32 path
      * man/ffi_call.3: Clarify size requirements for return value.
      * src/x86/ffi64.c: Fix filename in comment.

Please commit this and let me know as soon as you've done so.

I've got a few new test failures. They're of the form


libffi/testsuite/libffi.call/cls_align_sint64.c:80: warning: format '%ld' expects type 'long int', but argument 3 has type 'long long int'

It's because of changes like this:

- printf("res: %d %lld %d\n", res_dbl.a, res_dbl.b, res_dbl.c);
+ printf("res: %d %" PRId64 " %d\n", res_dbl.a, res_dbl.b, res_dbl.c);


which prints out a  long long  as an int64.  This is wrong, since
the type is "long long" and the printf format must match the
declaration of the object being printed.

When compiling with mingw(64), the underlying runtime library doesn't recognize "lld" (which is what PRId64 evaluates to on my OSX), but rather expects "I64" or some such (properly represented by PRId64 with mingw).


If PRId64 is evaluating to "%ld", then perhaps that's a bug in the inttypes.h header.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]