Like:

1). Have there been any other backdoors surreptitiously slipped in that nobody has noticed?

2). Is Linux Kernel really as secure as everyone thinks it is?

I'd spend more time scouring the code looking for other backdoors and securing those than worrying about a holy war on the merits of Yoda Comparisons [Which by the way I think suck. Use a compiler that errors out or warns on assignment found where comparison is expected, code is meant to be human readable, so make it so.]

The joy about Linux being open source is that you can get your fingers and minds in the code and even if Torvalds had put in a back door at the behest of some government entity or other, it wouldn't matter - you guys have the power (and ability) to close that door. So if I were you, I'd spend more time doing that and less time bitching about other coders' syntax preferences that may not match your own.

There are a number of ways to add entropy. I've used egd and haveged. Use them. It can't hurt.

I suppose you could not load microcode on boot. I've never tried.

This was done by going around the normal channels to get code into the kernel. Someone attacked the CVS server directly and modified the code: http://lkml.indiana.edu/hypermail/linux/kernel/0311.0/0621.h...

OTOH, I'm a pretty slow code reader and look at "pattern" and "flow" of code at least as much as I attempt to understand meaning. Probably why I'm so anal about style, indentation, and vertical white space.

   (0 == current->uid)

   (current->uid == 0) // or (current->uid = 0) in this case.

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

    if (foo = 0) ...

    warn.c:2: warning: suggest parentheses around assignment used as truth value

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.

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

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 value

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.

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.

I wonder why the decision was made in C to use '=' and '=='? I'm betting it has something to do with the laziness of the programmers :).

The reason I'm asking is, because I don't know if there's ever a case where you'd want to assign right inside the if-condition. Is there?

    if (Foo *foo = getFoo()) { // getFoo returns null if there is no foo
        // There is a foo
    }

Edit: Actually, forget I said this. It's a dumb statement. 'if(a = true)' would always pass, regardless of the value of 'a'.

I don't actually use C, although I know a few languages with C-like syntax (Java, JS, AS2.0) and I'm learning Go & planning to learn D.

This small change will be really helpful in all these languages. Even if I never make this error again it will help stop people who alter my code from making this error.

Perhaps they should teach it in more programming textbooks, as I've not come across it in anything from HeadFirst to online tutorials to Deitel & Deitel.

(I'll leave out the other warts of PHP since that's been discussed here and elsewhere ad nauseum)

It sacrifices readability. I'm sure there are tools (if not one can easily write one) that warn you for accidental assignment when comparison was meant instead.

Moreover, the (0 == a) trick only works for constants (which you can't assign values to, hence the compiler will complain), but not for variables. I.e. you can still do if (a = b) accidentally, when comparison was intended.

Using tools to find "errors" can be problematic. see, for example, the Debian random number bug. (https://www.schneier.com/blog/archives/2008/05/random_number...)

> These lines were removed because they caused the Valgrind and Purify tools to produce warnings about the use of uninitialized data in any code that was linked to OpenSSL.