Attila Lendvai | 2 Feb 12:23 2016

Re: New CFFI fails to load cl-cairo2-xlib

the error is in the struct accessors, they end up containing literal

i've added a test that exhibits this problem:

the fix is not trivial, i gave up.

i tried to make it expand into a form that looks up the struct and the
slot at load-time (in a MAKE-LOAD-FORM), but the slots don't know
about their structs, so i cannot walk up and then back down the


• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
Violation of consent is the foundation of all crime.
 Corollary 1: No victim? Then no crime.
 Corollary 2: The State is the most pervasive criminal gang known to man.

Liam Healy | 2 Feb 03:41 2016

New CFFI fails to load cl-cairo2-xlib

Latest head 9b312d0d7e38

(ql:quickload :cl-cairo2-xlib)

Many messages like

; caught ERROR:
;   don't know how to dump #<CFFI::AGGREGATE-STRUCT-SLOT {1016815063}>
(default MAKE-LOAD-FORM method called).

; ==>
;   #<CFFI::AGGREGATE-STRUCT-SLOT {1016815693}>

eventually abort to
; compilation unit aborted
;   caught 2 fatal ERROR conditions
;   caught 54 ERROR conditions


When rolled back to 26f11a2bfe6c, everything is fine. On SBCL, amd64 Debian.


Attila Lendvai | 13 Jan 22:26 2016

RFC on changes to enum and bitfield semantics

on my quest to implement an automatic generator for CFFI bindings
(using c2ffi), i've recorded some patches that change the semantics of
enums and bitfields.

automatically generated bindings (should) live in an empty lisp
package, and to avoid surprises it's also desirable to bring the CFFI
behavior (regarding e.g. C namespaces) as close to C as possible.

the code is available in this PR:

