Earlier quoted context omitted.
There is use after free
Majority. Parent said majority
Exactly. Use after free is common enough that you can't just assert that out-of-bounds is the majority without evidence.
-fbounds-safety: Enforcing bounds safety for C
61–70 of 129 posts
Re: -fbounds-safety: Enforcing bounds safety for C
#62I want an OS distro where all C code is compiled this way. OpenBSD maybe? or a fork of CheriBSD? macOS clang has supported -fbounds-safety for a while, but I"m not sure how extensively it is used.
It is called Solaris, and has this enabled since 2015 on SPARC. https://docs.oracle.com/en/operating-systems/solaris/oracle-...
Might as well not even talk about anything with the Oracular kiss of death.
Re: -fbounds-safety: Enforcing bounds safety for C
#63I want an OS distro where all C code is compiled this way. OpenBSD maybe? or a fork of CheriBSD? macOS clang has supported -fbounds-safety for a while, but I"m not sure how extensively it is used.
does any distro uses clang? I thought all linux kernels were compiled using gcc.
https://www.kernel.org/doc/html/latest/kbuild/llvm.html
> The Linux kernel has always traditionally been compiled with GNU toolchains such as GCC and binutils. Ongoing work has allowed for Clang and LLVM utilities to be used as viable substitutes. Distributions such as Android, ChromeOS, OpenMandriva, and Chimera Linux use Clang built kernels. Google’s and Meta’s datacenter fleets also run kernels built with Clang.
Re: -fbounds-safety: Enforcing bounds safety for C
#64Earlier quoted context omitted.
and if you write directly in assembly you don't even need a C++ compiler
That's an objectively correct statement, but I don't see how it makes sense as a response to my comment, as I'm advocating to use the more advanced feature-rich tool over the compiler-specific-hacks one.
If you're advocating switching languages, then there's no reason to stop at C++. It's more common to propose just converting the universe to Rust, but assembly also enjoys the possibility of being fairly easy to drop in on an existing C project.
Re: -fbounds-safety: Enforcing bounds safety for C
#65[dead]
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.
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
#66[dead]
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.
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
#67Niklaus Wirth died in 2024, and yet I hope he is having a major I-told-you-so moment about people blaming Pascal's bounds checking to be unneeded and making things slow.
Re: -fbounds-safety: Enforcing bounds safety for C
#68[dead]
There is GWPAsan that has lower overhead than asan but still is not super popular.
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.
Re: -fbounds-safety: Enforcing bounds safety for C
#69Has any progress been made on this? I remember seeing this proposal 3 or 4 years ago but it looks like it still hasn't been implemented. It's a shame because it seems like a useful feature. It looks like Microsoft has something similar ( https://learn.microsoft.com/en-us/cpp/code-quality/understan... ) but it would be nice to have something that worked on other platforms.
Apple is shipping code built with this, and is supporting it for developers to use (see https://developer.apple.com/documentation/xcode/enabling-enh...)
Re: -fbounds-safety: Enforcing bounds safety for C
#70Earlier quoted context omitted.
Personally, as someone in C and C++ for the last few years, memory access is almost never the root bug. It's almost always logic errors. Not accounting for all paths, not handling edge cases, not being able to handle certain combinations of user or file input, etc. Occasionally an out-of-bounds access pops up, but they're generally so blindingly obvious and easy to fix that it's never been the slow part of bug fixing…
I've been programming for long; the ratio of memory errors to logic bugs in production is so low as to be non-existent. My last memory error in C code in production was in 2018. Prior to that it I had a memory error in C code in production in 2007 or 2008. In C++, I eventually gave up trying to ship the same level of quality and left the language altogether.
The wider industry data gathered indicates that for memory unsafe languages 80% of issues are due to memory vulnerabilities, including mature codebases like Linux kernel, curl, V8, Chrome, Mach kernel, qemu etc etc etc. This doesn’t mean that logic bugs are less common, it just means that memory safety issues are the easiest way to get access.
As for why your experience may be different, my hunch is that either your code was super simple OR you didn’t test it thoroughly enough against malicious/unexpected inputs OR you never connected the code to untrusted I/O.
Keep in mind the data for this comes from popular projects that have enough attention to warrant active exploit research by a wide population. This is different from a project you wrote that doesn’t have the same level of attention.