Timur Tabi wrote:

On Mon, May 25, 2009 at 12:46 PM, Jon Smirl [off-list ref] wrote:

quoted

I just tried using this. The !rc has the effect of making the error
return be zero instead the normal not zero.

You're confused.  It's not a "return code", it's a return value.  I
guess I should have called the parameter "ret" instead of "rc", but I
didn't expect people to get confused.

'rc' is the value of the expression when the loop terminates.  That's
what makes the most sense, because the developer will want to know
what that value is.  If you're expression happens to rely on negative
logic (e.g. wait until a bit is cleared), then of course it's going to
appear "backwards" when you test it.

I've just been going through some hassles associated with wait_event
variants and their return codes.

Eg. wait_event_interruptible()'s return value is documented as; "The
function will return -ERESTARTSYS if it was interrupted by a signal and
0 if @condition evaluated to true." And wait_event_timeout()'s return
value is; "The function returns 0 if the @timeout elapsed, and the
remaining jiffies if the condition evaluated to true before the timeout
elapsed."

In all cases it seems, they don't return the what the expression
evaluates to, but instead return an indication about the wait outcome.
This is why I've taken to doing things like;
   wait_event_***(queue, !(ret = try_something()));

So from this user's perspective (FWIW), it would come as a surprise if
the return value reflected the evaluated expression rather than what
happened w.r.t. the spin/timeout.

Cheers,
Geoff