refactor: refactor ffi design document

This commit is contained in:
2026-08-11 22:47:50 +08:00
parent 44adb10989
commit d7e564d666
12 changed files with 69 additions and 19 deletions
@@ -0,0 +1 @@
# C/C++ Side
@@ -1,4 +1,4 @@
# C/C++ Headers # C Header
Under this section we discuss how to write the C/C++ header files that accompany the Under this section we discuss how to write the C/C++ header files that accompany the
Rust FFI library. The Rust-side counterpart of each topic is covered in Rust FFI library. The Rust-side counterpart of each topic is covered in
@@ -0,0 +1,3 @@
# C++ Header
@@ -0,0 +1,15 @@
# C/C++ Headers Example
## C Header Example
```c
```
## C++ Header Example
```c++
```
@@ -0,0 +1 @@
# Miscellaneous Stuff
+11 -3
View File
@@ -8,6 +8,14 @@ to write the accompanying C/C++ header files.
## Contents ## Contents
- [FFI Function Signatures](ffi-function-signatures.md) * [Rust Side](rust-side.md)
- [Allowed Data Types](allowed-data-types.md) - [FFI Function Signature](rust-side/func-signature.md)
- [C/C++ Headers](c-cpp-headers.md) - [Allowed Data Types](rust-side/data-types.md)
- [FFI Example](rust-side/example.md)
- [Miscellaneous Stuff](rust-side/misc.md)
* [C/C++ Side](c-cpp-side.md)
- [C Header](c-cpp-side/c-header.md)
- [C++ Header](c-cpp-side/cpp-header.md)
- [C/C++ Headers Example](c-cpp-side/example.md)
- [Miscellaneous Stuff](c-cpp-side/misc.md)
* [Pack Distribution](packer.md)
+2
View File
@@ -0,0 +1,2 @@
# Pack Distribution
@@ -0,0 +1,4 @@
# Rust Side
@@ -0,0 +1,15 @@
# FFI Example
## Rust Core Crate
```rust
```
## Rust FFI Binding Crate
```rust
```
@@ -1,15 +1,15 @@
# FFI Function Signatures # FFI Function Signature
Under this section we discuss the signature requirements of the exported FFI Under this section we discuss the signature requirements of the exported FFI
functions. functions.
## C-style Name Export ## The Way of Exporting Function
FFI functions must be exported under C names, that is, they must not go through the FFI functions must be exported under C names, that is, they must not go through the
C++ name mangling mechanism. C++ name mangling mechanism.
In Rust, you need to decorate the function with the `#[unsafe(no_mangle)]` attribute This requirement means that, in Rust, you need to decorate the function with the
together with `extern "C"`, for example: `#[unsafe(no_mangle)]` attribute together with `extern "C"`, for example:
```rust ```rust
#[unsafe(no_mangle)] #[unsafe(no_mangle)]
@@ -20,7 +20,7 @@ pub extern "C" fn WFStartup() -> CError {
// More FFI functions omitted... // More FFI functions omitted...
``` ```
## Export Name Style ## Function Name Styles
In this subsection, we discuss the naming style of exported functions. In this subsection, we discuss the naming style of exported functions.
@@ -93,10 +93,11 @@ The following examples show some legal and illegal POSIX style function names:
| `wf_GetMessage` | Illegal | `<FUNC>`, which is `GetMessage`, is not snake_case. | | `wf_GetMessage` | Illegal | `<FUNC>`, which is `GetMessage`, is not snake_case. |
| `wf_Icon_get_message` | Illegal | `<STRUCT>`, which is `Icon`, is not snake_case. | | `wf_Icon_get_message` | Illegal | `<STRUCT>`, which is `Icon`, is not snake_case. |
## Parameters and Return Value ## Function Signature Rules
Under this section we discuss the parameters and return value of the exported Under this subsection we discuss the parameters and return value of the exported
functions. A standard FFI function looks like the following on the Rust side: functions. A standard FFI function following this design looks like the following
on the Rust side:
```rust ```rust
#[unsafe(no_mangle)] #[unsafe(no_mangle)]
@@ -160,10 +161,9 @@ absolute, unambiguous success. Every other value's meaning is decided by the
consuming project: it may denote a failure, or, like some Win32 functions, a consuming project: it may denote a failure, or, like some Win32 functions, a
partial success. partial success.
#### Migrating from a bool Return Value > [!TIP]
> Projects that previously returned a plain `bool` can adopt the error-code scheme
Projects that previously returned a plain `bool` can adopt the error-code scheme > with minimal change: define exactly one non-success code, for example
with minimal change: define exactly one non-success code, for example > `const CERROR_FAIL: CError = 1;`, and map every error type to it. The result is
`const CERROR_FAIL: CError = 1;`, and map every error type to it. The result is > equivalent to a `bool`: `CERROR_OK` for success and `CERROR_FAIL` for any failure,
equivalent to a `bool`: `CERROR_OK` for success and `CERROR_FAIL` for any failure, > while leaving room to introduce finer-grained codes later.
while leaving room to introduce finer-grained codes later.
@@ -0,0 +1 @@
# Miscellaneous Stuff