Rust 1.98 Starts Checking the Runtime Symbols Your FFI Can Replace

Rust 1.98.0, released on August 20, adds a small but consequential layer of protection for low-level Rust: the compiler now checks declarations that use names reserved for core runtime symbols, and it warns when core::ffi::c_void is used as a return type.

The runtime-symbol change matters most to crates that define, override, or expose low-level functions such as memcmp, memset, and strlen. Rust 1.98 introduces invalid_runtime_symbol_definitions as a deny-by-default lint when a matching symbol has a significantly wrong signature—for example, an ABI or variadic mismatch, the wrong number of arguments, or a missing return type. A separate suspicious_runtime_symbol_definitions lint warns about signatures that deserve review. These checks turn a fragile linker- and ABI-level assumption into a compiler-visible review point.

The release also adds the warn-by-default c_void_returns lint. Rust’s c_void models C’s void when used through a pointer, such as *mut c_void; it is not the Rust spelling for a C function that returns void. Such a function should return () in Rust, or omit the return type. The standard library documentation makes the distinction explicit, and the lint documentation warns that declaring an extern function with c_void as its return type can produce undefined behavior when called.

For builders shipping FFI bindings, embedded code, allocators, runtimes, or WebAssembly-adjacent system crates, the practical response is straightforward: compile with Rust 1.98, inspect new diagnostics rather than silencing them globally, and audit declarations that intentionally use runtime symbol names. In generated bindings, correct the generator or the foreign declaration source instead of adding a broad allow. In hand-written extern blocks, verify the C header, calling convention, variadic status, argument count, and return type together.

This is a diagnostic boundary, not a complete FFI verifier. The lints do not prove that every foreign declaration is ABI-correct, and the release notes say runtime-symbol checking currently targets core symbols such as memcmp, memset, and strlen; Rust plans to expand that coverage in future releases. That limitation means a clean build is useful evidence, but not a substitute for header-driven binding generation, platform testing, or ABI review.

The broader change is a shift in where Rust catches mistakes. Previously, these errors could remain hidden in generated bindings or surface only during linking or execution. Rust 1.98 moves two classes of low-level mismatch—runtime symbol signatures and c_void returns—closer to ordinary compilation, where CI can review and reject them before a binary reaches production.