From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-32904-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 5686 invoked by alias); 24 Jul 2014 09:44:23 -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: 32904
Received: (qmail 13689 invoked from network); 24 Jul 2014 09:44: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=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI,
	SPF_HELO_PASS autolearn=ham version=3.3.2
X-AuditID: cbfec7f5-b7f626d000004b39-75-53d0d57093f4
Date: Thu, 24 Jul 2014 10:44:15 +0100
From: Peter Stephenson <p.stephenson@samsung.com>
To: zsh-workers@zsh.org
Subject: Re: segmentation fault with {1..1234567}
Message-id: <20140724104415.21fa2245@pwslap01u.europe.root.pri>
In-reply-to: <20140708113842.77378f62@pwslap01u.europe.root.pri>
References: <20140704172545.GA29213@xvii.vinc17.org>
 <140704184036.ZM18558@torch.brasslantern.com>
 <20140705111233.GA19385@xvii.vinc17.org>
 <140705095703.ZM12012@torch.brasslantern.com>
 <20140705233916.GA18368@xvii.vinc17.org>
 <140706091609.ZM18865@torch.brasslantern.com>
 <20140706193055.209f7a2b@pws-pc.ntlworld.com>
 <140706124629.ZM19578@torch.brasslantern.com>
 <20140707203312.27566ab8@pws-pc.ntlworld.com>
 <140707180806.ZM20805@torch.brasslantern.com>
 <20140708113842.77378f62@pwslap01u.europe.root.pri>
Organization: Samsung Cambridge Solution Centre
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-Brightmail-Tracker:
 H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42I5/e/4Vd2CqxeCDY5/0rM42PyQyYHRY9XB
	D0wBjFFcNimpOZllqUX6dglcGTPmtLEW3GKvOLJ+KnsDYytbFyMnh4SAicTZTU+ZIGwxiQv3
	1gPFuTiEBJYySrzcfY0JwlnOJHHy2T5GkCoWAVWJY1N7wbrZBAwlpm6aDRYXERCXOLv2PAuI
	LQwUv/n6IVgNr4C9RNPfh6xdjBwcnAIOEivWhUHMnMAicWz7d7DN/AL6Elf/foK6wl5i5pUz
	jBC9ghI/Jt8Dm8ksoCWxeVsTK4QtL7F5zVvmCYwCs5CUzUJSNgtJ2QJG5lWMoqmlyQXFSem5
	RnrFibnFpXnpesn5uZsYIUH4dQfj0mNWhxgFOBiVeHg5XpwKFmJNLCuuzD3EKMHBrCTCu3LT
	hWAh3pTEyqrUovz4otKc1OJDjEwcnFINjP4OX4PVnlrHN/Oe5Lr/Mv1yQyjz/kNdp9z7djcc
	enygfJ3VzIBVgnbLy5o0QlelX2Y4Gt/KfTdfwuHD77cePhmzz22M/VZsGDthyrrLelaVLx73
	nZp+1kN66mTrB66iZbMqhHrsr5+9+SPfcSdT92nv2es9Jfv2K/TqWzeZZBzMfBkV7nOxUYml
	OCPRUIu5qDgRAMDLMtEgAgAA

On Tue, 08 Jul 2014 11:38:42 +0100
Peter Stephenson <p.stephenson@samsung.com> wrote:
> On Mon, 07 Jul 2014 18:08:06 -0700
> Bart Schaefer <schaefer@brasslantern.com> wrote:
> > On Jul 7,  8:33pm, Peter Stephenson wrote:
> > } Subject: Re: segmentation fault with {1..1234567}
> > }
> > } On Sun, 06 Jul 2014 12:46:29 -0700
> > } Bart Schaefer <schaefer@brasslantern.com> wrote:
> > } > The question is ... do we redefine
> > } > VARARR() [possibly conditionally] to change all the usages at once ...?
> > 
> > Well, that one is easy, as I mentioned earlier; see patch below.  One added
> > hunk in mem.c for a place where we didn't check the return of malloc, but I
> > did not attempt to change the usual fatal-error behavior.
> 
> I'm trying this out, but I'm not sure I'm likely to prod the most likely
> problem areas with my usage.

Not seen any problems.  Should we commit it and see what happens?  I
ought to be making a new release before too long.

pws