Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: [PATCH] Removed arbitrary limitations on array accesses
- X-seq: zsh-workers 27564
- From: Mikael Magnusson <mikachu@xxxxxxxxx>
- To: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- Subject: Re: [PATCH] Removed arbitrary limitations on array accesses
- Date: Tue, 5 Jan 2010 16:43:19 +0100
- Cc: zsh-workers@xxxxxxx, Michael Hwang <michael.a.hwang@xxxxxxxxx>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=S4LRZ9SCYkVPcYKZEKo/0ATaROCHKQoSkomdBLBJIEc=; b=offgFHHRvR5csE8QdG1OiFsH7GMozzSsuPbe6oAWDFT0lIExbUANP8XlGVrV3g2NIU 8DL3PdnYHLOI2HJ/5GM0EX2CWsD6NnB+Ardd+6O2576tdSuuRAr+p8DSEKgiZslPuPGR ZNqsQOxgLjbviLl/UE13OIs4sZ0dO3m7GTOak=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=eaXzzUsFNg8KHDg6DUILLEFSSZDU9kexc6bzS6sHKEPTck2lYzoyt3au1Tr8br0JxF Akuh+K1Nw+ysAo+ZO4oTm/78dDf2rQwp78A5vm2UJ1B9As+rSBSEPJq2+VYmJatsK4Uz OG2jqcGAf7hO8LeF4HW/eVRZBSKBedcVqlKio=
- In-reply-to: <100105073253.ZM2749@xxxxxxxxxxxxxxxxxxxxxx>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <1262655497-21263-1-git-send-email-michael.a.hwang@xxxxxxxxx> <20100105094829.613883ab@news01> <100105073253.ZM2749@xxxxxxxxxxxxxxxxxxxxxx>
2010/1/5 Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>:
> On Jan 5, 9:48am, Peter Stephenson wrote:
> }
> } Those have been there for a long time. I don't have any evidence that
> } they're doing a lot of good but we have had people creating positional
> } parameters with <long_number>=something and wondering why it uses a
> } lot of memory. I suppose this is similar. The arbitrary limit is not
> } very useful and also undocumented; most people wouldn't miss it if it
> } wasn't there, certainly.
>
> I have a vague memory of when this was added, but it appears to have been
> sometime longer ago than when the zsh-workers archive begins and after
> the last zsh-2 archive I kept -- which means it was late 1994 or early
> 1995.
>
> My recollection, such as it is, is that attempting to read an array
> slice from N to some huge number would allocate a temporary array with
> empty slots for all the intervening positions, causing the shell to
> crash with an out-of-memory error or to DoS attack the university time-
> share system by attempting to consume all memory. The arbitrary 262144
> number was chosen based on some computation of the space occupied by
> one of those empty slots, to assure that the resulting temporary would
> be smaller than the typical VM limitations of a machine of the era.
>
> It seems like we need SOME kind of limit here to prevent the user from
> accidentally consuming huge amounts of memory, but it's probably useful
> for it to become a computed value based on process limits.
echo $path[1,100000000000000000] appears to work fine here (though
$path[1,1000000000000000000] seems to expand to nothing) without using
any noticable memory. If you mean an array that is actually that size,
then the memory is already used, so the worst would be doubling what
is already used? If it only affects slices, could single element
access still be unlimited?
I notice that even before the patch, using [-n] to access the last
element seems to work for larger arrays.
% test=({1..300000})
% echo $test[270000]
zsh: subscript too big: 270000
% echo $test[-1]
300000
% echo $test[-2]
299999
% echo $test[-100]
299901
% echo $test[-100,-90]
299901 299902 299903 299904 299905 299906 299907 299908 299909 299910 299911
% echo $test[-270000]
zsh: subscript too small: -270000
--
Mikael Magnusson
Messages sorted by:
Reverse Date,
Date,
Thread,
Author