From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: ffi docs Date: Sat, 17 Apr 2010 12:38:47 +0200 Message-ID: References: <87ljco1gyc.fsf@ossau.uklinux.net> <87wrw7t4ad.fsf@ossau.uklinux.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1271500722 24715 80.91.229.12 (17 Apr 2010 10:38:42 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 17 Apr 2010 10:38:42 +0000 (UTC) Cc: guile-devel To: Neil Jerram Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Apr 17 12:38:41 2010 connect(): No such file or directory 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.69) (envelope-from ) id 1O35Q7-0000ik-HL for guile-devel@m.gmane.org; Sat, 17 Apr 2010 12:38:39 +0200 Original-Received: from localhost ([127.0.0.1]:50777 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O35Q6-0004TM-NS for guile-devel@m.gmane.org; Sat, 17 Apr 2010 06:38:38 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O35Q2-0004R3-UC for guile-devel@gnu.org; Sat, 17 Apr 2010 06:38:34 -0400 Original-Received: from [140.186.70.92] (port=54801 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O35Q0-0004NQ-Qt for guile-devel@gnu.org; Sat, 17 Apr 2010 06:38:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O35Py-0004MK-6I for guile-devel@gnu.org; Sat, 17 Apr 2010 06:38:32 -0400 Original-Received: from a-pb-sasl-quonix.pobox.com ([208.72.237.25]:64802 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O35Px-0004M6-Tg for guile-devel@gnu.org; Sat, 17 Apr 2010 06:38:30 -0400 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 8945DABBFC; Sat, 17 Apr 2010 06:38:27 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=Gfwa53qMP20qfcklHNdan4lo1eI=; b=p/XqUw rbOAqoZgLRTqy11+it6pjuny0kYyL9OezOjgHXh+Qe23El6gsppHjVpOI/0+H7Hr YIHzbSkGIctX0pzUioajvZRy+hSh/x34TeZ+mPY2MaNbOMrZhGblB2BUBrkaR57G gnGh6UODriQxUtNFUpTfttRidSno3imX7V8b8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=ksghjuXI1sX7wREcbkR1jjIQLDjHkokA KPz01dTIWQTRwSRm4UNInuMK26Ub+7lKZAj3Bxg4mRFC6mkpl/50nsFj6t1/BxK/ zG3Jj2dkUNJab+CtbBtvjBe7yYyXC7B1ToEvzsmzmX+j6i1bOwUmZpwE2ksRZxhe +lqL+DwQQdU= Original-Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 75FDFABBFB; Sat, 17 Apr 2010 06:38:26 -0400 (EDT) Original-Received: from unquote (unknown [83.202.39.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id DCEA7ABBF9; Sat, 17 Apr 2010 06:38:24 -0400 (EDT) In-Reply-To: <87wrw7t4ad.fsf@ossau.uklinux.net> (Neil Jerram's message of "Fri, 16 Apr 2010 23:34:50 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux) X-Pobox-Relay-ID: 5AE71D54-4A0D-11DF-B7B1-D033EE7EF46B-02397024!a-pb-sasl-quonix.pobox.com X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) 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:10245 Archived-At: Greets, On Sat 17 Apr 2010 00:34, Neil Jerram writes: > I agree that it will make sense for me to handle these doc changes. Thank you very much for this; I have been writing too many docs recently, and long for the hack. >> The facility is typically >> called a "foreign function interface", but that name doesn't appear in >> e.g. "dynamic-link", so I was trying to explain. > > Ah yes, I see now. In that case I think it's just the last clause that > doesn't quite work for me. I would say that the _immediately_ following > text is about "components of foreign libraries", so why say "as we see > in future sections"? > > Maybe: "... really is foreign to Scheme. Foreign function and data > pointers, obtained via `dynamic-func' and `dynamic-pointer', or as > return values from a foreign function call, are inherently untyped, and > depend on the Scheme programmer using them in a way that is consistent > with the library's documented interface. Any other usage is unsafe and > can easily cause the containing Scheme program to crash, and the Guile > low-level FFI cannot protect against this. (This is quite different > from computations on Scheme values; Scheme values are typed, and so > operations on them can check in advance that the value types are as > expected.)" That looks great to me. I also think it's nice to preface this section, as you do, with a brief mention of unsafety. >>> - isn't it actually much more to do with the ELF binary format, rather >>> than with C? If libguile could read and parse C, it would be able to >>> infer the type of any variable that the Scheme layer might request. >>> The problem is precisely that what we are linking with is *not* C >>> anymore... It's just untyped pointers. >> >> I guess you're right, this is confusing. C doesn't really exist at >> runtime, and this API is all about accessing runtime values. > > On further reflection, I think I'm not completely right. Functions > assume that they will be called according to well known C calling > conventions. So I guess there are vestiges of C. > > Out of interest, do other languages that compile to library format use > different calling conventions, and if so can dlopen/dlsym and FFIs work > with them? AFAIK, the only thing you should rely on is the standard ABI for your architecture. For example for Intel 386, there is http://www.sco.com/developers/devspecs/abi386-4.pdf Yes, hosted on SCO. See chapter 3. I believe there are similar documents for other architectures. There are mentions of C there, but there are also attempts to make it known that it's the convention that matters, not the language. Not sure if that helps, though. It certainly doesn't have to do with ELF though, as far as I know. Andy -- http://wingolog.org/