Bilingual

Memory Safe Context Switching
22 days ago
- Fil-C supports memory-safe context switching via longjmp/setjmp and ucontext APIs, preventing stack corruption.
- setjmp/longjmp are used for exception handling, while ucontext APIs (getcontext, setcontext, makecontext, swapcontext) implement coroutines/fibers.
- Fil-C makes setjmp/longjmp safe by storing jmp_buf as an opaque zjmp_buf, restricting direct calls, and validating stack frame ancestry.
- ucontext safety is achieved using opaque zfiber_context objects, a strict state machine, thread affinity, and GC integration with grey fiber tracking.
- The implementation ensures no misuse leads to dangling stack execution; unsafe operations cause panics or compile-time errors.
- GC integration handles fiber stacks during marking via grey fiber lists to prevent race conditions in on-the-fly garbage collection.
- Fil-C's ucontext support is available in glibc builds (from source after version 0.680), with setjmp/longjmp being more mature.
- Examples demonstrate how volatile variables and compiler optimizations affect setjmp behavior, emphasizing Fil-C's compliance with C semantics.
Returning to Zig
17 days ago
- The author was initially drawn to Zig in 2020 as a promising replacement for C, appreciating its compile-time code execution and simple abstractions.
- They left Zig due to instability, frequent breaking changes, and an immature ecosystem, switching to Rust for its stability and strong tooling.
- Concerns about Rust's governance, including corporate influence and slow response to LLM-generated code policies, led the author to reconsider Zig.
- In 2026, Zig remains unstable but familiar, with added features like a package manager, though its ecosystem is still limited compared to others.
- Zig prioritizes simplicity over Rust-like memory safety, using release modes and testing to ensure safety, which the author finds acceptable for certain use cases.
Clang: Hardware-Assisted AddressSanitizer Design Documentation
4 days ago
- HWASAN is a hardware-assisted memory safety tool similar to AddressSanitizer.
- It uses address tagging to tag memory objects and pointers with random tags.
- Memory accesses are instrumented to compare pointer tags with memory tags to detect mismatches.
- Short granules handle memory objects smaller than the tagging granularity by storing their tag in the last byte.
- Heap, stack, and global memory objects are tagged with specific strategies for each.
- HWASAN relies on hardware address tagging (AArch64) or page aliasing (x86_64), limiting its portability.
- It offers probabilistic bug detection with lower memory overhead compared to AddressSanitizer.
Introduce a memory safe compilation mode inspired by Fil-C
a day ago
- Introduces a memory-safe compilation mode inspired by Fil-C, which differs from Rust by offering stronger memory safety guarantees without relying on unsafe code or escape hatches.
- Proposes a new ABI named 'fil' to implement Fil-C techniques, including invisicaps and syscall interception, for full memory safety across Zig and C/C++ dependencies.
- Aims to achieve memory safety with a performance penalty of 1-6x, preventing use-after-free and type confusion through unique type IDs and runtime pointer provenance checks.
- Discusses challenges such as intercepting all syscalls and inline assembly, while avoiding language changes by using compiler and standard library modifications.
- Highlights the potential for Zig to become a leading toolchain for memory-safe executables, even with C/C++ dependencies, surpassing Rust's safety in practice.
InvisiCaps: The Fil-C Capability Model
16 hours ago
- Fil-C ensures memory safety via a capability system for pointers, dynamically tracking allowed objects and prohibiting out-of-bounds, use-after-free, and other unsafe accesses.
- InvisiCaps are the latest capability model, replacing PLUT, SideCaps, and MonoCaps, offering 64-bit pointers on 64-bit systems and reduced performance overhead to about 4x.
- InvisiCaps support meaningful union usage, thread safety, and flexible memory type reinterpretation without compromising safety.
- Each flight pointer has a trusted lower bound (for bounds checks) and an untrusted intval (the raw C pointer value); lower is immutable by the program.
- When pointers are stored to heap, the intval goes in the object payload and the lower in a separate aux allocation, keeping capabilities invisible to the program.
- Atomic pointers use atomic boxes for lock-free operations, while non-atomic pointers use a cheaper approach with aux allocations.
- Use-after-free is detected deterministically by setting the upper bound equal to the lower, causing a panic on access.
- The model is fanatically compatible, supporting even undefined behavior idioms, and is inspired by SoftBound and CHERI but with better thread safety and compatibility.

Hasty Briefsbeta

#memory safety

Memory Safe Context Switching

Returning to Zig

Clang: Hardware-Assisted AddressSanitizer Design Documentation

Introduce a memory safe compilation mode inspired by Fil-C

InvisiCaps: The Fil-C Capability Model