From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-30451-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 8197 invoked by alias); 23 Apr 2012 16:40:22 -0000
Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
X-Seq: 30451
Received: (qmail 1690 invoked from network); 23 Apr 2012 16:40:20 -0000
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,
	SPF_HELO_PASS autolearn=ham version=3.3.2
Received-SPF: none (ns1.primenet.com.au: domain at csr.com does not designate permitted sender hosts)
Date: Mon, 23 Apr 2012 17:40:10 +0100
From: Peter Stephenson <Peter.Stephenson@csr.com>
To: "Zsh Hackers' List" <zsh-workers@zsh.org>
Subject: Re: MAX_ARRLEN
Message-ID: <20120423174010.42448946@pwslap01u.europe.root.pri>
In-Reply-To: <CAHYJk3T5x+tFan+CSLH6srijXiET_PxrxoTjDEsL5CUieMq+hw@mail.gmail.com>
References: <20120423162711.42a6bad1@pwslap01u.europe.root.pri>
	<CAHYJk3Qxx3nLLMARiGgbo9U8KL3NaOXO2ioWPA3n=6sJmmMzRQ@mail.gmail.com>
	<120423092123.ZM5041@torch.brasslantern.com>
	<20120423172723.238137e1@pwslap01u.europe.root.pri>
	<CAHYJk3T5x+tFan+CSLH6srijXiET_PxrxoTjDEsL5CUieMq+hw@mail.gmail.com>
Organization: Cambridge Silicon Radio
X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.101.10.18]
X-Scanned-By: MailControl 7.7.0 (www.mailcontrol.com) on 10.71.0.143

On Mon, 23 Apr 2012 18:36:22 +0200
Mikael Magnusson <mikachu@gmail.com> wrote:
> The problem with the current approach is that it only limits accessing
> an array beyond a certain index, even if it's already larger, and you
> can create arrays of any size by other means. To me it seems like the
> limit is applied in the wrong place at least. If there are places that
> unexpectedly create large arrays, we should add the safeguards in
> those places, if possible.

That's a good point --- and, in fact, creating *whole* arrays isn't a
problem, either, unless we think we're protecting against

  stuff=($(<bigfile))

and I don't think we are; why is that more problematic than the
unprotected

  stuff="$(<bigfile)"

?

However, this has now turned from a simple change to a research project.

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK




Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog