September 2005 - cffi-devel - mailman3.common-lisp.net

[cffi-devel] array ref in CFFI?
by Kenny Tilton 07 Sep '05

07 Sep '05

I am trying to port my code to CFFI, getting nowhere fast. The first thing I need to do is translate UFFI deref-array calls. Found it in the cffi uffi compatibility code, then killed a few minutes searching the doc for foreign-aref. Finally occurred to me to check and discovered there is no such thing. Now the leading candidate is mem-aref. Looks promising, but what is up with that UFFI compatibility code? -- Kenny Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film "I've wrestled with reality for 35 years, Doctor, and I'm happy to state I finally won out over it." Elwood P. Dowd, "Harvey", 1950

2 1

[cffi-devel] various
by Kenny Tilton 06 Sep '05

06 Sep '05

After a little wrestling with Verrazano I am now trying to port my existing OpenAL demo to use the CFFI bindings generated by VZN. I got a couple of warnings from ACL: Warning: :call-direct ignored; no argument types specified. ; While compiling (:TOP-LEVEL-FORM "openal-lib2.lisp" 10554) in C:\0dev\cl-openal\openal-lib2.lisp: Why the Hell are they not reporting on which defun? I will go digging to see if I can find which, but it may not matter. Anyway, I took a look at the expansion of: (cffi:defcfun ("alutUnloadWAV" alutunloadwav) alvoid (anonymous1 :int) (anonymous2 :pointer) (anonymous3 :unsigned-int) (anonymous4 :unsigned-int)) namely.... (PROGN (FF:DEF-FOREIGN-CALL (|%cffi-foreign-function/ALUTUNLOADWAV| "alutUnloadWAV") ((#:G1004 :INT INTEGER) (#:G1005 (* :VOID) INTEGER) (#:G1006 :UNSIGNED-INT INTEGER) (#:G1007 :UNSIGNED-INT INTEGER)) :RETURNING (:VOID NULL) :CALL-DIRECT T :ARG-CHECKING NIL :STRINGS-CONVERT NIL) (DEFUN ALUTUNLOADWAV (ANONYMOUS1 ANONYMOUS2 ANONYMOUS3 ANONYMOUS4) (CFFI::TRANSLATE-OBJECTS (#:G1000 #:G1001 #:G1002 #:G1003) (ANONYMOUS1 ANONYMOUS2 ANONYMOUS3 ANONYMOUS4) (:INT :POINTER :UNSIGNED-INT :UNSIGNED-INT) ALVOID (|%cffi-foreign-function/ALUTUNLOADWAV| #:G1000 #:G1001 #:G1002 #:G1003)))) I think there is a problem here in that the raw entry |%cffi-foreign-function/ALUTUNLOADWAV| is not really an inviting way to code raw calls to the API. Maybe I am wrong on this--perhaps the idea is that one would relatively rarely want to convert values explicitly and then call the raw function, so it is OK to make users write something like: (defun alutunloadwav-raw (a1 a2 a3 a4) (|%cffi-foreign-function/ALUTUNLOADWAV a1 a2 a3 a4) But is that raw name reliable between CFFI releases? What I did with my FFI utils was reserve the C name for raw functions and use the Lispified name for functions which autoconverted parameters and return values. I also allowed for pre- and post-processing. -- Kenny Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film "I've wrestled with reality for 35 years, Doctor, and I'm happy to state I finally won out over it." Elwood P. Dowd, "Harvey", 1950

2 1

[cffi-devel] Struct alignment/size bug fixed, win32 tweaks, etc..
by Luis Oliveira 02 Sep '05

02 Sep '05

Hello, About the struct alignment issue, I found some docs here: http://refspecs.freestandards.org/ and fixed the bug following the instructions in "System V Application Binary Interface Intel386 Architecture Processor Supplment, Fourth Edition". According to the other ABI docs under "Processor Specific ELF documents" the same rules apply at least for x86-64, MIPS and PowerPC. These documents mention System V, so I suppose it could be different for other systems. I have tested this under Win32 and MacOS X (as well as Linux) and they seem to use the same rules. So anyway, these are the new changes in cffi-luis: Fri Sep 2 08:57:50 WEST 2005 Luis Oliveira <loliveira(a)common-lisp.net> * CFFI User Manual update. Fri Sep 2 05:40:50 WEST 2005 Luis Oliveira <loliveira(a)common-lisp.net> * Fix struct bug, defcvar bug and tweaked bindings.lisp - defcvar now works (more) correctly with aggregate types. - struct types now carry alignment information which is now correctly calculated (for unions too) according to the x86 ABI (tested on darwin/ppc too, but should study other ABI docs at some point). - also tail padding is now correctly added to structs, when necessary. (also according to the x86 ABI). - 4 new tests for this struct bug (reported by Wilco Greven). - tweaked tests/bindings.lisp to correctly load the library on Lispworks and to make it more portable across win/nix/etc.. Thu Sep 1 08:36:04 WEST 2005 Luis Oliveira <loliveira(a)common-lisp.net> * Slight change to defcenum to make Corman Lisp happier. Wed Aug 31 07:46:45 WEST 2005 Luis Oliveira <loliveira(a)common-lisp.net> * Well, lets support MINGW too. Tweaked the Makefile a bit to support MINGW too. Wed Aug 31 07:30:13 WEST 2005 Luis Oliveira <loliveira(a)common-lisp.net> * Win32 tweaks to the test library... ... in order to work with the MSVC++ free toolkit. - correctly load the test library. - and __declspec(dllexport) to the test library functions - implement a strdup, used in 2 tests - added a compile.bat, the free toolkit doesn't seem to have nmake. Also, I don't know how to make ASDF automatically compile the lib under win32 like I did for *nix. -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/ Equipa Portuguesa do Translation Project http://www2.iro.umontreal.ca/~pinard/po/registry.cgi?team=pt

1 0

[cffi-devel] Enumerations cannot contain duplicate values
by Rayiner Hashem 02 Sep '05

02 Sep '05

Hello! I've encountered some behavior in C-FFI that I would like to discuss. When you try to define an enumeration containing duplicate values, C-FFI gives the error: "A foreign enum cannot contain duplicate values: 0." However, C enumerations can contain duplicate values, and this feature is used by real code. FLTK, for example, uses it to provide for source compatibility when the name of enumeration elements are changed. Without direct C-FFI support for this feature, the resultant C-FFI bindings do not translate well to what the user expects (enumeration keys available in the C header are not available in the Lisp binding). Verrazano works around this issue right now (by discarding duplicate keys), but it's a sub-optimal solution, since there is no way to programatically determine a consistent set of keys to discard. For example, FLTK contains an enumeration in which FL_ALIGN_TOP_LEFT and FL_ALIGN_LEFT_TOP alias each other, and FL_ALIGN_TOP_RIGHT FL_ALIGN_RIGHT_TOP alias each other. Depending on the ordering in the header file, the enumeration may end up containing an inconsistent set of names (eg: FL_ALIGN_TOP_LEFT and FL_ALIGN_RIGHT_TOP). Sincerely, Rayiner Hashem

2 1

[cffi-devel] foreign-type-size of struct types
by Wilco Greven 02 Sep '05

02 Sep '05

Hello, I'm using cffi for trying to revive the Qt bindings. Doing so I found out that for the calculation of the size of struct types, the alignment of the struct itself is not taking into account. For the following struct for example (defcstruct smoke-class (class-name string) (parents index) (class-fn :pointer) (enum-fn :pointer) (flags :unsigned-short)) cffi calculates a size of 18, which should be 20 (please correct me if I'm wrong). Attached is a patch which defines an extra method for foreign-type-size for a foreign-struct-type argument. This method is used to apply adjust-for-alignment on the newly defined struct. Greetings, Wilco

3 5