cffi-devel September 2013

cffi-devel@common-lisp.net

9 participants
6 discussions

Returning errno as a second value
by Felix Filozov 28 Jan '14

28 Jan '14

Hi all, In Allegro CL, the only safe way to get errno after a foreign function call is to configure the foreign function definition to return it as a second value. CFFI doesn't deal with errno. There has been some previous discussion ( http://lists.common-lisp.net/pipermail/cffi-devel/2009-January/003017.html) to return errno safely, but doesn't seem like it went anywhere. So any library that tries to get errno is potentially broken in Allegro CL. I'm seeing this in practice with lisp-zmq, for example. I'd like to introduce a new option to defcfun and foreign-funcall called :errno. It would look like this: (foreign-funcall ("strlen" :errno t) :string "foo" :int), or (defcfun (strlen "strlen" :errno t) :int (s :string)). Calling (strlen) would return two values, the return value of the foreign call, and errno. In some Lisps, the only way to get errno is to make an additional foreign call. Then perhaps that call could be made by CFFI and returns as the second value. I've created a pull request (https://github.com/cffi/cffi/pull/28) with a very rudimentary implementation for Allegro CL. Since CFFI delegates the handling of errno to the implementation, perhaps we could preserve the status quo and not get bugged down in grandiose plans of portability. Thoughts and suggestions are welcome. Thanks, Felix

7 23

using foreign-free on Win7 64-bit
by Rujia Liu 25 Sep '13

25 Sep '13

Dear all, I have trouble using foreign-free on win7 64bit. My code: C++: int* gen(int n) { int* x = new int[n]; for(int i = 0; i < n; i++) x[i] = i; return x; } LISP: (defun gen-values (n) (let* ((ret (cffi:foreign-funcall "gen" :int n :pointer))) (dotimes (i n) (format t "~A~%" (mem-ref (mem-aptr ret :int i) :int))) (foreign-free ret))) It works well on windows XP (32bit), but crashes on (foreign-free ret). SBCL win32 just crashes the process, while CCL win32 dropped me into kernel debugger. The topmost frame is a call to FREE. Our customers use both 32-bit and 64-bit systems, so I'd like to provide a single exe that runs on both 32-bit and 64-bits. Our dev machine is running a 32-bit Windows XP, uses VS2008 to compile to C++ library to DLL. After I commented out (foreign-free), the exe runs perfectly on both 32-bit and 64-bit, but there are memory leaks. Am I doing anything wrong? Thanks in advance. - Rujia

2 2

Question about docs
by Robert P. Goldman 17 Sep '13

17 Sep '13

