| @@ -1612,6 +1612,9 @@ mod prim_ref {} |
|
|
| 1612 |
1612 |
/// pointers, make your type [`Option<fn()>`](core::option#options-and-pointers-nullable-pointers) |
| 1613 |
1613 |
/// with your required signature. |
| 1614 |
1614 |
/// |
|
1615 |
+/// Note that FFI requires additional care to ensure that the ABI for both sides of the call match. |
|
1616 |
+/// The exact requirements are not currently documented. |
|
1617 |
+/// |
| 1615 |
1618 |
/// ### Safety |
| 1616 |
1619 |
/// |
| 1617 |
1620 |
/// Plain function pointers are obtained by casting either plain functions, or closures that don't |
| @@ -1750,8 +1753,13 @@ mod prim_ref {} |
|
|
| 1750 |
1753 |
/// is also used rarely. So, most likely you do not have to worry about ABI compatibility. |
| 1751 |
1754 |
/// |
| 1752 |
1755 |
/// But assuming such circumstances, what are the rules? For this section, we are only considering |
| 1753 |
|
-/// the ABI of direct Rust-to-Rust calls, not linking in general -- once functions are imported via |
| 1754 |
|
-/// `extern` blocks, there are more things to consider that we do not go into here. |
|
1756 |
+/// the ABI of direct Rust-to-Rust calls (with both definition and callsite visible to the |
|
1757 |
+/// Rust compiler), not linking in general -- once functions are imported via `extern` blocks, there |
|
1758 |
+/// are more things to consider that we do not go into here. Note that this also applies to |
|
1759 |
+/// passing/calling functions across language boundaries via function pointers. |
|
1760 |
+/// |
|
1761 |
+/// **Nothing in this section should be taken as a guarantee for non-Rust-to-Rust calls, even with |
|
1762 |
+/// types from `core::ffi` or `libc`**. |
| 1755 |
1763 |
/// |
| 1756 |
1764 |
/// For two signatures to be considered *ABI-compatible*, they must use a compatible ABI string, |
| 1757 |
1765 |
/// must take the same number of arguments, the individual argument types and the return types must |