> if (uid = NULL) { // Check if root

That's not the same class of error, since here a programmer can see the issue by simple inspection.

> or #include anything with a #DEFINE

This one perhaps is closer to the mark, although not based on unicode.

To me it's the same class of error which is convincing humans and other automated tests that your code is OK when it isn't.

I dealt with a bug that only appeared in release builds, and never in debug. The offending code looked roughly like this:

  if (blah)
    #ifdef DEBUG
    baz();
    #endif
  bar();

The systemic problem was it was a project created by interns, and they'd review each others code. By the time the bug got to me the interns had left and a Sr Dev had spent a day looking for the bug. It took me an hour to find it. In isolation its easy to see but in the mess of all the other code, you really have to look for these things.

Well, if you generalize the statement enough, indeed it's the same class of issue.

In the situation you described:

* you have a fairly easy way to detect the problem

* the interns still have plausible deniability as to whether they intended to leave a defect or not

The discussed problem with unicode is clearly meant to be used as an exploit, its likelihood of occurring by accident seems very close to zero.

Rust doesn't allow assignment in conditionals.

https://locka99.gitbooks.io/a-guide-to-porting-c-to-rust/con...

It does, in fact the article you posted, shows you exactly when rust allows assignment in conditionals.

As long as you're initializing a variable, it's allowed, if you're not initializing you'll have to use a block expression.

Should have just used this sentence - which also directly covers parent's case.

"Rust does not allow assignment within simple expressions so they will fail to compile. This is done to prevent subtle errors with = being used instead of ==."

Better?

Those are all detectable by a programmer's eyes. Unicode attacks are not.