cffi-devel January 2006

cffi-devel@common-lisp.net

34 participants
97 discussions

[cffi-devel] foreign-alloc is mostly untested
by Hoehle, Joerg-Cyril 02 Jan '06

02 Jan '06

I just found out that foreign-alloc is a complex function (many keyword arguments) and it has no single testcase yet. Regards, Jörg Höhle.

1 0

Re: [cffi-devel] Providing access to errno in CFFI-SYS
by Hoehle, Joerg-Cyril 02 Jan '06

02 Jan '06

James Bielman wrote: >While working through my fancy gettimeofday CFFI example, I've added a >type translator used as the return type for standard C functions that >return a negative integer on error and set 'errno'. A very useful type indeed. I'd like to hear about its design. Would a result of -1 raise a Lisp error? [ok, I'm checking the sources myself, "darcs pull" ...] I think you did TRT by throwing an error in that case. Yet possibly some people might object throwing errors out of "low-level" FFI code, as it requires them to be very careful about freeing all resources... May I suggest you defined a CLCS condition, so there's a) a known slot where to get the errno value (instead of pulling it out of a string) b) a known condition and a possibility to hook in with HANDLER-BIND etc.? I believe exporting an interface to errno from CFFI will avoid many headaches to users (writing unportable or otherwise broken code to get its value). Please go ahead and include this stuff in the main tree, not examples/. >(minusp value) I think you should specifically check for -1. Some functions could return a legal value such large that it overflows an int and becomes negative. Actually, I wonder whether the DWIM pattern of all these functions shouldn't have been: "it returns an unsigned int, except for (unsigned-int)(-1) which is taken to mean `error'". E.g. lseek() etc. (although I don't know whether Linux supports files of length >2GB, but lseek is just an example). BTW, I find the name syscall-result misleading. What about int-or-errno? (Or rather, to keep with my own advice: uint-or-errno)? Or, like the boolean generic type, write a (define-foreign-type maybe-errno (&optional (base-type int))? >Since errno is often a macro expanding to a function, I can't very well >define it as a foreign global. It is not, so it would be wrong to do so. errno is a per-thread value on all systems that support threading. In some versions of GLIBC, it's a #define wrapper around a function -- errno_location(). > (defun errno-value () (sb-alien:get-errno)) As soon as errno is there, people will ask for being able to reset it to 0. >haven't found anything in Allegro CL or CLISP (Jörg?) for this yet. See clisp/modules/bindings/glibc/linux.lisp as a source of inspiration & read the comments about errno there. It's hairy indeed. >(I know errno isn't _completely_ portable---at least one OS I use >regularly, Windows CE, doesn't have it at all [...] Interesting to know, thanks! Regards, Jörg Höhle

2 1

Re: [cffi-devel] Branch: New Type Translator Interface
by Hoehle, Joerg-Cyril 02 Jan '06

02 Jan '06

James Bielman wrote: >I've done yet-another rewrite of the type translator >interface. It does >everything through generic functions at run-time, which allows us to >specialize on both the Lisp object being converted, and the >foreign type we are converting to. How does this interact with compiler macros and the wish for partial evaluation at compile-time? This remembers me of the AMOP book which carefully distinguishes things possibly known at compile or macro-expansion time from the non-optimizable run-time path. It's design seems at odd which your approach of mixing both: the AMOP is very careful to separate the possibly known paths (depending on the type) from the unknown (depending on the value) and as a result, separates functions that operate on types only. Regards, Jorg Hohle.

2 1

[cffi-devel] a thought on string encodings
by Hoehle, Joerg-Cyril 02 Jan '06

02 Jan '06

Hi, I hope encoding stuff will be the next great addition to CFFI. Here's some vague idea I once had. I got the impression that there are (at least) two types of functions: - one where the conversion depends on whatever dynamic calling context - another where the conversion is fixed, i.e. depends on the function only, not on the caller (but possibly on the library). Given CFFI's post transformers, I suspect that there's an opportunity to model both kinds of functions, i.e. - some where defcfun expands to defaults of custom:*foreign-encoding* (in CLISP speak) - some where the wrappers within defcfun impose a given encoding, e.g. ASCII, ISO-8859-1, UTF-8 or UTF16. Examples that come to mind are the GDI YouNameIt*W() functions on MS-Windows, where the strings are all UTF-16. One could use that alternatively with getenv(), which might ask for UTF-8 (or just use the default from the Lisp system). Sometimes it seems, the encoding depends on the library to which the function belongs. Just my $0.02, and I'm eager to see what kind of design you'll come up with. Regards, Jörg Höhle.

2 1

Re: [cffi-devel] Calling function expecting char**
by Hoehle, Joerg-Cyril 02 Jan '06

02 Jan '06

