| So, an alternative
possibility might be: - Use Uppercase ABI names to indicate broad, "cross-platform" variants (e.g., C, Rust). - Use lowercase ABI names to indicate platform-specific variations (e.g., cdecl, stdcall, fastcall, aapcs). Each platform must define what it means to be a "C" function or "Rust" function (presumably: cdecl on x86, aapcs on ARM). Then the preferred thing would be to do `extern "C" fn()` and so forth. But you can use the lowercase variants if that is necessary for some reason. Invoking a function whose ABI is not defined for the current target (e.g., an attempt to call a stdcall function on ARM) would be a compile-time error. Most of the time this means you just use `extern "C"` and things will work. For weirder cases where something is somehow `stdcall` on x86 but `aapcs` on ARM (if such a thing ever happens), you can use #[cfg] directives. I envision a pattern like: #[cfg(target=x86)] // or whatever mod TheFn { type T = extern "stdcall" fn(...) -> ...; extern "stdcall" { fn the_fn(...) -> ...; } } #[cfg(target=aapcs)] // or whatever mod TheFn { type T = extern "aapcs" fn(...) -> ...; extern "stdcall" { fn the_fn(...) -> ...; } } Now I can refer to `TheFn::T` as the appropriate type of `TheFn` and `TheFn::the_fn()` to call it. A touch verbose but I honestly don't know where if ever this situation arises (maybe a port of Windows to some other architecture?) gcc allows you to associate multiple ABIs with a function definition, one per architecture, but it is unclear to me how that interacts with e.g. function pointers. My guess is that it just...doesn't. Therefore I'd prefer not to do the same. Niko
|
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
