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

[Alexander Zubkov]

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:"

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. I think this should be quite good too, the only problem with it
is inability to mix "hex" symbol with hex("...") bytestrings.
I parse string in two steps. First to know the length of a binary
output. Current hex realization does the same anyway. I made a
separate function for it to reuse it for "classic" bytestrings and for
function-like syntax.
It ignores all non-alphanumeric symbols and requires that each byte
symbols go in pairs without delimiters.
I added a HEX keyword and added it to kw_sym, but this solution does
not allow to mix "hex" symbol and hex("...") bytestring in the same
config.
There probably was a mistake in nest/config.Y with missing "|" here:
"kw_sym: MIN MAX ;"
There is a "TODO" in the heading of strtobin.c, don't know what is
your policy regarding that. The code is still based on the current
BYTESTRING parser.
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.

On Tue, Jun 13, 2023 at 6:37 PM Ondrej Zajicek <santiago at crfreenet.org> wrote:
>
> On Tue, Jun 13, 2023 at 05:34:18PM +0200, Alexander Zubkov wrote:
> > On Tue, Jun 13, 2023, 16:07 Ondrej Zajicek <santiago at crfreenet.org> wrote:
> >
> > > We agreed on keeping existing format for suffiently long hex bytestrings,
> > > using hex: prefix for bytestrings of any length, and adding hex("...") /
> > > base64("...") as ordinary expressions.
> >
> > Hi,
> >
> > So full house. :) I can try to implement it. Do you need a hand?
>
> If you implement hex: prefix, we could easily merge that. The
> hex("...") / base64("...") is not priority and would require some
> nontrivial changes to be done properly.
>
> --
> 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 --------------
A non-text attachment was scrubbed...
Name: bytestring-hex-prefix.patch
Type: text/x-patch
Size: 967 bytes
Desc: not available
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20230614/bdc713a6/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bytestring-hex-function.patch
Type: text/x-patch
Size: 7585 bytes
Desc: not available
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20230614/bdc713a6/attachment-0001.bin>