The option Walways-true is described as: Warn about comparisons which are always true such as testing if unsigned values are greater than or equal to zero. This warning is enabled by -Wall.
In the description of warnings emitted by -Wextra we can find: An unsigned value is compared against zero with < or >=. GCC also emits an unconditional and unnamed warning that says: "comparison is always true/false due to limited range of data type" In this mail I will argue AGAINST adding the two latter warnings to Walways-true. The origins of Walways-true can be traced to a mail from Andrew Morton [1]. Kernel devs hit a bug where a function's name has been used in a test instead of actually calling the function. C++ front-end had a warning for this with the following message "the address of `function', will always be `true'". The warning was added to the C front-end without an option to control it [2]. Much later, the warning was given a name, Walways-true [3], since the warning message said explicitly that something will always be true. However, Andrew Morton didn't want to get a warning just because the expression was always true. He wanted to be warned of using the address of a function where it makes more sense to call the function. This seems also to be the original intent of the warning in the C++ front-end, as evidenced by the comment that accompanied it: /* Common Ada/Pascal programmer's mistake. We always warn about this since it is so bad. */ The common mistake is that in Ada/Pascal you can call a function just by using its name (without parenthesis), while in C/C++ the name of a function is its address. Yes, "if (func)" is always true and "if (func == NULL)" is always false but that is not why Andrew Morton wants to get the warning. Simply because a warning indicates that something is bad coding, we should not put it under -Wbad-code. Not understanding what GCC users really want [*] has led to the current situation. The present. We want to give a name to the warnings above. From its description, Walways-true, which seems to be useful for kernel devs and it is enabled by -Wall, seems appropriate. On the other hand, the -Wextra warning is in -Wextra for a reason: it is hard to avoid for macros and templates. Moreover, it is one of the reasons why the kernel is not built with -Wextra [4]. The other warning is equally hard to avoid for macros and templates. We have two bug reports about this [5][6]. Enabling those warnings with -Wall doesn't seem to me to be a good idea. But, for the reasons exposed above, moving Walways-true to Wextra and adding the warnings to it would also be a mistake from my point of view. Instead, I grouped both unnamed warnings under a different new option, Wcomparison-fixed, which is only enabled by Wextra. The patch is available at http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01120.html Sincerely, Manuel. [*] I don't say it is easy and I don't say I am right. I haven't spoken with Andrew. Perhaps we should simply ask in linux-kernel. I am just trying to raise awareness about a potential problem. The lazy and easy way would be for me to add the warnings to Walways-true and get the patch accepted. [1] http://gcc.gnu.org/ml/gcc/2003-10/msg00414.html [2] http://gcc.gnu.org/ml/gcc/2003-10/msg00419.html [3] http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00972.html [4] http://lkml.org/lkml/2006/11/28/206 [5] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12963 [6] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11856
