3 ms·

Doesn't compiler complain about assignment in condition?

by lcedp 13y ago

duskwuff 13y ago
Only when unparenthesized (e.g, if (x = 0) { ... }, but not if ((x = 0)) { ... }). And the author of this mysterious bit of code has helpfully thrown some parentheses around the assignment...
8_hours_ago 13y ago
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.

Doesn't compiler complain about assignment in condition?

by lcedp 13y ago

Doesn't compiler complain about assignment in condition?

Only when unparenthesized (e.g, if (x = 0) { ... }, but not if ((x = 0)) { ... }). And the author of this mysterious bit of code has helpfully thrown some parentheses around the assignment...

8_hours_ago 13y ago

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.