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

[Alexander Zubkov]

Hi,

Good news, thanks!

On Thu, Aug 24, 2023 at 7:11 PM Ondrej Zajicek <santiago at crfreenet.org> wrote:
>
> On Thu, Jul 27, 2023 at 03:38:27PM +0200, Alexander Zubkov wrote:
> > Hi,
> >
> > Have you had a chance to look at all this?
>
> Hi
>
> Sorry for keeping you wait, i finally got to this patchset and merged it.

No problem, several days more and I would call it a birthday present. :)

> I did some changes:
>
> 1) Removal of support for multiline string literals - the patch is simple
> but it has an awkward consequence of making incomprehensible error messages
> for unterminated strings. We discussed that and decided to drop it.

OK. The idea was it could be possible, to insert long hexdumps as-is
or base64 outputs. So it seemed multiline strings is a good idea. But
yes, missing quote could lead to some fancy parsing. I also noticed I
missed "ifs->lino++; ..." there.

>
> 2) Refactor of bstrhextobin() and bstrbintohex() to be more generic and
> not depend bstrtobyte16(), which was removed. I never liked it anyway.
> Also, there is an explicit string of allowed delimiters in bstrhextobin(),
> for from_hex(), instead of ignoring everything that is not a letter.

OK. I also wanted to give a more freedom here to fomatting the source
string, because who knows what delimeters one would like to use, not
counting various types of spaces - '\t', '\n', etc. For example
current allowed delimeter set does not contain '.', which is used at
least for Cisco's MAC address notation: "0011.2233.4455". Also one
might want use various brackets to make his blob more human-readable.
But sure it can be started with a stricter variant and expanded later
if there is actual demand for it.

>
> 3) Change val_format() to not add 'hex:' prefix when printing bytestring.
> It offers human readable, but not necessary back-parsable form (i.e more
> like Scheme function 'display' than 'write'). That is consistent with its
> behavior for strings, where quotation marks are also not added.
>
> 4) Use different approach for bytestring or string argument for password
> keys, so the target expression can know which variant was used.
>
> For other details, see the commits.
>
> Thanks for the patchset. I especially like the cf_eval() / cf_eval_int()
> changes.

Thanks for reviewing and merging!

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