Hi, Good news, thanks!
On Thu, Aug 24, 2023 at 7:11 PM Ondrej Zajicek <santi...@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: santi...@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."
