Earlier quoted context omitted.
Code Formating tools can help avoid this too.
At some point we should juat switch to editing abstract syntax trees instead of raw text. Then formatting is irrelevant, the structure is always clear, and each developer can choose their own way to view the code.
The Apple goto fail vulnerability: lessons learned (2014)
31–40 of 42 posts
Re: The Apple goto fail vulnerability: lessons learned (2014)
#32For as long as I live, I’ll never understand style guides that permit omitting brackets around a single line following an if statement (or for, while, etc), nor code formatters that dont automatically insert them.
They add visual noise. The grammar of C is not the same as the grammar of it's offshoots and block statements aren't part of control structures. Moreover, GCC warns about extra statements with the same indentation level with -Wall on.
Which is a good thing, since it prevents errors such as this one. Extra verbosity with mandatory braces is noise (to the degree that without it, the compiler could still infer what we mean), but some degree of verbosity is a good thing, as it helps make patterns in the code more evident.
In which case we might want to call it a more fitting error than the dismissing "noise".
How about "dither"?
Re: The Apple goto fail vulnerability: lessons learned (2014)
#33For as long as I live, I’ll never understand style guides that permit omitting brackets around a single line following an if statement (or for, while, etc), nor code formatters that dont automatically insert them.
I'm so glad that modern languages are opinionated and have default formaters that come with them. Jumping from one C codebase to another is really a nightmare, especially if you want to review code. That's a security issue in my book, as you end up with more reading complexity.
Re: The Apple goto fail vulnerability: lessons learned (2014)
#34For as long as I live, I’ll never understand style guides that permit omitting brackets around a single line following an if statement (or for, while, etc), nor code formatters that dont automatically insert them.
Changes were made to that module without tests being run and then it was put into production code.
Re: The Apple goto fail vulnerability: lessons learned (2014)
#35Praise then for languages with significant white space? Using a formatter tool to add the white space and a lint rule in your compiler to catch when it's not done is a bandaid for something that should be encoded into the language in my opinion. Leaving this stuff optional to enforce only eats up productivity for no decent upside.
Re: The Apple goto fail vulnerability: lessons learned (2014)
#36Yes, compilers have flags, coding standards can achieve the same results. The point is that this stuff is non standard, not everybody uses GCC or Clang. Stating "this code is MISRA compliant" is stronger that "this code does not produce compile warnings with the flags x, y, z on compiler W version a.b.c".
Re: The Apple goto fail vulnerability: lessons learned (2014)
#37Hi, I'm the author of the referenced article. Thanks for pointing to it! However, can you change HN thread to the article title, which is: "The Apple goto fail vulnerability: lessons learned"? I never used the term "backdoor" in the entire article, and I certainly never claimed that this was an intentional backdoor or that it looked just like a backdoor. I said, "The Apple goto fail vulnerability was a dangerous vuln…
Excuse me for changing the title of your essay. I should not do that. The title was just my opinion. Some days ago, I read the excellent newsletter [1] of Filippo Valsorda about a Telegram's bug [2]. Yesterday, I googled for bugdoors and read about them and found this Apple's bug and your excellent essay (with many useful hyperlinks) about it. [1] https://news.ycombinator.com/item?id=25726068 [2] https://habrahabr.ru…
Re: The Apple goto fail vulnerability: lessons learned (2014)
#38Re: The Apple goto fail vulnerability: lessons learned (2014)
#39For as long as I live, I’ll never understand style guides that permit omitting brackets around a single line following an if statement (or for, while, etc), nor code formatters that dont automatically insert them.
They add visual noise. The grammar of C is not the same as the grammar of it's offshoots and block statements aren't part of control structures. Moreover, GCC warns about extra statements with the same indentation level with -Wall on.
if (cond) {
// statement
} else {
// statement
}
existed. Allow you to quote everything while not waste so much vertical space.Re: The Apple goto fail vulnerability: lessons learned (2014)
#40The code written in my company must follow the MISRA rules. Among the others, there is a rules that requires branches to have code blocks, and another one that prohibits the use of goto. Yes, compilers have flags, coding standards can achieve the same results. The point is that this stuff is non standard, not everybody uses GCC or Clang. Stating "this code is MISRA compliant" is stronger that "this code does not prod…