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

[cffi-devel] introspection in cffi
by nitralime 14 Apr '11

14 Apr '11

/*Hi folks!*/ Is there a way to get the (meta) information of structure slots defined by */defcstruct/*? Consider the following concrete example: (defcstruct test (a :uint) (b :char :count 10) (c :pointer)) Is it possible to get info like type, (array-)size of the slots /*a, b* /and /*c*/ by only introspecting '/*test*/'? Something like (foreign-slot-type 'test 'a) /*==> :char*/ (foreign-slot-count 'test 'b) /*==> 10*/ would be very useful! Regards Nik

2 1

[cffi-devel] CCL on Windows errors
by Anton Vodonosov 12 Apr '11

12 Apr '11

Hello. I have a crash when use CFFI + CCL + callbacks on Windows. I am not sure the crash is caused by CFFI, there is another suspect. But the CFFI tests on Windows have errors. Could you take a look to the test results (attached)? This is CFFI 0.10.6 About the crash. It happens with CL+SSL. OpenSSL requires multi-threaded applications to provide a callback, which implements locking, as described here: http://www.openssl.org/docs/crypto/threads.html. The callback function prototype is void locking_function(int mode, int n, const char *file, int line) The callback is installed using void CRYPTO_set_locking_callback(void (*func)(int mode,int type, const char *file,int line)) CL+SSL has the following definitions: (cffi:defcallback locking-callback :void ((mode :int) (n :int) (file :string) (line :int)) ;(declare (ignore file line)) ;; the callback body here ) (cffi:defcfun ("CRYPTO_set_locking_callback" crypto-set-locking-callback) :void (fun :pointer)) If during initialization of CL+SSL we do (crypto-set-locking-callback (cffi:callback locking-callback)) then we have a crash at the first SSL connection to hunchentoot. The crash is 100% reproducible. It doesn't matter what we have in the callback body, it may be even empty. The symptoms are always the same. If we comment out the line ;; (crypto-set-locking-callback (cffi:callback locking-callback)) then the crash doesn't happen. As I said, I am not sure CFFI is the cause of the crash. I tried to print the values passed to the callback, they are not corrupted, valid numbers and strings. Also, the callback is called thousands of times before the crash happen. But on the other hand, if we don't set the callback, the crash doesn't happen; and setting even empty callback guarantees the crash... Anyway, If you provide any patches to CFFI, at least to fix the tests, I can run the tests on Windows. Best regards, - Anton

2 4

[cffi-devel] A question about C and Unicode
by nitralime 23 Mar '11

23 Mar '11

Hi folks! I am playing around with a C library and came across some issues related to unicode in C. In the unicode enabled version of this C library which implements UCS-2 (i.e. just BMP) the "unicode character type" is defined in the header file as follows: ====================================== /* * ZAB_CHAR * ZAB_UC */ #ifdef ZABonAIX #if defined(_AIX51) && defined(ZABwith64_BIT) #define ZABonAIX_wchar_is_4B #else #define ZABonAIX_wchar_is_2B #endif #endif #ifdef ZABonAIX #if defined(_AIX51) && defined(ZABwith64_BIT) #define ZABonAIX_wchar_is_4B #elif defined(ZABccQ) #define ZABonAIX_wchar_is_4B #else #define ZABonAIX_wchar_is_2B #endif #endif #if defined(ZABonNT) || \ defined(ZABonOS400) || \ (defined(ZABonOS390) && !defined(_LP64)) || \ defined(ZABonAIX) && defined(ZABonAIX_wchar_is_2B) #define WCHAR_is_2B #else #define WCHAR_is_4B #endif #if defined(ZABonLIN) && defined(GCC_UTF16_PATCH) #if __GNUC_PREREQ (4,3) #include <uchar.h> #define ZAB_UC_is_char16 #endif #endif #ifndef ZABwithUNICODE #define ZAB_UC_is_1B typedef char ZAB_CHAR; typedef char ZAB_UC; #else /* ZABwithUNICODE */ #if defined(WCHAR_is_2B) #define ZAB_UC_is_wchar typedef wchar_t ZAB_CHAR; typedef wchar_t ZAB_UC; #elif defined(ZAB_UC_is_char16) typedef char16_t ZAB_CHAR; typedef char16_t ZAB_UC; #else #define ZAB_UC_is_UTF16_without_wchar typedef unsigned short ZAB_CHAR; typedef unsigned short ZAB_UC; #endif #endif /* ZABwithUNICODE or not */ /* * CFRSDKwith(out)UTF16_LITERALS * for CFR SDK applications: controls use of UTF-16 * literal enabled compilers. */ #if defined(CFRSDKwithUTF16_LITERALS) #elif defined(CFRSDKwithoutUTF16_LITERALS) #define ZABwithoutUTF16_LITERALS #elif defined(WCHAR_is_2B) || \ defined(ZABonHP_UX) || \ (defined(ZABonLIN) && defined(__i386__) && defined(__GNUC__) && (__GNUC__<3)) || \ (defined(ZABonLIN) && defined(GCC_UTF16_PATCH)) || \ defined(ZABonSUN) || defined(ZABonAIX) /* we have literals for UTF-16 */ #else #define ZABwithoutUTF16_LITERALS #endif ====================================== All this boils down to +---------------------------+ +------>-| typedef wchar_t ZAB_CHAR; | | | typedef wchar_t ZAB_UC; | | +---------------------------+ | +---------+ | +----------------------------+ | Unicode |------+------>-| typedef char16_t ZAB_CHAR; | +---------+ | | typedef char16_t ZAB_UC; | | +----------------------------+ | | +----------------------------------+ +------>-| typedef unsigned short ZAB_CHAR; | | typedef unsigned short ZAB_UC; | +----------------------------------+ The question is now: Is it correct (resp. safe) to /*defctype*/ ZAB_UC just as :uint16 and interpret it as a UFT-16 code point (with an appropriate endiannness)? How can the types like wchar_t and char_16_t be defined (resp. used) in CFFI? Regards Nik

