On Mon, Aug 09, 2021 at 08:45:59PM +0200, Florian Westphal wrote: > Phil Sutter <phil@xxxxxx> 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
