Hi,
On Fri, Feb 12, 2021 at 01:20:07PM +0100, Florian Westphal wrote:
> Phil Sutter <phil@xxxxxx> wrote:
> > I didn't find a better way to conditionally parse two following args as
> > strings instead of just a single one. Basically I miss an explicit end
> > condition from which to call BEGIN(0).
>
> Yes, thats part of the problem.
>
> > > Seems we need allow "{" for "*" and then count the {} nests so
> > > we can pop off a scanner state stack once we make it back to the
> > > same } level that we had at the last state switch.
> >
> > What is the problem?
>
> Detect when we need to exit the current start condition.
I explored my approach further but ended up in an ugly situation due to
the use of 'set' keyword in rules: My code is not context-aware, so upon
recognizing 'set' keyword it switches to spec-condition. I can't simply
detect preceding command-keywords due to them being implicit in nested
notation.
> We may not even be able to do BEGIN(0) if we have multiple, nested
> start conditionals. flex supports start condition stacks, but that
> still leaves the exit/closure issue.
>
> Example:
>
> table chain {
> chain bla { /* should start to recognize rules, but
> we did not see 'rule' keyword */
My code worked with this after enabling detection of '{' in all
conditions and making it call BEGIN(0) (regardless of nspec value).
> ip saddr { ... } /* can't exit rule start condition on } ... */
Maybe we could track nesting block depth in a simple counter?
> ip daddr { ... }
> } /* should disable rule keywords again */
>
> chain dynamic { /* so 'dynamic' is a string here ... */
> }
> }
>
> I don't see a solution, perhaps add dummy bison rule(s)
> to explicitly signal closure of e.g. a rule context?
We can't influence start conditions from within bison (if that's what
you had in mind). All we can do is try make flex aware of the current
input context. For instance, detect 'table' followed by '{' to open
"table definition context" and start tracking braces to detect its end.
Though after all I think your assessment of all this being "fragile" is
appropriate. :/
Cheers, Phil
