Background. Device drivers are a critical layer between hardware and software in embedded systems, where defects are a leading cause of crashes and security vulnerabilities. C has historically dominated this space despite well-documented memory-safety weaknesses, while Rust offers compile-time safety guarantees and structured error handling. Prior comparative work has focused on kernel-space drivers and isolated metrics, leaving user-space sensor drivers largely unstudied.

Objectives. To empirically compare functionally equivalent C and Rust user-space device drivers with respect to reliability, memory safety, fault behaviour, architectural complexity, and performance.

Methods. This study applies Design Science Research (DSR) through a controlled empirical experiment. The primary artefacts are two functionally equivalent user-space BME280 drivers implemented in C and Rust, developed together with supporting experimental infrastructure. Both artefacts were constructed and evaluated on a Raspberry Pi 3B using a custom Python measurement harness under identical conditions, with implementation language as the independent variable across dependent variables spanning stability, memory safety, fault behaviour, architectural complexity, and performance. Reliability was assessed through a 48-hour stress test against a reference sensor; memory safety through Valgrind Memcheck and an audit of Rust unsafe blocks; fault behaviour through physical disconnection, LD_PRELOAD-based I/O fault injection, and a 12-hour AFL++ fuzzing campaign; architectural complexity through cyclomatic complexity and lines of code; and performance through latency, CPU utilisation, and memory-footprint microbenchmarks with sequential probability ratio testing.

Results. Both drivers remained fully stable, exhibited no invalid memory accesses or leaks, and produced no crashes during fuzzing. The C driver was approximately 0.178% faster, a difference detectable at 99% confidence but well within a ±1 % equivalence zone. The Rust driver consumed approximately 29% more memory and contained five small unsafe blocks wrapping unavoidable system calls. It exhibited consistent rc=1 exit behaviour across all injected faults via unified Result/DriverError propagation, whereas the C driver exited with call-site-dependent codes. This robustness came at the cost of higher cyclomatic complexity a greater number of lines of code.

Conclusions. Rust’s safety guarantees come at no measurable runtime cost for this class of user-space driver, with trade-offs expressed in implementation complexity and a modest fixed memory overhead. The results support Rust as a credible alternative to C for user-space embedded drivers, bounded by the simplicity of the studied driver.