Re: libffi stdcall closures

[Tom Tromey <tromey@redhat.com>]

>>>>> "Timothy" == Timothy Wall <twalljava@dev.java.net> writes:

Timothy> Here's the patch for stdcall closures, including a basic test.  The
Timothy> diff is against the JNA repo; I can probably do one against a gcc
Timothy> checkout if necessary.

I'm not really an x86 expert, so perhaps a port maintainer could look
it over.  The test case also looked good at first blush, but Andreas
is really the person for that...

I have a couple nits to pick, but nothing major.

Timothy> BTW, the lack of support came up as people were trying to install
Timothy> Java callbacks into various windows API functions (services, keyboard
Timothy> hooks, etc).  Some would work fine, others would crash.  I wasn't
Timothy> aware that libffi didn't have stdcall closure support since the few
Timothy> simple tests and examples I wrote just happened to work.

FWIW there are other areas where you may run into problems.  The
biggest one is varargs -- libffi basically doesn't support this at
all.  I'm sure there are more obscure ones, too, involving any new ABI
additions... maybe vectors, or decimal float, or I don't know what.

Timothy> +#ifdef X86_WIN32
Timothy> +  if (cif->abi == FFI_STDCALL) {
Timothy> +    FFI_INIT_TRAMPOLINE_STDCALL (&closure->tramp[0],    \
Timothy> +                                 &ffi_closure_STDCALL,  \
Timothy> +                                 (void*)closure, cif->bytes);
Timothy> +  }
Timothy> +#endif

You don't need the backslashes here.  I see them elsewhere in the
file, but they are bogus.  Also the "{" should be on its own line.

Also, it looks to me as though there's a missing 'else' in
here... shouldn't we call either FFI_INIT_TRAMPOLINE_STDCALL or
FFI_INIT_TRAMPOLINE, but not both?

thanks,
Tom