hi there.

i just enabled -Wextra to catch broken if statements,
i.e. to enable warnings on:
           *   An empty body occurs in an if or else statement.

however this unfortunately triggers other warnings that i can't
reasonably get rid of. here's a test snippet:

============== test.c ==============
typedef enum { VAL0 = 0, VAL1 = 1, VAL2 = 2 } PositiveEnum;
int main (int argc, char *argv[])
{
  PositiveEnum ev = VAL1;
  unsigned int limit = VAL2;
  if (ev >= 0)
    {}
  if (ev <= limit)
    {}
  if (1)
    ;
  return 0;
}
============== test.c ==============

compiled as C code, this will produce (with a 4.2 snapshot):
$ gcc -Wall -Wextra -Wno-unused -x c test.c
test.c: In function 'main':
test.c:6: warning: comparison of unsigned expression >= 0 is always true
test.c:11: warning: empty body in an if-statement

and compiled as C++ code:
$ gcc -Wall -Wextra -Wno-unused -x c++ test.c
test.c: In function 'int main(int, char**)':
test.c:8: warning: comparison between signed and unsigned integer expressions
test.c:11: warning: empty body in an if-statement

that means, for a header file that is used for C and C++ code, i simply
can't avoid one of those enum signedness warnings. simply because the enum
is treated as unsigened in C and as signed in C++.

now, aparently the enum related signedness warnings are unconditionally
enabled by -Wextra, as is the if-related warnings, from the man-page:
        -Wextra
           [...] Print extra warning messages for these events:

        *   An unsigned value is compared against zero with < or >=.

        *   An empty body occurs in an if or else statement.

since the enum related signedness warnings are clearly bogus [1], i'd
like to request new warning options, that allow enabling/disabling of
the empty-body vs. unsigned-zero-cmp warnings independently. that way
i can preserve "empty body in an if-statement" while getting rid of the
useless enum comparison warnings.


[1] i'm aware that the enum signedness comparison warnings could be worked
    around by explicit casts or by adding a negative enum value. this would
    just create new problems though, because aside from worsen readability,
    casts tend to "blinden" the compiler with regards to whole classes of
    other bugs, and adding a dummy enum value would affect API and auto
    generated documentation.

---
ciaoTJ

Reply via email to