All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: 2.6.38 nfsd bugfixes
Date: Wed, 16 Feb 2011 23:51:26 -0500	[thread overview]
Message-ID: <20110217045125.GI14534@fieldses.org> (raw)
In-Reply-To: <AANLkTikeK77v7y346-OX9dvufJSjbJ7qQSpJc4C3wLrZ@mail.gmail.com>

On Wed, Feb 16, 2011 at 08:32:06PM -0800, Linus Torvalds wrote:
> On Wed, Feb 16, 2011 at 8:25 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
> > -               if ((host_err = nfsd_map_name_to_uid(argp->rqstp, buf, dummy32, &iattr->ia_uid)))
> > -                       goto out_nfserr;
> > +               if ((status = nfsd_map_name_to_uid(argp->rqstp, buf, dummy32, &iattr->ia_uid)))
> > +                       return status;
> 
> Btw, can we please just agree to not doing those idiotic double parenthesis?

Fine by me; I don't write new code that way.

I already committed it like that, so would rather just do any cleanup as
another patch for the next merge window; but let me know what you want.

--b.

> 
> There is a really trivial solution to the gcc warning - write your
> code like a sane person, instead of some ex-LISP hacker that has
> withdrawal symptoms. IOW, the above should be written as
> 
>   status = nfsd_map_name_to_uid(argp->rqstp, buf, dummy32, &iattr->ia_uid);
>   if (status)
>     return status;
> 
> which is a hell of a lot more readable, no?
> 
> There is never any real excuse to put an assignment inside a regular
> if-statement.
> 
> Inside a while/for loop? Sure. There are real syntactic reasons for
> doing things like
> 
>    while ((c = getchar()) != EOF) {
>    }
> 
> that actually make the code better and denser and avoid extra control
> flow crap or duplicate code.
> 
> Inside a macro expansion? Again, there may be good reasons to try to
> make it a single statement.
> 
> But a simple if-statement? There just isn't any reason for it, since
> the obvious thing is to just write it as two separate statements: the
> assignment, and the if-statement. So why do it and make the code
> uglier and harder to parse?
> 
>                                    Linus

  reply	other threads:[~2011-02-17  4:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-15 18:59 2.6.38 nfsd bugfixes J. Bruce Fields
2011-02-17  4:25 ` J. Bruce Fields
2011-02-17  4:32   ` Linus Torvalds
2011-02-17  4:51     ` J. Bruce Fields [this message]
2011-02-17  5:54       ` Linus Torvalds
2011-02-18 19:27         ` J. Bruce Fields

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110217045125.GI14534@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.