2 1

[cffi-devel] trivial-features, CLX and SBCL mutual incompatibility
by Cyrus Harmon 13 Mar '11

13 Mar '11

Forgive me if you've heard me rant about this before, but there is a mutual incompatibility between CLX, trivial-features (which, for me at least, gets pulled in whenever I try to use CFFI) and SBCL. The problem is that trivial-features puts :little-endian on *features* and CLX has the following code in defdeps.lisp: #+(or lispm vax little-endian Minima) (eval-when (eval compile load) (pushnew :clx-little-endian *features*)) These old-style eval-when conditions cause SBCL to issue a warning, which causes ASDF to stop compiling CLX. There are many workarounds to this, such as loading CLX before CFFI and there are many possible fixes (such as making SBCL less pedantic or making ASDF not stop on warnings of this kind, etc...) But it seems to me that either fixing the CLX source code such that it is more tolerant of SBCL's pedantry or, alternatively, picking less common names for the *features* in trivial-features would be a good thing. I don't really have a preference, but it would be nice if the CLX and trivial-features maintainers would play nice with each other such that, at least when using SBCL, one can load trivial-features and then CFFI. I'm certainly open to other suggestions, but I've grown tired of working around this particular problem. thanks, Cyrus

2 4

[cffi-devel] A question about arrays and enums
by nitralime 07 Mar '11

07 Mar '11

Hi folks! Hopefully here is the right place to ask CFFI user related questions. What would be an appropriate CFFI definition for the following C entities? 1) typedef enum { a = 0x01, b = 0x02, c = a | b, d = 0x04 | c } test; 2) typedef char XXX[8]; How are the C arrays handled in CFFI? Any feedback is very much appreciated! Regards Nik

2 3

[cffi-devel] Memory limit when using with-foreign-pointer?
by Carlo Hamalainen 25 Feb '11

25 Feb '11

