Re: Possible huge setarrvalue optimization

[Sebastian Gniazdowski <psprint@xxxxxxxxxxxx>]

On Sun, Nov 20, 2016, at 09:41 AM, Bart Schaefer wrote:

> Thanks for pointing out those possible details.  I know from
> implementing the param_private module that this part of the code is
> really important to assumptions made downstream -- it may appear safe
> to "give away" strings based on local examination here but in fact
> cause problems outside this function.
> This and the proposed getstr optimization both make me nervous.  I
> know Sebastian is anxious to have them appear in the next release, but
> it feels and if we should have more time using them in dev branches.


Not much problem to not see this in 5.3, my code doesn't benefit much,
however it's a very cool thing that allows to do typeset -a arr;
arr[max_size] = 2000, and then freely write to not reallocated array –
really, arrays of size 5000 are unusable without the patch when storing
to single fields, times are too large. I counted on feedback about what
might break, was from some time aware of the ename, curiously tied
arrays/scalars work fine, but the environment fixing on not empty ename
is a problem.


Best regards,

Sebastian Gniazdowski