All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Chancellor <natechancellor@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Christian Brauner <christian.brauner@ubuntu.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] usercopy structs for v5.4-rc2
Date: Fri, 4 Oct 2019 12:43:30 -0700	[thread overview]
Message-ID: <20191004194330.GA1478788@archlinux-threadripper> (raw)
In-Reply-To: <CAHk-=whxf5HVdaXqL6RgHCLzb2LNn3U2n_x4GWQZroCC+evRoA@mail.gmail.com>

On Fri, Oct 04, 2019 at 10:53:41AM -0700, Linus Torvalds wrote:
> On Fri, Oct 4, 2019 at 3:42 AM Christian Brauner
> <christian.brauner@ubuntu.com> wrote:
> >
> >            The only separate fix we we had to apply
> > was for a warning by clang when building the tests for using the result of
> > an assignment as a condition without parantheses.
> 
> Hmm. That code is ugly, both before and after the fix.
> 
> This just doesn't make sense for so many reasons:
> 
>         if ((ret |= test(umem_src == NULL, "kmalloc failed")))
> 
> where the insanity comes from
> 
>  - why "|=" when you know that "ret" was zero before (and it had to
> be, for the test to make sense)
> 
>  - why do this as a single line anyway?
> 
>  - don't do the stupid "double parenthesis" to hide a warning. Make it
> use an actual comparison if you add a layer of parentheses.
> 
> So
> 
>         if ((x = y))
> 
> is *wrong*. I know the compiler suggests that, but the compiler is
> just being stupid, and the suggestion comes from people who don't have
> any taste.
> 
> If you want to test an assignment, you should just use
> 
>         if ((x = y) != 0)
> 
> instead, at which point it's not syntactic noise mind-games any more,
> but the parenthesis actually make sense.
> 
> However, you had no reason to use an assignment in the conditional in
> the first place.
> 
> IOW, the code should have just been
> 
>         ret = test(umem_src == NULL, "kmalloc failed");
>         if (ret) ...

Yes, I had this as the original fix but I tried to keep the same
intention as the original author. I should have gone with my gut. Sorry
for the ugliness, I'll try to be better in the future.

Cheers,
Nathan

  parent reply	other threads:[~2019-10-04 19:43 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-04 10:41 [GIT PULL] usercopy structs for v5.4-rc2 Christian Brauner
2019-10-04 17:53 ` Linus Torvalds
2019-10-04 19:07   ` Aleksa Sarai
2019-10-04 19:43   ` Nathan Chancellor [this message]
2019-10-07 13:11     ` David Laight
2019-10-10 15:15       ` Al Viro
2019-10-04 19:59   ` Christian Brauner
2019-10-04 18:25 ` pr-tracker-bot

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=20191004194330.GA1478788@archlinux-threadripper \
    --to=natechancellor@gmail.com \
    --cc=christian.brauner@ubuntu.com \
    --cc=linux-kernel@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.