Both gcc and clang appear to lack any way to generate a warning in the first case. Something like splint (http://www.splint.org) does, which is a good argument for including that into a C developer's workflow.

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.

> 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.