Path: csiph.com!weretis.net!feeder8.news.weretis.net!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail
From: Binarus <lists@binarus.de>
Newsgroups: gnu.bash.bug
Subject: Incorrect / Inconsistent behavior with nameref assignments in functions
Date: Fri, 28 Aug 2020 10:56:34 +0200
Lines: 100
Approved: bug-bash@gnu.org
Message-ID: <mailman.1593.1598619823.2469.bug-bash@gnu.org>
References: <a20e4692-69b3-9836-4861-3e822e407ef7@binarus.de>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
To: bug-bash@gnu.org, bash@packages.debian.org
Envelope-to: bug-bash@gnu.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
Content-Language: en-US
Received-SPF: pass client-ip=144.76.90.229; envelope-from=lists@binarus.de; helo=odysseus.binarus.de
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Mailman-Approved-At: Fri, 28 Aug 2020 09:03:40 -0400
X-BeenThere: bug-bash@gnu.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Bug reports for the GNU Bourne Again SHell <bug-bash.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/bug-bash>
List-Post: <mailto:bug-bash@gnu.org>
List-Help: <mailto:bug-bash-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=subscribe>
X-Mailman-Original-Message-ID: <a20e4692-69b3-9836-4861-3e822e407ef7@binarus.de>
Xref: csiph.com gnu.bash.bug:16824

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR$
uname output: Linux cerberus 4.9.0-13-amd64 #1 SMP Debian 4.9.228-1
(2020-07-05) x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 4.4
Patch Level: 12
Release Status: release


Description:
------------

Under certain circumstances, assignments of namerefs to local variables
in functions behaves in a way which makes namerefs completely useless.
Furthermore, the behavior is not consistent.

The two scripts given below really should produce the same output.
Instead, the output is different. To reproduce, run the two scripts and
observe the difference in the output.

In summary, the -a qualifier alters the assignment in an undocumented
and surprising way. Both scripts should work identically as expected.

Important additional information: I have tried the same with exactly the
same results in bash 5.0.3 and bash 5.0.11.


Repeat-By:
----------

Consider the following two scripts:

SCRIPT 1:

#!/bin/bash

function Dummy() {

  local -n namerefArray="$1"
  local -a -i myArray=("${namerefArray[@]}")

  local -p
}

declare -a -i myArray=('1' '2' '3')

Dummy 'myArray'


SCRIPT 2:

#!/bin/bash

function Dummy() {

  local -n namerefArray="$1"
  local myArray=("${namerefArray[@]}")

  local -p
}

declare -a -i myArray=('1' '2' '3')

Dummy 'myArray'


OUTPUT OF SCRIPT 1:

myArray=()
namerefArray=myArray


OUTPUT OF SCRIPT 2:

myArray=([0]="1" [1]="2" [2]="3")
namerefArray=myArray


That is, in SCRIPT 1, the assignment to myArray in the function destroys
the contents of the variable referenced by namerefArray. I think that
this a bug, but I am not completely sure about it.

However, what I am quite sure about is that the behavior, whether or not
it is correct, should not differ between the two variants. The
attributes -a and -i in this case should not make any difference, but
actually make a fundamental difference.


Thank you very much, and best regards,

Binarus