cffi-devel June 2012

cffi-devel@common-lisp.net

2 participants
3 discussions

[cffi-devel] CFFI from git bug with :int64 struct fields?
by Alistair Gee 07 Nov '12

07 Nov '12

When using latest CFFI via clbuild2 (git:// common-lisp.net/projects/cffi/cffi.git), I encountered a problem with :int64 fields. CFFI seems to treat this field as (signed-byte 32). This is with SBCL x86-64 on Ubuntu 10.10: This is SBCL 1.0.55.1-6548750, 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. * (require :cffi) NIL * (cffi:defcstruct foo (a :int64)) FOO * (cffi:with-foreign-object (foo 'foo) (setf (cffi:foreign-slot-value foo 'foo 'a) 123456789012345)) ; in: CFFI:WITH-FOREIGN-OBJECT (FOO 'FOO) ; (SETF (CFFI:FOREIGN-SLOT-VALUE FOO 'FOO 'A) 123456789012345) ; --> LET* MULTIPLE-VALUE-BIND LET PROGN CFFI::FOREIGN-SLOT-SET SETF LET* ; --> MULTIPLE-VALUE-BIND LET PROGN CFFI::MEM-SET CFFI-SYS:%MEM-SET LET SETF ; ==> ; (SB-KERNEL:%SET-SIGNED-SAP-REF-32 FOO 0 #:VALUE14) ; ; caught WARNING: ; Derived type of #:VALUE14 is ; (VALUES (INTEGER 123456789012345 123456789012345) &OPTIONAL), ; conflicting with its asserted type ; (SIGNED-BYTE 32). ; See also: ; The SBCL Manual, Node "Handling of Types" ; ; compilation unit finished ; caught 1 WARNING condition debugger invoked on a SIMPLE-TYPE-ERROR in thread #<THREAD "initial thread" RUNNING {10029B97C3}>: Value of #:VALUE14 in (SB-KERNEL:%SET-SIGNED-SAP-REF-32 FOO 0 #:VALUE14) is 123456789012345, not a (SIGNED-BYTE 32). 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. (SB-C::%COMPILE-TIME-TYPE-ERROR (123456789012345) (SIGNED-BYTE 32) #<unavailable argument> ((SB-KERNEL:%SET-SIGNED-SAP-REF-32 FOO 0 #:VALUE14) . #:VALUE14)) 0] 0

3 4

[cffi-devel] requesting help debugging error in libclang bindings
by Eric Schulte 01 Jul '12

01 Jul '12

Hello, I'm working to write CFFI binding for libclang [1], I've used swig to generate CFFI declarations of all libclang bindings, and I'm hoping to wrap those in a nice CLOS-based interface (my code is up here [2]). However I've run into an error which I'm having trouble getting past. Although the following simple C code [3] compiles and runs w/o problem. A direct translation into lisp [4] using the swig-generated cffi bindings throws this error [5]. For some reason the `clang_getTranslationUnitCursor' function always throws an error. FWIW I'll include the original C function headers [6] and the swig-generate CFFI declarations [7] below. I'm using SBCL version 1.0.57 and CFFI version 0.10.6 installed with quicklisp. Any idea what could be causing this error? Could the problem lie in SBCL, in CFFI, or possibly in some difference in state between the C world and the lisp world? Thanks, Footnotes: [1] http://clang.llvm.org/doxygen/group__CINDEX.html [2] https://github.com/eschulte/cl-libclang [3] hello-cursor.c // -*- C -*- #include "clang-c/Index.h" #include <stdio.h> int main(int argc, char *argv[]) { // declare CXIndex Idx; CXTranslationUnit TU; CXCursor CU; enum CXCursorKind Kind; // initialize Idx = clang_createIndex(0, 0); TU = clang_createTranslationUnit(Idx, "hello.ast"); CU = clang_getTranslationUnitCursor(TU); Kind = clang_getCursorKind(CU); // is the cursor null if(clang_Cursor_isNull(CU)) return 1; else printf("cursor is not null\n"); // cursor Kind (should be 300 for 'root') if(Kind != 300) return 1; else printf("kind of cursor is %d\n", Kind); // cleanup clang_disposeTranslationUnit(TU); clang_disposeIndex(Idx); return 0; } [4] hello-cursor.lisp ;; -*- lisp -*- (require :libclang) (in-package :libclang) (defvar idx nil "CXIndex") (defvar tu nil "CXTranslationUnit") (defvar cu nil "CXCursor") (defvar kind nil "CXCursorKind") (setf idx (clang_createIndex 0 0)) (setf tu (clang_createTranslationUnit idx "etc/hello.ast")) (setf cu (clang_getTranslationUnitCursor tu)) ;; we never get this far (setf kind (clang_getCursorKind cu)) [5] error running with SBCL 1.0.57 CORRUPTION WARNING in SBCL pid 30785(tid 140737353975552): Memory fault at 7841 (pc=0x7ffff57edb4a, sp=0x7ffff6e37508) The integrity of this image is possibly compromised. Continuing with fingers crossed. debugger invoked on a SB-SYS:MEMORY-FAULT-ERROR in thread #<THREAD "main thread" RUNNING {1002998D93}>: Unhandled memory fault at #x3E800007841. 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. [6] from Index.h // -*- C -*- CINDEX_LINKAGE CXIndex clang_createIndex(int excludeDeclarationsFromPCH, int displayDiagnostics); // ... CINDEX_LINKAGE CXTranslationUnit clang_createTranslationUnit(CXIndex, const char *ast_filename); // ... CINDEX_LINKAGE CXCursor clang_getTranslationUnitCursor(CXTranslationUnit); [7] from libclang-swig.lisp ;; -*- lisp -*- (cffi:defcfun ("clang_createIndex" clang_createIndex) :pointer (excludeDeclarationsFromPCH :int) (displayDiagnostics :int)) ;; ... (cffi:defcfun ("clang_createTranslationUnit" clang_createTranslationUnit) :pointer (arg0 :pointer) (ast_filename :string)) ;; ... (cffi:defcstruct CXCursor (kind CXCursorKind) (xdata :int) (data :pointer)) ;; ... (cffi:defcfun ("clang_getTranslationUnitCursor" clang_getTranslationUnitCursor) CXCursor (arg0 :pointer)) -- Eric Schulte http://cs.unm.edu/~eschulte

2 1

[cffi-devel] cffi-libffi funcall path and :string
by Ryan Pavlik 07 Jun '12

07 Jun '12

For functions using the libffi foreign-funcall path, functions defined with :string parameters still fail because TRANSLATE-INTO-FOREIGN-MEMORY is not defined on FOREIGN-STRING-TYPE. E.g., (defcfun ("xcb_intern_atom" xcb-intern-atom) (:struct xcb-intern-atom-cookie-t) (c :pointer) (only_if_exists :unsigned-char) (name_len :unsigned-short) (name :string)) Calling this fails: There is no applicable method for the generic function #<STANDARD-GENERIC-FUNCTION TRANSLATE-INTO-FOREIGN-MEMORY (5)> when called with arguments (#.(SB-SYS:INT-SAP #X7FFFD8000DC0) #<CFFI::FOREIGN-STRING-TYPE :UTF-8> #.(SB-SYS:INT-SAP #X7FFFECDB7FD8)). [Condition of type SIMPLE-ERROR] This is using unmodified master. -- Ryan Pavlik <rpavlik(a)gmail.com> 425.220.9585

3 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

cffi-devel June 2012