From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: FFI again Date: Mon, 07 Oct 2013 10:41:41 +0900 Message-ID: <87iox9luwa.fsf@uwakimon.sk.tsukuba.ac.jp> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1381110120 14461 80.91.229.3 (7 Oct 2013 01:42:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 7 Oct 2013 01:42:00 +0000 (UTC) Cc: joakim@verona.se, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 07 03:42:04 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VSzpj-0002dt-KS for ged-emacs-devel@m.gmane.org; Mon, 07 Oct 2013 03:42:03 +0200 Original-Received: from localhost ([::1]:57028 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VSzpi-0002JB-V2 for ged-emacs-devel@m.gmane.org; Sun, 06 Oct 2013 21:42:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56479) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VSzpY-0002J0-PL for emacs-devel@gnu.org; Sun, 06 Oct 2013 21:42:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VSzpR-0008Dn-Gc for emacs-devel@gnu.org; Sun, 06 Oct 2013 21:41:52 -0400 Original-Received: from mgmt1.sk.tsukuba.ac.jp ([130.158.97.223]:32774) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VSzpQ-0008Da-VY for emacs-devel@gnu.org; Sun, 06 Oct 2013 21:41:45 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id E7ABF3FA098A; Mon, 7 Oct 2013 10:41:41 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id D6D191A2707; Mon, 7 Oct 2013 10:41:41 +0900 (JST) In-Reply-To: X-Mailer: VM undefined under 21.5 (beta34) "kale" 182d01410b8d XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 130.158.97.223 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:163933 Archived-At: Stefan Monnier writes: > I personally don't have any experience either way. The SXEmacs people do, though (using libffi). Their proof-of-concept is a simple wrapper for libcurl. If somebody wants to push forward with this they should ask. Most of the other scripting languages (Python for sure has "ctypes", Ruby has something, maybe Guile does too) have libffi wrappers. That experience might be useful too. Me, I'm just going to use the SXEmacs patch (for XEmacs). If Steve Y is willing to sign off, that is probably a good route for Emacs to start with (the DEFUN macro is different and I don't think ours is FSF-assigned, but the translation is routine). > But I think that a good benchmark for an FFI is to make our libxml > and libgnutls code use it. libxml, maybe. libgnutls I would continue to provide a dedicated wrapper for. It's very tricky to get the Lisp-to-C type matching robust in an FFI, and if there's a problem in the FFI you probably break all existing modules by fixing it. In the meantime, if the FFI doesn't do *all* the checks just right (and that's very hard to do in standard C because called libraries typically use platform-dependent types like "int" rather than "int32", and are often pretty cavalier about casting internally), you have a crash waiting for some unsuspecting Lisp code. Nevertheless, there is a lot of pressure to avoid changing the FFI. Better to tweak all that stuff in dedicated code when you're dealing with security code. > > The routines declared in lisp.h do not form stable interface. > > Indeed, we'd need to define a slightly more stable API. This is awfully tricky. The Python guys spent something like ten years developing their ABI specification, and had the advantage of a religious mandate for backward compatibility. Emacs has always been wild and woolly with respect to APIs and ABIs since they're all internal as far as Emacs is concerned. Even in the published Lisp Reference backward compatibility with 3rd party programs is frequently (as measured with decade time units) sacrificed to somebody's sense of symmetry. Every release of Emacs has new surprises for XEmacs and SXEmacs. (This isn't a complaint, it's a statement of fact. The point is that these surprises are much more painful for users at the level of C code because it's not safe and because it's harder for most of them to change.)