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

71–80 of 168 posts

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

#71

Post by ajross »

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 have if our editors hadn't been enforcing this since time immemorial.

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

#72

Post by dcvuob »

pavlov wrote: post #54
mediocrejoker wrote: post #25

Earlier quoted context omitted.

I'm not sure that expanding your statement to multiple lines is any less "useful". I suppose in certain cases it can make code much more verbose, as one line effectively becomes 3-4, which can make it harder to navigate.

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 shouldn't look like Python. Small amount of functionality should be written unambiguously and take a lot of space if necessary. Because of the nature of C, it needs a lot boilerplate, and will take a lot of screen space anyway, but that is not a problem, as we are not coding on paper.

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

#73

Post by nathanielc »

asadjb wrote: post #66
nathanielc wrote: post #42

Earlier quoted context omitted.

Yes, and that the nuances of how things are formatted are really not that important, but rather having a standard which provides a consistent reading experience is the important aspect.

I agree completely with this. After fighting over code formatting for so long (often starting those fights myself), I have thankfully come to realize that what format you use almost never matters, only that you use some standardized format.

And in the case of go that standard is language wide, not just project, team, or company wide.

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

#74

Post by MattConfluence »

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....

Since Python 3 the interpreter will halt when detecting mixed whitespace, forcing the programmer to deal with it.

https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces

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

#75

Post by marcosdumay »

gravypod wrote: post #47
kllrnohj wrote: post #31

Earlier quoted context omitted.

People will make mistakes. Policy does not prevent that. Tools do.

Not in every case. I'd say that policy does help in some cases and tools do in others. What I often see is people just ignore the output from tooling and commit anyway. No method of prevention is perfect, but everything you do can help to increase stability in projects.

A policy of "never ignore this warning" has a much better chance of being followed and removing the bugs than a policy of "always put brace on code blocks".

Yes, both are policy, but they are different kinds.

Of course, banishing single line blocks at the compiler would be infallible, but it's also not viable.

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

#76

Post by seiji »

nathanielc wrote: post #73
asadjb wrote: post #66

Earlier quoted context omitted.

I agree completely with this. After fighting over code formatting for so long (often starting those fights myself), I have thankfully come to realize that what format you use almost never matters, only that you use some standardized format.

And in the case of go that standard is language wide, not just project, team, or company wide.

Except the go standard is awful, so a language-wide formatting requirement with bad defaults makes the language basically unusable (since programs are made to be read, not run).

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

#77

Post by MichaelBurge »

gravypod wrote: post #57
mikeash wrote: post #49

Earlier quoted context omitted.

That seems like a somewhat different case, though. Your approach will help prevent new bugs like this from being introduced, but won't help you against existing examples of it in areas you're not currently working on. And just because it's been around a long time doesn't mean it's "working." Goto fail showed that the bugs can be subtle and easily missed for a long time.

Yes, but from what I understand this bug is more commonly introduced in code that is being updated. Notice that I said "avoided", not "fixed". That is because I am rather focused on making code that is maintainable. I posted this original comment to have a dialogue about something I include in my programming practices. I wanted to see how other people viewed this as a development technique.

You didn't say it explicitly, but your original comment came off more like "This option is unnecessary and should be removed from gcc, since we can simply enforce a style of using curly braces everywhere"

C doesn't do this, but I like this feature from Perl for single-statement checks:

    return if is_red($traffic_light);

    return unless is_green($traffic_light);
In C, I usually put the early returns on their own line without curly braces, but place them all together at the start of the function to make it easier to spot inconsistencies.

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

#78

Post by seiji »

gravypod wrote: post #7
iainmerrick wrote: post #4

Earlier quoted context omitted.

This warning is a practical solution to a real problem (of which the famous "goto fail" is an example). Using braces everywhere is definitely good style, but it isn't a practical solution because there's a ton of existing C/C++ code that doesn't use braces.

Wouldn't it make sense to update that as you change the code? If you edit an if statement, you should add the braces in. It would make sure that no new errors are introduced due to this.

Automatic brace insertion program with helper scripts: https://matt.sh/howto-c#_formatting

It is never an error to insert braces, and the rules for inserting braces are fully deterministic in C.

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

#79

Post by Tyr42 »

return0 wrote: post #40
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.

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

That's what plugins are for :P

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

#80

Post by dcvuob »

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…

Second example is very readable using Allman style:

    if( condition_a )
    {
         if( condition_b )
         {
             do_thing_a();
         } 
         else 
         {
             do_thing_b();
         }
    } 
    else 
    {
         do_something_else();
    }
Editor space is free, why not use it.
Post reply on HN