cffi-devel August 2013

cffi-devel@common-lisp.net

13 participants
5 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

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

Problem loading a dylib file through LOAD-FOREIGN-FUNCTION
by Robert P. Goldman 26 Aug '13

26 Aug '13

I have been trying to load a dylib file I got from compiling the NuSMV model-checking program (nusmv.fbk.eu). I keep getting this error, which I am afraid I don't understand: Unable to load foreign library (LIBNUSMV.DYLIB-1090). Error opening shared object "libnusmv.dylib": dlopen(libnusmv.dylib, 10): Library not loaded: /usr/local/lib/libsmvgrammar.0.dylib Referenced from: /usr/local/lib/libnusmv.dylib Reason: no suitable image found. Did find: /usr/local/lib/libsmvgrammar.0.dylib: mach-o, but wrong filetype /usr/local/lib/libsmvgrammar.0.dylib: mach-o, but wrong filetype. If this had said "wrong architecture", I would have guessed that this was a 32bit/64bit mismatch. But "wrong filetype" seems to indicate a different error, and one that I haven't had any luck googling. At any rate, I have checked and I have x86_64 SBCL and x86_64 dylibs. Any suggestions would be very welcome. Thanks, R

3 6

Allowing GC in Allegro CL SMP during foreign function calls
by Felix Filozov 21 Aug '13

21 Aug '13

Hi all, When defining a foreign function using def-foreign-call, there's an option one could set called :allow-gc. Setting it to :always, allows the garbage collector to run while the foreign function is executing. At the moment CFFI uses the default value for :allow-gc, which is :never. This prevents GC from running when a foreign function is executing. Moreover, once GC blocks, other processes can't make progress. In my case, I need GC to run during foreign function execution. What do you think about extending the defcfun and foreign-call interfaces to allow for native options to be passed? name-and-options could be extended to accept a new argument, :native-args, for example. Then you'd be able to use defcfun as follows: (defcfun ("strlen" :native-args (:allow-gc :always)) :int (str :string)) Another option is to create a global variable that holds native arguments, and def-foreign-call would read this directly. Thanks, Felix

6 16

Problems with nested structs and the newer cffi
by Willem Rein Oudshoorn 18 Aug '13

18 Aug '13

I am encountering some problems with trying to upgrade my old cffi code to the new version from quicklisp. If I use the old code, I get lots of warnings about my structs, that I should use either (:struct ...) or (:pointer (:struct ...)) However whateer I try, I do not seem to get it to work, and I am starting to think there is some issue between me and the new cffi. The main issue is a nested struct definition like this: ``` (defcstruct timeval (time %time) (offset :int)) (defcstruct (git-signature) (name :string) (email :string) (time (:struct timeval))) ``` With type definitions ``` (define-foreign-type time-type () nil (:actual-type :int64) (:simple-parser %time)) (define-foreign-type git-signature-type () nil (:actual-type :pointer) (:simple-parser %git-signature)) ``` I encounter problems when I am trying to update the `translate-to-foreign` for the `git-signature-type`. The implementation boils down to: ``` (defmethod translate-to-foreign ((value list) (type git-signature-type)) (let ((signature (foreign-alloc '(:struct git-signature)))) (with-foreign-slots ((name email time) signature (:struct git-signature)) (setf name (getf value :name (getenv "USER"))) (setf email (getf value :email (default-email))) (with-foreign-slots ((time offset) time (:struct timeval)) (let ((time-to-set (getf value :time (local-time:now)))) (setf time time-to-set) (setf offset (/ (local-time:timestamp-subtimezone time-to-set local-time:*default-timezone*) 60))))) signature) ``` The problem is in the inner `with-foreign-slots ((time offset)...`. The error I get is: ; Evaluation aborted on #<TYPE-ERROR expected-type: SYSTEM-AREA-POINTER datum: (CL-GIT::OFFSET 0 TIME @1970-01-01T01:00:03.000000+01:00)>. The reason is, as far as I can tell, that in the code: (with-foreign-slots ((time offset) time (:struct timeval)) ... the value of `time` is already a plist (due to the outer with-foreign-slots), and the inner with-foreign-slots expects a pointer. So what is the best way of fixing this? I can fix this by replacing the inner `with-foreign-slots` by ``` (with-foreign-slots ((time offset) (foreign-slot-pointer signature '(:struct git-signature) 'time) (:struct timeval)) ``` which seems a bit long. An additional question is, when to use (:struct ...) and when to use (:pointer (:struct ..))) I did expect that I needed to use (:pointer (:struct ..)) in the toplevel `with-foreign-slots`, because the argument is actually a pointer to the struct. But that did not work. As you can tell, I am a bit confused. Hope that someone can give some hints to clear my head. Kind regards, Wim Oudshoorn.

4 10

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

cffi-devel August 2013