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
https://gcc.gnu.org/wiki/FAQ#wnowarning
- -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 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 https://gcc.gnu.org/PR52961
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
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 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 ;-)
Cheers,
Manuel.
