Luís Oliveira wrote:
- (defcfun-varargs "printf" :int (control :string))
(defcfun-varargs "printf" :int (constrol :string) (&rest args))
(defmacro defcfun-varargs (name return-type &body args) `(foreign-funcall ,',foreign-name ,@,varargs
Actually, I believe it's not enough to let defcfun know about varargs. FOREIGN-FUNCALL needs it as well, so it can tell the underlying Lisp where varargs happen.
Regarding TIFFGetValue(), I went to http://www.remotesensing.org/libtiff/man/TIFFGetField.3tiff.html and saw that it's all pointers. Therefore, I don't expect a problem with varargs when interfacing to this particular function on typical platforms (read Intel32). (But what do I know? some platforms could pass the first 4 pointers in registers, and the rest on the stack, and that would already break with varargs which would all be on the stack).
The TIFFGetValue specification is hairy, though. Pile up WITH-POINTER and submit a working example to the cffi team for inclusion in the manual :-)
An alternative implementation strategy for cffi might be to build up a va_list structure and call the *V() functions (e.g. TIFFVGetField)?? Uhoh...
Regards, Jörg Höhle.
"Hoehle, Joerg-Cyril" Joerg-Cyril.Hoehle@t-systems.com writes:
Actually, I believe it's not enough to let defcfun know about varargs. FOREIGN-FUNCALL needs it as well, so it can tell the underlying Lisp where varargs happen.
Indeed. As soon as some Lisp supports this we'll extend foreign-funcall that way. :-)
An alternative implementation strategy for cffi might be to build up a va_list structure and call the *V() functions (e.g. TIFFVGetField)?? Uhoh...
That'd be nice too. If only the varargs stuff wasn't all macros...
-
Hoehle, Joerg-Cyril -
Luís Oliveira