Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google broke a conditional statement that verifies passwords on Chrome OS

arstechnica.com

Post reply on HN
Print view View original

91–100 of 276 posts

Re: Google broke a conditional statement that verifies passwords on Chrome OS

#91

Post by phkahler »

shawnz wrote: post #74
fouric wrote: post #17

From 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]…

Other than this particular edge case it's not obvious to me why bitwise operators shouldn't be applicable to boolean values. Aren't they just single-bit vectors? Of course it makes sense that logical operators wouldn't be applicable to numeric types, but why the reverse?

>> Other than this particular edge case it's not obvious to me why bitwise operators shouldn't be applicable to boolean values.

That is a really good question. At some point they decided that true=1 and false=0 but I'm not sure how deep that goes. In particular what does ! actually do in this context?

Re: Google broke a conditional statement that verifies passwords on Chrome OS

#92

Post by gene91 »

gmfawcett wrote: post #48
fouric wrote: post #17

From 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.

This is a typo of missing an ampersand. If the author were writing Ada, it would have been a typo of missing a “then”. How is it different?

Re: Google broke a conditional statement that verifies passwords on Chrome OS

#93

Post by grishka »

shawnz wrote: post #75
grishka wrote: post #52

Earlier quoted context omitted.

Certainly won't compile in Java.

In fact you can apply the single ampersand & operator to booleans in Java, and just like in the example here it has the same behaviour as && but with no short-circuiting.

Huh. I didn't know that.

Re: Google broke a conditional statement that verifies passwords on Chrome OS

#94

Post by anyfoo »

crazygringo wrote: post #90
anyfoo wrote: post #50

Earlier quoted context omitted.

The problem is not even with "easy to mix up operators" for this, it's about languages without a strong and static enough type system. While the particular problem Google hit is a bit more subtle (involving undefined behavior), in the majority of cases a strongly typed language would not allow expressions that accidentally mix up = and ==, as they often resolve to different types. In C "if (foo = bar)" and "if (foo =…

> in the majority of cases a strongly typed language would not allow expressions that accidentally mix up = and ==, as they resolve to different types. That's not true at all. Whenever you're intending to compare equality, they're usually going to be the same type already unless you're being really slopping in a scripting language like JavaScript or PHP -- but even then they're usually two numbers, two strings, or tw…

No. It can help because the result of the expression would have a different type, one that "if" does not accept. If a and b are integers, then the expression "a = b" is an integer too, but "a == b" is a boolean. In a strongly typed language, you can assume that "if" only accepts booleans.

Re: Google broke a conditional statement that verifies passwords on Chrome OS

#95

Post by slavik81 »

anyfoo wrote: post #86
gpderetta wrote: post #73

Earlier quoted context omitted.

the problem is that bitwise & and | are routinely used for their non-shortcircuiting behaviour in boolean expressions, so it is hard for the compiler to flag this as an error. Many linters and static analysis tools do flag them though as these days it is not considered good practice.

Why would you even need non-shortcircuiting behavior in boolean expressions? Because either side of the operator has side effects that you want to happen unconditionally? Please just write it out as an extra statement then instead of hammering it into place with an implicit coercion to an integer type only so you can abuse bitwise AND and OR only to force that side effect to... you can see why this is probably not th…

Matt Godbolt gave an example of a significant performance hit caused by unnecessary short-circuiting in his CppCon 2019 talk[1]. EDIT: Deleted tangent.

[1]: https://youtu.be/HG6c4Kwbv4I?t=45m

Re: Google broke a conditional statement that verifies passwords on Chrome OS

#96

Post by nicoburns »

anyfoo wrote: post #79
sneak wrote: post #41

Earlier quoted context omitted.

I would say this is negligence, but perhaps not extremely so.

You are all very quick to judge. I don't work for Google so I don't know what happened, but consider the possibility that this may have been a freak accident. That piece of code for example might only be on a path that is not activated when testing, or it may be executed but not have the same fatal effect. And before anyone comes along and says "well, every possible path should be tested then": That would be absolute…

This is the sort of thing that most linting tools will catch, so it's a bit worse than that I think. You shouldn't need any test coverage to catch this.

Re: Google broke a conditional statement that verifies passwords on Chrome OS

#97

Post by ectopod »

vlovich123 wrote: post #85
idiotsecant wrote: post #35

Earlier quoted context omitted.

>extreme negligence If this doesn't qualify, what does?

This isn’t extreme negligence of any single individual. If there are linters/compiler warnings that should have caught this, this is an organizational failure that can be remedied and the manager/TL should be taking a bit of a hit here as having those enabled is best practices. Since it’s ChromeOS I imagine there’s a dedicated team managing the build infra and it’s not using the base set of things that Google3 protec…

The GGGP is talking about failures at a higher level. Not reprimanding the coder who missed an ampersand, but the manager who was ultimately responsibly for ensuring there was a functioning process for catching this sort of nonsense.

Re: Google broke a conditional statement that verifies passwords on Chrome OS

#98

Post by mdoms »

sneak wrote: post #20
mdoms wrote: post #18

Earlier quoted context omitted.

> Heads should probably roll here, I disagree. It's obviously a major balls up by multiple people, but at the end of the day this is an organizational failure. You don't fire people for this, you learn from it and fix the organizational holes that caused it.

Someone is responsible for the organizational units and their processes. By that logic, almost no individual failure is a firing offense. Many people in the organization are responsible for ensuring that the processes themselves overlap in ways that exclude the possibility of failures like this. I'm talking about the meta-failure in management's oversight of the processes. There is belt person, and there is suspender…

> By that logic, almost no individual failure is a firing offense.

Correct.

Re: Google broke a conditional statement that verifies passwords on Chrome OS

#99

Post by qalmakka »

fouric wrote: post #30
Trollmann wrote: post #26

Earlier quoted context omitted.

You can use `and` and its siblings instead of && and similar in C++11. Most people here, and in other boards, will try to convince you that it hurts readability because 'that‘s how we always did it' (read I‘m used to it and don‘t like change).

I am also of the opinion that `and` is more readable than `&&` (and isn't as easy to typo in a catastrophic way) - although my main point was about the weaker type system.

C++ definitely hasn't a weaker type system than "newer" languages like Java - if any, it is much more richer and complex than most languages out there. What's happening here is a type conversion that has to be in place due to C not having a boolean type until 1999. C++ attempts to construct a boolean from the argument of an `if()`, and given that bool can be constructed from int, the conversion succeedes.

You can define your own conversion operators to boolean, too, which are very useful for stuff like smart pointers and similar classes that may or may not have a value.

  struct A {
     std::string value;
  
     explicit operator bool() const {
        return this->value.size();
     }
  };
  
  // ...
  
  A a {};
  if (!a) { 
     // ...
  }
Post reply on HN