This is the mail archive of the
mailing list for the GCC project.
Re: Please, take '-Wmisleading-indentation' out of -Wall
- From: Joel Sherrill <joel dot sherrill at oarcorp dot com>
- To: Manuel López-Ibáñez <lopezibanez at gmail dot com>,David Malcolm <dmalcolm at redhat dot com>,Antonio Diaz Diaz <antonio at gnu dot org>,"gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 4 May 2016 15:09:22 -0500
- Subject: Re: Please, take '-Wmisleading-indentation' out of -Wall
- Authentication-results: sourceware.org; auth=none
- References: <572A2029 dot 6030106 at gnu dot org> <1462386029 dot 14738 dot 43 dot camel at redhat dot com> <572A4F0A dot 2070304 at gmail dot com>
On May 4, 2016 2:35:38 PM CDT, "Manuel LÃpez-IbÃÃez" <email@example.com> wrote:
>On 04/05/16 19:20, David Malcolm wrote:
>> On Wed, 2016-05-04@18:15 +0200, Antonio Diaz Diaz wrote:
>>> - It can't be portably disabled; older versions of gcc do not
>>> '-Wno-misleading-indentation'. (At least 4.1.2 does not accept
>> FWIW "-Wall -Wno-misleading-indentation" works for me with gcc 4.8.3
>It should work since GCC 4.4 (7 years old). See
>>> - -Wempty-body is much simpler to test for, and in general less
>>> questionable than -Wmisleading-indentation, yet it is not
>>> enabled by
>Many useful warnings are outside -Wall/-Wextra because there were bugs
>initially implemented, users complained, they were moved out and then
>the bugs were forgotten or they got fixed but nobody bothered to move
>again within -Wall/-Wextra. See https://gcc.gnu.org/PR52961
>Nowadays it is extremely easy to disable a warning that annoys you (the
>written in the message and you can use #pragmas very selectively), but
>quite hard to discover which warning you need to enable that could have
>certain bug. It is also much harder to find regressions in warnings not
>by -Wall -Wextra because they are not tested as much.
>I really commend David for being brave and putting the warning in
>easy way out would have been to say: "I know how to enable it, so let's
>so that users do not complain to me about bugs that I don't suffer". We
>included) have done this plenty of times in the past and the result is
>the same: bugs don't get fixed, regressions appear, and users complain
>missing warnings that are actually already implemented.
I personally was dreading seeing how many warnings we would see in RTEMS when this first option first appeared. But we only saw a few warnings and a false positive. One of the warnings was definitely code that was unclear what the author's intent was. Others were worth addressing.
The false positive was reported and fixed promptly.
David has done well on this one.
I am a strong believer that code is written once, read many times, and debugged by unfortunate souls. It needs to be clear and unambiguous. This warning is helpful for that.
>>> I think that keeping separated categories of warnings (instead of
>>> warning about everything by default) is a valuable feature. Maybe
>>> -Wempty-body and -Wmisleading-indentation (and any future similar
>>> options) could be put in a new category (-Wcoding-style or
>>> -Wstatic-analysis, for example).
>I agree that GCC warnings could be better categorized, but your
>categories are not clearly defined. A better classification would look
>possibilities of false positives, how easy is to silence it, whether it
>"undefined/unspecified at runtime", "undefined/unspecif under some
>but not others", "atypical code that is often/sometimes a bug",
>that is often/sometimes a bug", etc. Of course, this would be a lot of
>that no one wants to do ;-)