Re: segfault w/ localvar_inherit and associative array insert

[Chet Ramey]

On 7/29/18 10:26 PM, Grisha Levit wrote:
> Though my motivation in reporting this was to point out the segfault, I'm a
> bit confused by why compound assignment should be an error here.
> 
>> Bash is consistent in defaulting to indexed array variables when you don't
>> specify -A and assign a value using the compound assignment syntax.
> 
> Since localvar_inherit is new behavior anyway, I'm not sure why the above must
> be the controlling default. I think a less surprising-to-the-user default
> might be "when this option is set, Bash consistently inherits the
> previous-scope variable's value/attributes before performing any new
> value/attribute modifications".

I don't think that we should use this as a way to change a variable's
type, since bash doesn't allow that in other contexts.

The tendency to mix types and attributes is something that should have
been different from the start, but we're stuck with what we have.

> In the alternative, it seems that Bash should be consistent in also
> defaulting to indexed arrays in the case of `array[subscript]' assignments
> with no -A specified?

Ah, yes, this case. The current behavior is heavily influenced by the
contents of this bug-bash discussion:

http://lists.gnu.org/archive/html/bug-bash/2014-12/msg00028.html

There's code in there that accepts this based on whether or not the
variable exists as an array and depends on the array type.

> ----
> 
>> So you create a local indexed array variable, and when you attempt to
>> inherit the value from a global associative array before performing any
>> specified assignment, you should either ignore the inherited value or
>> throw an error.

I agree that the documentation needs to be more specific about not allowing
this to change a variable's type, even though types are expressed as
attributes.

> 
> I feel like this doesn't seem very apparent from the documentation (though
> it's not strictly contradictory, the step where we first check the RHS to see
> if it is a compound array assignment seems surprising):

We have to know this all the way back at the parser stage. We know whether
or not this is an argument to `declare', and enforce the basic equivalence
of
        declare a=(1 2 3)
        declare -a a=(1 2 3)
        declare -a a; a=(1 2 3)

to satisfy the requirements placed on so-called `declaration utilities' and
the expansions their arguments undergo. The defaulting to indexed arrays is
due to backwards compatibility -- indexed arrays came first.


> There's also an issue that only a value of a matching type is inherited and
> the usual scalar-to-array[0] conversion is not performed. 

Yep, this was an omission that I've since fixed.

> Maybe I'm missing the intended use of the option but based on the description
> in the man page, I guess I'm expecting `declare var' with localvar_inherit to
> be roughly the same as `eval $(declare -p var 2>/dev/null); declare var'
> without it (except for namerefs). Is there maybe a use case for the
> differences in behavior?

I see the most common use case as inheriting values for variables of the
same type, and for that, non-array variables. If we are not restricting it
to variables of the same type, it should align with `type conversion'
behavior in other contexts.

> 
> As a side note: I wonder if this functionality, regardless or edge case
> handling, would be more useful as an option supplied to `declare' and so
> applied explicitly so specific variables, rather than a global shell option.

There is some skeletal support for that, and kre has certainly asked me to
add options to do it, but I haven't done that part yet.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/