On Tue, Jun 27, 2023 at 2:13 AM Alexander Zubkov <green@qrator.net> wrote:
On Mon, Jun 26, 2023 at 5:54 PM Alexander Zubkov <green@qrator.net> wrote:
On Mon, Jun 26, 2023 at 5:43 PM Ondrej Zajicek <santiago@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@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@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."