Without any ::prelude and some void* arguments.
Maybe you have thoughts about it.
The URL is just a sample of “why” but not “because”.
I have my own preference but will keep it inside my mind to not burn a tornado that will erase me from the matrix of the world.
P.S.: I think C is faster, more powerful, and more elegant. I like it more than Rust.
…and the bulk of these attempts don’t even consider onboarding basic static analysis tools to projects.
I think this comparison is disingenuous. Rust has static code analysis checks built into the compiler, while C compilers don’t. Yet, you can still add static code analysis checks to projects, and from my experience they do a pretty good job flagging everything ranging from Critical double-frees to newlines showing up where they shouldn’t. How come these tools are kept out of the equation?
I’m not familiar with C tooling, but I have done multiple projects in C++ (in a professionnel environnement) and AFAIK the tooling is the same. Tooling to C++ is a nightmare, and that’s and understatement. Most of the difficulty is self inflicted like not using cmake/meson but a custom build system, relying on system library instead of using Conan or vcpkg, not using smart-pointers,… but adding basically anything (LSP, code coverage, a new dependency, clang-format, clang-tidy, …) is horrible in those environments. And if you compare the quality of those tools to the one of other language, they are not even close. For exemple the lint given by clang-tidy to the one of Rust clippy.
If it took no more than an hour to add any of those tools to a legacy C project, then yes it would be disingenuous to not compare C + tooling with Rust, but unfortunately it’s not.
You are making an extreme assumption, and it also sounds like you’ve misread what I wrote. The “attempts” I’m talking about are studies (formal and informal) to measure the root causes of bugs, not the C or C++ projects themselves.
I cited one specific measurement, Daniel Stenberg’s analysis of the Curl codebase. Here’s a separate post about the testing and static analysis used for Curl.
Here’s a post with a list of other studies. The projects analyzed are:
Do you really think that Google, Apple, Microsoft, Mozilla, and the Ubuntu project “don’t even consider onboarding basic static analysis tools” in their C and C++ projects?
If you’re curious about the specifics of how errors slip through anyway, here’s a talk from CppCon 2017 about how Facebook, despite copious investment into static analysis, still had “curiously recurring” C++ errors. It’s long, but I think it’s worthwhile; the most interesting part to me, though, starts around 29:40, where he asks an audience of C++ users whether some specific code compiles, and only about 10% of them get the right answer, one of whom is an editor of the C++ standard.
I think you’re talking past the point I’ve made.
The point I’ve made is that the bulk of these attempts don’t even consider onboarding basic static analysis tools for projects. Do you agree?
If you read the post of other studies you’ve quoted, you’d be aware that some of them quite literally report results of onboarding a single static analysis tool to C or C++ projects. The very first study in your list is quite literally the results of onboarding projects to Hardware-assisted AddressSanitizer, after acknowledging that they haven’t onboarded AddressSanitizer due to performance reasons. The second study in your list reports results of enabling LLVM’s bound sanitizer.
Yet, your personal claim over “the lack of memory safety” in languages like C or C++ is unexplainably based on failing to follow very basic and simple steps like onboarding any static analysis tool, which is trivial to do. Yet, your assertion doesn’t cover that simple step. Why is that?
Again, I think this comparison is disingenuous. You take zero effort to address whole family of errors and then proceed to claim that whole family of errors are not addressed, even though nowadays there’s a myriad of ways to tackle those. That doesn’t sound like a honest comparison to me.
You’re misunderstanding the posts you’re explaining. Sanitizers, including ASan, HWASan, and bound sanitizer, are not “static analysis tools”. They are runtime tools, which is why they have a performance impact. They’re not intended to be deployed as part of a final executable.
I don’t know how you can read this sentence and interpret it to mean that they “haven’t onboarded AddressSanitizer”: