Sure, if you are in habit of releasing code that compiles with warnings.
This sort of pointless code twisting is intensely annoying. It solves a rare problem with a wrong tool and in a very intrusive way.
Zero is constant. You compare to it.
$ cat test.c
int main(int argc, char *argv[]) {
if (0 == argc)
return 1;
return 0;
}
$ CFLAGS="-Wall -ansi -pedantic" make test
cc -Wall -ansi -pedantic test.c -o test
I'd much rather go that way than write code that reads less like a human wrote it.
$ cat test2.c
int main(int argc, char *argv[]) {
if (argc = 0)
return 1;
return 0;
}
$ make test
cc -Wall -ansi -pedantic test.c -o test
huh@px:/tmp$ cat a.c
int main(int argc, char *argv[]) {
if (argc = 0)
return 1;
return 0;
}
huh@px:/tmp$ gcc -Wall a.c
a.c: In function 'main':
a.c:2: warning: suggest parentheses around assignment used as truth valueBut this is a such commonly-recognized pitfall that I actually don't know a single modern production compiler that does not generate this warning.
(edit) Just checked 4.7.1 and it generates the warning.
I will now go and hit myself with a LART for a bit to remember not to do that again.
There are two different ways to catch this class of bug. Both have value.
if (foo = 0) ...
warn.c:2: warning: suggest parentheses around assignment used as truth value
That in itself is sign that a mistake can be made without noticing.
That said, I agree with huhtenberg above that twisting the language conventions around to deal with this is never going to fix anything. Subtle code remains subtle in all languages, and subtle code is where security bugs lie. You can't fix "subtle" with a rulebook.