GCC 6: -Wmisleading-indentation vs. “goto fail;” • Hacker News Board

Re: GCC 6: -Wmisleading-indentation vs. “goto fail;”

#131

Post by strommen » Fri, Feb 26, 2016, 6:03 PM UTC

ajross wrote: post #71

strommen wrote: post #13

Making braces optional in single-statement if/else/while/for clauses is one of the biggest anti-features in C. It's frustrating that it was ported forward to more modern languages like Java, JavaScript, C#, etc. I'm glad Python (with semantic whitespace) and Go (with gofmt) solve this problem.

> one of the biggest anti-features in C Please. I'm as big a C apologist as you'll find and even I can think of six or nine thing objectively worse about the language. This issue is merely a great bike shed because it allows all of us rabble to join in on a discussion about "compiler" technology. Look: it's a good warning. People should clearly use it. It probably should have been written long ago, and probably would…

Good point, there's plenty of bad stuff about C.

But optional braces are perhaps the most pointless anti-feature in C. The only benefit is a minor (and subjective) improvement in aesthetics.

Re: GCC 6: -Wmisleading-indentation vs. “goto fail;”

#132

Post by arnsholt » Fri, Feb 26, 2016, 6:04 PM UTC

wyager wrote: post #105

pklausler wrote: post #101

Earlier quoted context omitted.

