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

161–170 of 276 posts

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

#161

Post by d110af5ccf »

saagarjha wrote: post #123
samtheprogram wrote: post #112

Earlier quoted context omitted.

This reminds me of Silicon Valley’s main character preferring tabs to spaces because they use less bytes, despite his own product being for... compression! I personally prefer spaces so that under any circumstances, the code reads the same as the author intended (whether you’re in an editor or viewing a file with a CLI tool). Are we really counting bytes in this day and age?

Considering that most code get read by more than one person, I think hardcoding the author's preferences in how it should be read is strange and in some cases inaccessible.

This. Author chose two spaces per indent and proceeded to nest blocks 5 levels deep? Guess I have to run it through a code formatter now just to read it.

Alternatively, author chose eight spaces per indent and proceeded to nest things? My tiled windows only have ~100 columns, thanks so much for breaking my workflow with your poor choices.

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

#162

Post by yongjik »

Trollmann wrote: post #26
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]…

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.

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

#163

Post by d110af5ccf »

anyfoo wrote: post #120
hashingroll wrote: post #115

Earlier quoted context omitted.

The argument for tabs really goes that time is spent much more on reading code than authoring, so it should be optimized and customizable (tab width) for the reader.

Tabs for indentation, spaces for alignment.

I used to feel very strongly about this. Then I started using Common Lisp and discovered the abomination that is tabstop. This archaic "feature" leads to tab width that varies across the line and seems to be hardcoded in every text editor out there. Worse, it's only useful if using tabs for alignment which is completely broken anyway! At some point I intend to patch the source for the editors I use to remove this nonsense.

Admittedly this is something of an edge case - how many languages other than Lisps involve alternating layers of indentation and alignment? The more common C like languages don't suffer from this at all.

At this point I'm largely convinced that more or less all of our tools, languages, and conventions are poorly thought out, brittle, and inelegant. /rant

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

#164

Post by thesuperbigfrog »

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.

The equivalent Ada code does not exist as the Ada boolean type only has a logical AND operator (no bitwise operations exist):

http://www.ada-auth.org/standards/12rm/html/RM-A-1.html#I538...

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

#165

Post by frankzinger »

areyousure wrote: post #133
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).

While it is true that you can use `and` in C++11, that's a bit of an understatement: these keywords have in fact been present since the very first ISO C++ standard C++98!

Note however that MSVC does not support these by default. You need to #include before their use, or you need to pass the `/permissive-` compiler option.

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

#166

Post by antonvs »

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…

One point that doesn't seem to have been explained yet - mentioned in the OP article - is that Chrome OS has canary, dev, and beta channels prior to stable, with real users.

For something like this to have happened without those non-stable channel users experiencing it, it seems like there must have been a code change that was pushed direct to the stable channel - which negates the purpose of the other channels in the first place.

At the very least it seems like a severe process failure. I don't think the dev who changed the code is necessarily at fault - it's more a question of how it was allowed to get into the stable channel without going through the normal process.

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

#168

Post by dodobirdlord »

snvzz wrote: post #62

What it means is: They push crap to users with no testing. Testing would have caught this.

Since the issue is caused by an undefined behavior optimization, possibly the tests ran on a different optimization level or on a different architecture target? Would still be surprising, but less so than there not being tests at all.

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

#169

Post by snovv_crash »

josefx wrote: post #160
anyfoo wrote: post #86

Earlier quoted context omitted.

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…

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.

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

#170

Post by geofft »

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.

On the other hand, if it were actually the case that people kept turning on the wipers instead of signaling their turns, it would be a sign that we should figure out how to make these two different operations not use symmetrical levers, and that it would be okay to change people's expectations because those expectations weren't very firm.

In aircraft, where it matters a whole lot more that you don't confuse the various levers, the handle of the landing gear lever is shaped like a little wheel and the handle of the flaps lever is shaped like a little wing edge: https://aviation.stackexchange.com/a/22689

Typing "and"/"bitand" seems like the same sort of thing. It's a minor change, but it prevents errors.

Post reply on HN