Architectural Friction in C Mechanics for Rust-First Systems Engineers

Systems programmers approaching C from a Rust-first background encounter fundamentally different abstractions regarding memory layouts, type guarantees, and runtime error enforcement. This analysis details the structural mechanics of C, including integer target dependency, string termination, parameter array decay, and unconstrained error propagation.

Primitive Boolean Evolution

In initial ISO C specifications, boolean types did not exist as distinct language primitives, relying instead on standard scalar integers where zero represented false and non-zero represented true. The C99 revision introduced pseudo-boolean support through the `` header, which implemented standard preprocessor macros expanding `true` to `1` and `false` to `0`. Primitive boolean semantics were not fully incorporated into the core language syntax until the C23 standard.

String Representation and Overhead

Rust represents string slices (`&str`) as 16-byte fat pointers containing an 8-byte pointer and an 8-byte length field. C dispenses with string metadata entirely, relying instead on sentinel null bytes (`\0`) to signal sequence termination.

This architectural choice eliminates explicit length storage but imposes distinct performance and memory tradeoffs:

• Empty strings require a minimum allocation of 1 byte to store the null byte.
• Embedded null bytes terminate processing early when using standard `` operations.
• Missing null terminators introduce out-of-bounds read vulnerabilities.
• String mutations require explicit accounting for the extra byte, such as allocating `len + 1` bytes via `malloc()` during array reversal.

Target-Dependent Integer Widths

Unlike Rust's standard fixed-width primitives, native C integer types specify only minimum bit-width constraints. A standard `long` type guarantees at least 32 bits, but its actual size varies across platform data models:

• 64-bit Unix (LP64): `long` is allocated 64 bits.
• 64-bit Windows (LLP64): `long` is allocated 32 bits.

To ensure deterministic platform layout, cross-platform systems development requires abandoning standard integer types in favor of fixed-width definitions provided by ``. Mapping target types directly aligns C definitions with Rust primitives: `uint8_t` (`u8`), `uint64_t` (`u64`), `size_t` (`usize`), and `ptrdiff_t` (`isize`).

Unenforced Error Handling and Type Safety

C lacks algebraic data types like `Result` and relies on sentinel values—such as `-1` or `NULL` pointers—alongside thread-local global state (`errno`) to convey execution failures. The C compiler imposes no structural checks requiring call sites to evaluate failure states. Unchecked system calls, such as an unverified `malloc()` return, yield immediate segmentation faults upon dereference.

Emulating sum types in C via tagged unions fails to provide functional type safety. Because C lacks visibility modifiers (`private` or `public`), the compiler cannot enforce access contracts or restrict raw access to pointer variants prior to checking state tags.

Access Syntax and Function Array Decay

C enforces an explicit syntactic distinction between value field access (`.`) and pointer dereference field access (`->`).

Array types present distinct behavior based on declaration scope. Within the local function scope of their definition, arrays retain boundary context, allowing `sizeof()` to evaluate total memory allocation. However, passing an array parameter into a function implicitly decays the array to a pointer referencing its first element (`char[]` decays to `char *`). Within the called function scope, `sizeof()` returns the width of the target architecture pointer (8 bytes on 64-bit architectures) rather than the underlying array length. Toolchains like Clang issue explicit compile-time warnings (`-Wsizeof-array-argument`) when `sizeof` is invoked on decayed parameter arrays.