3 ms·

> 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 re

> 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

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.