cffi-devel May 2010

cffi-devel@common-lisp.net

13 participants
10 discussions

[cffi-devel] Foreign structures by value
by Liam Healy 26 Aug '10

26 Aug '10

I have written Foreign Structures By Value (FSBV) to allow calling foreign functions while passing or returning structures by value. It uses CFFI and libffi. It currently provides two macros for users, fsbv:defcstruct and fsbv:foreign-funcall, which are used exactly like their CFFI counterparts. It works for small test cases I've tried, but probably could use some improvement. If the keepers of CFFI are interested, I would be happy for it to be included in CFFI. In the meantime, it can be found here: http://repo.or.cz/w/fsbv.git Thank you. Liam

2 3

[cffi-devel] Foreign string arguments
by Michael Raskin 22 Aug '10

22 Aug '10

Hello. I use callback feature of CFFI. I want to use an encoding as a default and if I get an invalid string (non-UTF-8 in my case), I'd just reject it by returning an error. Unfortunately, if I declare string arguments with encoding, attempts by CFFI to decode the string raise an error which prevents me from returning protocol-compliant error to the caller. The context: I currently work on FUSE bindings for Common Lisp (or at least SBCL for now). In case of error occurring in my code, I return EIO. Of course, for invalid file names I want to return either EIO or ENOENT. Currently, request just hangs. This can be mitigated by patching CFFI. If I just wrap the conversion in ignore-errors, I lose the distinction between an invalid string and null pointer, but I get a chance to process the request (both cases are wrong in my case). Specifying a designated "wrong string object" and letting user change it seems to be the nicest way: the user gets an error on trying to use the object as a string, but user code can handle it nicely. I changed the following in string conversion code: (defmethod translate-from-foreign (ptr (type foreign-string-type)) (unwind-protect (block nil (handler-case (values (foreign-string-to-lisp ptr :encoding (fst-encoding type))) (error (x) (return t)) )) (when (fst-free-from-foreign-p type) (foreign-free ptr)))) That allowed me to handle invalid requests to the FS by returning ENOENT (just as originally intended). Would you please consider adding some similar modification in official CFFI repository? Michael Raskin

2 1

[cffi-devel] Memory fault using CFFI
by Andrew Kirkpatrick 22 Aug '10

22 Aug '10

Hi, It seems that in many cases when I call code in a library that results in a loaded foreign library function being called, I get a memory fault. Typically this error appears in my slime REPL: Help! 11 nested errors. SB-KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded. 0: ; Evaluation aborted. The 11 errors appear in my *inferior-lisp* buffer, each one similar to: CORRUPTION WARNING in SBCL pid 3239(tid 3039865744): Memory fault at 100020 (pc=0x9c77963, sp=0xb52f6110) The integrity of this image is possibly compromised. Continuing with fingers crossed. Crossed fingers or not, from that point on the lisp image is unstable. It happens when I try to use Elephant to open a BDB store, or when I use CL-SQLITE directly to open a database. However I just discovered that I can successfully run the hello-world.lisp example in CLG. I'm using clbuild on 32bit x86 Ubuntu 9.10, that I used to install SBCL 1.0.35.1 and the latest (according to clbuild) CFFI. Looking closer at CFFI, it fails one test unexpectedly. I'm quite baffled and googling and asking on #lisp draws a blank. The failed test is below. Any ideas? Test DEFCFUN.BFF.2 failed Form: (SUM-127 (MAKE-POINTER 2746181372) (MAKE-POINTER 177623060) -32334.0 3158055028 (MAKE-POINTER 242315091) 4288001754991016425 -21047.0d0 287.0d0 18722 243379286 -8677366518541007140 581399424 -13872 4240394881 1353358999 226 969197676 -26207.0d0 6484 11150 1241680089902988480 106068320 61865 2253 (MAKE-POINTER 866809333) -31613 35616 11715 1393601698 8940888681199591845 (MAKE-POINTER 1524606024) 805638893 3315410736 3432596795 (MAKE-POINTER 1490355706) 696175657106383698 -25438.0 1294381547 26724 (MAKE-POINTER 3196569545) 2506913373410783697 -4405955718732597856 4075932032 3224670123 2183829215657835866 1318320964 -22 -3786.0d0 -2017024146 1579225515 -626617701 -1456 (MAKE-POINTER 3561444187) 395687791 1968033632506257320 -1847773261 48853 142937735275669133 -17974.0 (MAKE-POINTER 2791749948) -14140.0 2707 3691328585 3306.0 1132012981 303633191773289330 (MAKE-POINTER 981183954) 9114.0d0 8664374572369470 -19013.0d0 -10288.0d0 -3679345119891954339 (MAKE-POINTER 3538786709) 23761 -154264605 (MAKE-POINTER 2694396308) 7023 997.0d0 1009561368 241 (MAKE-POINTER 2612292671) 48 1431872408 -32675.0d0 (MAKE-POINTER 1587599336) 958916472 -9857.0d0 111 -14370.0d0 -7308 -967514912 488790941 2146978095 -24111.0d0 13711 86681861 717987770 111 1013402998690933877 17234.0d0 -8772.0 3959216275 -8711 (MAKE-POINTER 3142780851) 9480.0 -3820453146461186120 1616574376 -3336232268263990050 -1906114671562979758 -27925.0d0 9695970875869913114 27033.0d0 1096518219 -12 104 3392025403 -27911 60 89 509297051 -533066551 29158.0 110 54 -9802.0d0 593950442165910888 -79) Expected value: 7758614658402721936 Actual value: 7758614624042983568. Thanks! -- Andrew Kirkpatrick "The first rule of Perl Club... has subscript 0. Unless you changed $[. But don't!" -- blazar on perlmonks.org

