This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Please, take '-Wmisleading-indentation' out of -Wall

On May 4, 2016 2:35:38 PM CDT, "Manuel LÃpez-IbÃÃez" <> 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
>>> accept
>>>       '-Wno-misleading-indentation'. (At least 4.1.2 does not accept
>>> it).
>> 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
>>>       -Wall.
>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
>Nowadays it is extremely easy to disable a warning that annoys you (the
>name is 
>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
>found a 
>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
>-Wall. The 
>easy way out would have been to say: "I know how to enable it, so let's
>hide it 
>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
>>> both
>>> -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
>at the 
>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",
>"typical code 
>that is often/sometimes a bug", etc. Of course, this would be a lot of
>that no one wants to do ;-)
>	Manuel.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]