Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #16244
| From | Andrej Podzimek <andrej@podzimek.org> |
|---|---|
| Newsgroups | gnu.bash.bug |
| Subject | Re: Variable references (declare -n, "nameref") are limited to a depth of 8. |
| Date | 2020-04-26 05:46 +0200 |
| Message-ID | <mailman.1267.1587872792.3066.bug-bash@gnu.org> (permalink) |
| References | <courier.000000005EA3DECF.0000B702@charon.podzimek.org> <09fac3bd-2d96-c0ee-ac03-f729507af74a@case.edu> <1b9cc5d.a1fea93e.171b497bdae@podzimek.org> |
>> Description: >> >> While looking for a way to share a "cache" array with a recursive function >> call stack (using local -n (nameref)), I hit a well-known problem with >> "circular name reference" (which has been around for a long time). > > Yes, that's how it does loop detection. There are, however, no loops involved in my $a … $k example; it is merely a chain of declare -n references starting from a regular variable $a. The chain breaks unexpectedly and silently after 8 links ($j and $k appear to be empty). Better options, IMHO, would include: (a) An unlimited number of declare -n resolution steps (as long as there are no cycles, i.e., no variable name(*) is encountered twice). This may have performance consequences when abused, but it would be better than unexpected empty values after >8 steps. (b) An error message when trying to dereference $j or $k (links No. 9 and 10 in the chain example), saying e.g. “maximum nameref depth (8) exceeded”. This would at least make the problem obvious and easy to debug. (*) More precisely, this would be [function context, variable name] pairs in case of local variables referenced by declare -n. Andrej
Back to gnu.bash.bug | Previous | Next | Find similar
Re: Variable references (declare -n, "nameref") are limited to a depth of 8. Andrej Podzimek <andrej@podzimek.org> - 2020-04-26 05:46 +0200
csiph-web