Luís Oliveira wrote:
About the FUNCALL.VARARGS.DOUBLE test, it passes on Linux and OSX but fails on Win32. Probably a CLISP bug, Joerg? :-)
Maybe, maybe not. My opinion is that interfacing to varargs is hairy and I hear mention of problems with them, when coming from any language (Python, perl, Haskell, .NET, xyz).
I believe the tests are (potentially) incorrect. As I was quoting in "[cffi-devel] bits from a new tutorial" on 2005-12-23, http://gcc.gnu.org/ml/gcc/2004-06/msg01019.html "It's assuming that the calling conventions for a varargs function and a non-varargs function are the same, and that's not necessarily true on all platforms."
I believe this could explain the observed behaviour. The test calls sprintf() as if it were declared void sprintf(void*,char*,double); This could cause the value to be passed directly in a floating point register, which would not surprise me. Whilst varargs are all passed on the stack.
So far, I've no reason to believe there's a bug in CLISP, but try to convince me of the contrary. I believe interfacing to varargs is a problem and needs careful thought. In the meantime, I suggest to recommend not to use them. Individual tests may remain in testsuite so we are remembered of the problem. My current thought is that I'm going to suggest to the maintainer of the ffcall package (which happens to be Bruno Haible, CC'ed) to provide some mean to interface to such functions(*), or restrict it, warn about their use, or try to narrow down the problematic area to well documented cases.
(*) would mean that the top-level description also would need to account for that, i.e. ffi:def-call-out or cffi:defcfun need means to describe them. It's possibly hairy.
Regards, Jörg Höhle.