From: "matt.smillie@..." <matt.smillie@...>
Date: 2006-02-20T22:53:31+09:00
Subject: Re: If statement and if modifier not equivalent?

Which makes the assignment a side-effect of the conditional, and
depending on the context can be an excellent example of bad
side-effects, particularly from a software-engineering point of view,
where the code has to be maintained over any sort of time, by a team.

I think of it as the imperative corollary to duck-typing: if it looks
like a duck and sounds like a duck, it should *be* a duck.

There's a great public example of where this technique can break down
from an attempted hack on the linux kernal a couple of years ago.  It's
worth noting that it was only caught because of 1) very tight, very
paranoid peer review, and 2) the secure nature of the project.  It
would have gone through unnoticed virtually anywhere else.  In my past
life doing telecoms programming, I can remember this exact pattern
being responsible for bringing down a good portion of the US East
Coast's 1-800 (and 900, etc) phone numbers.

To each their own, and if it's code for your own use it's unlikely to
matter, but assignment-as-conditional really, really smells bad to me.

http://kerneltrap.org/node/1584

> +       if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
> +                       retval = -EINVAL;

Associated commentary:

> > Setting current->uid to zero when options __WCLONE and __WALL are set?  The
> > retval is dead code because of the next line, but it looks like an attempt
> > to backdoor the kernel, does it not?

> It sure does.  Note "current->uid = 0", not "current->uid == 0".
> Good eyes, I missed that.  This function is sys_wait4() so by passing in
> __WCLONE|__WALL you are root.  How nice.