4 ms·

I strongly suspect the reason is because they tolerate incomplete test suite, and don't use sanitisers enough, despite their use of an insanely unsafe language

I strongly suspect the reason is because they tolerate incomplete test suite, and don't use sanitisers enough, despite their use of an insanely unsafe language (one thing I absolutely hate about C is the sheer amount of undefined behaviour). -Werror is just a stop gap desperate measure for when devs are pressured to write crap as quickly as possible. What's exceptional about Monocypher is not really that it's a cryptographic library (though that helps, modern cryptographic code tends to have pathologically simple control flow), it's that I took the time to polish it. That being said, I am not against static analysis. On the contrary, I am huge fan of strong static type systems, and for languages like C a static analyser can be a huge help. I also trust John Carmack when he says running a static analyser has found non-trivial bugs in real code. But then I want real static analysis, that can assess actual risks of making mistakes. Compilers need to be fast, so their warnings naturally tend to be crude. And if they start complaining about stuff like whitespace in a language where whitespace has no semantics, that may hurt more than it helps.

UncleMeat 5y ago
"Just write good code" is not a workable plan for most organizations of any size. You often want workflows that are resistant to "we promoted somebody to TL when they shouldn't have been and they are not doing a very good job" situations. Yes, it is outrageous that anybody still writes programs in C or C++, which basically guarantee that you'll write oodles of subtle bugs. Yes, static analysis that finds problems that you can't train humans to find is more interesting. Yes, sanitizers and fuzzing should be mandatory for any serious project in C or C++. But "hey, you've got a vacuously true branch predicate" is valuable in a large number of cases even if humans can catch that with tests, since most organizations are not able to successfully hire only excellent engineers and give them sufficient time to never be rushed. Just a few weeks ago Google shipped a branch condition that included & rather than && that broke all Chromebook logins. I submit this as evidence that it it not possible to construct a large organization that is resistant to bad code without automation. Yes, a lot of other things needed to go wrong to enable this code to reach production but so many of those processes are either done by humans (and therefore error prone) or produce the same complaints when mandated by automation (e.g., 100% line coverage).
- MaxBarraclough 5y ago
  > Google shipped a branch condition that included & rather than && that broke all Chromebook logins To be fair to C++, that's not the sort of issue that can really be blamed on the language, its unsafety, or its many footguns. Did they skimp on testing?
  - UncleMeat 5y ago
    I don't know the testing situation. But there is a lesson from other forms of engineering here. Almost no failure has a single cause. A variety of things need to go wrong. "Just test better" is not a strategy. Any honest view of large scale software engineering has to internalize that all of the human processes can fail and even the technical processes can fail and so you need layers of protection. People should try to write correct code. Sometimes they will fail. People should review code carefully. Sometimes they will fail. People should test code thoroughly. Sometimes they will fail. Tooling should automate issue detection with static analysis and fuzzing. Sometimes it will fail. Tooling should automate issue detection with canaries and monitoring. Sometimes it will fail. Maybe the team skimped on testing as a rule. Maybe the engineers who submitted and review the code were tired that day and didn't test it well. Maybe something in the the CI was flakey so they did a force push. I don't know. But I do know that making it harder to do weird things like using bitwise-and in a branch predicate with something other than a constant mask adds an extra layer of defense.
    - MaxBarraclough 5y ago
      > I do know that making it harder to do weird things like using bitwise-and in a branch predicate with something other than a constant mask adds an extra layer of defense. Sure, and perhaps I was mistaken in saying this isn't due to C++'s footguns. The & / && operators do look similar. Ada uses and / and then, which is more distinctive.

UncleMeat 5y ago

"Just write good code" is not a workable plan for most organizations of any size. You often want workflows that are resistant to "we promoted somebody to TL when they shouldn't have been and they are not doing a very good job" situations. Yes, it is outrageous that anybody still writes programs in C or C++, which basically guarantee that you'll write oodles of subtle bugs. Yes, static analysis that finds problems that you can't train humans to find is more interesting. Yes, sanitizers and fuzzing should be mandatory for any serious project in C or C++. But "hey, you've got a vacuously true branch predicate" is valuable in a large number of cases even if humans can catch that with tests, since most organizations are not able to successfully hire only excellent engineers and give them sufficient time to never be rushed. Just a few weeks ago Google shipped a branch condition that included & rather than && that broke all Chromebook logins. I submit this as evidence that it it not possible to construct a large organization that is resistant to bad code without automation. Yes, a lot of other things needed to go wrong to enable this code to reach production but so many of those processes are either done by humans (and therefore error prone) or produce the same complaints when mandated by automation (e.g., 100% line coverage).

MaxBarraclough 5y ago
> Google shipped a branch condition that included & rather than && that broke all Chromebook logins To be fair to C++, that's not the sort of issue that can really be blamed on the language, its unsafety, or its many footguns. Did they skimp on testing?
- UncleMeat 5y ago
  I don't know the testing situation. But there is a lesson from other forms of engineering here. Almost no failure has a single cause. A variety of things need to go wrong. "Just test better" is not a strategy. Any honest view of large scale software engineering has to internalize that all of the human processes can fail and even the technical processes can fail and so you need layers of protection. People should try to write correct code. Sometimes they will fail. People should review code carefully. Sometimes they will fail. People should test code thoroughly. Sometimes they will fail. Tooling should automate issue detection with static analysis and fuzzing. Sometimes it will fail. Tooling should automate issue detection with canaries and monitoring. Sometimes it will fail. Maybe the team skimped on testing as a rule. Maybe the engineers who submitted and review the code were tired that day and didn't test it well. Maybe something in the the CI was flakey so they did a force push. I don't know. But I do know that making it harder to do weird things like using bitwise-and in a branch predicate with something other than a constant mask adds an extra layer of defense.
  - MaxBarraclough 5y ago
    > I do know that making it harder to do weird things like using bitwise-and in a branch predicate with something other than a constant mask adds an extra layer of defense. Sure, and perhaps I was mistaken in saying this isn't due to C++'s footguns. The & / && operators do look similar. Ada uses and / and then, which is more distinctive.