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

[Alexander Zubkov]

On Fri, Jun 23, 2023, 18:30 Ondrej Zajicek <santiago at crfreenet.org> wrote:

> On Wed, Jun 14, 2023 at 12:40:47AM +0200, Alexander Zubkov wrote:
> > Hi,
> >
> > Please look at these patches:
> >
> > bytestring-hex-prefix.patch - syntax with "hex:" prefix
> > I allowed mixed colons with no-divider there, so hex:12:345678:90 is
> > allowed. As there is a distinguishing prefix here, this should not be
> > a problem.
> > Empty bytestrings are allowed too: "hex:"
>
> Hi
>
> Merged:
>
> https://gitlab.nic.cz/labs/bird/-/commit/65d6a525944faa3f77041419991d77106d8f0a0d
>
> I have mixed opinion on mixed colons here :-)
>
>
> > bytestring-hex-function.patch - function-like hex("...") syntax (on
> > top of the other patch)
> > It wasn't too complex, but you might have wanted to do it some other
> > way.
>
> Yes, the original idea there was to add bytestring as a data type, make
> hex() a regular (filter) function instead of special function-like
> syntax, and add equivalent of 'expr' grammar term for other data types.
>

I see. I think I can look into preparing a patch for that too.
But for such variant I would suggest using function names like
"from_hex/base64" instead of "hex/base64", or something including
bytestring reference: "bs_hex". Because the simple variants could be
misleading when used not only in the limited set of scopes. For example
they can be thought of converting to hex/base64 representation too. Or they
could collide with "hex" function to convert from string to int, which
someone would need to implement in the future.


>
> > I think this should be quite good too, the only problem with it
> > is inability to mix "hex" symbol with hex("...") bytestrings.
>
> This is an issue with any keyword, so not a big thing.
>

Yes. By the way what do you think about the patch that allows using
keywords and symbols together? Is it viable?


>
> > There probably was a mistake in nest/config.Y with missing "|" here:
> > "kw_sym: MIN MAX ;"
>
> You are right there.
>
>
> > I also enabled TEXT literals to be multiline. Didn't know it was not
> > allowed already, so I think it should not break things, but allows to
> > be more flexible with binary strings.
>
> That is probably right.
>
>
> --
> Elen sila lumenn' omentielvo
>
> Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
> OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
> "To err is human -- to blame it on a computer is even more so."
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20230624/5b04fdd4/attachment.htm>