I have been working with CFFI from quicklisp and am a bit puzzled about translate-from-foreign with defcstruct. The documentation says: "A user wishing to define other translations should use the :class argument to [defcstruct], page 33, and then define methods for [translate-from-foreign], page 52 and [translate-into-foreign-memory], page 54 that specialize on this class, possibly calling call-next-method to translate from and to the plists rather than provide a direct interface to the foreign object." But I don't see any documentation of the class option to defcstruct. Is there an example of writing one of these translators for a class somewhere? I've been having quite a bit of trouble. I have created a class for defcstuct (just using the source to try to use it properly), (cffi:defcstruct (node :class node-class) ...) and then have tried to make a translate-from-foreign method dispatching on NUSMV-NODE::NODE-CLASS. I get the error that my new class NUSMV-NODE::NODE-CLASS is not found: unknown CFFI type: NUSMV-NODE::NODE-CLASS. when I try to invoke this. But (FIND-CLASS 'NUSMV-NODE::NODE-CLASS) finds it successfully. I suspect this has something to do with things going awry in find-type-parser, but am insufficiently familiar with the code or intention to make further process. Thanks for any help, R

3 2

Question about cffi-libffi on win32
by Rujia Liu 16 Sep '13

16 Sep '13

Dear all, I'm using SBCL 1.1.4.0.mswin.1288-90ab477. I want to use cffi-libffi but failed. Here is what I did: 1. First, download libffi_3.0.6-1_win32.zip from http://ftp.gnome.org/pub/GNOME/binaries/win32/dependencies/ and drop libff-5.dll to a place that SBCL can find. 2. use quicklisp to load the cffi-libffi system. However, I got the following error: * (ql:quickload "cffi-libffi") To load "cffi-libffi": Load 1 ASDF system: cffi-libffi ; Loading "cffi-libffi" ; c:/msys/1.0/bin/gcc.exe -m32 -I/Documents and Settings/eryiju/quicklisp/dists/ quicklisp/software/cffi_0.11.2/ -o C:\Documents and Settings\eryiju\Application Data\common-lisp\cache\sbcl-1.1.4.0.mswin.1288-90ab477-win-x86\C\Documents and S ettings\eryiju\quicklisp\dists\quicklisp\software\cffi_0.11.2\libffi\libffi-win3 2.exe C:\Documents and Settings\eryiju\Application Data\common-lisp\cache\sbcl-1 .1.4.0.mswin.1288-90ab477-win-x86\C\Documents and Settings\eryiju\quicklisp\dist s\quicklisp\software\cffi_0.11.2\libffi\libffi-win32.c note: SBCL on windows can't redirect output. debugger invoked on a SIMPLE-ERROR in thread #<THREAD "main thread" RUNNING {23D A8AC1}>: External process exited with code 1. Command was: "c:/msys/1.0/bin/gcc.exe" "-m32" "-I/Documents and Settings/eryiju/ quicklisp/dists/quicklisp/software/cffi_0.11.2/" "-o" "C:\\Documents and Setting s\\eryiju\\Application Data\\common-lisp\\cache\\sbcl-1.1.4.0.mswin.1288-90ab477 -win-x86\\C\\Documents and Settings\\eryiju\\quicklisp\\dists\\quicklisp\\softwa re\\cffi_0.11.2\\libffi\\libffi-win32.exe" "C:\\Documents and Settings\\eryiju\\ Application Data\\common-lisp\\cache\\sbcl-1.1.4.0.mswin.1288-90ab477-win-x86\\C \\Documents and Settings\\eryiju\\quicklisp\\dists\\quicklisp\\software\\cffi_0. 11.2\\libffi\\libffi-win32.c" Output was: Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [RETRY ] Retry #<STANDARD-CLASS CFFI-GROVEL::PROCESS-OP> on #<GROVEL-FILE " cffi-libffi" "libffi" "libffi">. 1: [ACCEPT] Continue, treating #<STANDARD-CLASS CFFI-GROVEL::PROCESS-OP> on #< GROVEL-FILE "cffi-libffi" "libffi" "libffi"> as having been successful. 2: [ABORT ] Give up on "cffi-libffi" 3: Exit debugger, returning to top level. (CFFI-GROVEL::INVOKE #<unavailable argument> "-m32" "-I/Documents and Settings/e ryiju/quicklisp/dists/quicklisp/software/cffi_0.11.2/" "-o" "C:\\Documents and S ettings\\eryiju\\Application Data\\common-lisp\\cache\\sbcl-1.1.4.0.mswin.1288-9 0ab477-win-x86\\C\\Documents and Settings\\eryiju\\quicklisp\\dists\\quicklisp\\ software\\cffi_0.11.2\\libffi\\libffi-win32.exe" "C:\\Documents and Settings\\er yiju\\Application Data\\common-lisp\\cache\\sbcl-1.1.4.0.mswin.1288-90ab477-win- x86\\C\\Documents and Settings\\eryiju\\quicklisp\\dists\\quicklisp\\software\\c ffi_0.11.2\\libffi\\libffi-win32.c") 0] I noticed that .....\cffi_0.11.2\libffi\libffi-win32.c does NOT exist, even in git repository. What should I do now? BTW: How to change gcc's location? I used grep in cffi's directory but can't find it. My MinGW was installed somewhere else, I had to copy it to c:/msys/1.0/bin so that cffi-libffi can find it (I saw a "can't fork" error message before doing so). Thanks in advance. - Rujia

2 1

Grovelling with unsigned base types.
by Mark Cox 08 Sep '13

08 Sep '13

G'day, The attached patch ensures that the BASE-TYPE argument specified in CONSTANTENUM grovel forms has an affect on the format string passed to fprintf. It appears CENUM should be fixed too. The patch does NOT fix that. Thanks Mark diff --git a/grovel/grovel.lisp b/grovel/grovel.lisp index a0c150c..1f97da6 100644 --- a/grovel/grovel.lisp +++ b/grovel/grovel.lisp @@ -634,7 +634,9 @@ int main(int argc, char**argv) { (check-type c-name string) (format out "~&#ifdef ~A~%" c-name) (c-format out " ") - (c-printf out "%i" c-name) + (format out "~& fprintf(output, ~A, ~A);~%" + (foreign-type-to-printf-specification (or base-type :int)) + c-name) (format out "~&#else~%")) (unless optional (c-format out

1 0

Building on win64
by James Gatannah 02 Sep '13

02 Sep '13

This may be a complete dead-end, but it seems worth a stab. I'm trying to get a program running on win64. It requires FFI, and I'd much prefer to use CFFI. The short version (for anyone who doesn't already know) is that SYSV and STDCALL options have been replaced with WIN64. This breaks the groveller. I've traced the actual issue down to the point where the ASD passes a template file into a method in grovel.lisp that generates a C file that prints out a bunch of sexps...I'm guessing to configure a running lisp to let it know what kind of hardware it's running on. It seems like it would be simple enough to either a) update the win32 template with read conditionals to export appropriate calling conventions b) add a win64 template that's really a copy/pasted duplicate with the minor modifications to make it work, then update the ASD to choose it instead of the win32 template, if appropriate. That part seems so trivial that I'm guessing there's a much bigger piece to the puzzle. It's been years since I dug into different calling conventions, and my only refresher so far has been a glance through a wikipedia article. Is win64 different enough that it hasn't been worth bothering with yet on the CFFI end? Is support in various lisp implementations so poor/limited that it hasn't been interesting so far? Is there just not enough interest from library users so far to justify any efforts? Am I totally off-base? I'm sorry if this is an FAQ...I haven't been able to find mailing list archives to dig through. Thanks in advance, James

4 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

cffi-devel September 2013