From: Phil Sutter <phil@nwl.cc>
To: Daniel Borkmann <daniel@iogearbox.net>
Cc: Stephen Hemminger <stephen@networkplumber.org>, netdev@vger.kernel.org
Subject: Re: [iproute PATCH] lib/bpf: Fix bytecode-file parsing
Date: Wed, 30 Aug 2017 16:11:56 +0200 [thread overview]
Message-ID: <20170830141155.GH20614@orbyte.nwl.cc> (raw)
In-Reply-To: <59A6C377.90705@iogearbox.net>
Hi Daniel,
On Wed, Aug 30, 2017 at 03:53:59PM +0200, Daniel Borkmann wrote:
> On 08/29/2017 05:09 PM, Phil Sutter wrote:
[...]
> > @@ -228,18 +229,20 @@ static int bpf_parse_string(char *arg, bool from_file, __u16 *bpf_len,
> > case '\n':
> > if (c_prev != ',')
> > *(pos++) = ',';
> > + c_prev = ',';
> > break;
> > case ' ':
> > case '\t':
> > if (c_prev != ' ')
> > *(pos++) = c;
> > + c_prev = ' ';
> > break;
> > default:
> > *(pos++) = c;
> > + c_prev = c;
> > }
> > if (pos - tmp_string == tmp_len)
> > break;
> > - c_prev = c;
>
> I don't really have a strong opinion on this, but the logic for
> normalizing here is getting a bit convoluted. Is your use case
> for making the parser more robust mainly so you can just use the
> -ddd output from tcpdump for cBPF w/o piping through tr? But even
> that shouldn't give multiple empty lines afaik, no?
Well, using tcpdump output was functional before already. I just noticed
that if I add an empty line to the end of bytecode-file, it will fail
and I didn't like that. Then while searching for the EOF issue, I
noticed that the parser logic above is a bit faulty in that it will
treat different characters equally but doesn't make sure c_prev will be
assigned only one of them. So apart from the added robustness, it really
fixes an inconsistency in the parsing logic.
Cheers, Phil
next prev parent reply other threads:[~2017-08-30 14:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-29 15:09 [iproute PATCH] lib/bpf: Fix bytecode-file parsing Phil Sutter
2017-08-30 13:53 ` Daniel Borkmann
2017-08-30 14:11 ` Phil Sutter [this message]
2017-09-01 19:13 ` Daniel Borkmann
2017-09-04 19:09 ` Stephen Hemminger
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=20170830141155.GH20614@orbyte.nwl.cc \
--to=phil@nwl.cc \
--cc=daniel@iogearbox.net \
--cc=netdev@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).