[cffi-devel] Design problem?

[Luís Oliveira]

On 10/12/06, Juan Jose Garcia-Ripoll <jjgarcia at users.sourceforge.net> wrote:
> First of all, every time you call a function with foreign-funcall you
> have to supply the types of the arguments. The aliasing of all pointer
> types to :pointer means that type information is lost. Not all pointer
> type are equivalent, because some types have alignment restrictions.

Can you give me an example?


> Supplying the argument types is extremely tricky in some cases and
> might not be enough type information. For example,
>       int f1(int i, ...)
> is not the same function as
>       int f2(int i, int j)
> even though when we invoke f1(1, 2) the (2) is coerced to type int.

On all platforms I have access too they seem to behave the same since
we manage to call varargs functions and the various Lisps don't know
anything about their varargs-ness. I hear that might not always be
true, so see below.


> The information about "..." is taken cared of by DEFCFUN, but not by
> FOREIGN-FUNCALL. That may seem useless but really, it is not the same
> thing to call f1 and f2, because the C compiler does produce different
> assembly code. For instance, using AMD64, in the first case it has to
> push the arguments on the stack, while in the second case everything
> goes into registers Similar things happen with a PPC backend.

See my comment in src/functions.lisp about foreign-funcall-varargs:

;;; ATM, the only difference between this macro and FOREIGN-FUNCALL is that
;;; it does argument promotion for that variadic argument. This could be useful
;;; to call an hypothetical %foreign-funcall-varargs on some hypothetical lisp
;;; on an hypothetical platform that has different calling conventions for
;;; varargs functions. :-)

If ECL can do something special about varargs, we can go ahead and use that!

-- 
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/