From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Re: dynamic foreign function interface Date: Tue, 26 Jan 2010 23:29:24 +0100 Message-ID: <87aaw08pq3.fsf@gnu.org> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1264545914 3289 80.91.229.12 (26 Jan 2010 22:45:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 26 Jan 2010 22:45:14 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Jan 26 23:45:06 2010 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NZu9d-0002Hs-O4 for guile-devel@m.gmane.org; Tue, 26 Jan 2010 23:45:02 +0100 Original-Received: from localhost ([127.0.0.1]:51781 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NZtzd-00084o-QC for guile-devel@m.gmane.org; Tue, 26 Jan 2010 17:34:41 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NZtv2-0003wX-Ns for guile-devel@gnu.org; Tue, 26 Jan 2010 17:29:56 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NZtux-0003sx-Q9 for guile-devel@gnu.org; Tue, 26 Jan 2010 17:29:56 -0500 Original-Received: from [199.232.76.173] (port=35025 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NZtux-0003sp-KS for guile-devel@gnu.org; Tue, 26 Jan 2010 17:29:51 -0500 Original-Received: from mx20.gnu.org ([199.232.41.8]:15684) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NZtux-0003bR-5k for guile-devel@gnu.org; Tue, 26 Jan 2010 17:29:51 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NZtuv-00078R-6g for guile-devel@gnu.org; Tue, 26 Jan 2010 17:29:49 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.50) id 1NZtur-0004hT-Rw for guile-devel@gnu.org; Tue, 26 Jan 2010 23:29:45 +0100 Original-Received: from reverse-83.fdn.fr ([80.67.176.83]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 26 Jan 2010 23:29:45 +0100 Original-Received: from ludo by reverse-83.fdn.fr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 26 Jan 2010 23:29:45 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 52 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: reverse-83.fdn.fr X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 7 =?iso-8859-1?Q?Pluvi=F4se?= an 218 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 83C4 F8E5 10A3 3B4C 5BEA D15D 77DD 95E2 EA52 ECF4 X-OS: x86_64-unknown-linux-gnu User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:61hTPDET/JgOdgFiQ+Bj5Wmxq3Y= X-detected-operating-system: by mx20.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:9933 Archived-At: Hello! Andy Wingo writes: > I just finished up some work to make a dynamic foreign function > interface. This is on the wip-ffi branch. Nice! > By "dynamic", I mean that you don't have to write C and compile it; you > can do everything at runtime from Scheme. You use dynamic-func and > dynamic-link to get the raw function pointer, and make-foreign-function > to turn that function pointer into a Scheme procedure. > > The interface is very low-level. Obviously declaring that an arbitrary > symbol resolved via `dlsym' is of a certain function type is an unsafe > operation that can lead to crashes. If it’s in a module of its own, then users will (in theory) be able to prevent its use by “untrusted” code, which would be fine. > Apart from that typing problem, you have pointer and struct types. If > you say that the function takes an int8, Guile will ensure that it can > make an int8; but if you say that the function takes a pointer or a > by-value struct, Guile will only ensure that the arg is a "foreign" > (from foreign.[ch]) pointer, only checking lengths in the case that it's > a struct of known length. > > The intention is to provide an expressive Scheme layer, on top of which > any safety constructs can be built as needed. Cool. One thing that would be neat is to integrate nicely with GNU ld’s symbol versioning (it would work around some of the safety lost by not compiling actual C code.) For instance, one would be able to say: (dynamic-func "foo" lib "FOO_0.2") That would use dlvsym() on GNU and ignore the last argument on other systems. (Though ideally ltdl would provide a wrapper for dlvsym). > I would merge it now, except for the fact that it depends on libffi. > Libffi is very portable, and probably exists for all of Guile's > architectures, but it is an extra dependency. Should we require libffi > in Guile 1.9.8? Or should we build the necessary pieces conditionally? Well, it’s always annoying to add a dependency, but OTOH it was bound to happen. So... let’s go? Thanks, Ludo’.