Build and diagnostic evidence
What this concept is
A reproducible C investigation records source, compiler, flags, input, expected behavior and observed output. Compilation, linking, assertions and runtime instrumentation provide different kinds of evidence.
Why it matters here
A successful build can still contain a logical error. A sanitizer run can still miss a contract violation that stays inside allocated storage. The lab checks both status/output behavior and writes beyond the declared capacity.
Concrete example
Compile reference.c and check.c together, then separately compile reference.c with main.c. These are two executables with different entry points. Compiling every .c file together accidentally includes competing implementations and entry points. Predict the linker complaint before trying this only in a disposable build directory.
Common confusion / misconception
Warnings are useful feedback, not a proof. ASan and UBSan instrument selected runtime checks on executed paths; an unsupported tool is not a passing check. Optimization level changes are experiments, not a method for repairing undefined behavior.
How to use it
Run warning-clean C11 builds at O0 and O2, then the supported sanitizer build documented in the README. Keep assertion checks enabled. Retain a failing regression before repair and rerun it afterward. Add one fresh input case that was not in the provided examples. Read the first relevant failure before changing code.
Check yourself
Which check catches an early return that fails to drain rejected input? Could that bug pass ASan? What information is missing from the claim “it works on my machine”?
Mini drill or application
Build the starter and record its assertion failure. Implement your repair, reproduce the checks, and explain the source/reader/stdio adapter boundary without running it. Label any unavailable instrumentation honestly.
Read this only if stuck
The C Programming Language for separate compilation; Clang ASan and Clang UBSan for supported instrumentation and limitations.