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 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 when initially implemented, users complained, they were moved out and then either the bugs were forgotten or they got fixed but nobody bothered to move them 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 still 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 enabled 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 (myself included) have done this plenty of times in the past and the result is always the same: bugs don't get fixed, regressions appear, and users complain about missing warnings that are actually already implemented.

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 proposed categories are not clearly defined. A better classification would look at the possibilities of false positives, how easy is to silence it, whether it is "undefined/unspecified at runtime", "undefined/unspecif under some conditions 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 work that no one wants to do ;-)



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