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

171–180 of 276 posts

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

#171

Post by thaumasiotes »

dataflow wrote: post #154
MauranKilom wrote: post #138

Earlier quoted context omitted.

What I would like to write in unit tests: for (auto x : y) ok &= check(x); That gets you angry messages from static analysis, so you probably have to write (since there is no corresponding assignment operator) for (auto x : y) ok = ok && check(x); ...except now you don't actually perform checks after the first failure. That may or may not be intentional (or even confusing - depending on logging). What you'd really ne…

> I really do wonder why the standard doesn't just specify the behavior of bool & bool. Confused about your question. Did you have a typo? bool & bool is valid in C++.

I'm guessing the question is related to this complaint:

> What I would like to write in unit tests:

> ok &= check(x);

> That gets you angry messages from static analysis

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

#172

Post by dataflow »

thaumasiotes wrote: post #171
dataflow wrote: post #154

Earlier quoted context omitted.

> I really do wonder why the standard doesn't just specify the behavior of bool & bool. Confused about your question. Did you have a typo? bool & bool is valid in C++.

I'm guessing the question is related to this complaint: > What I would like to write in unit tests: > ok &= check(x); > That gets you angry messages from static analysis

That has nothing to do with the standard though? The behavior is well-defined, it's just compilers warning about use of & tending to be error-prone (rightly or wrongly).

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

#173

Post by thaumasiotes »

snovv_crash wrote: post #169
josefx wrote: post #160

Earlier quoted context omitted.

Reduced unit test complexity? Short circuiting implies more branches, more branches means more tests for 100% coverage. Of course for that to be a downside someone would have to write tests for security critical code, which obviously did not happen.

That is just gaming your coverage stats, there are still the different branches they just aren't visible now.

That's not true.

Compare `( a() || b() || c() ) ? yes() : no()` to `( a() | b() | c() ) ? yes() : no()`.

In the second case, there are two paths through the code:

  a()
  b()
  c()
  yes()

  a()
  b()
  c()
  no()
But in the first case, there are more paths:

  a()    /* true */
  yes()

  a()    /* false */
  b()    /* true */
  yes()

  a()    /* false */
  b()    /* false */
  c()    /* true */
  yes()

  a()    /* false */
  b()    /* false */
  c()    /* false */
  no()
That is because there are fewer branches in the second statement (just one) than there are in the first statement (three).

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

#174

Post by unfamiliar »

yongjik wrote: post #162
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).

> that‘s how we always did it ... which, frankly, is a very good reason. Don't needlessly change something people are used to. Why is the blinker control on the left side and the wiper control on the right side? Because that's what people expect.

Fyi it does in fact change depending on the car manufacturer.

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

#175

Post by thaumasiotes »

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…

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

Interestingly, the example provided by slavik81 is able to tolerate non-shortcircuiting behavior specifically because no side effects are involved. It's more of a case of "we don't care about the result of this work, but we have to do it anyway, because it's better to do a lot of extra work concurrently than to do only the necessary work sequentially." And doing the extra work is OK because it doesn't have any side effects.

If side effects were involved, you'd be stuck needing to short-circuit despite the fact that it's slower.

There are also areas in cybersecurity where you'd like the time taken for some operation to be insensitive to the input; short-circuiting is bad there too.

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

#176

Post by encryptluks2 »

perl4ever wrote: post #119
kevincox wrote: post #82

Earlier quoted context omitted.

I don't think they could possibly be sued for this. They would just be responsible for fixing or refunding the product. In this case they issued a "fix". It is the same as when a car is defective. They don't get sued, they do a recall and fix it.

>They don't get sued, they do a recall and fix it Are you kidding? Major (car, drug, you name it) companies have hundreds, if not thousands of lawsuits going at any given moment. Public companies will sometimes list major lawsuits in their annual report, but most of them don't get mentioned because the amount at stake is trivial for them.

You have to remember, pretty much anyone can sue anyone... doesn't mean that they'll be successful.

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

#177

Post by jcelerier »

Macha wrote: post #143
jcelerier wrote: post #127

Earlier quoted context omitted.

Which of "Rust, Haskell (core Haskell), OCaml, and SML" is able to parametrize types on values, à la template ?

Rust 1.51+: https://blog.rust-lang.org/2021/03/25/Rust-1.51.0.html

It only supports integers so far, which c++ could do pretty much since before it was even standardized 25 years ago. Doesn't seem to support as wide of a type menagerie as C++20's NTTP. Does it even support parametrization over function pointers ?

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

#178

Post by pjmlp »

dolni wrote: post #5

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

We need more lawsuits for faulty deliverables and less "reboot and hope it works again" attitude.

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

#179

Post by qalmakka »

fouric wrote: post #102
qalmakka wrote: post #99

Earlier quoted context omitted.

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 def…

"Not as weak as Java" is not a very interesting benchmark, as Java also has a poor type system. C++'s type system is pitiable relative to those of Rust, Haskell, OCaml, and SML. Moreover, in addition to being less expressive than them, C++'s type system is also weak , in formal sense, by allowing many implicit type conversions - which is one of the issues that I was complaining about. The fact that it "has to be in p…

The fact implicit conversions exist doesn't really weaken the type system, the two are different concepts. If you define an overload or a type specialization on both the compiler will call the right version without any ambiguity. You can even define your own implicit conversions itself, and sometimes they have their uses, like when you need to wrap values in proxies but you still don't want the user to actually have to know that.

The template system and stuff like auto and such are crazy powerful. The Rust typesystem doesn't suffer from the C compatibility baggage and has been designed almost 30 years later, so it is amazing C++ can be so powerful and feel modern despite it being a forty years old language.

I write both Rust and C++ and I have to say, you can do a lot of type safe stuff in C++ too. Most patterns can be backported from Rust and while the ergonomics are not obviously at par, there is still a lot you can do. In C++you can do a crazy amount of metaintrospection at compile time that Rust can only do using procedural macros. Also constexpr and C++20's constinit and consteval are still more powerful than Rust's const.

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

#180

Post by qalmakka »

shawnz wrote: post #108
qalmakka wrote: post #101

Earlier quoted context omitted.

If you stop integer values from being implicitly convertible to booleans, you break the language and its compatibility with C. The inverse is debatable, though. I honestly don't see why someone would do bitwise operations on boolean, unless they really wish to die a slow death from thousand cuts. Integer promotion rules make even the simplest operations a wild mess, and there's nothing in the standard that prevents b…

I don't think the other poster was imagining a language that retained compatibility with C, but rather a new language altogether. Of course it would be impossible to change this aspect of the language if retaining compatibility with C was a requirement. > I honestly don't see why someone would do bitwise operations on boolean For example, you might want the behaviour shown here of not short-circuiting. Or you might w…

> you might want the behaviour shown here of not short-circuiting. Or you might want to create a bitwise function that also allows calling on single-bit (i.e. boolean) values.

In both cases, I think the risk-benefit ratio is way too skewed towards the risk of creating ugly, hard to detect bugs. When I don't want short circuiting from happening, I just assign the RHS of the expression to a variable beforehand; if I want a boolean to become an integer, I make it explicit with a cast.

Sometimes, using certain C and C++ debatable features feels like attempting to shave yourself using a dagger. The fact you could do that doesn't mean you should, or even that it is a good idea.

Post reply on HN