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

[Alexander Zubkov]

On Tue, Jun 27, 2023 at 2:13 AM Alexander Zubkov <green at qrator.net> wrote:
>
> On Mon, Jun 26, 2023 at 5:54 PM Alexander Zubkov <green at qrator.net> wrote:
> >
> > On Mon, Jun 26, 2023 at 5:43 PM Ondrej Zajicek <santiago at crfreenet.org> wrote:
> > >
> > > On Mon, Jun 26, 2023 at 03:24:47AM +0200, Alexander Zubkov wrote:
> > > > On Sat, Jun 24, 2023 at 3:16 PM Ondrej Zajicek <santiago at crfreenet.org> wrote:
> > > > >
> > > > > On Sat, Jun 24, 2023 at 02:20:03AM +0200, Alexander Zubkov wrote:
> > > > > > > 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.
> > > > > > 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.
> > > > >
> > > > > Yes, that is true.
> > > > >
> > > > > You can try it if you are brave enough to add new f_val type.
> > > >
> > > > Take a look at the patch, please. Waiting for the critics and
> > > > improvement suggestions.
> > >
> > > Hi
> > >
> > > It looks pretty good. First, could you split it to at least four patches?
> >
> > Sure. I'll provide split patches later.
> >
> > >
> > > 1) unrelated changes, like the newline-in-string-constant
> > > 2) preparatory changes (functions in lib/bytestring.c, change to BYTESTRING lexer)
> > > 3) adding bytestring type to filter code (including FI_FROM_HEX inst)
>
> Added patches up to this point. There are also some fixes and
> modification. For example, I noted that 'bytestring' symbol for the
> type name conflicts with lexer's BYTESTRING id. So I had to rename
> lexer's BYTESTRING to BYTETEXT (like it is done for strings).
> For the following patches it is better to decide the structure of the
> new *eval* functions.
>
> > > 4) change to parser related to f_eval_val(), bytestring nonterminal and so on.

Final patches to modify current f_eval_int() to generic approach. And
for nonterminal bytestring.
Again, waiting for comments/suggestions. Also feel free, of course, to
fix naming/etc when applying.
Next, I will be able to move forward with patches to the documentation.

> > >
> > > Some more comments:
> > >
> > > > It was needed to add another function like f_eval_int(), so I decided
> > > > to do some more generic approach and replaced all occurences of
> > > > f_eval_int() with it.
> > >
> > > That is good approach, although it would be probably better to call this
> > > function like cf_eval(), associated macro as cf_eval_val, and keep some
> > > inline functions like cf_eval_int(), cf_eval_bs() and so on.
> > >
> > > Or perhaps cf_eval() could return f_val as return value, and have
> > > shorthand functions like:
> > >
> > > static inline cf_eval_int(..) { return cf_eval(.., T_INT).i; }
>
> I actually tried first to return the struct instead of modifying it by
> a reference. But for that we need to have "struct f_val" known in
> filter/filter.h, which is defined in filter/data.h. But that causes
> some circular dependencies problem. I didn't dig deep into it, but
> maybe it is possible to solve the conflict in a clean way.

Looked at it again. It seems safe to include filter/data.h into
filter/filter.h. I probably had problems when trying to incude it
somewhere else, until it all finalized into filter.h

>
> > >
> > > I will give more comments later.
> > >
> > > --
> > > 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: 0005-Conf-use-more-generic-approach-for-intra-config-expr.patch
Type: text/x-patch
Size: 5473 bytes
Desc: not available
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20230629/7940d0a4/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0006-Conf-use-nonterminal-bytestring-instead-of-BYTETEXT.patch
Type: text/x-patch
Size: 3898 bytes
Desc: not available
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20230629/7940d0a4/attachment-0001.bin>