Re: [nft PATCH RFC] scanner: nat: Move to own scope

[Phil Sutter <phil@nwl.cc>]

On Mon, Aug 09, 2021 at 08:45:59PM +0200, Florian Westphal wrote:
> Phil Sutter <phil@nwl.cc> wrote:
> > > So, it is in IP scope, sees 'prefix' (which will be STRING as the
> > > PREFIX scan rule is off) and that ends up in a parser error due to lack
> > > of a 'IP STRING' rule.
> > 
> > OK, thanks. So does this mean we won't ever be able to move keywords
> > opening a statement or expression out of INIT scope or is my case a
> > special one?
> 
> We can move them out of INIT scope, but only if they remain within
> the same scope.
> 
> For example, you could create a 'rule scope' or 'expression scope'
> that contains all tokens (ip, tcp, etc.) that start a new expression.

Ah, OK!

> I did not do this because there are too many cases where expressions are
> permitted outside of rule scope, e.g. in set definitions (key, elements
> ...)
> 
> > To clarify, what I have in mind is a sample rule 'ip id 1 tcp dport 1'
> > where 'tcp' must either be in INIT scope or part of SC_IP. 
> 
> IP and TCP need to be in the same scope (e.g. INIT).
> 
> In the given example I suspect that TCP doesn't have to be in SC_IP
> scope since 'ip id 1' is a full expression and scope closure happens
> before next token gets scanned.

Now I got it: The problem with nat_stmt is that 'snat ip' may either be
'SNAT nf_key_proto' or 'SNAT stmt_expr' and bison carries on until it's
clear. I missed the fact that stmt_expr is allowed in nat_stmt_args.

Thanks for the clarification! Maybe one day I'll finally understand how
bison really works. %)

Cheers, Phil