Hi, I have a small test program that tries to allocate 100Mb and then say hello: ;;;;;;;;;;;;;;;; start of malloc-test.lisp ;;;;;;;;;;;; (asdf:oos 'asdf:load-op :cffi) (defpackage :malloc-test (:use :common-lisp :cffi)) (in-package :malloc-test) ; Attempt to malloc 100Mb of memory and say hello (with-foreign-pointer (data (* 100 1048576 (foreign-type-size :char))) (print "hello")) ;;;;;;;;;;;;;;;; end of malloc-test.lisp ;;;;;;;;;;;;; But when I run it using SBCL on Ubuntu 10.10 32bit, it complains about some value not being of type (MOD 536870909). Is this a deliberate limit on the part of CFFI or SBCL? If so where can I adjust this limit? $ sbcl This is SBCL 1.0.40.0.debian, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. * (load "malloc-test.lisp") ; loading system definition from /usr/share/common-lisp/systems/cffi.asd into ; #<PACKAGE "ASDF0"> ; registering #<SYSTEM CFFI {ADD22C1}> as CFFI ; loading system definition from /usr/share/common-lisp/systems/babel.asd into ; #<PACKAGE "ASDF0"> ; registering #<SYSTEM BABEL {B2CB081}> as BABEL ; loading system definition from /usr/share/common-lisp/systems/alexandria.asd ; into #<PACKAGE "ASDF0"> ; registering #<SYSTEM :ALEXANDRIA {B4AF1B1}> as ALEXANDRIA ; loading system definition from ; /usr/share/common-lisp/systems/trivial-features.asd into #<PACKAGE "ASDF0"> ; registering #<SYSTEM TRIVIAL-FEATURES {ABBB251}> as TRIVIAL-FEATURES debugger invoked on a TYPE-ERROR in thread #<THREAD "initial thread" RUNNING {AACA871}>: The value 838860800 is not of type (MOD 536870909). Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level. ((LAMBDA ())) 0] Thanks, -- Carlo Hamalainen http://carlo-hamalainen.net

2 3

[cffi-devel] Groveller bitfield support
by Nicolas Martyanoff 12 Feb '11

12 Feb '11

Hi, On 2010-04-30 a patch was submitted to the cffi-devel mailing-list (http://www.mail-archive.com/cffi-devel@common-lisp.net/msg01820.html) adding support for bitfield in the groveller. On 2010-05-01, a ticket was created about this patch on launchpad (https://bugs.launchpad.net/cffi/+bug/622338) Recently, I asked Stelian Ionescu on #lisp if it was possible to apply the patch to the cffi trunk, and the answer seemed positive. Is there something that prevents committing this patch ? I use it in three different personal projects, it works. If the people which manage the git repository don't have the time (for the last 10 months…) to apply a trivial patch (1 minute top), would they consider giving a commit bit to people that can ? Thank you, -- Nicolas Martyanoff http://codemore.org khaelin(a)gmail.com

3 7

[cffi-devel] CLISP with CFFI for Mac OS X
by Andrew Pennebaker 07 Feb '11

07 Feb '11

Hello, I am a budding Common Lisper. I was working on a cl-mechanize<https://github.com/joachifm/cl-mechanize>script to fill out an HTML form when I noticed that one of cl-mechanize's dependencies, cl+ssl <http://common-lisp.net/project/cl-plus-ssl/>, depends on CFFI. When I try to load cl-mechanize, which loads drakma, which loads cl+ssl, I get the following message: *** - CFFI requires CLISP compiled with dynamic FFI support. The problem seems to be that ffcall is not installed. When I try to install it with MacPorts, I get this message: $ sudo port install ffcall ---> Fetching ffcall ---> Attempting to fetch ffcall-1.10.tar.gz from http://ykf.ca.distfiles.macports.org/MacPorts/mpdistfiles/ffcall ---> Verifying checksum(s) for ffcall ---> Extracting ffcall ---> Configuring ffcall ---> Building ffcall Error: Target org.macports.build returned: shell command failed (see log for details) Log for ffcall is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_ffcall/main.log Error: Status 1 encountered during processing. To report a bug, see <http://guide.macports.org/#project.tickets> Here are my specs: - cl-mechanize 0.0 (depends on drakma) - drakma 1.2.3 (depends on cl+ssl) - cl+ssl 2007 - Quicklisp 2010121400 (used to install common lisp packages) - CLISP 2.49 - ffcall 1.10 - MacPorts 1.9.2 - Mac OS X 10.6.6 - MacBook Pro 5,1 Thanks for your consideration, Andrew Pennebaker http://www.yellosoft.us/

2 1

[cffi-devel] CFFI patches for ECL
by Juan Jose Garcia-Ripoll 07 Jan '11

07 Jan '11

+ %foreign-symbol-pointer no longer signals an error when the symbol is not found + various typos in cffi-ecl.lisp made the code not work when the libffi is not linked into ECL. This library is required for CFFI's function calls to work as interpreted code. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com

3 2

[cffi-devel] ECL and foreign-symbol-pointer
by Luke Crook 06 Jan '11

06 Jan '11

I have a report that ECL (at least on win32) throws an error if foreign-symbol- pointer does not find the specified function. The docs state that NIL should be returned in this case. This makes use of lispbuilder-sdl problematic on ECL as I make extensive use of foreign-symbol-pointer to detect at runtime if functions in the SDL_gfx, SDL_image, and SDL_ttf libraries are available. Is this something that needs to be fixed in CFFI or ECL? Thanks, -Luke

3 2