Lucien Pullen | 25 Mar 19:26 2015

64-bit stat and statfs on Mac

Greetings list.

I'm running into a bit of a conundrum.  I'm calling into stat(2) and
statfs(2) on Mac operating systems and get back the old 32-bit structure
instead of the new 64-bit structure.

If I compile a test program in C I get the 64-bit structure with just
<sys/mount.h> included.  When I use DEFCFUN I get the 32-bit structure.
Same for <sys/stat.h>.  I'm working around it currently using #+, but
I'd like some help understanding what's going on so I can do a proper

I read in the include files and man pages that the *64 functions are
temporary things while old code gets updated and that users should never
actually call them.  In the include file they are different functions
(see below for statfs), but there is some preprocessor magic happening.
There's a pair of defines _DARWIN_USE_64_BIT_INODE and
_DARWIN_NO_64_BIT_INODE that you can set before doing the include to set
the default behavior, but CFFI doesn't do grovelling for function

--8<---------------cut here---------------start------------->8---
int	statfs(const char *, struct statfs *) __DARWIN_INODE64(statfs);
int	statfs64(const char *, struct statfs64 *) __OSX_AVAILABLE_BUT_DEPRECATED(__MAC_10_5,__MAC_10_6,__IPHONE_NA,__IPHONE_NA);
#endif /* !__DARWIN_ONLY_64_BIT_INO_T */
--8<---------------cut here---------------end--------------->8---

It just caused me a bunch of confusion because I was getting junk out of
CONVERT-FROM-FOREIGN with :INODE64 in *FEATURES*, so now that I've
(Continue reading)

Mirko Vukovic | 9 Feb 21:50 2015

foreign-free causes stack dump (on CCL) after a repeated calls


I am running 64-bit CCL 1.10 on Windows 7.  I'm writing an interface to a National Instruments library (dll)
The library was downloaded from the NI site.  It was compiled using Microsofts C++ compiler.

I get a stack dump when a pointer is being freed using foreign-free.  This error occurs not in a fresh lisp
session, but after a second or third call to the same function (with same arguments).

One more detail: the library is used to access data in files in NI's TDMS format.  This error does not
seem to happen on all files that I am trying to access, only some of them.

I don't have much experience in cross-language library interface building, and I am wondering if I am making
some kind of mistake.  I am hoping for pointers on how to debug this further.

I define a pointer of type :uint to access results of a call to a library function that places them into an
unsigned int variable.  I then retrieve the value using using mem-ref, and the free the pointer. 
This is where the stack dump happens.

What follows is the defcfun, and the lisp function.  I mark with *** the pointer, and the relevant variable
definitions that pertain to it:

The C-function interface (with the C-documentation included) is
(defcfun (ddc-get-num-channel-group-properties "DDC_GetNumChannelGroupProperties")
This function will get numberOfProperites (via a pointer)

int DDC_GetNumChannelGroupProperties (DDCChannelGroupHandle channelGroup,
                                      unsigned int *numberOfProperties); *******"
  (group-handle group-handle) ;; group-handle is define to be a pointer type
  (num-channel-group-properties :pointer)) ;;*******

The pointer issue arises with the second variable num-channel-group-properties.

The lisp code where the error occurs is below (relevant lines highlighted with ***).

