From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-32839-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 22695 invoked by alias); 5 Jul 2014 01:40:59 -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: 32839
Received: (qmail 24496 invoked from network); 5 Jul 2014 01:40:56 -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=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE
	autolearn=ham version=3.3.2
From: Bart Schaefer <schaefer@brasslantern.com>
Message-id: <140704184036.ZM18558@torch.brasslantern.com>
Date: Fri, 04 Jul 2014 18:40:36 -0700
In-reply-to: <20140704172545.GA29213@xvii.vinc17.org>
Comments: In reply to Vincent Lefevre <vincent@vinc17.net>
 "segmentation fault with {1..1234567}" (Jul  4,  7:25pm)
References: <20140704172545.GA29213@xvii.vinc17.org>
X-Mailer: OpenZMail Classic (0.9.2 24April2005)
To: zsh-workers@zsh.org
Subject: Re: segmentation fault with {1..1234567}
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii

On Jul 4,  7:25pm, Vincent Lefevre wrote:
}
} With zsh 5.0.5 (Debian/unstable):
} 
} $ zsh -c 'echo {1..1234567}'
} zsh: segmentation fault (core dumped)  zsh -c 'echo {1..1234567}'
} 
} If a failure is expected for any reason, it shouldn't be a crash.

Whether that expression fails depends entirely on the memory allocation
limitations of the local host.  It works fine for me.

What's the "expected" behavior of the shell when the user requests a
vast amount of memory?  How should the shell recover from running out of
memory at any arbitrary point during execution of a command or script?
Is it really helpful to trap the signal and exit *without* dumping core?