2 1

[cffi-devel] utf-16
by Helmut Eller 01 Jun '10

01 Jun '10

Is this assertion (assert (equal (cffi:with-foreign-string (data "foobar" :encoding :utf-16) (cffi:foreign-string-to-lisp data :count 6 :encoding :utf-16)) "foobar")) expected to fail? Helmut

2 4

Re: [cffi-devel] :pointer size on 64-bit OS's
by Кальянов Дмитрий 27 May '10

27 May '10

27 мая 2010 г. 14:29 пользователь Кальянов Дмитрий <kalyanov.dmitry(a)gmail.com> написал: > 2010/5/27 Luke Crook <luke(a)balooga.com>: >> I am receiving reports of nasty intermittent crashes when lispbuilder-sdl is >> run within a 32-bit Lisp (SBCL & CCL) on a 64-bit OS (Windows 7 and OSX). A 32- >> bit Lisp is used because the SDL library is 32-bit. No problems are reported >> using Lispworks/32-bit in Windows 7. > > As for CCL, its 32-bit version might work badly on 64-bit version of > Windows because CCL uses > undocumented parts of NT API which behave differently in 64-bit > version. E.g., they store pointer > to TLS data in ES segment register but Wow64 subsystem does not > preserve its value. > > SBCL itself is unstable on Windows. >

1 0

[cffi-devel] :pointer size on 64-bit OS's
by Luke Crook 27 May '10

27 May '10

