Re: Bug Report: Variable becomes unset without reason

[Mikael Magnusson <mikachu@xxxxxxxxx>]

On 8/14/19, Peter Stephenson <p.stephenson@xxxxxxxxxxx> wrote:
> On Wed, 2019-08-14 at 10:37 +0100, Stephane Chazelas wrote:
>> 2019-08-08 20:38:05 +0430, Aryn Starr:
>> Now, that being said, as discussed on U&L it looks like a bug
>> indeed and a shorter reproducer is:
>>
>> $ zsh -xc 'v=1; f() { local v; v=2 true; }; f; typeset -p v'
>> +zsh:1> v=1
>> +zsh:1> f
>> +f:0> local v
>> +f:0> v=2 +f:0> true
>> +zsh:1> typeset -p v
>> zsh:typeset:1: no such variable: v
>>
>> Most likely, that's the "v=2 true" (where "true" is a builtin) that ends
>> up
>> unsetting the "v" from the global scope.
>
> Yes, the saved version of "v" that we restore after the builtin is
> missing the pointer back to the version of v in the enclosing scope.  So
> it's not only not shown as set, it will leak memory.
>
> This simply preserves that pointer in the copy, but this assumes we've
> correctly blocked off the old parameter from being altered inside the
> function scope --- if we haven't that preserved old pointer is going to
> get us into trouble.  However, if we haven't that's already a bug, so
> this shouldn't make things worse.

This got me thinking about related stuff. I guess these results are
expected, maybe even at best unspecified?
% foo=initial; foo=bar printf -v foo hello; echo $foo
initial
% set hi; argv= set hello; echo $1
hi
% set a b c; argv= shift; echo $@
a b c
% a=1; a=5 typeset a=3 b=7; echo $a$b
17

-- 
Mikael Magnusson