the following are controversial and i'd welcome some input on them
from CFFI gurus, especially regarding what should/could get into
master eventually:

 - enums don't demand member names to be CL:KEYWORDP anymore

 - DEFCENUM and DEFBITFIELD now expand a toplevel DEFCONSTANT for
   each member. the rationale is to bring it closer to the C enum
   semantics where they are in the main namespace.

 - BITFIELD now inherit from ENUM, and adds extra semantics for values
   that are the power of two. but should 0 be treated as a bitfield
   bitmask? IOW, should (FOREIGN-BITFIELD-SYMBOLS 'FOO 0) return NIL
   or '(ZERO-MEMBER-NAME)? the code currently does not treat 0 as a
   bitmask (which is an incompatible change).

 - the accessor names are rather inconsistent:
(Continue reading)

Liam Healy | 23 Dec 04:29 2015

Calling a struct-by-value by reference

Hi Attila,


(There is an error in the sample code, the struct is called
'struct-pair, not 'pair.)
Here is a simpler exhibition of the problem

(sumpair (convert-to-foreign '(40 . 2) '(:struct struct-pair)))
The value #.(SB-SYS:INT-SAP #X7FFFEC003560) is not of type LIST.
   [Condition of type TYPE-ERROR]

So, you've said the function is call-by-value, and then you want to
pass a pointer to the structure, and it makes sense there's an error.
You have to assume a translator, because that's the only way to have a
structure by value.

I understand the desire to be able to pass a pointer instead, but my
approach would be different. I'd change the function argument
definition and extend the syntax to say that you're going to pass a
pointer, e. g.

(defcfun "sumpair" :int
       (p (:struct struct-pair) :pointer))

which I would have expand to something like

(Continue reading)

Attila Lendvai | 21 Dec 20:15 2015

Type propagation proposal

i wrote up some ideas here:

you're invited to comment/edit it.


• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
“The first thing you have to do if you want to raise nice kids, is you
have to talk to them like they are people instead of talking to them
like they're property.”
	— Frank Zappa (1940–1993), 'The Howard Stern Show' (1987)

Attila Lendvai | 9 Dec 22:10 2015

RFC on plans to implement a c2ffi->cffi generator

dear list,

c2ffi is a tool written in C that uses the llvm/clang libs to generate
a json file from C headers. it's like gcc-xml, only much better. the
json file has explicit offsets and sizes, etc... see an example here:

once this json has been generated for your platform, it can be checked
into the repo and no external tool is needed afterwards.

cl-autowrap uses such json files to generate an alternative FFI API,
but i'd like to use vanilla CFFI, so i'm planning to write some code
towards this direction, but i'd like to hear some input on this before
i start working on anything...

i imagine it to be similar to how groveling works in iolib, namely:
generate the intermediate files from the json files using some ASDF
integration, and then compile the lisp files as any other lisp files.

my first question is why isn't this ASDF integration, or something
like this, ported into cffi for the gorveler? is there any other
reason besides nobody has done it yet?

does anyone see some showstoppers? e.g. can i lay out defcstruct
fields with explicit offsets? NOTICE-FOREIGN-STRUCT-DEFINITION
suggests so.

(Continue reading)

Liam Healy | 4 Dec 22:19 2015

Using pkg-config (hdf5)

Debian has relocated hdf5 includes and libraries in serial/, which
means that hdf5-cffi does not compile. See this issue: I am trying to come
up with a CFFI solution. It seems like pkg-config-cflags should do the
job for me, as pkg-config is installed and does the right thing:

     pkg-config --libs hdf5
     -L/usr/lib/x86_64-linux-gnu/hdf5/serial -lhdf5
     pkg-config --cflags hdf5

However, I put a line
(pkg-config-cflags "hdf5" :optional t)
in hfd5-cffi/hdf5/grovel.lisp and got nothing useful; it is clear it
is running pkg-config but the result never makes it into the cc arg

 (ql:quickload :hdf5-cffi)
To load "hdf5-cffi":
  Load 1 ASDF system:
; Loading "hdf5-cffi"
[package hdf5]; pkg-config hdf5 --cflags
; cc -m64 -o /home/healy/.cache/common-lisp/sbcl-1.2.15-linux-x64/home/healy/languages/lisp/hdf5-cffi/hdf5/grovel__grovel-tmpGHU3ALSV
; /home/healy/.cache/common-lisp/sbcl-1.2.15-linux-x64/home/healy/languages/lisp/hdf5-cffi/hdf5/grovel__grovel
; cc -m64 -o /home/healy/.cache/common-lisp/sbcl-1.2.15-linux-x64/home/healy/languages/lisp/hdf5-cffi/hdf5/h5-grovel__grovel-tmpAAURSO1
(Continue reading)

Mirko Vukovic | 23 Nov 03:55 2015

what is the length of a long (motivated by GSL2.1 and GSLL)

This message has two audiences:  One the general CFFI group, and second the GSL maintainer.

This is using latest CCL and SBCL on 64-bit Windows 7, and MSYS2 running 64-bit MinGW and its GSL2.0 and 2.1.

Running GSL 2.0 and 2.1 under GSLL resulted in exception violations.  I could eliminate them by specifying the length of an integer as 8 instead of 4 bytes.  

My question has to do with the origin of this specification, since it is derived from CFFI and GSLL, not hard-coded.

Specifically, in GSLL, the following code in init/types.lisp:
(case (cffi:foreign-type-size :long)
  (8 (push :int64 *features*))
  (4 (push :int32 *features*)))

evaluates to 4, pushing :int32 into *features*.  Here is some additional output of cffi:foreign-type-size on my machine:

GSL> (cffi:foreign-type-size :double)
GSL> (cffi:foreign-type-size :long)
GSL> (cffi:foreign-type-size :long-long)
GSL> (cffi:foreign-type-size :int)

This feature eventually makes its way to other code in GSLL.  In the Linear Algebra module, the function make-permutation (in data/permutation.lisp) has this line:
 :element-type '(unsigned-byte #+int64 64 #+int32 32)
 :dimensions (if (typep n 'permutation) (grid:dimensions n) (list n)))))

In my environment element type resulted in unsigned-byte 32.

When I hard-coded my features to :int64 (and unsigned-byte 64), all the exception errors disappeared.

I hope this gives enough background to fix this error (either in my setup, gsll, or cffi).


Luís Oliveira | 11 Nov 18:07 2015

Re: tweak for cffi-grovel::trim-whitespaces?

On Wed, Nov 11, 2015 at 4:39 PM, Mirko Vukovic <mirko.vukovic <at>> wrote:
> Hi Louis,
> (I reply to you and not to the forum since you replied to me only - you are
> welcome to forward my reply to the forum)

Oops, my mistake.

> I downloaded from github and got qualified success:
> - At first loading I had to specify the path to ffi.h using cffi::*cc-flags*
> for the compilation to proceed

That's unexpected. Does that mean it failed to execute pkg-config? If
the compilation log doesn't yield any tips, perhaps you could tweak the
pkg-config-cflags definition (in cffi/grovel/grove.lisp) to add some
debugging output and see what's going on there?

> I downloaded from github and got qualified success:
> - At first loading I had to specify the path to ffi.h using cffi::*cc-flags*
> for the compilation to proceed
> - On subsequent loadings, I did not need to do that
> I used ql:quickload to load :cffi-libffi
> Tested on CCL 1-11 and SBCL 1.3.0
> Both Antik and GSLL compile nicely (except for some other minor issues, but
> those are for the antik/gsll forum).
> Thanks,
> Mirko



Luís Oliveira

Mirko Vukovic | 11 Nov 03:53 2015

tweak for cffi-grovel::trim-whitespaces?


This is on 
- 64-bit Windows
- Msys+mingw64 GCC compilation suite
- ccl and/or sbcl (latest Windows version)
- cffi 0.16.1.

I had problems loading cffi-libffi:
- CCL did fine
- SBCL barfed during the grovel phase:
  > Paths returned by pkg-config had a control-M appended to the end

I fixed that by adding \#Return to the list of characters trimmed by cffi-grovel::trim-whitespaces.

With that addition both SBCL and CCL loaded cffi-libffi.


Faré | 17 Sep 05:29 2015

CFFI + asdf bundles

Here is a patch that will make CFFI play better with ASDF bundles.
This allows delivery with a single .so and/or .a file for all the
wrappers in a system, which can be automatically linked into ECL (and
in the future, in SBCL or other implementations, for application

Also, report for a bug, not fixed in the attached patch: compiling,
linking, etc., should be atomic, by using temporary pathnames;
otherwise, there is a race condition when multiple processes try to
execute a script that depends on a CFFI library. Recent-enough ASDF
3.1.2 provides with-temporary-file to help, and 3.1.5 uses it
internally for its own targets, but some implementations still lag
behind with ASDF 3.0.x, and ASDF can't backwards-compatibly use
with-temporary-file for you, so you must use it yourself.

This patch also drops support for ASDF 2 or earlier, because backwards
compatibility is hard, and not necessary: today, all implementations
provide ASDF 3.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics•
The least deviation from truth will be multiplied later.
        — Aristotle