[PATCH] adding custom options in radv protocol, strict ipv6 regex

[Alexander Zubkov]

Hello!

On Sat, Jun 24, 2023 at 3:30 PM Maria Matejka <maria.matejka at nic.cz> wrote:
>
> Hello!
>
> On 6/24/23 15:13, Ondrej Zajicek wrote:
>
> On Thu, Jun 15, 2023 at 03:57:10AM +0200, Alexander Zubkov wrote:
>
> Also, I think that the current realization in bird relies on the fact
> that lexer would not have symbols parsed in advance, i.e. that further
> mentions of the keyword should return CF_SYM_KNOWN. But if it is not
> the case and the lexer parses forward for some reason (before the
> parser creates the symbol for the keyword) it would not return
> CF_SYM_KNOWN. I don't know the internals of the lexer and parser much,
> maybe it is impossible situation (parser does not backtrack, etc.).
> And there is no need to worry here.
>
> Yes, it is kind of strange, in long-term, it would make more sense to move all
> symbol processing from lexer to parser.
>
> I was moving the symbol processing from parser to lexer several years ago due to Bison limitations. Flex afaik guarantees that it only parses one token at a time. The Bison-Flex boundary is a nasty can of worms and I'm afraid that the best way to get rid of it is to get rid of it altogether. Yet for now, I'd prefer keeping it as is.

Yes, I see. There are two languages with different structure (config
and filter) in the same grammar. And that requires some tradeoffs to
be made, at least with its current parsing approach.

>
> BTW the new method-call code (branch mq-func-types) depends exactly on the fact that I can manipulate lexer state/context from parser immediately before parsing the following token.
>
> Maria
>
> --
> Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.