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

Maria Matejka maria.matejka at nic.cz
Sat Jun 24 15:30:03 CEST 2023


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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20230624/187e8960/attachment.htm>


More information about the Bird-users mailing list