Re: PATCH libffi win64 support

[NightStrike <nightstrike at gmail dot com>]

On Fri, Jun 12, 2009 at 11:44 AM, Andrew Haley<aph@redhat.com> wrote:
> Timothy Wall wrote:
>>
>> 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.
>>
>> I see that on 64-bit linux, PRId64 evaluates to "ld". ? "long int" is
>> the same size as "long long int", but gcc is still complaining. ?Can you
>> instead cast the "long long int" argument to int64_t or something to
>> remove the warning?
>
> Hmm. ?I guess under the circumstances that's the right thing to do,
> but it's pretty evil in a test case that's suppose to test long long.
> Is the Windows library going to get fixed to accept %lld in the
> forseeable future? ?If so, we could just xfail it until then.

It's not really a bug per se.  It's a feature of the platform.

If the test case is testing a type that doesn't exist on a given
platform, maybe the proper thing to do is mark it UNSUPPORTED, as
opposed to XFAIL.