12 ms·

>Chromium has suffered from buffer-overflow issues, and that's a high-profile security-sensitive C++ codebase run by Google. Like I said, I haven't worked at G

by carlmr 6y ago

>Chromium has suffered from buffer-overflow issues, and that's a high-profile security-sensitive C++ codebase run by Google. Like I said, I haven't worked at Google. But are you sure every programmer on Chromium is a genius? Google has a hard Interview process, but does it filter out every bad engineer? And if Google's "probably better than other company's" engineers can't do it? How can we expect other companies to deal with C? >I'd rather avionics code be written in verified SPARK than in Rust, but if they can build a rock-solid Rust compiler it would be good to have it compete in that space. I imagine it could be a nice alternative to MISRA C++, for instance. Right now SPARK would definitely be favorable. But I think even current Rust would be much safer than MISRA C++.

MaxBarraclough 6y ago
> are you sure every programmer on Chromium is a genius? Google has a hard Interview process, but does it filter out every bad engineer? I suspect that yes, it filters out all candidates who are outright bad. I don't think this point really matters though. If even Google aren't able to produce a large C++ codebase free of buffer-overflows, even when it really matters, it suggests that no-one can. edit This doesn't need to be an argument drawn from a single sample, either. Buffer overflows happen to just about all major C/C++ codebases. OpenSSL, the Linux kernel, Windows, the Apache Web Server, nginx, etc. We could quibble about the way they don't use the sort of methodology used in avionics software development, but I don't think there's much value in exploring that. If Google consider that to be too slow/costly for Chromium, it highlights how rarely those methodologies can practically be used. I don't think there are any individual C++ programmers who are too smart to ever introduce undefined behaviour, but even if there were it wouldn't matter. As you indicate, real large-scale software development happens with teams, not lone geniuses. > I think even current Rust would be much safer than MISRA C++. I agree that the language might be a reasonable choice, but I don't think the Sealed Rust project is anywhere near delivering a Rust compiler that can be trusted with your life. Even mature C compilers can have serious bugs, [0] and compiling Rust is far more challenging than compiling C. [0] [PDF] Finding and Understanding Bugs in C Compilers, Regehr et al, 2011, https://www.cs.utah.edu/~regehr/papers/pldi11-preprint.pdf https://www.cs.utah.edu/~regehr/papers/pldi11-preprint.pdf
- carlmr 6y ago
  I've run into (multiple) compiler bugs in certified C and C++ compilers, I know how difficult this is. But still a much larger percentage of bugs I've seen was introduced by the developers. Which is why I said even now Rust would probably beat MISRA C++ in terms of total amount of bugs. I do think Sealed Rust has a bit of a way to go, but it would be a worthy investment. Seen from the point of total risk, the compiler errors are much harder to find, but the developer errors can still kill you. In any case SPARK is indeed even farther ahead in terms of having a reliable toolchain paired with a language that makes safe code easier to produce.

by carlmr 6y ago

MaxBarraclough 6y ago

> are you sure every programmer on Chromium is a genius? Google has a hard Interview process, but does it filter out every bad engineer? I suspect that yes, it filters out all candidates who are outright bad. I don't think this point really matters though. If even Google aren't able to produce a large C++ codebase free of buffer-overflows, even when it really matters, it suggests that no-one can. edit This doesn't need to be an argument drawn from a single sample, either. Buffer overflows happen to just about all major C/C++ codebases. OpenSSL, the Linux kernel, Windows, the Apache Web Server, nginx, etc. We could quibble about the way they don't use the sort of methodology used in avionics software development, but I don't think there's much value in exploring that. If Google consider that to be too slow/costly for Chromium, it highlights how rarely those methodologies can practically be used. I don't think there are any individual C++ programmers who are too smart to ever introduce undefined behaviour, but even if there were it wouldn't matter. As you indicate, real large-scale software development happens with teams, not lone geniuses. > I think even current Rust would be much safer than MISRA C++. I agree that the language might be a reasonable choice, but I don't think the Sealed Rust project is anywhere near delivering a Rust compiler that can be trusted with your life. Even mature C compilers can have serious bugs, [0] and compiling Rust is far more challenging than compiling C. [0] [PDF] Finding and Understanding Bugs in C Compilers, Regehr et al, 2011, https://www.cs.utah.edu/~regehr/papers/pldi11-preprint.pdf https://www.cs.utah.edu/~regehr/papers/pldi11-preprint.pdf

carlmr 6y ago
I've run into (multiple) compiler bugs in certified C and C++ compilers, I know how difficult this is. But still a much larger percentage of bugs I've seen was introduced by the developers. Which is why I said even now Rust would probably beat MISRA C++ in terms of total amount of bugs. I do think Sealed Rust has a bit of a way to go, but it would be a worthy investment. Seen from the point of total risk, the compiler errors are much harder to find, but the developer errors can still kill you. In any case SPARK is indeed even farther ahead in terms of having a reliable toolchain paired with a language that makes safe code easier to produce.