Re:-fbounds-safety: Enforcing bounds safety for C
by clarabennett26 on Thursday February 19, 2026 @11:23AM
(#47075445)
The key issue is whether this can be gradually implemented in large codebases without needing a complete rewrite. ASan detects bounds violations during runtime, but its performance cost makes it unsuitable for production use. If -fbounds-safety can enforce checks while maintaining reasonable overhead and working seamlessly with unchecked translation units, it could significantly improve C safety in practice, far more than simply urging everyone to switch to Rust would.
[ Parent
| on HN ]
Re:-fbounds-safety: Enforcing bounds safety for C
by hoyhoy on Thursday February 19, 2026 @12:15PM
(#47076235)
I looked at trying to implement -fbounds-safety and -Wunsafe-buffer on a reasonably large codebase (4,000 C and C++ files), and it's basically impossible.
You have to instrument every single file. It can be done in stages though. Just turn the flag on one-by-one for each file. The xnu kernel is _mostly_ instrumented with -fbounds-safety.
Re:-fbounds-safety: Enforcing bounds safety for C
by jimmaswell on Thursday February 19, 2026 @01:24PM
(#47077121)
This sounds like the kind of low-thought pattern-based repetitive task where you could tell an LLM to do it and almost certainly expect a fully correct result (and for it to find some bugs along the way), especially if there's some test coverage for it to verify itself against. If you're skeptical, you could tell it to do it on some files you've already converted by hand and compare the results. This kind of thing was a slam dunk for an LLM even a year or two ago.
Re:-fbounds-safety: Enforcing bounds safety for C
by safercplusplus on Thursday February 19, 2026 @01:27PM
(#47077173)
Plug: In theory you could auto-convert to a memory-safe subset of C++ as a build step. Auto-converted code would have some run-time overhead, but you can mark any performance-sensitive parts of the code to be exempt from conversion. And you get lifetime and type safety too. For full coverage, performance-sensitive parts of the code can be manually converted to the safe subset to minimize overhead. (Interfaces in extern C blocks remain unconverted by default to maintain ABI compatibility.)
[1]: https://duneroadrunner.github.io/scpp_articles/PoC_autotrans...
Re:-fbounds-safety: Enforcing bounds safety for C
by adrianN on Thursday February 19, 2026 @11:28AM
(#47075527)
There is GWPAsan that has lower overhead than asan but still is not super popular.
Re:-fbounds-safety: Enforcing bounds safety for C
by hoyhoy on Thursday February 19, 2026 @12:22PM
(#47076334)
ASAN/LSAN is amazing. It absolutely monkey-hammers performance though.
Re:-fbounds-safety: Enforcing bounds safety for C
by lelanthran on Thursday February 19, 2026 @02:22PM
(#47077911)
> ASAN/LSAN is amazing. It absolutely monkey-hammers performance though.
It's not so bad; until the sanitisers arrived all we had was valgrind :-/
The sanitisers are about 10x to 50x faster than valgrind.
Re:-fbounds-safety: Enforcing bounds safety for C
by vlovich123 on Thursday February 19, 2026 @01:28PM
(#47077196)
Because it can only catch a subset of issues, it’s not guaranteed to catch issues (probabilistic), even issues it “could” catch may not be caught due to temporal distance of the free and a subsequent use, and requires the use of a different allocator that supports it. It’s also unclear to me how it know whether a given free is for a sampled or unsampled region - I suspect it must capture all free/realloc to accomplish that but it does imply all of these are sampled.
It’s nowhere near the same as robust bounds checking.