- cffi-devel - mailman3.common-lisp.net

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

01 Jun '10

I think there is a bug in CFFI with CCL's 32-bit version: (cffi:defcunion foo-union (int16 :int16 ) (uint64 :uint64 ) ) (cffi:defcstruct bar-struct (tag :uint8) (val foo-union)) (defun foo () (cffi:with-foreign-string (data "0123456789" :encoding :latin-1) (- (cffi:pointer-address (cffi:foreign-slot-value data 'bar-struct 'val)) (cffi:pointer-address data)))) FOO returns 4 in SBCL and Lispworks but with CCL it's 8. Helmut

1 0

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

Re: [cffi-devel] Latest changes, (probably) no significant errors with CFFI
by Luís Oliveira 29 Apr '10

29 Apr '10

On Thu, Apr 29, 2010 at 8:50 AM, Juan Jose Garcia-Ripoll <juanjose.garciaripoll(a)googlemail.com> wrote: >> CFFI> (macroexpand-1 '(foreign-funcall "foo" :boolean)) >> (NOT (ZEROP (%FOREIGN-FUNCALL "foo" (:INT) ...))) >> >> Or did you mean something else? > > I mean reading and writing data into foreign types, not calling functions. Ah, yes. That too. CFFI> (swank-backend:compiler-macroexpand '(mem-aref p :boolean 4)) (NOT (ZEROP (%MEM-REF P :INT 16))) CFFI> (swank-backend:compiler-macroexpand '(%MEM-REF P :INT 16)) (SB-SYS:SIGNED-SAP-REF-32 P 16) -- Luís Oliveira http://r42.eu/~luis/

1 0

[cffi-devel] New patches: 28-Apr-2010
by Luis Oliveira 29 Apr '10

29 Apr '10

Wed Apr 28 18:56:04 EDT 2010 Luis Oliveira <loliveira(a)common-lisp.net> * cffi-ecl: always push no-long-long LONG-LONG is not supported by ECL's interpreter yet. M ./src/cffi-ecl.lisp -1 +1 Wed Apr 28 18:53:37 EDT 2010 Luis Oliveira <loliveira(a)common-lisp.net> * cffi-tests: don't use FOREIGN-FREE for malloc()ed memory Patch courtesy of Juan Jose Garcia-Ripoll. M ./tests/libtest.c +6 M ./tests/misc-types.lisp -3 +5 Wed Apr 28 18:42:43 EDT 2010 Luis Oliveira <loliveira(a)common-lisp.net> * New pointer-related tests Testing error situations for some pointer operations. M ./tests/bindings.lisp +4 M ./tests/memory.lisp +36 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-100428.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi-cffi;a=summary

1 0

[cffi-devel] Inline expansions for pointer operations
by Juan Jose Garcia-Ripoll 28 Apr '10

28 Apr '10

... provided in this patch. I have a couple of questions. One is whether NULL-POINTER has to cons a new pointer _every_time_. It would be more clever to create a variable and put the pointer there. The other one is whether MAKE-POINTER is used at all, given that we have pointer increment / decrement operations. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://tream.dreamhosters.com

2 4