Ffi Code Review
/install ffi-code-review
FFI Code Review
Review Workflow
- Check Cargo.toml -- Note Rust edition (2024 has breaking changes to extern blocks and unsafe attributes),
build-dependencies(bindgen, cc, pkg-config),crate-type(cdylib,staticlib), andlinkskey - Check build.rs -- Verify link directives (
cargo:rustc-link-lib,cargo:rustc-link-search), bindgen configuration, and C source compilation - Check extern blocks -- Verify calling conventions, symbol declarations, and safety annotations
- Check type layout -- Every type crossing FFI must be
#[repr(C)]or a primitive FFI type - Check string and pointer handling -- CStr/CString usage, null checks, ownership transfers
- Check callbacks --
extern "C" fnpointers, panic safety across FFI boundary - Gates -- Complete Gates below before reporting; do not skip ahead on “internal verification”
Gates
Complete in order. Do not emit findings until Gate 4 passes for each issue.
Gate 1 — Crate context (on disk)
PASS when: You opened the reviewed crate’s Cargo.toml (workspace member path if applicable) and recorded edition =, plus any of links, crate-type, or build-dependencies that matter for this FFI.
Blocks rationalization: Edition-specific findings (unsafe extern "C" {}, #[unsafe(no_mangle)], etc.) require this — if edition is not 2024, do not flag 2024-only requirements.
Gate 2 — Linkage and binding sources
PASS when: If the crate links native code or uses bindgen/pkg-config, you opened build.rs (or the checked-in bindings entry point). If there is no build.rs, you stated that bindings are hand-written and reviewed those extern / include! sites.
Artifact: At least one path you opened (e.g. build.rs, src/ffi.rs, or OUT_DIR bindings via include!).
Gate 3 — Code evidence
PASS when: Every planned finding has a target [FILE:LINE] from a full function/block you read, not only diff hunks or partial snippets.
Gate 4 — Pre-report protocol
PASS when: You loaded and applied beagle-rust:review-verification-protocol, including FFI-Specific Verification for repr(C), safety comments, ownership/callbacks, or bindgen-heavy code.
Output Format
Report findings as:
[FILE:LINE] ISSUE_TITLE
Severity: Critical | Major | Minor | Informational
Description of the issue and why it matters.
Quick Reference
| Issue Type | Reference |
|---|---|
| C-to-Rust type mapping, repr(C) layout, enums, opaque types | references/type-mapping.md |
| Safe wrappers, ownership transfer, callbacks, build.rs, testing | references/safety-patterns.md |
Review Checklist
extern Blocks and Calling Conventions
- Foreign function declarations use
extern "C"(explicit, not bareextern) - Edition 2024:
extern "C" {}blocks written asunsafe extern "C" {} - Functions exposed to C use
extern "C" fn(not default Rust calling convention) - Calling convention matches the foreign library (
"C","system"for Win32 API) -
#[link(name = "...")]specifies the correct library name -
#[link(name = "...", kind = "static")]used when statically linking
Symbol Management
- Exported functions use
#[no_mangle]to preserve symbol names - Edition 2024:
#[no_mangle]written as#[unsafe(no_mangle)] - Edition 2024:
#[export_name = "..."]written as#[unsafe(export_name = "...")] -
#[link_name = "..."]used when Rust name differs from C symbol - Exported items are
pub(only public#[no_mangle]symbols appear in library output)
Type Layout
- Every struct/union crossing FFI has
#[repr(C)]-- Rust's default layout is undefined - Primitive types use
std::ffi/std::os::rawequivalents (c_int,c_char,c_void) - No bare
i32where C usesint-- usec_int(width varies by platform) - Quirky C types like
__be32use byte arrays ([u8; 4]), not Rust integers - Enums crossing FFI use
#[repr(C)]or#[repr(u8)]/#[repr(u32)]with explicit discriminants - C-style bitflag enums use a newtype around an integer (or
bitflagscrate), not a Rust enum -
#[non_exhaustive]on enums representing C enumerations that may gain new values
String Handling
- C strings use
CStr(borrowed) orCString(owned), never&strorString -
CString::new()result is checked for interior null bytes (returnsErron\0) -
CStringoutlives any*const c_charpointer derived from it via.as_ptr() - Incoming
*const c_charvalidated withCStr::from_ptr()insideunsafe - No assumption that C strings are valid UTF-8 -- use
to_str()which returnsResult - OS paths use
OsStr/OsStringandCStr, not&str
Ownership and Allocation
- Clear ownership contract: who allocates, who frees
- Rust-allocated memory freed by Rust (
Box::from_raw), C-allocated freed by C -
Box::into_raw/Box::from_rawpaired correctly for heap transfers -
Vec::into_raw_partsused when passing arrays to C (pointer + length + capacity) - Destructor functions exposed for every opaque Rust type given to C
- No
Droprunning on C-allocated memory (and vice versa)
Callbacks
- Callback types are
extern "C" fn(...), not closures orfn(...) - Callbacks use
std::panic::catch_unwindto prevent panics from unwinding across FFI - Callback context passed as
*mut c_voidwith safe reconstruction at call site -
Option\x3Cextern "C" fn(...)>used for nullable function pointers (niche optimization)
Bindgen and Build Scripts
- Bindgen output reviewed for correctness (auto-generated types may need adjustment)
-
-syscrate pattern used for raw bindings, separate crate for safe wrappers -
build.rsusescargo:rustc-link-libandcargo:rustc-link-searchcorrectly -
linkskey inCargo.tomlprevents duplicate linking of the same native library - Platform-specific bindings generated per-build (not checked in for a single platform)
Safety Documentation
- Every
unsafeblock has a// SAFETY:comment explaining invariants - Every public FFI wrapper function documents safety requirements
- Edition 2024:
unsafe fnbodies use explicitunsafe {}blocks around unsafe ops
Severity Calibration
Critical (Block Merge)
- Missing
#[repr(C)]on types crossing FFI boundary (undefined memory layout) - Wrong string handling:
&str/StringwhereCStr/CStringrequired - Ownership confusion: freeing C-allocated memory with Rust's allocator (or vice versa)
- Panic unwinding across FFI boundary without
catch_unwind - Using Rust enum for C bitflags (invalid discriminant = undefined behavior)
- Passing closure where
extern "C" fnpointer required
Major (Should Fix)
- Missing safety documentation on
unsafeblocks or public FFI functions - No null pointer check on incoming
*const T/*mut Tbefore dereferencing CStringdropped before its pointer is used by C (dangling pointer)- Missing
#[link(name = "...")]causing link failures on some platforms - Edition 2024:
externblock not markedunsafe extern - Edition 2024:
#[no_mangle]not wrapped in#[unsafe(...)]
Minor (Consider Fixing)
- Using
i32instead ofc_intfor Cint(correct on most platforms but not portable) - Missing
#[non_exhaustive]on enums mapping to extensible C enumerations - Verbose manual bindings where bindgen would be more maintainable
- Checked-in bindings without platform guards
Informational
- Suggestions to split raw bindings into a
-syscrate - Suggestions to add opaque wrapper types for distinct
*mut c_voidpointers - Suggestions to use
Option\x3CNonNull\x3CT>>for nullable pointers
Valid Patterns (Do NOT Flag)
unsafe extern "C" {}in edition 2024 -- correct form for foreign declarations#[unsafe(no_mangle)]in edition 2024 -- correct form for symbol exportOption\x3Cextern "C" fn(...)>for nullable callbacks -- niche optimization guaranteedOption\x3CNonNull\x3CT>>for nullable pointers -- zero-cost nullable pointer pattern*mut c_voidfor opaque C types -- standard when internal layout is irrelevant- Distinct empty structs wrapping
c_voidfor type-safe opaque pointers -- prevents pointer confusion CStr::from_bytes_with_nul_uncheckedwith compile-time literal -- safe when literal is known null-terminatedextern "C-unwind"for controlled unwinding -- valid per RFC 2945include!(concat!(env!("OUT_DIR"), "/bindings.rs"))in bindgen crates -- standard patternBox::into_raw/Box::from_rawpairs for ownership transfer -- correct pattern when paired
Before Submitting Findings
Complete Gates 1-4 in order before reporting any issue; Gate 4 incorporates beagle-rust:review-verification-protocol.
- 确保已安装 OpenClaw(本地或 Docker 部署)
- 在对话框中输入安装命令:
/install ffi-code-review - 安装完成后,直接呼叫该 Skill 的名称或使用
/ffi-code-review触发 - 根据 Skill 的参数说明提供必要输入,即可获得结构化输出
Ffi Code Review 是什么?
Reviews Rust FFI code for type safety, memory layout compatibility, string handling, callback patterns, and unsafe boundary correctness. Use when reviewing e... 它是一个面向 Claude Code / OpenClaw 的 AI Agent Skill 插件,目前累计下载 108 次。
如何安装 Ffi Code Review?
在 OpenClaw 或 Claude Code 对话框中运行命令「/install ffi-code-review」即可一键安装,无需额外配置。
Ffi Code Review 是免费的吗?
是的,Ffi Code Review 完全免费,采用 MIT-0 许可证,可自由下载、安装和使用。
Ffi Code Review 支持哪些平台?
Ffi Code Review 跨平台运行,可在任意部署了 OpenClaw / Claude Code 的环境中使用(cross-platform)。
谁开发了 Ffi Code Review?
由 Kevin Anderson(@anderskev)开发并维护,当前版本 v1.0.1。