Loading page…
Master the fundamental concepts of rust for systems programming through this focused micro-challenge.
You have read the whole brief, and the concepts above stay free on every task. Writing and running the code needs a plan.
Three hints are available for this task, revealed one at a time inside the code workspace so you can struggle productively before seeing them.
Every task includes starter code, theory, and hidden tests so you can implement and verify locally in the browser.
How it worksRust adoption rides on calling existing C: librsvg in GNOME, Stylo in Firefox, OpenSSL-shaped dependencies via FFI. extern "C" disables name mangling and pins the System V AMD64 calling convention so symbols link cleanly.
rustLoading…
i32→int, f64→double, *const T→const T*\0; CString builds them, CStr reads them back#[repr(C)] on structs matches C field order and padding rulesEvery FFI call is unsafe because Rust cannot prove C upheld aliasing or lifetimes.
For this exercise, you will declare a C function, link a small C library, and wrap the call in a safe facade where possible. This task asks you to document pointer validity, because bindgen-generated bindings still crash when you pass a dangling *mut across the boundary.
Keep the relevant man page, ABI doc, or Rust reference chapter open while you work. When your output disagrees with the reference implementation on the same machine, the mismatch is usually an alignment rule, an off-by-one terminator, or a register slot you misread in GDB. Skim the official documentation for the tool or ABI named in the exercise; the prose changes, but register roles, syscall numbers, and ownership rules stay stable across releases.
Most FFI bugs come from two places: struct layout and strings. C decides a struct's layout by declaration order. Rust's default repr(Rust) is free to reorder fields, which is why every struct that crosses the boundary needs #[repr(C)]. C strings are NUL-terminated byte arrays, which is why CString::new rejects interior NULs and CStr has to check its input. Build a tool that computes both layouts and validates C strings the way std::ffi does.
cLoading…
u8 i8 bool → 1, u16 i16 → 2, u32 i32 f32 → 4, u64 i64 f64 usize ptr → 8. An array T[N] (N in 1..64) has size N × size(T) and the alignment of T.\0, \n, \t, \\, \" and \xHH. Anything else after a backslash is an error.cLoading…
CString, the bytes include the added terminator.CStr checks run in order: no NUL at all, then the first NUL not being the last byte, then UTF-8 validity of the bytes before the NUL. The reported byte is the valid_up_to index.Errors: error: bad field TOKEN (missing :, empty name, or unknown type), error: struct NAME has no fields, error: expected a quoted string, error: bad escape, and error: bad command: LINE.
Input:
cLoading…
Output:
cLoading…
std::ffi::CString / CStr for the string checks, or reproduce their rules exactly (strict UTF-8: no overlong forms, no surrogates, nothing above U+10FFFF).size_of and offset_of! on a real Rust struct. The test structs were checked against rustc.Hidden tests cover arrays and tail padding, structs that are already optimally ordered, ties in alignment, CStr inputs with interior NULs and invalid UTF-8 (truncated, overlong, surrogate), and malformed input.