41–50 of 112 posts
C++ is not C. They are two totally different languages. Boundaries and overflows are not an issue in C++ like they are in C. I have no idea why people can't understand this.
If someone thinks that compiler for their favorite programming language provides safety they have no idea what safe code is. C/C++ is used to write safe code for medical and aerospace applications every day. The compiler for the languages like C, C++, Ada, Rust or whatever, is not enough. You can get better static and dynamic code analysis and test coverage analysis tools for C/C++/Ada than you can for Rust.
> C/C++ is used to write safe code for medical and aerospace applications every day. Crack is smoked by humans every day. This is an Argumentum ad Populum ( https://web.cn.edu/kwheeler/fallacies_list.html ). And I dispute the statement anyway; what is "safe" code without a guarantee of memory safety?
Memory safety is the absolute minimum for safety critical code.
It seems to be surprise for most people that you can write memory safe code in C and check for that statically and that includes static stack and heap exhaustion checks.
If someone thinks that compiler for their favorite programming language provides safety they have no idea what safe code is. C/C++ is used to write safe code for medical and aerospace applications every day. The compiler for the languages like C, C++, Ada, Rust or whatever, is not enough. You can get better static and dynamic code analysis and test coverage analysis tools for C/C++/Ada than you can for Rust.
One of these things is not like the others, One of these things just doesn't belong, Can you tell which thing is not like the others...?
C++ is not C. They are two totally different languages. Boundaries and overflows are not an issue in C++ like they are in C. I have no idea why people can't understand this.
Because it is not true. C++ is not memory safe. Especially, C++ is not very good at handling use-after-free.
The bugs in dnsmasq were buffer overflows. In this case, the good practices would be always use std::array and std::vector and index with "at".
Tackling UAF is more complex. It involves using smart pointers exclusively with a runtime-check on dereferencing. This will result in some performance loss.
P.S: I'm not saying it trivial to secure C++ code, nor that every project out there is using these techniques. It's a worthwile task to try to make existing C++ projects as safe as possible, and that's an effort parallel to Rust which should have very beneficial results.
Nothing comes for free. I expect to have to trade something for security. It seems we have to trade speed and size. Ok, it shouldn't matter to us: this should not be developers' call. Instead it should go into a costs benefit matrix with plenty of other technical and not technical stuff. Developers will advise on their part of the matrix, marketers on their own, etc. Managers will make the decision and be held respon…
Right now Rust is slower than C (though not always slower than C++), produces bigger binaries, and compiles slower. But more safety required a more expressive language, and a more expressive language contains more information for code generation and optimizer. It's certainly conceivable that in a few years the Rust compiler might generate faster code than C compilers.
Ah, I see the Rust evangelism strike force is back. n-gate.com is right, as usual.
Note that you can write safe C code. seL4 is written in C! (And verified in Isabelle.) If that is too hard core, PolarSSL is a normal looking C code, which still has been proved to lack any buffer overflow. https://trust-in-soft.com/polarssl-verification-kit/ has details. On the other hand, it probably is less effort to rewrite PolarSSL in Rust than doing that proof.
It's probably even less effort to convert to SaferCPlusPlus[1] (essentially a memory-safe subset of C++). There's even an tool[2] (under construction, but functional) to do a lot of the conversion for you.
[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus
[2] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...
Note that you can write safe C code. seL4 is written in C! (And verified in Isabelle.) If that is too hard core, PolarSSL is a normal looking C code, which still has been proved to lack any buffer overflow. https://trust-in-soft.com/polarssl-verification-kit/ has details. On the other hand, it probably is less effort to rewrite PolarSSL in Rust than doing that proof.
I think the seL4 kernel rather proves that you can write safe haskell, verify it, and then transpile that to C. That's different from directly writing C...
We run high-load web services in something-other-than-c with managed memory and checked array access. It is native, 8/9 as fast as C, and it works. We will never have the budget to pay for the additional 1/9th that C would afford us, in terms of security concerns. Yet, everyday, I have to field questions about why our low-level, network-facing system code is not written in C... old prejudices die hard.
I'm asking because my own gut estimate of the cost of automatic memory management is significantly higher.
If you really want to build on "rock", check out Bedrock: http://plv.csail.mit.edu/bedrock/ . Don't just prove your program is memory safe, prove it satisfies arbitrary properties! (A bit tongue in cheek, but the tools are really cool). Check out http://adam.chlipala.net/cpdt/cpdt.pdf for a nice introduction.
Rust is super interesting to me because it prevents the most common vulnerabilities w/regards to memory safety that show up time and again, but it's accessible enough that it's got a big community and a ton of high quality libraries. I think that's a pretty awesomely potent combination.