Hacker News new | ask | show | jobs
by harrytuttle 4649 days ago
Huh?

   $ 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
Nope, no warnings there.
2 comments

I believe they mean that

    if (foo = 0) ...
generates a warning like this:

    warn.c:2: warning: suggest parentheses around assignment used as truth value
which you should be paying attention to, in favour of yoda-comparisons in this particular holy war :)
The code in question (see the LWN link elsewhere in this discussion) actually had parens around the expression (in a context where they looked "normal") and wouldn't have generated a warning.

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.

I would but if you see the rest of the thread, my gcc isn't raising this as a warning!

That in itself is sign that a mistake can be made without noticing.

Right, but if you compile with warnings as errors, then assignment within a condition won't compile, which prevents the issue.

I'd much rather go that way than write code that reads less like a human wrote it.

What compiler flag is that? Genuinely interested. Wall,pedantic,ansi don't trigger it. I've tried the following and I don't get a warning or error:

   $ 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
GCC version: gcc version 4.7.2 (Debian 4.7.2-5)

  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 value
Doesn't do that for me - what GCC ver and environment. Very odd! Digging in docs. Thanks for info.
It's some old-ish Debian on x86. GCC is 4.3.2.

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

Thanks. I think this must be a config issue on this box. It makes me wonder what other warnings it is not telling me about.
Notice that you cat test2.c and then compile test.c.
Well spotted! Thanks for pointing this out!

I will now go and hit myself with a LART for a bit to remember not to do that again.

However the same issue happens in a lot of C-like languages, and not all of them have compilers that inform you of errors. But the habit works in all of them.

There are two different ways to catch this class of bug. Both have value.