I am receiving reports of nasty intermittent crashes when lispbuilder-sdl is run within a 32-bit Lisp (SBCL & CCL) on a 64-bit OS (Windows 7 and OSX). A 32- bit Lisp is used because the SDL library is 32-bit. No problems are reported using Lispworks/32-bit in Windows 7. The errors reports state that the Lisp debugger is invoked on the CFFI call to "SDL_PollEvent" (stack trace below). This is intermittent in that it might happen almost immediately, or after several thousand times through the event loop. SDL_PollEvent takes an SDL_Event struct as a parameter. SDL_Event looks like this; (cffi:defcunion SDL-Event (type :unsigned-char) (active SDL-Active-Event) (key SDL-Keyboard-Event) (motion SDL-Mouse-Motion-Event) (button SDL-Mouse-Button-Event) (jaxis SDL-Joy-Axis-Event) (jball SDL-Joy-Ball-Event) (jhat SDL-Joy-Hat-Event) (jbutton SDL-Joy-Button-Event) (resize SDL-Resize-Event) (expose SDL-Expose-Event) (quit SDL-Quit-Event) (user SDL-User-Event) (syswm SDL-Sys-WM-Event)) A few of the SDL_Events structs include pointers... (cffi:defcstruct SDL-User-Event (type :unsigned-char) (code :int) (data1 :pointer) (data2 :pointer)) (cffi:defcstruct SDL-Sys-WM-Event (type :unsigned-char) (msg :pointer)) If :pointer is created as a 64-bit pointer instead of 32-bit then I can foresee a problem as SDL_Event created by CFFI is larger than expected by SDL_PollEvent. So my question is, on SBCL/32-bit & CCL/32-bit, what is the expected size of :pointer on a 64-bit OS? Stack trace for SBCL/32-bit below; debugger invoked on a SIMPLE-ERROR: EXCEPTION_ACCESS_VIOLATION Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [CONTINUE] Ignore runtime option --load "load.lisp". 1: [ABORT ] Skip rest of --eval and --load options. 2: Skip to toplevel READ/EVAL/PRINT loop. 3: [QUIT ] Quit SBCL (calling #'QUIT, killing the process). ("bogus stack frame") 0] ba 0: ("bogus stack frame") 1: ("foreign function: #x757A8112") 2: ("foreign function: #x68132D60") 3: ("foreign function: #x68106812") 4: ("foreign function: #x6810684B") 5: (LISPBUILDER-SDL-CFFI::SDL-POLL-EVENT #.(SB-SYS:INT-SAP #X02106EC0)) - Luke

5 5

[cffi-devel] detecting int size used by library
by Tamas K Papp 27 May '10

27 May '10

Hi, Is there a way to detect the size of integers (ie 32 or 64 bit) used by a library? I am using LAPACK/BLAS (ATLAS) libraries via CFFI. Recently, my tests failed, and to my surprise, the solution was to use 32-bit ints. Note that I am on a 64-bit platform, using the Ubuntu libraries, so why this happens is a mystery. But it would be great if I could detect it somehow from within Lisp. Thanks, Tamas

5 4

[cffi-devel] ECL specific changes for CFFI
by Juan Jose Garcia-Ripoll 01 May '10

01 May '10

* The former definition for :long-long types in cffi-ecl.lisp was broken. I have agumented ECL with a feature that signals the existence of such a type in ECL and include a patch here for CFFI to take that into account. (Patch attached) * Instead of defining NULL-POINTER-P, it would be better to simply reexport the symbol living in the "EXT" package. Patch attached. * Upon reading the CFFI specification it seems that FOREIGN-FREE can only free memory that has been allocated by CFFI. However the test cases in misc-types.lsp do something else, deallocating the output of my_strdup() explicitely. * At the low level ECL has two different foreign function interfaces: one used in the interpreter and relying on an external library (libffi) and another one, much simpler, using the C compiler. Right now CFFI was only using the former unless it was not available. I provide a patch that chooses the interface depending on the use of the code: interpreter or compiled. (patch attached). * Is there the equivalent of launchpad for CFFI? Should I always submit the patches to the mailing list? I say this because there are other improvements I could forward when I find time. Cheers Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://tream.dreamhosters.com

2 6

[cffi-devel] foreign-string-to-lisp should use keywords
by Leslie P. Polzer 01 May '10

01 May '10

A minor nit I found while passing a custom encoding to this function. It's quite cumbersome to have to specify the other optional arguments to this function just to change one of them. Using keywords would also have the benefit of matching the lambda list of lisp-string-to-foreign. Leslie

3 2

[cffi-devel] Groveller's bitfield support
by Desmond O. Chang 01 May '10

01 May '10

Hi all, This patch adds bitfield support to the groveller. Here is the usage: In grovel file, write: (bitfield flags-ctype ((:flag-a "FLAG_A") :documentation "DOCU_A") ((:flag-b "FLAG_B") :documentation "DOCU_B") ((:flag-c "FLAG_C") :documentation "DOCU_C")) And if the C header file has: #define FLAG_A 1 #define FLAG_B 2 #define FLAG_C 4 This will generate: (cffi:defbitfield (flags-ctype) (:flag-a 1) (:flag-b 2) (:flag-c 4)) Documentation is also provided in the patch. Thanks

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

cffi-devel May 2010