On 09/29/2012 10:43 AM, Alex Rønne Petersen wrote:
Hi folks,
I just read this in tutorial-ffi.md:
The `"abi"` attribute applies to a foreign module (it can not be applied
to a single function within a module), and must be either `"cdecl"`
or `"stdcall"`. Other conventions may be defined in the future.
Why must it be applied to a module as a whole? I don't quite
understand why this limitation is there.
The main reason for this arrangement is that one platform, OS X, does
symbol resolution using a 'two-level namespace' that includes the name
of the library, so encoding that information in the structure of the
bindings is attractive.
I realize that a C library mixing calling conventions would be quite
pathological, but it just seems completely arbitrary that the
attribute is only allowed on modules. I don't think Rust should try to
dictate how external modules are written.
There are workarounds for most of Rust's FFI limitations. In this case
you can (probably) declare multiple extern mods with different abi's.
Could anyone shed some light on this?
The FFI is not expressive enough to encode all the information you might
want. It isn't because of any fundamental design reason, but because all
the use cases haven't been accounted for yet. Most aspects
of the FFI are getting an overhaul.
After the overhaul the ABI will be encoded in the type of the function
and the value of that function will directly represent the foreign
function, as opposed to now where it is Rust ABI wrapper around that
function.
// Explict
extern "C" fn foo();
// Implicit
extern fn foo();
// Windows
extern "stdcall" fn foo();
// You can probably encode the convention in an entire extern block
extern "C" {
fn foo();
fn bar();
}
Linkage will be done completely differently with a more expressive
attribute language, instead of trying to guess from the name of the
extern mod.
Some open bugs:
first class extern fns: https://github.com/mozilla/rust/issues/3321
linkage: https://github.com/mozilla/rust/issues/3321
-Brian
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
