Making Infrastructure More Trustworthy
Causes preserved along the call chain
Structured error objects carry the error domain, operation, and cause chain; a thread-level error context connects the layers, and a static out-of-memory error object supports low-resource paths.
Read the error model API →See the implementation →Strict parsing, clear semantics
HTTP/1.1 handles message lengths and framing rules explicitly; WebSocket validates canonical lengths, UTF-8, and fragmentation state — so higher layers build on crisp protocol semantics.
Read the HTTP/1.1 API →See the implementation →Identity verification in the connection flow
TLS clients confirm the peer through verifiers; SSH clients establish trust through host-key verification policy; mail authentication paths treat secure transport as the default premise.
Read the TLS verification API →See the implementation →File access constrained by directory handles
File-root capabilities organize access through directory handles; POSIX paths use openat with symlink confinement, Windows paths handle reparse points — serving bounded file operations.
Read the file API →See the implementation →A Test System That Travels with the Source
The test tree covers the kernel and five extension libraries, watching not only functional results but also memory, object state, and the different build shapes.
Test C files in the current source tree.
Test C files with _oom in the name.
Test C files with _noalloc in the name.
Counts cover physical .c files under tests/ and the five extensions' tests/; the last two are subsets of the total. See the counting rules and source revision.
Fault injection and resource wind-down
The memory-debug facilities provide allocation-failure injection and resource statistics; tests advance error paths step by step, checking resource release and object state after failed returns.
Memory debug API →Protocol and input boundaries
Parser tests cover truncation, lengths, encodings, and state combinations; fuzz entry points keep exploring varied inputs, helping maintain protocol and memory boundaries.
See a fuzz test example →Single-header and modular verification
Single-header probes compile and call the amalgamated artifact; trimming tests check dependency constraints; package verification links against real consumer programs.
See the build & package commands →Quality Across the Build Pipeline
Many platforms, many compilers
The continuous-integration configuration covers desktop and mobile test suites, combining GCC, Clang, MSVC, and clang-cl to exercise platform adaptation paths.
See the CI configuration →Memory and behavior checks
ASan, UBSan, and strict compiler warnings participate in kernel verification, bringing memory-access and undefined-behavior checks into the engineering flow.
See the build tool →Connection and lifecycle tests
Network and concurrency tests organize cases around connection setup, data transfer, cancellation, shutdown, and resource reclamation — focused on the complete lifecycle.
See the network tests →From One Test Run into the Implementation
Run the following in the XRT repository root: first the kernel and concurrency tests, then the chosen extension and the release artifacts.
python tools/build.py --suite core,concurrency --jobs 4 python tools/build.py --manifest extlibs/xhttp/config/modules.json --suite xhttp_tests python tools/package.py --kind static --verify