cffi-devel

cffi-devel@common-lisp.net

1113 discussions

What is the equivalent of "void" in CFFI?
by oleg harput 29 Jul '20

29 Jul '20

void InitWindow(int width, int height, const char *title); in C (cffi:defcfun ("InitWindow" init-window) in CFFI :void <==== This void is true or not? (width (:pointer :int)) (heigh (:pointer :int)) (title (:pointer :char))) please help.

2 2

c2ffi handling va_list
by Madhu 16 Jul '20

16 Jul '20

one of the cffi/TODO items has -> Handle va_list. For now it's treated as any other argument. Maybe someone has thought deeply about how to do this? Please let me know if you have any suggestions. [It seems borodust/claw tries to handle this by converting va_list args to variadic lisp arguments - but it still seems to blow up at a cffi:parse-type. Or maybe it is a defect with my Clang-7.0 stdarg vs. what is included with gcc]

4 6

Passing a pointer to a cstruct
by basho1600＠pm.me 30 Jun '20

30 Jun '20

I am using SBCL and trying to pass a pointer to a c-struct to a CFFI routine. The difficulty I am having is in formulating the function call correctly. I have tried 'define-alien-routine' but was getting nowhere. So now I am using cffi:foreign-funcall directly. Here is the call: (cffi:foreign-funcall "v4lconvert_convert" :POINTER convert-info :POINTER *camera-format* :POINTER *display-format* :POINTER raw-image :INT *local-length* :POINTER pixdata :INT pixbuf-size :INT) It is the pointers to the two '-format' items that are causing the trouble I think. Both of them were defined using defcstruct. But the error message I get is complaining about the expansion of the foreign-funcall macro and makes no sense at all to me. Can somebody help me interpret this? ; (CFFI:FOREIGN-FUNCALL "v4lconvert_convert" ; :POINTER ENCOMM.GUI::CONVERT-INFO ; :POINTER ENCOMM.GUI::*CAMERA-FORMAT* :POINTER ; ENCOMM.GUI::*DISPLAY-FORMAT* :POINTER ; ENCOMM.GUI::RAW-IMAGE :INT ENCOMM.GUI::*LOCAL-LENGTH* ; ...) ; --> LET LET LET LET LET LET LET CFFI-SYS:%FOREIGN-FUNCALL ; --> CFFI-SYS::%%FOREIGN-FUNCALL ALIEN-FUNCALL ; --> SB-ALIEN-INTERNALS:INVOKE-WITH-SAVED-FP-AND-PC LAMBDA FUNCTION ; --> SB-ALIEN-INTERNALS:NATURALIZE LET LET LET LET LET LET LET ; --> SB-ALIEN-INTERNALS:MAYBE-WITH-PINNED-OBJECTS PROGN SB-C:%ALIEN-FUNCALL ; ==> ; (SB-ALIEN-INTERNALS:DEPORT #:G77 ; '#<SB-ALIEN::ALIEN-SYSTEM-AREA-POINTER-TYPE SB-SYS:SYSTEM-AREA-POINTER>) ; ; caught WARNING: ; Derived type of #:G77 is ; (VALUES (ALIEN (* T)) &OPTIONAL), ; conflicting with its asserted type ; SB-SYS:SYSTEM-AREA-POINTER. ; See also: ; The SBCL Manual, Node "Handling of Types"

2 1

Re: How can we convert C 0x00000001u (unsigned int in C) to Common Lisp ?
by Luís Oliveira 28 Jun '20

28 Jun '20

The various C integer types map to Lisp integers, so if you want to define the 0x00000010u constant you can use the Lisp value 16. (You can use Lisp's hexadecimal syntax, of course: #x10.) You may find the cl-sdl2 project <https://github.com/lispgames/cl-sdl2> interesting. You can use it and/or read its source to learn how to access SDL2 using CFFI. Cheers, Luís On Sat, 27 Jun 2020 at 13:40, oleg harput <olegharput(a)gmail.com> wrote: > > i am trying to reach C SDL2 using CFFI, in C SDL2 there many functions like int "SDL_Init(Uint32 flags)" > its return value is integer but its are arguments are defined like (in source code) > #define SDL_INIT_TIMER 0x00000001u > #define SDL_INIT_AUDIO 0x00000010u > #define SDL_INIT_VIDEO 0x00000020u /**< SDL_INIT_VIDEO implies SDL_INIT_EVENTS */ > #define SDL_INIT_JOYSTICK 0x00000200u /**< SDL_INIT_JOYSTICK implies SDL_INIT_EVENTS */ > #define SDL_INIT_HAPTIC 0x00001000u > #define SDL_INIT_GAMECONTROLLER 0x00002000u /**< SDL_INIT_GAMECONTROLLER implies SDL_INIT_JOYSTICK */ > #define SDL_INIT_EVENTS 0x00004000u > #define SDL_INIT_SENSOR 0x00008000u > when calling "SDL_Init" using CFFI in CL i did not know how to call arguments like SDL_INIT_TIMER,SDL_INIT_AUDIO,SDL_INIT_VIDEO,... so i tried instead of calling them, i tried to insert their corresping values (they are hexidecimal unsigned integers in C) like > (cffi:foreign-funcall "SDL_Init" > :uint32 32;;for #define SDL_INIT_VIDEO 0x00000020u > :int) > but i am not sure that was a valid transformation or not(32 in CL corresponds to 0x00000020u in C or not) > A better option is to call SDL_INIT_TIMER,SDL_INIT_AUDIO,... directly from cffi but i don not know how because they seemed undefined. > Do you know how to call SDL_INIT_TIMER, SDL_INIT_AUDIO ... using CFFI? > And can you tell me the transformation rules (if there are any) the numbers from C to CL using CFFI? > > пт, 26 июн. 2020 г. в 23:58, Luís Oliveira <luismbo(a)gmail.com>: >> >> On Fri, 26 Jun 2020 at 20:52, oleg harput <olegharput(a)gmail.com> wrote: >> > How can we convert C 0x00000001u (unsigned int in C) to Common Lisp using CFFI? >> > >> > Can we type directly 1?(Is this a valid translation to CL?) >> >> In what context? >> >> -- >> Luís Oliveira >> http://kerno.org/~luis/ -- Luís Oliveira http://kerno.org/~luis/

1 0

How can we convert C 0x00000001u (unsigned int in C) to Common Lisp ?
by oleg harput 26 Jun '20

26 Jun '20

How can we convert C 0x00000001u (unsigned int in C) to Common Lisp using CFFI? Can we type directly 1?(Is this a valid translation to CL?)

2 1

Shared/static libraries in static-program-op context
by Florian Margaine 25 May '20

25 May '20

Good morning cffi-devel, I have been recently sending a bunch of pull requests: - https://github.com/cffi/cffi/pull/162 - https://github.com/cffi/cffi/pull/157 Which are really the following issue: - CFFI loads a static foreign library, either as :grovel-wrapper or :system - The image is dumped with the loaded library - When restored, the runtime will try to reload those "shared" libraries and fails because the path doesn't exist on the target system Specifically for the 2nd one, CFFI provides a :c-file ASDF integration, which, when used with :static-program-op, will compile the C file into an object file (among others), load it as a foreign library, and statically link the object file with the program. In order to make it possible to distribute this static-program-op output, we essentially need to close the foreign library (IOW unload it), or not load it to begin with, before dumping the image. That means tracking those. The 2nd PR I made, as sionescu pointed out, doesn't work because C-FILE code isn't aware of whether it's going to be used for static-program-op or not. So I can see 2 ways out of this: - Either we make FOREIGN-LIBRARY-TYPE settable from the outside (remember that CFFI-TOOLCHAIN is not in the CFFI package), which doesn't sound like the correct way to go to me? - Or we add a CLOSE-ON-DUMP option, which we can use when registering the library. (Btw, that means exposing the REGISTER-FOREIGN-LIBRARY symbol, but that sounds uncontroversial to me.) Both of the PRs I mentioned earlier would benefit this CLOSE-ON-DUMP option. Instead of having to manually go through the foreign libraries and guess which ones need to be closed before dumping, this option would be explicit. What do you think? Regards, -- Florian Margaine

4 6

unwanted recompilation with :CFFI-GROVEL-FILE
by JTK 16 Apr '20

16 Apr '20

Hello, Sorry if this is the wrong place to ask ... I’m using the ‘osicat’ package ( https://common-lisp.net/project/osicat/ <https://common-lisp.net/project/osicat/> and https://github.com/osicat/osicat <https://github.com/osicat/osicat> ) in SBCL on OSX. whenever I do ‘(asdf:load-system “osicat”) it seems to recompile the cffi-grovel-files and their dependencies. Is this normal, or is there some way to make it behave like asdf usually does, that it recompiles only when a file has changed? I know that this issue has 3 components (asdf, cffi, and osicat), but I thought I’d first check whether this is an unavoidable feature of using grovel files. If not, I can try to fix osicat. Here are some of the compilation messages: https://pastebin.com/GKArFCWc <https://pastebin.com/GKArFCWc> JK

2 5

size_t questions
by JTK 15 Apr '20

15 Apr '20

Hello, From the CFFI manual, Section 4.9, I understand that >> "Implementor’s note: size_t is almost always an unsigned int.” However, this seems to fail on a 64 bit Linux computers, where the C ints are 32 bit I’ve had better success with (cffi:defctype size_t #.(cond ((= 4 (cffi:foreign-type-size :pointer)) :uint32) ((= 8 (cffi:foreign-type-size :pointer)) :uint64) (t (error "Failed type lisp-pointer-type")))) Is this general enough to be trusted everywhere? If so, should it be part of CFFI, or at least mentioned in the manual? The current text in the manual doesn’t seem to be working for me, and this is a frequent issue when I port a new foreign library and forget what I did in the past … first thing I do is (apropos “size-t” :cffi) and (apropos “size_t” :cffi) and nothing shows up. Best regards, J.K.

2 1

fsvb and foreign-typedefs with aggregate types
by Madhu 21 Feb '20

21 Feb '20

Consider the following definitions (defcstruct record1 (a :int) (b :int)) (defctype record1-type (:struct record1)) (defcstruct record2a (r (:struct record1)) (c :int)) (defcstruct record2b (r record1-type) (c :int)) record2a_type and record2b_type have identical representations. However when translating structs using libffi-fsvb record2b_type will put a pointer in the r field rather than translating the typedef: struct record2a foo_a() { return (struct record2a) { .r = { .a = 1, .b = 2 }, .c = 2 }; } struct record2a foo_b() { return (struct record2a) { .r = { .a = 1, .b = 2 }, .c = 2 }; } (setq $a (cffi:foreign-funcall "foo_a" (:struct record2a))) ;; => (R (B 2 A 1) C 2) (setq $b (cffi:foreign-funcall "foo_b" (:struct record2b))) ;; => (R #<foreign :VOID 0x1566e70> C 2) The pointer in the r field is useless, because of its extent. The immediate fix for this is to define (either in structures or early-types) (defmethod translate-from-foreign (value (type foreign-typedef)) (translate-from-foreign value (follow-typedefs))) so foreign-typedefs always resolve to a structure But I am not sure. Does this have other ramifications: there seems to be confusion over how typedefs are resolved (and I do not understand code for the bare structs and enhanced-typedefs - perhaps I am expected to go about this problem in some other way? Am I expected to define methods on translate-from-foreign-memory? or should CFFI always translate nested aggregates to lisp lists)

2 8

passing extra libraries when loading
by Alfred M. Szmidt 30 May '19

30 May '19

[I sent this message on the 15th of May, 2018. But it got stuck in the moderation queue.] Hi, On OpenBSD when trying to load libreadline (or libereadline), one gets: * (cffi:load-foreign-library "libreadline.so") sbcl:/usr/lib/libreadline.so.4.0: undefined symbol 'tgetnum' sbcl:/usr/lib/libreadline.so.4.0: undefined symbol 'tgoto' sbcl:/usr/lib/libreadline.so.4.0: undefined symbol 'tgetflag' sbcl:/usr/lib/libreadline.so.4.0: undefined symbol 'tputs' sbcl:/usr/lib/libreadline.so.4.0: undefined symbol 'tgetent' sbcl:/usr/lib/libreadline.so.4.0: undefined symbol 'tgetstr' debugger invoked on a CFFI:LOAD-FOREIGN-LIBRARY-ERROR: Unable to load foreign library (LIBREADLINE.SO-431). Error opening shared object "libreadline.so": Cannot load specified object. This is since libreadline is sometimes not linked directly against ncurses or termcap (to allow the user to decide which of the two to use). On many GNU/Linux systems, libreadline is already linked against libtinfo which provides those functions; so on those systems this is not an issue. But on OpenBSD, libreadline is not linked against it, and one needs to explicitly pass -ltinfo (or similar). Is there some fancy way of passing the extra needed libraries in cffi?

2 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

cffi-devel