rust-unsafe_skill

This skill helps engineers write safer, higher-performance unsafe Rust code by enforcing SAFETY comments, validating patterns, and guiding FFI and pointer use.
  • Shell

20

GitHub Stars

3

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill huiali/rust-skills --skill rust-unsafe

  • SKILL_EN.md1.7 KB
  • SKILL_ZH.md5.2 KB
  • SKILL.md10.3 KB

Overview

This skill is an expert guide for writing, reviewing, and refactoring unsafe Rust and FFI code. It distills practical patterns, a 47-rule checklist, and tool-based workflows to avoid undefined behavior and unsafe API exposure. The skill emphasizes SAFETY documentation, safe wrappers, and validated pointer usage to keep unsafe code minimal and auditable.

How this skill works

The skill inspects unsafe blocks, FFI boundaries, raw pointer usage, unions, and memory-layout choices against a compact rule set and review checklist. It recommends concrete replacement patterns (NonNull, MaybeUninit, repr(C), safe wrappers), produces SAFETY comments for each unsafe region, and proposes verification commands like Miri and ASAN to validate invariants. It also guides creating private unsafe internals with safe public APIs.

When to use it

  • Wrapping C libraries or exposing Rust to foreign ABIs (FFI)
  • Implementing low-level data structures (Vec, Arc internals) that require manual memory control
  • Fixing UB found by Miri, ASAN, or production crash reports
  • Measured performance hotspots where safe abstractions are proven too slow
  • During code reviews of unsafe changes or prior-to-merge safety audits

Best practices

  • Question the need for unsafe: prefer safe abstractions and redesign over escaping the borrow checker
  • Add a SAFETY comment before every unsafe block and a /// # Safety section for public unsafe functions
  • Validate raw pointers with NonNull and bounds checks before dereference
  • Use MaybeUninit for uninitialized memory; avoid mem::uninitialized/zeroed
  • Prefer repr(C) and portable type aliases at FFI boundaries and handle panics across extern calls
  • Wrap unsafe internals in safe private helpers and expose a safe public API

Example use cases

  • Create a safe Rust wrapper for a C API: validate inputs, build CString, call extern and return Result
  • Implement buffer write using NonNull pointer with index bounds validation and SAFETY comment
  • Allocate and initialize a Vec of MaybeUninit, then transmute after safe initialization
  • Define FFI-compatible structs with #[repr(C)] and document layout invariants for external callers
  • Audit a module: run cargo +nightly miri test, address sanitizer, and check checklist items before merge

FAQ

Use unsafe for FFI, low-level abstractions, or measured performance needs. Never use it to bypass the borrow checker without redesign.

What must a SAFETY comment include?

Document preconditions, explain why they hold, and reference invariants. For public unsafe functions include a /// # Safety section listing requirements and consequences of violation.

How do I validate unsafe code?

Run Miri, ASAN, valgrind or sanitizer-enabled builds, add unit tests for invariants, and include the 47-rule review checklist in code reviews.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational
rust-unsafe skill by huiali/rust-skills | VeilStrat