From: Jiri Benc <jbenc@redhat.com>
To: David Laight <David.Laight@ACULAB.COM>
Cc: Paul Blakey <paulb@mellanox.com>,
Stephen Hemminger <stephen@networkplumber.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Jiri Pirko <jiri@mellanox.com>,
Or Gerlitz <ogerlitz@mellanox.com>, Roi Dayan <roid@mellanox.com>,
Simon Horman <simon.horman@netronome.com>
Subject: Re: [PATCH net-next V4] tc: flower: Refactor matching flags to be more user friendly
Date: Fri, 20 Jan 2017 17:41:14 +0100 [thread overview]
Message-ID: <20170120174114.183f6e81@griffin> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DB0268D18@AcuExch.aculab.com>
On Fri, 20 Jan 2017 12:27:42 +0000, David Laight wrote:
> Consider what happened with "no", "nofubar" and "nofubar_baz",
> all ought to be rejected.
Why? "no" translates to "", "nofubar" to "fubar", etc. And those will
be evaluated the same way as if they were supplied without the "no".
I don't see a problem with this.
> Actually using strncmp() is also overkill.
Why? It compares two bytes. There's an extra null at the end of the
"no" string but I wouldn't call that "overkill".
> Nothing wrong with:
> if (token[0] == 'n' && token[1] == 'o' && token[2]) {
Except that strncmp is easier to understand and cleaner.
> no = true;
> token += 2;
> if (token[0] == '_' && token[1])
> token++;
This doesn't make sense. The intent was not to allow both "nofrag" and
"no_frag". The code in the patch treats "no_frag" as invalid and that's
okay.
> ...
>
> or replace the last 3 lines with:
> token += 2 + (token[2] == '_' & token[3]);
That's horribly ugly. Anyone looking at this will spent 2 minutes
trying to untangle the code instead of the 2 seconds with the current
code. We're not trying to win the Obfuscated C Contest here.
Jiri
prev parent reply other threads:[~2017-01-20 16:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-19 14:17 [PATCH net-next V4] tc: flower: Refactor matching flags to be more user friendly Paul Blakey
2017-01-19 14:22 ` Jiri Benc
2017-01-19 14:29 ` Paul Blakey
2017-01-20 12:27 ` David Laight
2017-01-20 16:41 ` Jiri Benc [this message]
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=20170120174114.183f6e81@griffin \
--to=jbenc@redhat.com \
--cc=David.Laight@ACULAB.COM \
--cc=jiri@mellanox.com \
--cc=netdev@vger.kernel.org \
--cc=ogerlitz@mellanox.com \
--cc=paulb@mellanox.com \
--cc=roid@mellanox.com \
--cc=simon.horman@netronome.com \
--cc=stephen@networkplumber.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.