3 ms·

I don't see any warnings when compiling "if (1 && (i = 2)) {...}", but there is an warning when compiling "if (i = 2) {...}". This is using gcc 4.7.2 with -Wall

• acdha 13y ago
  Both gcc and clang appear to lack any way to generate a warning in the first case. Something like splint (http://www.splint.org http://www.splint.org) does, which is a good argument for including that into a C developer's workflow.
  • deleted 13y ago
    [deleted]
  • twoodfin 13y ago
    clang and gcc don't warn on this because real large codebases have an (unfortunate?) number of assignments inside boolean expressions. Most of them are intentional and at least some significant fraction are correct. Taking advantage of assignment-as-an-expression is idiomatic in a fair amount of code I've seen, at least. Stuff like: /* check_something returns non-zero on error */ if (need_to_check && (status = check_something())) { handle_error(status); } The clang and gcc folk tend to avoid adding default (or even -Weverything) warnings that will trigger on entirely valid, at least marginally common code, even if the style choice is problematic.
    • acdha 13y ago
      > clang and gcc don't warn on this because real large codebases have an (unfortunate?) number of assignments inside boolean expressions Definitely. I personally find that style bad because it's concealed a far number of bugs in the past (either things like the =/== confusion or simply logic errors when the line became long enough that scanning it is non-trivial) but the only way that could fly for a compiler would be as a flag or pragma allowing you to opt-in for valid-but-discouraged style warnings and that's served well enough by existing linters that standardization isn't worth the cost of moving it into a compiler.