Re: ffi docs

[Andy Wingo <wingo@pobox.com>]

Greets,

On Sat 17 Apr 2010 00:34, Neil Jerram <neil@ossau.uklinux.net> 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/