Haskell's solution to this problem is also excellent and needs to be better known and copied into newer languages. The language has curly braces around the bodies of 'let', 'case', 'where', and 'do' constructs, and also the bodies of modules, and semicolons between the constituents of those constructs -- but when the compiler demands a '{' and doesn't see one, it uses indentation to insert them in the obvious places.…

I've actually never seen production code with braces or semicolons. The only place it's semi-common is when people write complicated expressions and need to put them on one line for the REPL (GHCi).

I think another use-case for non-layout version is generated code. If you happen to generate Haskell code, it's easier to keep the syntax correct with the explicit notation rather than the implicit whitespace version.

Re: GCC 6: -Wmisleading-indentation vs. “goto fail;”

#133

Post by TorKlingberg » Fri, Feb 26, 2016, 6:05 PM UTC

dcvuob wrote: post #124

TorKlingberg wrote: post #121

Earlier quoted context omitted.

How would you use the ternary operator there? Like this? image ? foo_release(image) : 0;

Yes. And cast that 0 to (void), so the compiler won't complain over an unused expression. Any C programmer will recognize what (void)0 means, do nothing.

Sure, but I find it strange to use the ternary operator and discarding the value. It's not wrong, but I think most C programmers prefer a simple if statement.

Re: GCC 6: -Wmisleading-indentation vs. “goto fail;”

#134

Post by TorKlingberg » Fri, Feb 26, 2016, 6:07 PM UTC

GFK_of_xmaspast wrote: post #44

pif wrote: post #17

> it’s been finding real world bugs One more case to support -Werror.

-Werror holds things back, because it makes the gcc maintainers hesitant to add more warnings on grounds of "it will break old code that uses -Werror", and in fact I was surprised to see that this warning is going into -Wall.

Just add -Wno-error=something if you don't want to fix your code for a new warning.

Re: GCC 6: -Wmisleading-indentation vs. “goto fail;”

#135

Post by Coding_Cat » Fri, Feb 26, 2016, 6:08 PM UTC

oftenwrong wrote: post #60

Semi-related: What do people think about if-else-if... chains vs nested simple if-else blocks? I have seen many cases on the job where someone writes a complex if-else-if chain and then an oversight in their logic WRT the dependencies between conditions causes the wrong branch to be taken. I prefer the latter style of the ones I've put below, especially when the conditions are more complex. For me, it makes it easier…

Thinking about it, I'd say the second one is better. I think it parse better in my mind as to what is meant.

However I also always comment nested logic chains with their intent in plain language. I have made bugs in going from intent->complex logic to often, and I found that writing comments at each fork greatly reduces these errors as well as the odds of missing an edge case.

e.g., I'd write "if(a) and not b" in plain English at the nested else statement, possibly followed by a "what & why" comment at the do_thing_b statement.

Re: GCC 6: -Wmisleading-indentation vs. “goto fail;”

#136

Post by arohner » Fri, Feb 26, 2016, 6:12 PM UTC

andybak wrote: post #30

The argument for significant white space in Python goes as follows: You need indentation for humans to understand the structure. Why do you also need braces for the parser to understand the structure when the parser can use the same information that your eyes use? You therefore avoid the possibility of the two signals contradicting each other.

Allowing explicit braces fixes deficiencies in python's grammar. For example, multi-line lambdas aren't currently possible in python.

Re: GCC 6: -Wmisleading-indentation vs. “goto fail;”

#137

Post by TorKlingberg » Fri, Feb 26, 2016, 6:17 PM UTC

swehner wrote: post #62

You'd think a stand-alone program could take care of this quite nicely? No need to clutter the compiler itself.

I have set up stand-alone static analyzers a couple of times, and it can be a giant hassle to get them working correctly. It is especially bad with complicated build systems for embedded applications.

To parse a C file correctly a tools needs to know the exact set of include path and defines you passed to the compiler. Then it needs to go read the whole tree of header files and preprocess everything. It needs to know where your standard header files are (different from the system header file when cross compiling). It needs to know about your compiler's built-in defines. It may also choke on any C extensions that your code (or any header file) is using.

In this particular case it may be enough to parse the file with some regexes but I wouldn't trust it; people do some crazy things with C macros.

Re: GCC 6: -Wmisleading-indentation vs. “goto fail;”

#138

Post by humanrebar » Fri, Feb 26, 2016, 6:19 PM UTC

Ace17 wrote: post #130

Why not give to your developers an immediate way to reformat the whole source tree before each commit/pullrequest, using dedicated tools, like uncrustify, bcpp or AStyle? Just store the configuration file in the repository, hook the reformat pass to the beginning of your build, and you're done. We've been doing this at work for several years ; and we found that this solved nearly every style-related issue (diffs, arg…

In theory that works fine, but in practice, I find every tool leaves little bits of cruft laying around:

// comments that get formatted correctly but then // the // wrapping // isn't // merged // into // one // line

On the other hand

// this could // be a // tabular comment

So you'd need everyone to use the same tool and you'd still need to go back and fix things periodically. To be fair, it might still be a net win.

Re: GCC 6: -Wmisleading-indentation vs. “goto fail;”

#139

Post by nisse72 » Fri, Feb 26, 2016, 6:27 PM UTC

Coding_Cat wrote: post #123

RHSeeger wrote: post #35

Earlier quoted context omitted.

Because, by having both, you can have your editor auto-indent and then you get a visual indication of where implementation does not equal intention.

If you don't have braces like in Python, then you always have the same visual feedback don't you? If you were to add braces to Python and auto-indent you'd end up with the same look as you would with python with only whitespace, only now there are superfluous brackets.

Rearranging code, refactoring, moving blocks, inserting conditionals etc would be easier and could be auto-indented if there were braces. Instead you need to carefully ensure that everything aligns correctly with the intended meaning at the new location.

Also, a closing brace is a nice signal to the editor that it's time to "outdent".

Finally, people seem to forget that python already has an opening brace, except it's spelled ':'. So why no closing brace to match? This seems inconsistent to me.

Re: GCC 6: -Wmisleading-indentation vs. “goto fail;”

#140

Post by Nemo157 » Fri, Feb 26, 2016, 6:30 PM UTC

lmm wrote: post #116

stephenr wrote: post #100

Earlier quoted context omitted.

> when they mean a function no longer fits on one screen What screen size? What resolution? What ide/editor window size? What font face & size? With or without soft line wrapping? Honestly arguments about how "pretty" code is are fucking ridiculous. Despite what someone said, the purpose of source code is not to be "read" with "running" as a secondary task. That literally only applies to code written purely for educa…

> What screen size? What resolution? What ide/editor window size? What font face & size? With or without soft line wrapping? Does it matter? There will be a point at which an extra line makes the difference. And particularly with modern screen shapes, vertical space is at much more of a premium than horizontal space. > Honestly arguments about how "pretty" code is are fucking ridiculous. Despite what someone said, th…

> And particularly with modern screen shapes, vertical space is at much more of a premium than horizontal space.

What? Modern 10:16 screens give more lines than 3:4. 900x1440 gets like 70 lines with 100 columns at a decent font size, better than around 60 lines with 110 columns with 960x1280.