* [PATCH 1/2 nft] meta: remove line break when printing priority
@ 2014-02-13 11:41 Pablo Neira Ayuso
2014-02-13 11:41 ` [PATCH 2/2 nft] scanner: fix parsing of tc handle Pablo Neira Ayuso
0 siblings, 1 reply; 10+ messages in thread
From: Pablo Neira Ayuso @ 2014-02-13 11:41 UTC (permalink / raw)
To: netfilter-devel; +Cc: kaber
The line break is added after printing the rule.
---
src/meta.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/meta.c b/src/meta.c
index 0a3df39..af5c3f9 100644
--- a/src/meta.c
+++ b/src/meta.c
@@ -75,11 +75,11 @@ static void tchandle_type_print(const struct expr *expr)
printf("none\n");
default:
if (TC_H_MAJ(handle) == 0)
- printf(":%04x\n", TC_H_MIN(handle));
+ printf(":%04x", TC_H_MIN(handle));
else if (TC_H_MIN(handle) == 0)
- printf("%04x:\n", TC_H_MAJ(handle) >> 16);
+ printf("%04x:", TC_H_MAJ(handle) >> 16);
else {
- printf("%04x:%04x\n",
+ printf("%04x:%04x",
TC_H_MAJ(handle) >> 16, TC_H_MIN(handle));
}
break;
--
1.7.10.4
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH 2/2 nft] scanner: fix parsing of tc handle
2014-02-13 11:41 [PATCH 1/2 nft] meta: remove line break when printing priority Pablo Neira Ayuso
@ 2014-02-13 11:41 ` Pablo Neira Ayuso
2014-02-13 11:51 ` Patrick McHardy
0 siblings, 1 reply; 10+ messages in thread
From: Pablo Neira Ayuso @ 2014-02-13 11:41 UTC (permalink / raw)
To: netfilter-devel; +Cc: kaber
hexstring:hexstring
hexstring:
:hexstring
---
The spaces to separate the key and the action in dictionaries is very
important, otherwise (with this patch) the scanner misinterprets this.
# nft add filter input tcp dport vmap { 25:drop }
<cmdline>:1:41-43: Error: syntax error, unexpected string, expecting comma or '}'
add rule filter input tcp dport vmap { 25:drop }
^^^
I think we can just document this, I don't see any better solution for this
at this moment.
src/scanner.l | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/scanner.l b/src/scanner.l
index e4cb398..ea61fa0 100644
--- a/src/scanner.l
+++ b/src/scanner.l
@@ -109,7 +109,7 @@ digit [0-9]
hexdigit [0-9a-fA-F]
decstring {digit}+
hexstring 0[xX]{hexdigit}+
-range ({decstring}?:{decstring}?)
+priostring {hexdigit}{0,4}:{hexdigit}{0,4}
letter [a-zA-Z]
string ({letter})({letter}|{digit}|[/\-_\.])*
quotedstring \"[^"]*\"
@@ -447,6 +447,11 @@ addrstring ({macaddr}|{ip4addr}|{ip6addr})
return STRING;
}
+{priostring} {
+ yylval->string = xstrdup(yytext);
+ return STRING;
+ }
+
\\{newline} {
reset_pos(yyget_extra(yyscanner), yylloc);
}
--
1.7.10.4
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH 2/2 nft] scanner: fix parsing of tc handle
2014-02-13 11:41 ` [PATCH 2/2 nft] scanner: fix parsing of tc handle Pablo Neira Ayuso
@ 2014-02-13 11:51 ` Patrick McHardy
2014-02-13 13:01 ` Patrick McHardy
0 siblings, 1 reply; 10+ messages in thread
From: Patrick McHardy @ 2014-02-13 11:51 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: netfilter-devel
On Thu, Feb 13, 2014 at 12:41:12PM +0100, Pablo Neira Ayuso wrote:
> hexstring:hexstring
> hexstring:
> :hexstring
> ---
> The spaces to separate the key and the action in dictionaries is very
> important, otherwise (with this patch) the scanner misinterprets this.
>
> # nft add filter input tcp dport vmap { 25:drop }
> <cmdline>:1:41-43: Error: syntax error, unexpected string, expecting comma or '}'
> add rule filter input tcp dport vmap { 25:drop }
> ^^^
> I think we can just document this, I don't see any better solution for this
> at this moment.
Let me try if I can come up with something ...
>
> src/scanner.l | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/src/scanner.l b/src/scanner.l
> index e4cb398..ea61fa0 100644
> --- a/src/scanner.l
> +++ b/src/scanner.l
> @@ -109,7 +109,7 @@ digit [0-9]
> hexdigit [0-9a-fA-F]
> decstring {digit}+
> hexstring 0[xX]{hexdigit}+
> -range ({decstring}?:{decstring}?)
> +priostring {hexdigit}{0,4}:{hexdigit}{0,4}
> letter [a-zA-Z]
> string ({letter})({letter}|{digit}|[/\-_\.])*
> quotedstring \"[^"]*\"
> @@ -447,6 +447,11 @@ addrstring ({macaddr}|{ip4addr}|{ip6addr})
> return STRING;
> }
>
> +{priostring} {
> + yylval->string = xstrdup(yytext);
> + return STRING;
> + }
> +
> \\{newline} {
> reset_pos(yyget_extra(yyscanner), yylloc);
> }
> --
> 1.7.10.4
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 2/2 nft] scanner: fix parsing of tc handle
2014-02-13 11:51 ` Patrick McHardy
@ 2014-02-13 13:01 ` Patrick McHardy
2014-02-13 13:08 ` Mart Frauenlob
2014-02-13 13:31 ` Pablo Neira Ayuso
0 siblings, 2 replies; 10+ messages in thread
From: Patrick McHardy @ 2014-02-13 13:01 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: netfilter-devel
On Thu, Feb 13, 2014 at 11:51:12AM +0000, Patrick McHardy wrote:
> On Thu, Feb 13, 2014 at 12:41:12PM +0100, Pablo Neira Ayuso wrote:
> > hexstring:hexstring
> > hexstring:
> > :hexstring
> > ---
> > The spaces to separate the key and the action in dictionaries is very
> > important, otherwise (with this patch) the scanner misinterprets this.
> >
> > # nft add filter input tcp dport vmap { 25:drop }
> > <cmdline>:1:41-43: Error: syntax error, unexpected string, expecting comma or '}'
> > add rule filter input tcp dport vmap { 25:drop }
> > ^^^
> > I think we can just document this, I don't see any better solution for this
> > at this moment.
>
> Let me try if I can come up with something ...
I think we might be able to do something with flex "trailing contexts",
though I didn't manage to figure it out yet.
Generally it seems like using a ':' in maps might not be the best idea
after all, its used for too many other things already. This might be
the reason why I initially used =>, not sure anymore.
Is there a reasonable alternative to ':' with a single character?
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 2/2 nft] scanner: fix parsing of tc handle
2014-02-13 13:01 ` Patrick McHardy
@ 2014-02-13 13:08 ` Mart Frauenlob
2014-02-13 13:21 ` Patrick McHardy
2014-02-13 13:31 ` Pablo Neira Ayuso
1 sibling, 1 reply; 10+ messages in thread
From: Mart Frauenlob @ 2014-02-13 13:08 UTC (permalink / raw)
To: Patrick McHardy, Pablo Neira Ayuso; +Cc: netfilter-devel
On 13.02.2014 14:01, Patrick McHardy wrote:
...
> Generally it seems like using a ':' in maps might not be the best idea
> after all, its used for too many other things already. This might be
> the reason why I initially used =>, not sure anymore.
>
> Is there a reasonable alternative to ':' with a single character?
x = y or x=y sounds and looks very reasonable and fitting the case to
me, would it break something else?
Thanks
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 2/2 nft] scanner: fix parsing of tc handle
2014-02-13 13:08 ` Mart Frauenlob
@ 2014-02-13 13:21 ` Patrick McHardy
0 siblings, 0 replies; 10+ messages in thread
From: Patrick McHardy @ 2014-02-13 13:21 UTC (permalink / raw)
To: Mart Frauenlob; +Cc: Pablo Neira Ayuso, netfilter-devel
On Thu, Feb 13, 2014 at 02:08:17PM +0100, Mart Frauenlob wrote:
> On 13.02.2014 14:01, Patrick McHardy wrote:
> ...
>
> >Generally it seems like using a ':' in maps might not be the best idea
> >after all, its used for too many other things already. This might be
> >the reason why I initially used =>, not sure anymore.
> >
> >Is there a reasonable alternative to ':' with a single character?
>
> x = y or x=y sounds and looks very reasonable and fitting the case
> to me, would it break something else?
I've thought about this myself, it should prevent these problems, though
I actually don't like it very much. Just my taste though, I still hope
we can come up with something in the lexer.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 2/2 nft] scanner: fix parsing of tc handle
2014-02-13 13:01 ` Patrick McHardy
2014-02-13 13:08 ` Mart Frauenlob
@ 2014-02-13 13:31 ` Pablo Neira Ayuso
2014-02-13 13:36 ` Patrick McHardy
1 sibling, 1 reply; 10+ messages in thread
From: Pablo Neira Ayuso @ 2014-02-13 13:31 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netfilter-devel
On Thu, Feb 13, 2014 at 01:01:03PM +0000, Patrick McHardy wrote:
> On Thu, Feb 13, 2014 at 11:51:12AM +0000, Patrick McHardy wrote:
> > On Thu, Feb 13, 2014 at 12:41:12PM +0100, Pablo Neira Ayuso wrote:
> > > hexstring:hexstring
> > > hexstring:
> > > :hexstring
> > > ---
> > > The spaces to separate the key and the action in dictionaries is very
> > > important, otherwise (with this patch) the scanner misinterprets this.
> > >
> > > # nft add filter input tcp dport vmap { 25:drop }
> > > <cmdline>:1:41-43: Error: syntax error, unexpected string, expecting comma or '}'
> > > add rule filter input tcp dport vmap { 25:drop }
> > > ^^^
> > > I think we can just document this, I don't see any better solution for this
> > > at this moment.
> >
> > Let me try if I can come up with something ...
>
> I think we might be able to do something with flex "trailing contexts",
> though I didn't manage to figure it out yet.
>
> Generally it seems like using a ':' in maps might not be the best idea
> after all, its used for too many other things already. This might be
> the reason why I initially used =>, not sure anymore.
>
> Is there a reasonable alternative to ':' with a single character?
Everything seems pretty overloaded, and I still like that python uses
this for dictionaries.
I think even bash and gcc provide bad error reporting if one space is
missing in a for/while statement or a missing bracket is left out.
Let's check if that trailing context can help us to fix it, if not,
just document it.
We can revisit the scanner/parser at some point. I checked antlr but I
don't think their C library API is very stable / ready for third party
project. But not now, we already have quite a lot of work in many
other fronts :)
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 2/2 nft] scanner: fix parsing of tc handle
2014-02-13 13:31 ` Pablo Neira Ayuso
@ 2014-02-13 13:36 ` Patrick McHardy
2014-02-13 14:17 ` Patrick McHardy
0 siblings, 1 reply; 10+ messages in thread
From: Patrick McHardy @ 2014-02-13 13:36 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: netfilter-devel
On Thu, Feb 13, 2014 at 02:31:37PM +0100, Pablo Neira Ayuso wrote:
> On Thu, Feb 13, 2014 at 01:01:03PM +0000, Patrick McHardy wrote:
> > On Thu, Feb 13, 2014 at 11:51:12AM +0000, Patrick McHardy wrote:
> >
> > I think we might be able to do something with flex "trailing contexts",
> > though I didn't manage to figure it out yet.
> >
> > Generally it seems like using a ':' in maps might not be the best idea
> > after all, its used for too many other things already. This might be
> > the reason why I initially used =>, not sure anymore.
> >
> > Is there a reasonable alternative to ':' with a single character?
>
> Everything seems pretty overloaded, and I still like that python uses
> this for dictionaries.
I also thing this would be the nicest way to express this.
> I think even bash and gcc provide bad error reporting if one space is
> missing in a for/while statement or a missing bracket is left out.
>
> Let's check if that trailing context can help us to fix it, if not,
> just document it.
I think I almost got it using:
{priostring}/[ \t\n:] {
Only thing missing is EOF handling, IOW when the priostring is the last
expression on the command line (not in files) it fails.
I also changed priostring to:
priostring ({hexdigit}{1,4}:{hexdigit}{0,4})|({hexdigit}{0,4}:{hexdigit}{1,4})
since it otherwise also matches a single ':'. I'll try again later, have
to take care of other things first.
> We can revisit the scanner/parser at some point. I checked antlr but I
> don't think their C library API is very stable / ready for third party
> project. But not now, we already have quite a lot of work in many
> other fronts :)
Yeah, this is something for the future.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 2/2 nft] scanner: fix parsing of tc handle
2014-02-13 13:36 ` Patrick McHardy
@ 2014-02-13 14:17 ` Patrick McHardy
2014-02-14 10:59 ` Pablo Neira Ayuso
0 siblings, 1 reply; 10+ messages in thread
From: Patrick McHardy @ 2014-02-13 14:17 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: netfilter-devel
On Thu, Feb 13, 2014 at 01:36:38PM +0000, Patrick McHardy wrote:
> On Thu, Feb 13, 2014 at 02:31:37PM +0100, Pablo Neira Ayuso wrote:
> > On Thu, Feb 13, 2014 at 01:01:03PM +0000, Patrick McHardy wrote:
> > > On Thu, Feb 13, 2014 at 11:51:12AM +0000, Patrick McHardy wrote:
> > >
> > > I think we might be able to do something with flex "trailing contexts",
> > > though I didn't manage to figure it out yet.
> > >
> > > Generally it seems like using a ':' in maps might not be the best idea
> > > after all, its used for too many other things already. This might be
> > > the reason why I initially used =>, not sure anymore.
> > >
> > > Is there a reasonable alternative to ':' with a single character?
> >
> > Everything seems pretty overloaded, and I still like that python uses
> > this for dictionaries.
>
> I also thing this would be the nicest way to express this.
>
> > I think even bash and gcc provide bad error reporting if one space is
> > missing in a for/while statement or a missing bracket is left out.
> >
> > Let's check if that trailing context can help us to fix it, if not,
> > just document it.
>
> I think I almost got it using:
>
> {priostring}/[ \t\n:] {
>
> Only thing missing is EOF handling, IOW when the priostring is the last
> expression on the command line (not in files) it fails.
>
> I also changed priostring to:
>
> priostring ({hexdigit}{1,4}:{hexdigit}{0,4})|({hexdigit}{0,4}:{hexdigit}{1,4})
>
> since it otherwise also matches a single ':'. I'll try again later, have
> to take care of other things first.
This is what I'm currently testing. Seems to work alright, it even
recognizes
filter output meta priority { ffff:ffff:accept }
correctly.
diff --git a/src/erec.c b/src/erec.c
index 4930085..5bb8141 100644
--- a/src/erec.c
+++ b/src/erec.c
@@ -84,6 +84,7 @@ void erec_print(FILE *f, const struct error_record *erec)
case INDESC_BUFFER:
case INDESC_CLI:
line = indesc->data;
+ *strchrnul(line, '\n') = '\0';
break;
case INDESC_FILE:
memset(buf, 0, sizeof(buf));
diff --git a/src/main.c b/src/main.c
index 9d50577..56e2ecd 100644
--- a/src/main.c
+++ b/src/main.c
@@ -307,12 +307,13 @@ int main(int argc, char * const *argv)
for (len = 0, i = optind; i < argc; i++)
len += strlen(argv[i]) + strlen(" ");
- buf = xzalloc(len + 1);
+ buf = xzalloc(len + 2);
for (i = optind; i < argc; i++) {
strcat(buf, argv[i]);
if (i + 1 < argc)
strcat(buf, " ");
}
+ strcat(buf, "\n");
parser_init(&state, &msgs);
scanner = scanner_init(&state);
scanner_push_buffer(scanner, &indesc_cmdline, buf);
diff --git a/src/scanner.l b/src/scanner.l
index cd68534..07f0810 100644
--- a/src/scanner.l
+++ b/src/scanner.l
@@ -109,7 +109,7 @@ digit [0-9]
hexdigit [0-9a-fA-F]
decstring {digit}+
hexstring 0[xX]{hexdigit}+
-range ({decstring}?:{decstring}?)
+priostring ({hexdigit}{1,4}:{hexdigit}{0,4})|({hexdigit}{0,4}:{hexdigit}{1,4})
letter [a-zA-Z]
string ({letter})({letter}|{digit}|[/\-_\.])*
quotedstring \"[^"]*\"
@@ -449,6 +449,13 @@ addrstring ({macaddr}|{ip4addr}|{ip6addr})
return STRING;
}
+{priostring}/[ \t\n:] {
+ printf("priostring %s\n", yytext);
+ yylval->string = xstrdup(yytext);
+ return STRING;
+ }
+
+
\\{newline} {
reset_pos(yyget_extra(yyscanner), yylloc);
}
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH 2/2 nft] scanner: fix parsing of tc handle
2014-02-13 14:17 ` Patrick McHardy
@ 2014-02-14 10:59 ` Pablo Neira Ayuso
0 siblings, 0 replies; 10+ messages in thread
From: Pablo Neira Ayuso @ 2014-02-14 10:59 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netfilter-devel
On Thu, Feb 13, 2014 at 02:17:09PM +0000, Patrick McHardy wrote:
> On Thu, Feb 13, 2014 at 01:36:38PM +0000, Patrick McHardy wrote:
> > On Thu, Feb 13, 2014 at 02:31:37PM +0100, Pablo Neira Ayuso wrote:
> > > On Thu, Feb 13, 2014 at 01:01:03PM +0000, Patrick McHardy wrote:
> > > > On Thu, Feb 13, 2014 at 11:51:12AM +0000, Patrick McHardy wrote:
> > > >
> > > > I think we might be able to do something with flex "trailing contexts",
> > > > though I didn't manage to figure it out yet.
> > > >
> > > > Generally it seems like using a ':' in maps might not be the best idea
> > > > after all, its used for too many other things already. This might be
> > > > the reason why I initially used =>, not sure anymore.
> > > >
> > > > Is there a reasonable alternative to ':' with a single character?
> > >
> > > Everything seems pretty overloaded, and I still like that python uses
> > > this for dictionaries.
> >
> > I also thing this would be the nicest way to express this.
> >
> > > I think even bash and gcc provide bad error reporting if one space is
> > > missing in a for/while statement or a missing bracket is left out.
> > >
> > > Let's check if that trailing context can help us to fix it, if not,
> > > just document it.
> >
> > I think I almost got it using:
> >
> > {priostring}/[ \t\n:] {
> >
> > Only thing missing is EOF handling, IOW when the priostring is the last
> > expression on the command line (not in files) it fails.
> >
> > I also changed priostring to:
> >
> > priostring ({hexdigit}{1,4}:{hexdigit}{0,4})|({hexdigit}{0,4}:{hexdigit}{1,4})
> >
> > since it otherwise also matches a single ':'. I'll try again later, have
> > to take care of other things first.
>
> This is what I'm currently testing. Seems to work alright, it even
> recognizes
>
> filter output meta priority { ffff:ffff:accept }
>
> correctly.
This patch works here after some testing. Thanks Patrick!
> diff --git a/src/erec.c b/src/erec.c
> index 4930085..5bb8141 100644
> --- a/src/erec.c
> +++ b/src/erec.c
> @@ -84,6 +84,7 @@ void erec_print(FILE *f, const struct error_record *erec)
> case INDESC_BUFFER:
> case INDESC_CLI:
> line = indesc->data;
> + *strchrnul(line, '\n') = '\0';
> break;
> case INDESC_FILE:
> memset(buf, 0, sizeof(buf));
> diff --git a/src/main.c b/src/main.c
> index 9d50577..56e2ecd 100644
> --- a/src/main.c
> +++ b/src/main.c
> @@ -307,12 +307,13 @@ int main(int argc, char * const *argv)
> for (len = 0, i = optind; i < argc; i++)
> len += strlen(argv[i]) + strlen(" ");
>
> - buf = xzalloc(len + 1);
> + buf = xzalloc(len + 2);
> for (i = optind; i < argc; i++) {
> strcat(buf, argv[i]);
> if (i + 1 < argc)
> strcat(buf, " ");
> }
> + strcat(buf, "\n");
> parser_init(&state, &msgs);
> scanner = scanner_init(&state);
> scanner_push_buffer(scanner, &indesc_cmdline, buf);
> diff --git a/src/scanner.l b/src/scanner.l
> index cd68534..07f0810 100644
> --- a/src/scanner.l
> +++ b/src/scanner.l
> @@ -109,7 +109,7 @@ digit [0-9]
> hexdigit [0-9a-fA-F]
> decstring {digit}+
> hexstring 0[xX]{hexdigit}+
> -range ({decstring}?:{decstring}?)
> +priostring ({hexdigit}{1,4}:{hexdigit}{0,4})|({hexdigit}{0,4}:{hexdigit}{1,4})
> letter [a-zA-Z]
> string ({letter})({letter}|{digit}|[/\-_\.])*
> quotedstring \"[^"]*\"
> @@ -449,6 +449,13 @@ addrstring ({macaddr}|{ip4addr}|{ip6addr})
> return STRING;
> }
>
> +{priostring}/[ \t\n:] {
> + printf("priostring %s\n", yytext);
> + yylval->string = xstrdup(yytext);
> + return STRING;
> + }
> +
> +
> \\{newline} {
> reset_pos(yyget_extra(yyscanner), yylloc);
> }
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2014-02-14 10:59 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-02-13 11:41 [PATCH 1/2 nft] meta: remove line break when printing priority Pablo Neira Ayuso
2014-02-13 11:41 ` [PATCH 2/2 nft] scanner: fix parsing of tc handle Pablo Neira Ayuso
2014-02-13 11:51 ` Patrick McHardy
2014-02-13 13:01 ` Patrick McHardy
2014-02-13 13:08 ` Mart Frauenlob
2014-02-13 13:21 ` Patrick McHardy
2014-02-13 13:31 ` Pablo Neira Ayuso
2014-02-13 13:36 ` Patrick McHardy
2014-02-13 14:17 ` Patrick McHardy
2014-02-14 10:59 ` Pablo Neira Ayuso
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.