libc

libc provides raw FFI (foreign function interface) bindings to the C system library on every platform Rust supports — type definitions like c_int, constants like EINVAL, and function declarations like malloc. It is one of the most-depended-upon crates in the Rust ecosystem, forming the low-level foundation that higher-level system-interaction crates build on.

All exported items match the exact types and values of the platform libc is compiled for, and everything is accessible directly under the crate root as libc::foo. It deliberately excludes Windows API bindings, which live in the separate windows-sys crate, keeping its scope tightly focused on C-compatible system interfaces across Unix-like systems, Windows’ C runtime, WASI, and embedded targets.

What You Get

• Raw type definitions (c_int, c_char, etc.) matching each supported platform’s C ABI exactly
• Constants for system-level values like errno codes (EINVAL), file flags, and signal numbers
• Function declarations for core C library calls such as malloc, open, and pthread primitives
• Platform-specific modules covering Unix variants, Windows’ C runtime, WASI, Fuchsia, and embedded/RTOS targets
• A stable, near-universal dependency that higher-level crates (Tokio, nix, mio) build their safe abstractions on top of

Common Use Cases

• Writing low-level system programming crates that need direct syscall or C library access
• Building safe wrapper crates (like nix or mio) on top of libc’s raw bindings
• Interfacing Rust code with existing C libraries that expect standard C types and constants
• Implementing cross-platform low-level utilities that need to branch on platform-specific constants or types
• Embedded or no-std development targeting RTOS platforms like Hermit, SGX, or VxWorks

Under The Hood

Architecture - The crate root (src/lib.rs) re-exports a large tree of platform-specific modules under src/unix/, src/windows/, src/wasi/, and further per-OS/per-arch subdirectories, each defining the exact struct layouts, constants, and extern "C" function signatures for that target. src/macros.rs and src/types.rs provide the code-generation macros used to keep thousands of near-identical platform declarations consistent, while build.rs handles target-specific compile-time configuration.

Tech Stack - Pure Rust with no_std support for embedded targets, dual-licensed MIT OR Apache-2.0, MSRV 1.65. The ci/verify-build.py script cross-compiles the crate against dozens of Tier 1/2/3 Rust targets (aarch64-apple-darwin, x86_64-pc-windows-msvc, wasm targets, RTOS targets, and more) to catch platform-specific breakage before release.

Code Quality - The libc-test/ctest subdirectories run a C-vs-Rust cross-validation suite that compiles small C programs against the actual system headers and compares struct layouts and constant values against what the crate declares — an unusually rigorous approach for an FFI-bindings crate, since a mismatched struct layout is undefined behavior rather than a compile error. The project is one of the most heavily reviewed crates in the Rust ecosystem given how many other crates transitively depend on it.

API Design - Because this is a raw FFI layer, the API is deliberately unsafe and matches C naming/signatures rather than idiomatic Rust conventions — callers are expected to wrap calls in safe abstractions themselves (which is exactly what crates like nix provide). There is effectively no onboarding curve for using individual bindings (libc::EINVAL, libc::malloc), but using them correctly requires C/systems-programming knowledge the crate does not abstract away.