31–40 of 300 posts
Earlier quoted context omitted.
Or just rewrite it in modern C. This is sane and doable in a short period of time. You just have to make sure it's modern C. (no true Scotsman)
> Or just rewrite it in modern C. This is sane and doable in a short period of time. What do you call modern C?
C can be safe if you use Turing incomplete libraries that have been verified. It's the YOLO ad hock parsers that get you in trouble.
I am not sure if you are serious or not. How does verification prevent buffer overflows? It can reduce their frequency, but you can never know you got them all. They find issues in libCURL and openSSL that have existed for years. Very few people are better than the people working on those libraries. It is better to be safe by default then add risk only when you need it. I say this as a C++ developer, I think const sh…
> They find issues in libCURL and openSSL that have existed for years
Neither of them are formally verified. https://github.com/seL4/seL4 however is formally verified.
If you are really worried about the security of old C code, then the safest, most portable thing to do is re-write in modern C++. This is sane and doable in a short period of time. Rust is not.
Oh no, no, no! Some people may reasonably, with some extreme care and diligence, maybe try to claim they can write safe and UB-free C code. If stars align properly. (See maybe SQLite. Seen as one of the pinnacles of crazy pedantism in C. Also, see the article about errors found recently in SQLite with fuzzing!) But with C++, it's just impossible for a human. It's too big, too quirky, too big, too wide, too deep, too…
Why the sarcasm?
Why Rust? Why not Idris? Why not Haskell? Or you know, why rewrite it at all? You could instead try and use a safe C implementation (such as gcc/clang with the sanitisers or something like https://staff.aist.go.jp/y.oiwa/FailSafeC/index-en.html ), but to be frank if I was to rewrite my programs I would use a truly modern language like the ones that I mentioned above.
> Why Rust? Why not Idris? Why not Haskell?
it can easily call C code
it can easily be called by C code (it can export C compatible functions and structures)
it does not need a garbage collector
if you want, it does not even need to handle allocations
the Rust compiler can produce static and dynamic libraries, and even object files
the Rust compiler avoids most of the memory vulnerabilities you get in C (yes, I had to mention it)Or even better, Haskell!
haskell is not tailored for that.
of course there are other domains for which haskell is top-nocth and rust falls flat.
Earlier quoted context omitted.
Oh no, no, no! Some people may reasonably, with some extreme care and diligence, maybe try to claim they can write safe and UB-free C code. If stars align properly. (See maybe SQLite. Seen as one of the pinnacles of crazy pedantism in C. Also, see the article about errors found recently in SQLite with fuzzing!) But with C++, it's just impossible for a human. It's too big, too quirky, too big, too wide, too deep, too…
> Oh no, no, no! Some people may reasonably, with some extreme care and diligence, maybe try to claim they can write safe and UB-free C code. If stars align properly. Why the sarcasm?
Earlier quoted context omitted.
I am not sure if you are serious or not. How does verification prevent buffer overflows? It can reduce their frequency, but you can never know you got them all. They find issues in libCURL and openSSL that have existed for years. Very few people are better than the people working on those libraries. It is better to be safe by default then add risk only when you need it. I say this as a C++ developer, I think const sh…
Formal verification is not the same as a security audit. With formal verification you can prove that something is bug-free. > They find issues in libCURL and openSSL that have existed for years Neither of them are formally verified. https://github.com/seL4/seL4 however is formally verified.
I don't know if its too hard to do to real software or if C doesn't allow for it, or if it is just too expensive. The simple matter is that is not an option for the vast majority of projects. Unless you can make it practical, I assert it has no place in a practical discussion about preventing software issues.
If you are really worried about the security of old C code, then the safest, most portable thing to do is re-write in modern C++. This is sane and doable in a short period of time. Rust is not.
Oh no, no, no! Some people may reasonably, with some extreme care and diligence, maybe try to claim they can write safe and UB-free C code. If stars align properly. (See maybe SQLite. Seen as one of the pinnacles of crazy pedantism in C. Also, see the article about errors found recently in SQLite with fuzzing!) But with C++, it's just impossible for a human. It's too big, too quirky, too big, too wide, too deep, too…
Has anyone done any in depth explorations of the safety and security of rust code vs well written C or C++?
anyone thinking "I'll just write these 50k SLOC very well so it'll be ok" should not consider a career in programming.