James Bielman wrote: >I wonder if MEM-AREF might be >better given a more generic name and documented as the default accessor >for foreign pointers. I think mem-AREF is fine, since (apropos "AREF") will find it, and it nicely fits array access. Yet I also thought MEM-REF's offset-as-bytes needs better visibility (presence in the user's mind & documentation). That's precisely why I submitted one patch to the documentation on 2005-12-23. Let's hope it will be enough and this issue will not become a FAQ or a FMB (frequently made bug). I think it's perfectly fine for MEM-REF to count in bytes. Such a low-level operator is needed. > I don't think user code will need to use the more >primitive features of MEM-REF directly very often... What about dereferencing a pointer (not as a slot in a struct)? mem-ref is the only candidate for that. BTW, thanks to Yaroslav for checking whether the documentation works. Every project needs such contributions. Regards, Jorg Hohle.

1 0

[cffi-devel] Re: [Sbcl-devel] Re: CFFI Callbacks on SBCL
by Thomas F. Burdick 01 Jan '06

01 Jan '06

On 12/31/05, Juho Snellman <jsnell(a)iki.fi> wrote: > <luismbo(a)gmail.com> wrote: > > We're not even testing if the callback moves or not. Our libtest is > > not saving the callbacks' address. > > > > Here's the a testcase, using sb-alien (sort of): > > Thanks. The problem is that the callback support assumes that > #'SB-VM::ENTER-ALIEN-CALLBACK can never move [*]. Which is no > longer true on x86 and x86-64 as of a few releases ago, since > everything is in the dynamic space by default, and will get > relocated when the core is saved [**]. Okay, that makes sense now. Any pointers to the discussion of why purify doesn't happen by default anymore on those platforms? (curious). > A workaround is to run PURIFY once before creating any callbacks. The > proper solution would be adding a level of indirection into the > generated callback wrappers. Maybe make 'SB-VM::ENTER-ALIEN-CALLBACK a > static symbol, so that it will be guaranteed to not move, and then > emit instructions to peek into its symbol-function slot. The layout of symbols is unlikely to change soon, so that will work fine. But another option would be to cater to what the trampolines do now and move the ENTER-ALIEN-CALLBACK function to static space.

2 1

[cffi-devel] Re: CFFI Callbacks on SBCL
by Luís Oliveira 01 Jan '06

01 Jan '06

I'm Cc-ing cffi-devel and sbcl-devel, since I'm sure more people will be interested in this and hopefully others will help in figuring this out. On 2005-dec-31, at 13:59, Thomas F. Burdick wrote: > I noticed in the #lisp logs that you're having problems preserving > callbacks across image saves. SBCL already goes to quite a bit of > effort to make sure this works. From C's point of view, the callbacks > will never move. But because your library is in lisp, and persists > across image saves, from its point of view, callback objects can move > at arbitrary times. Instead of storing SAPs, you should store the > alien-value object that alien-lambda returns. If you actually need > the SAP, get it only when you need it, using alien-sap. We're not even testing if the callback moves or not. Our libtest is not saving the callbacks' address. Here's the a testcase, using sb-alien (sort of): luis@nhop:/tmp$ cat sbcl-callback.lisp (use-package :sb-alien) (define-alien-routine "qsort" void (base system-area-pointer) (nmemb int) (size int) (compar system-area-pointer)) (defparameter *callback* (sb-alien::alien-lambda int ((a system-area-pointer) (b system-area-pointer)) (let ((x (sb-sys:signed-sap-ref-32 a 0)) (y (sb-sys:signed-sap-ref-32 b 0))) (cond ((> x y) 1) ((< x y) -1) (t 0))))) (defun test () (let ((array (alien-sap (make-alien (unsigned 32) 10)))) (dotimes (i 10) (setf (sb-sys:signed-sap-ref-32 array (* i 4)) (nth i '(7 2 8 9 6 1 10 3 5 4)))) (qsort array 10 4 (alien-sap *callback*)) (dotimes (i 10) (format t "~A " (sb-sys:signed-sap-ref-32 array (* i 4)))) (free-alien (sap-alien array (* (unsigned 32)))))) luis@nhop:/tmp$ sbcl --sysinit /dev/null --userinit /dev/null This is SBCL 0.9.8.3, 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 "sbcl-callback.lisp") T * (test) 1 2 3 4 5 6 7 8 9 10 NIL * (sb-ext:save-lisp-and-die "test.core") [undoing binding stack and other enclosing state... done] [saving current Lisp image into /tmp/test.core: writing 1584 bytes from the read-only space at 0x01000000 writing 1368 bytes from the static space at 0x05000000 writing 22609920 bytes from the dynamic space at 0x09000000 done] luis@nhop:/tmp$ sbcl --core test.core This is SBCL 0.9.8.3, 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. * (test) debugger invoked on a SB-KERNEL::MEMORY-FAULT-ERROR: memory fault 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-KERNEL::MEMORY-FAULT-ERROR) 0] Any pointers? Well, I'm off to party. Happy new year! -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/ Equipa Portuguesa do Translation Project http://www.iro.umontreal.ca/translation/registry.cgi?team=pt

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

cffi-devel January 2006