Earlier quoted context omitted.
$ gcc -Wall -Werror -x c - :1:37: error: null passed to a callee that requires a non-null argument [-Werror,-Wnonnull] 1 | void f(int x[static 1]){}int main(){f(0);} | ^ ~ :1:12: note: callee declares array parameter as static here 1 | void f(int x[static 1]){}int main(){f(0);} | ^~~~~~~~~~~ 1 error generated. It can be done, though it usually isn't.
Can you do that with a dynamic array? If not, it's pretty severely limited (unless you mean that literally forbidding dynamic memory is usually not done, which I guess it's true outside of some embedded code but not a particularly meaningful statement).
How memory safety CVEs differ between Rust and C/C++
171–180 of 270 posts
Re: How memory safety CVEs differ between Rust and C/C++
#172Earlier quoted context omitted.
Compliance != security. It's almost the natural enemy of security.
This is true, but security teams often work on tooling dedicated to reduce the n. of CVEs so that a company can keep compliance. That is in fact part of compliance itself to have an automated/reliable processo to tackle CVEs...
Re: How memory safety CVEs differ between Rust and C/C++
#173There can be made very good arguments why C is less safe than Rust, but null pointer dereferences which are perfectly safe everywhere except on weird platforms (and usually could be made safe even there by turning on a compiler flag) seems a very misleading argument. And as as the Cloudflare incident showed, a Rust unwrap can have equally bad consequences. (or as Ariane 5 showed, a safe overflow in Ada can have explo…
For availability and stability concerns, the C approach is actually better, but for security and reproducibility, it is not.
Re: How memory safety CVEs differ between Rust and C/C++
#174Re: How memory safety CVEs differ between Rust and C/C++
#175Earlier quoted context omitted.
No one writing anything that needs performance cares about some standard library ABI issues. Rust already has warts from bad API designs that constrains performance and they are unlikely to ever be fixed even with new editions. Rust will continue to pick up baggage as basically every language has done. Aliasing has yet to provide any real benefit for Rust and a hell of a lot of issues. Maybe one day it will be a big…
> Rust already has warts from bad API designs that constrains performance and they are unlikely to ever be fixed even with new editions. Like what? > Aliasing has yet to provide any real benefit for Rust and a hell of a lot of issues. Yeah, the performance wins so far are quite small. But rust's noalias-by-default did unearth a whole lot of latent bugs in LLVM. Even if you don't care about rust, its great that rust l…
It's also a statement, whether you want callers to pass the same object to different parameters. If that doesn't make sense or you don't want that, write restrict.
Re: How memory safety CVEs differ between Rust and C/C++
#176Earlier quoted context omitted.
I'm a / used to be a C++ programmer for 10 years. I've been lucky enough to work in a company that aims to adopt Rust. I have been working on Rust projects in the embedded space that runs on real-world devices right now for 3.5 years. Slowly but surely, not going into "rewrite every single thing now in Rust" but one component at a time when the project justifies it. So, tell me what compiler option disables non-moder…
Enable sanitizers on test suites and fuzzers. Enable warnings and WError Use clang tidy and other static analyzers Actually use a modern compiler and enable the safety features they ship with Most of these things have solutions that would take years of work in an existing project so it isn't done And it takes significantly more effort to write good modern C++ code than Rust code So Rust wins But I don't like writing…
Re: How memory safety CVEs differ between Rust and C/C++
#177Earlier quoted context omitted.
May. If. If. If. In case. We are talking about an extremely simple straightforward API with an obvious contract. It's good enough for this function to reliably surface almost all wrong uses with a segfault immediately. Wrong use will result in segfaults and otherwise bugs and crashes. The goal is not to work when used wrong but to work when used right. You cannot save the world from scratch in every little function.…
> You cannot save the world from scratch in every little function. You still have a job to get done, and you have to move on. Or you can take all of 10 minutes to put sanity-check assertions at the start of all your public-facing API functions, eliminating a source of security bugs, get on with your life, and worry about the performance implications as and when it becomes a problem (hint: it's never going to become a…
Re: How memory safety CVEs differ between Rust and C/C++
#178Earlier quoted context omitted.
If these hardened libraries were as good, we wouldn't have blog posts like this[1], from the android team last year. > We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android’s C and C++ code Maybe the android team could have gotten the same benefits by simply auditing and modernising their C++ code? I'm not convinced. Google has some amazing engine…
There’s a few things happening here. First of all, Rust is default safe. In C++ developers always trade performance for safety, in Rust they just swallow the penalty (which is often still performant enough). C++ code will often not be as memory safe as it could because someone decided to not use particular checks (like compiler-driven integer overflow checks). Secondly, Android C++ code is not particularly high quali…
A "trade" implies care which isn't actually taken. What WG21 does is they assume that safety costs performance and so they throw away the safety hoping that this means they get performance. They don't measure, which is why you get to see first Herb Sutter explaining that C++ doesn't do bounds checks because they're unaffordable (notice he presents no data) and then a few years later Herb Sutter explaining that the latest C++ will offer bounds checks because they're actually affordable after all (now Google has collected the data)
In most cases it's much worse than the bounds checks, which actually did have a small cost, it's often net negative to throw away safety, C++ chose the less safe and slower option, assuming that this "trade" exists when it doesn't and if they'd measured they'd have seen the news before making the decision.
Re: How memory safety CVEs differ between Rust and C/C++
#179Earlier quoted context omitted.
I agree about Rust gaining ground but using the argument that it got 10% faster due to Rust is not really that useful. If they rewrote it in C++ again, they would have most likely got the same result because they got a chance to fix a design that might not have been most optimal.
> If they rewrote it in C++ again, they would have most likely got the same result because they got a chance to fix a design that might not have been most optimal. This speculation has been offered every time. It's not crazy to think this might be true, but it's also not crazy to think that if C++ keeps leaving performance on the table and Rust doesn't that adds up for real projects. When Titus wrote "ABI: Now or Nev…
Could you elaborate on that?
Re: How memory safety CVEs differ between Rust and C/C++
#180Earlier quoted context omitted.
I agree about Rust gaining ground but using the argument that it got 10% faster due to Rust is not really that useful. If they rewrote it in C++ again, they would have most likely got the same result because they got a chance to fix a design that might not have been most optimal.
> If they rewrote it in C++ again, they would have most likely got the same result because they got a chance to fix a design that might not have been most optimal. This speculation has been offered every time. It's not crazy to think this might be true, but it's also not crazy to think that if C++ keeps leaving performance on the table and Rust doesn't that adds up for real projects. When Titus wrote "ABI: Now or Nev…