(defun get-num-channel-group-properties (group-handle*)
  "Get number of file properties

FILE-HANDLE* is a pointer to the file handle"
;;  (trace foreign-alloc)
  (let ((number-of-properties
       (let ((number-of-properties* (foreign-alloc :uint))) ;;******
         (print 'allocated-pointer)
         (print number-of-properties*)
         (ddc-get-num-channel-group-properties group-handle*
         (print 'done-with-ddc)
         (print 'acessing-number-of-properties)
         (mem-ref number-of-properties* :uint) ;; ********
           (print 'freeing-pointer)
           (foreign-free number-of-properties*) ;; ********
           (print 'freed-pointer)))))
  ;;  (untrace foreign-alloc)
    (print 'ready-to-return-with-value)

The traceback is:

#<A Foreign Pointer #x5FFC70>
 1> Calling (FOREIGN-FREE #<A Foreign Pointer #x5FFC70>)

and the debugger traceback is

(#x0000000026479810) #x00000000000F532C : #<Function FREE #x00000001000F51BF> + 365
(#x0000000026479840) #x0000000001491314 : #<Function (TRACED FOREIGN-FREE) #x000000210149109F> + 629
(#x0000000026479888) #x000000000139DE14 : #<Function GET-NUM-CHANNEL-GROUP-PROPERTIES #x000000210139DCDF> + 309

So, to summarize:

I have created a pointer to access results of a library call.  Library accesses contents of files created with National
Instruments software.  Library is compiled with MS C++.

The pointer free crash occurs on the third call of the lisp function.  The first two calls (with same arguments)
run OK.


Cffi-devel mailing list
Cffi-devel <at>
Mirko Vukovic | 8 Feb 01:55 2015

cffi idioms: with-foreign-pointer

Does with-foreign-pointer free up the memory after body is executed?

I have been using constructs such as:

     (let ((num-channel-groups* (foreign-alloc :uint)))
        (ddc-get-num-channel-groups file-handle* num-channel-groups*)
        (prog1 (mem-ref num-channel-groups* :uint)
          (foreign-free num-channel-groups*)))

Is with-foreign-pointer the idiomatic way to accomplish the same thing?


Cffi-devel mailing list
Cffi-devel <at>
Luís Oliveira | 25 Jan 23:40 2015

New CFFI dependency: UIOP


While fixing lp bug #1414277
<> I needed to use a
couple of utilities provided by UIOP that would have been a pain to
implement in CFFI-SYS.

UIOP is ASDF's utility library -- it is also available standalone via
Quicklisp -- and next version of CFFI will depend on it.

I hope that's not inconvenient to anyone. :-)



Luís Oliveira

Cffi-devel mailing list
Cffi-devel <at>
Frank | 17 Jan 10:27 2015

cffi-grovel bitfield

Given this C code:

enum uv_tcp_flags {
  /* Used with uv_tcp_bind, when an IPv6 address is used. */

The following cffi-grovel form fails:

(bitfield (uv-tcp-flags)
  ((:ipv6-only "UV_TCP_IPV6ONLY")))

The C-file generated by cffi-grovel looks like this:

/* bitfield section for UV-TCP-FLAGS */
fputs("(cffi:defbitfield (", output);
fputs("uv-tcp-flags", output);
fputs(")", output);
fputs("\n  (", output);
fputs(":ipv6-only", output);
fputs(" ", output);
fprintf(output, "%d", UV_TCP_IPV6ONLY);
fputs("\n  #.(cl:progn (cl:warn 'cffi-grovel:missing-definition :name
'IPV6-ONLY) -1)", output);
fputs(")", output);
fputs(")\n", output);

Obviously the #ifdef guard is the culprit here.  Maybe you guys want to
fix this?
Luís Oliveira | 6 Dec 16:40 2014

Fwd: Passed: cffi/cffi#1 (master - 6cf6892)


I've just finished setting up Travis CI for the CFFI repository. This means that each commit and pull request will be tested automatically. If an unexpected test fails, the commit author gets a notification similar to one I'm forwarding only with more red.

Currently only SBCL (32, and 64-bit) and CCL (64-bit) are being tested because the other Lisps fail to even execute the suite on the test box.

(The setup bits come from that I hope you may find useful in your own lisp projects.)


---------- Forwarded message ----------
From: Travis CI <notifications <at>>
Date: Sat, Dec 6, 2014 at 3:31 PM
Subject: Passed: cffi/cffi#1 (master - 6cf6892)
To: loliveira <at>

cffi / cffi (master)
Build #1 passed.
2 minutes and 22 seconds
Luís Oliveira 6cf6892 Changeset →
  Test using Travis CI

Want to know about upcoming build environment updates?

Would you like to stay up-to-date with the upcoming Travis CI build environment updates? We set up a mailing list for you! Sign up here.

Documentation about Travis CI
For help please join our IRC channel
Choose who receives these build notification emails in your configuration file.

Would you like to test your private code?

Travis Pro could be your new best friend!

Travis CI is powered by

Luís Oliveira
Cffi-devel mailing list
Cffi-devel <at>
Stelian Ionescu | 26 Nov 17:39 2014


Once upon a time Launchpad was the best in open-source and Github's
issue tracker was unusable, but that's no longer the case. How about we
officially switch to Github ?


Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.

Cffi-devel mailing list
Cffi-devel <at>
FAU | 25 Nov 11:06 2014

inline decfun

I'm wondering if it as any effect to declaim inline a function defined
by defcfun?
FAU | 24 Nov 02:13 2014

clear foreign memory


Lets say I want to keep around blocks of foreign memory but I need to
clear them before I reuse them what would be the best way to do it?

In C we could use memset() is there such an equivalent for CFFI?

Luís Oliveira | 23 Nov 23:16 2014

pkg-flags (was: Re: Cannot load cffi-libffi)

OK, so I see two needs for pkg-flags here then.

1. finding headers that aren't in the standard locations and wouldn't
otherwise be found.
2. finding headers for a specific version of a library.

I think the current committed behaviour works nicely for use case #1.
Use case #2, which you've raised, suggests that ignoring a missing
pkg-config is a bad default. What about adding making it an option?

Also, if we're going to cater to use case #2, then perhaps we should
support a list of alternatives à la define-foreign-library. What do
you think?

Finally, how about renaming the directive to pkg-config-cflags? (I can
sort of imagine we might want a pkg-config-lfags for wrappers at some
point in the future.)


Luís Oliveira

Cffi-devel mailing list
Cffi-devel <at>
Luís Oliveira | 22 Nov 16:02 2014

Issue tracker (still) lives at Launchpad


I'm not sure how, but the issue tracker for CFFI's GitHub repository
was somehow enabled. We still use Launchpad for bug tracking -- -- so I've closed all the issues on
github and moved the one that still needs fixing to launchpad.

Sorry for the confusion.



Luís Oliveira

Cffi-devel mailing list
Cffi-devel <at>