And I forgot to ask about kw_sym. "kw_sym: FROM_HEX" definition is not needed? To provide fallback for someone using such name in config already.
On Fri, Aug 25, 2023 at 3:55 AM Alexander Zubkov <[email protected]> wrote: > > Hi, > > Good news, thanks! > > On Thu, Aug 24, 2023 at 7:11 PM Ondrej Zajicek <[email protected]> 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: [email protected]) > > OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) > > "To err is human -- to blame it on a computer is even more so."
