[GuB-42]

But that should be something the compiler could catch. The expression is always false and the condition would never be executed. You usually get a warning for that. And if the compiler doesn't, linters do.

This is a common mistake, and I believe most linters have rules for that. And I don't think there is any situation where there is a good reason for code like this to exist. Either the expression is wrong, or it doesn't belong in a "if". You may get stuff like that in legitimate code with macro expansion, but again, it is not the case here, and from my experience, you get a warning anyways.

[_notreallyme_]

You didn't get a warning for that in 2003... or maybe with the pedantic flag. And even if it were the case, it would have been drowned by all the other unfixed warnings...

The only people using linters at that time was because it was forced by regulation (like automotive, aeronautics, ...)

[rcxdude]

Even now, and I'm pretty sure back then, the relevant warning in GCC is suppressed if the assignment occurs in parentheses, like it did in the diff (clang I believe has the same behaviour). So you would likely need a static analysis tool to flag up the behaviour, and those are quite noisy at the best of times.

[diath]

The compiler does not, but tools like clang-tidy do, (bugprone-assignment-in-if-condition in clang-tidy) but that didn't exist back then.

[lelanthran]

> But that should be something the compiler could catch.

Today, certainly. My compiler even catches errors in the format strings to printf[1].

But back then? I doubt it, even with all the warnings turned up.

[1] Removing yet another common source of bugs.