This is clearly a typo that happened to stomp some logic that is not covered by a test. The review 3002282 includes the bug, which deletes one of the & from a && operator. It says it was cherry-picked from review 2994464, which does not change that line. So, slip of the backspace key plus poor testing.
Google broke a conditional statement that verifies passwords on Chrome OS
51–60 of 276 posts
Re: Google broke a conditional statement that verifies passwords on Chrome OS
#52From the article: > The line should read "if (key_data_.has_value() && !key_data_->label().empty()) {" but instead of "&&"—the C++ version of the "AND" operator—the bad update used a single ampersand, breaking the second half of the conditional statement. Someone correct me if I'm wrong, but this seems like it wouldn't be possible in a language that didn't conflate boolean values with bitvectors. Edit: I was wrong[1]…
Certainly won't compile in Java.
Re: Google broke a conditional statement that verifies passwords on Chrome OS
#53Earlier quoted context omitted.
Forgive my poor C++, but has_value() sounds like a bool, and empty() sounds like a bool. Why wouldn't "bool1 & bool2" work correctly?
Dereferencing via key_label_-> has undefined behavior when !key_label_.has_value(), so the compiler treats that case the same as if key_label_.has_value(). Or to put it another way, the compiler reasons that key_label_ must have had a value (since you dereferenced it), and thus optimizes out the check for `has_value()` (since clearly it was unnecessary).
Would this optimization not have been on the beta/canary channel? I assumed they were but perhaps not since this was not caught.
Re: Google broke a conditional statement that verifies passwords on Chrome OS
#54From the article: > The line should read "if (key_data_.has_value() && !key_data_->label().empty()) {" but instead of "&&"—the C++ version of the "AND" operator—the bad update used a single ampersand, breaking the second half of the conditional statement. Someone correct me if I'm wrong, but this seems like it wouldn't be possible in a language that didn't conflate boolean values with bitvectors. Edit: I was wrong[1]…
That so sounds like an error I would make and not some superDev working at the Googs making around 4x the amount of money I make.
They're just people. If you want to get in you probably could, with some effort.
Re: Google broke a conditional statement that verifies passwords on Chrome OS
#55From the article: > The line should read "if (key_data_.has_value() && !key_data_->label().empty()) {" but instead of "&&"—the C++ version of the "AND" operator—the bad update used a single ampersand, breaking the second half of the conditional statement. Someone correct me if I'm wrong, but this seems like it wouldn't be possible in a language that didn't conflate boolean values with bitvectors. Edit: I was wrong[1]…
The most general solution here is to use algebraic types and pattern match on the value being “None” or “Some data”.
Re: Google broke a conditional statement that verifies passwords on Chrome OS
#56From the article: > The line should read "if (key_data_.has_value() && !key_data_->label().empty()) {" but instead of "&&"—the C++ version of the "AND" operator—the bad update used a single ampersand, breaking the second half of the conditional statement. Someone correct me if I'm wrong, but this seems like it wouldn't be possible in a language that didn't conflate boolean values with bitvectors. Edit: I was wrong[1]…
This is one of those times when, for all its verbosity, Ada got it right. For boolean conjunction you must choose between writing "A and B", or "A and then B". The "and then" version is short circuiting, while the bare "and" version is not.
Visual Basic also has this distinction (but the keywords are "And" and "AndAlso")
Re: Google broke a conditional statement that verifies passwords on Chrome OS
#57If you've been in tech for a while, this is one of those things that makes you sigh and shake your fist at "move fast and break stuff" as a strategy.
Google's philosophy isn't "move fast and break stuff". It's probably the opposite - "move slow and be careful". These things happen.
Re: Google broke a conditional statement that verifies passwords on Chrome OS
#58Earlier quoted context omitted.
I've seen the = instead of == in the wild with disastrous results: the assignment was on an ORM backed object, e.g. // accidentally mutates all names to Sam and persists to the DB myList.filter { myDomainObj.name = 'Sam' } But it makes me wonder why our programming languages would use characters which can often lead to this type of error.
I'm a fan of programming languages using := for assignment for this reason
Look, I know that this is an enormously bad bug, but...
Google has a codebase that numbers multiple billions of lines. Using := means typing multiple billions of extra characters. That adds up. And it wouldn't even have prevented this bug!
All checks have costs. As Emerson said, "A stitch in time saves nine. So we make 1000 stitches, that by doing so we may save nine."
Re: Google broke a conditional statement that verifies passwords on Chrome OS
#59From the article: > The line should read "if (key_data_.has_value() && !key_data_->label().empty()) {" but instead of "&&"—the C++ version of the "AND" operator—the bad update used a single ampersand, breaking the second half of the conditional statement. Someone correct me if I'm wrong, but this seems like it wouldn't be possible in a language that didn't conflate boolean values with bitvectors. Edit: I was wrong[1]…
That so sounds like an error I would make and not some superDev working at the Googs making around 4x the amount of money I make.
Not sure why you think a "superDev" would be less susceptible to simple typos?
Re: Google broke a conditional statement that verifies passwords on Chrome OS
#60Earlier quoted context omitted.
I've seen the = instead of == in the wild with disastrous results: the assignment was on an ORM backed object, e.g. // accidentally mutates all names to Sam and persists to the DB myList.filter { myDomainObj.name = 'Sam' } But it makes me wonder why our programming languages would use characters which can often lead to this type of error.
If you consider a linter part of a programming language, most, when properly configured, do not permit this. It's just the syntax that does; professionals do not rely on syntax validity alone but employ linting, code review, static analysis, and integrations tests on top. The gradient of professionalism in our industry is very wide, and the slope is quite shallow. To your point, however, many languages (such as Go, d…
what is the difference between linting and static analysis? Coverity, cppcheck etc, what are those? You mention integration tests, but not unit test, do you value unit test?