On 2/7/24 2:23 AM, Grisha Levit wrote:
If a single declare command both sets and unsets the array or assoc attribute for an existing scalar variable, the `value' member of the SHELL_VAR is assigned an ARRAY* or HASH_TABLE* as appropriate, but later ends up treated as a char*:$ bash-asan -c 'X=Y; declare -A +A X; declare -p X' declare -- X=$'\200_\020\005\001' $ bash-lsan -c 'X=Y; declare -A +A X; X=(Z)' ERROR: LeakSanitizer: detected memory leaks Direct leak of 1024 byte(s) in 1 object(s) allocated from: #0 0xaaaada7342f8 in malloc #1 0xaaaada7f24d0 in xmalloc xmalloc.c:107:10 #2 0xaaaada7b81fc in hash_create hashlib.c:72:25 #3 0xaaaada7cc0c8 in convert_var_to_assoc arrayfunc.c:117:10 Maybe it would be appropriate to reject a request to turn off an attribute that is being turned on?
Only for indexed and associative arrays, since those are the attributes
that cause changes in the underlying value storage format. That's different
than turning the integer attribute on and off, for instance.
Should it be an actual error, or should the shell just cancel out the
attribute change requests and go on? What do folks think?
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
