News for hackers. Stuff that matters.
Re:Google broke a conditional statement that verifies passwo... by MauranKilom on Thursday July 22, 2021 @08:23PM (#27925948)
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 need to write to preserve the original logic is

    for (auto x : y)
      ok = check(x) && ok;
Now the `&& ok` is much easier to miss (both in writing and reading) and the intent is much less clear.

I really do wonder why the standard doesn't just specify the behavior of bool & bool. Is it just because of holdover from C?

Re:Google broke a conditional statement that verifies passwo... by dataflow on Thursday July 22, 2021 @11:08PM (#27926751)
> 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++.

Re:Google broke a conditional statement that verifies passwo... by thaumasiotes on Friday July 23, 2021 @01:42AM (#27927591)
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 passwo... by dataflow on Friday July 23, 2021 @01:45AM (#27927608)
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 passwo... by gpderetta on Friday July 23, 2021 @09:33AM (#27930460)
I lost track how many times I have been bitten by the ok = ok && ... trap.