Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

developerblog.redhat.com

Post reply on HN
Print view View original

151–160 of 168 posts

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

#151

Post by GFK_of_xmaspast »

dcvuob wrote: post #72
pavlov wrote: post #54

Earlier quoted context omitted.

Fairly often there's a whole sequence of this type of calls. For example cleanup of multiple objects: if (image) foo_release(image); if (label) foo_release(label); if (data) foo_buffer_destroy(data); if (window) foo_window_destroy(window); It's easier to see that all objects are being cleaned up when each occupies just one line, as that typically matches the look of the initialization: window = foo_window_create(); d…

Those if statement should be written using the ternary operator. In my subjective opinion, putting the expression in the same line as the if statement is awful. Objectively it is worse because you create a possibility of certain types of errors, like a hanging statement or similar. Ternary operator doesn't have those. The second example is missing error checking. So the real code isn't that nice. My point is that C s…

I'm closing in on year 25 of programming in c, and I still refuse to use the ternary operator.

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

#152

Post by chriswarbo »

arohner wrote: post #136
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.

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

I'd clarify that to "lambdas can't contain statements". Lambdas can contain expressions, which can be nested arbitrarily, have side-effects (e.g. tuples guarantee left-to-right evaluation of elements), and be spread across multiple lines. It's not exactly pretty though ;)

I wrote about this a few years ago at http://programmers.stackexchange.com/questions/99243/why-doe... and slightly more obtusely at http://chriswarbo.net/blog/2012-11-17-anonymous_closures_in_...

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

#153

Post by tbirdz »

noamsml wrote: post #11

Nice. These sorts of warnings are why it's worth investing the extra effort to enable -Werror in your codebase if you can.

The problem with -Werror in open source projects is that it can produce errors for users building your code on different compilers or compiler versions than the one you originally developed it for.

As compilers change they can end up adding new warnings to the defaults, or for or example -Wall, or -Weverything. And different compilers might throw different warnings on the same code with the same options involved. Using -Werror will force an error, which can end up terminating the build for users, even when the code compiles cleanly on your version of your compiler.

So -Werror is fine if you are shipping binaries, but if you are shipping source code, it's probably a good idea to not use it in the public build system.

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

#154

Post by Gibbon1 »

Coding_Cat wrote: post #122
return0 wrote: post #40

Earlier quoted context omitted.

Agreed, but with braces, i can press % over a '{' in vi and find the matching }

Lack for jumping to the end of the current indent block is a missing-feature/bug in vi then. There is nothing technologically harder about finding the end of a block based on indentation than based on braces.

When I think about this I think about streaming protocols, you have two types those that totally lose the thread when there is an error and those that don't. And there is an issue of the typical hamming distance between valid code sequences.

I'm on the side of having to reflexively type an extra character or two to gain some parser redundancy and error detection. I've also read a few people talking about auto formatting tools and seems like they need all the help they can get.

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

#155

Post by Gibbon1 »

AdmiralAsshat wrote: post #6
gravypod wrote: post #2

This seems like it could have been avoided by people using braces around every block. Omitting braces in this case leads to a lot of problems.

I'm in favor of braces around everything, but to be honest even I will occasionally use the indent if I only expect one action. e.g. if (true) foo(); else bar(); This looks prettier to my eyes than if(true){ foo(); } else { bar(); } However, I might not be the last person to touch the code. My coworker might come later and add: if (true) foo(); else bar(); baz(); And hence the indent problem.

I think I don't really have that bar() baz() problem because I use blank lines to separate blocks of code from each other. And also because as a heathen I use Allman style not K&R.

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

#156

Post by dcvuob »

dcvuob wrote: post #72
pavlov wrote: post #54

Earlier quoted context omitted.

Fairly often there's a whole sequence of this type of calls. For example cleanup of multiple objects: if (image) foo_release(image); if (label) foo_release(label); if (data) foo_buffer_destroy(data); if (window) foo_window_destroy(window); It's easier to see that all objects are being cleaned up when each occupies just one line, as that typically matches the look of the initialization: window = foo_window_create(); d…

Those if statement should be written using the ternary operator. In my subjective opinion, putting the expression in the same line as the if statement is awful. Objectively it is worse because you create a possibility of certain types of errors, like a hanging statement or similar. Ternary operator doesn't have those. The second example is missing error checking. So the real code isn't that nice. My point is that C s…

It would be really nice if instead of downvoting, someone could provide a counterargument, or comment on parts the disagree.

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

#157

Post by infogulch »

MereInterest wrote: post #115
aikah wrote: post #67

Earlier quoted context omitted.

> I think that gofmt is particularly innovative, in the sense that it acknowledges that formatting is integral part of the language. gofmt is still optional. Python significant white spaces are not.

I thought that the go compiler would throw an error of your code is not in the format produced by gofmt. You don't need to use the tool, but you need to have your code in the same format that the tool would produce.

Nope. The gofmt-contract is a purely social one. But it's one held by nearly the entire go community which probably gave you that impression for good reason.

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

#158

Post by Redoubts »

ktRolster wrote: post #69
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.

>I'm glad Python (with semantic whitespace)... solve this problem. Python solved it....then added the problem of making things you can't even see semantically significant. If you write Python, it's helpful to have an editor that makes the difference between tabs and spaces visible....

> it's helpful to have an editor that makes the difference between tabs and spaces visible....

I do this for any and every language. Mixing tabs and spaces always sucks.

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

#159

Post by nkurz »

dcvuob wrote: post #156
dcvuob wrote: post #72

Earlier quoted context omitted.

Those if statement should be written using the ternary operator. In my subjective opinion, putting the expression in the same line as the if statement is awful. Objectively it is worse because you create a possibility of certain types of errors, like a hanging statement or similar. Ternary operator doesn't have those. The second example is missing error checking. So the real code isn't that nice. My point is that C s…

It would be really nice if instead of downvoting, someone could provide a counterargument, or comment on parts the disagree.

I downvoted it to indicate that I don't agree with your preference. I rarely downvote for disagreement, but this was a case where I thought it worthwhile to offer the feedback that others strongly do not share your view. My equally strongly felt subjective personal belief is that single line if statements without braces are fine, but that once a second line is required braces should be mandatory.

I find the single line "if" statement without braces to be clearer and simpler than ternary with a (void) expression, and don't think the downsides are significant. It breaks if you were to add another statement after the semicolon on the same line, but I think that should almost always be avoided anyway.

I do find it interesting that others prefer two-line without braces over the single line approach. I find this one to be more dangerous than the single line. Possibly because with line-oriented debuggers it can be hard to set the right breakpoint?

It's quite possible that others are downvoting because they think you are trolling, and that no one would actually believe the ternary operator to be clearer. I wondered also about your defense of Allman braces, which I didn't downvote because I think it's a good example of how different the others's views can be on what seems obvious. While I think (some of) your views are in the (very small) minority, please keep posting them!

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

#160

Post by MereInterest »

infogulch wrote: post #157
MereInterest wrote: post #115

Earlier quoted context omitted.

I thought that the go compiler would throw an error of your code is not in the format produced by gofmt. You don't need to use the tool, but you need to have your code in the same format that the tool would produce.

Nope. The gofmt-contract is a purely social one. But it's one held by nearly the entire go community which probably gave you that impression for good reason.

Wow, true. The first thing that I read was how to set up emacs to run gofmt every time you save a src file. After that, I never questioned it.
Post reply on HN