zsh-workers
 help / color / mirror / code / Atom feed
From: Mikael Magnusson <mikachu@gmail.com>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: zsh-workers@zsh.org, Michael Hwang <michael.a.hwang@gmail.com>
Subject: Re: [PATCH] Removed arbitrary limitations on array accesses
Date: Tue, 5 Jan 2010 16:43:19 +0100	[thread overview]
Message-ID: <237967ef1001050743v141df0e2qd67bc31bd331fe99@mail.gmail.com> (raw)
In-Reply-To: <100105073253.ZM2749@torch.brasslantern.com>

2010/1/5 Bart Schaefer <schaefer@brasslantern.com>:
> 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


  reply	other threads:[~2010-01-05 15:43 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-05  1:38 Michael Hwang
2010-01-05  9:48 ` Peter Stephenson
2010-01-05 15:32   ` Bart Schaefer
2010-01-05 15:43     ` Mikael Magnusson [this message]
2010-01-05 20:48     ` Geoff Wing
2010-01-06 13:42   ` Duncan Sinclair
2010-01-06 14:02     ` Mikael Magnusson
2010-01-06 17:03       ` Richard Hartmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=237967ef1001050743v141df0e2qd67bc31bd331fe99@mail.gmail.com \
    --to=mikachu@gmail.com \
    --cc=michael.a.hwang@gmail.com \
    --cc=schaefer@brasslantern.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).