Re: Example / partial fix for printf with math expressions

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

Thanks for the builtin.c patch.  Just a couple of notes:

On Sat, Feb 24, 2024 at 6:40 AM Stephane Chazelas
<stephane@xxxxxxxxxxxx> wrote (with correction from a later message):
>
> The math parser seems to work OK with NULs at least in:
>
> $ typeset -A a
> $ let $'a[\0]++'

That's not exactly the math parser; mathparse() get as far as noticing
it's a parameter reference and then goes through
params.c:getnumvalue() which actually does the subscript parsing.
You're "cheating" with this construction (and of course "let" is doing
the metafication properly to pass the reference through).

> $ let $'b = (a = ##\0) + 32'; echo $a $b

For the ## operator the parse is reading just one byte, so you're
still not involving anything that might hit a nul-terminated string.

This is the math parser and only the math parser, but again with
proper metafication:

% let $'a\0b = 2'
zsh: bad math expression: illegal character: \M-C
% let $'ab \0 2'
zsh: bad math expression: illegal character: \M-C
% let $'ab \02'
zsh: bad math expression: illegal character: ^B
% let $'ab y\02'
zsh: bad math expression: operator expected at `y^B'
% let $'ab = \02'
zsh: bad math expression: operand expected at `^B'

I'm not sure it's actually very useful to display more than the first
character in the latter two cases, but we can try to improve what's
currently displayed in multibyte cases.

Compare math parser without metafication:

% a=42
% printf "%d\n" $'a\0b = 2'
42

This is what I meant by "stops at NUL".

> With and without your example patch applied however:
>
> $ printf '%d\n' $'a[\0]++'
> zsh: invalid subscript

That does demonstrate that the length is needed in bin_print() to
properly metafy the subscript, yes.