From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-40984-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 27372 invoked by alias); 16 Apr 2017 23:17:51 -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: 40984
Received: (qmail 13216 invoked from network); 16 Apr 2017 23:17:51 -0000
X-Qmail-Scanner-Diagnostics: from out1-smtp.messagingengine.com by f.primenet.com.au (envelope-from <d.s@daniel.shahaf.name>, uid 7791) with qmail-scanner-2.11 
 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1.  
 Clear:RC:0(66.111.4.25):SA:0(-0.7/5.0):. 
 Processed in 1.833265 secs); 16 Apr 2017 23:17:51 -0000
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au
X-Spam-Level: 
X-Spam-Status: No, score=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,
	RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,T_DKIM_INVALID autolearn=unavailable
	autolearn_force=no version=3.4.1
X-Envelope-From: d.s@daniel.shahaf.name
X-Qmail-Scanner-Mime-Attachments: |
X-Qmail-Scanner-Zip-Files: |
Received-SPF: none (ns1.primenet.com.au: domain at daniel.shahaf.name does not designate permitted sender hosts)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	daniel.shahaf.name; h=content-transfer-encoding:content-type
	:date:from:in-reply-to:message-id:mime-version:references
	:subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s=
	fm1; bh=ng1kE06swHQ9rP2zxDpV1Cpuis8zQEgude9rGJs5TsQ=; b=OD96XO7e
	QJOvIvMEiOuTyZet+Hr/QReVpLyZt7fOil32Aoi5eVCu17Luu3nf6UHVYR6z/lI/
	QSmPoLdkNIapw1M2EDUeGqUEw+8zweFp9zDk9dGQOLGhwfHSgplDRTBXhaTdQyfk
	JDyZhrhwuFwOBvbFKpZJAoNH8cVwthEfnBeVJbydP+h6qLQPcbDJ2k/pGFZ77PS/
	vBixM0QB10OEQyaxs7FAiH2ZvT961UKOymykjfSPfY//Z0c/7Wjx4dN266hAX72Z
	CZLg1dbuJOdev6/VnNHdBSIzJSEWIJrpdxTjXLVD9rnDiGz4YidjHjiaKTEffg3K
	MMDH937R8Jgr6Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=content-transfer-encoding:content-type
	:date:from:in-reply-to:message-id:mime-version:references
	:subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s=
	fm1; bh=ng1kE06swHQ9rP2zxDpV1Cpuis8zQEgude9rGJs5TsQ=; b=jSYk89A5
	r5GbPx1Kq7MvyYNm8ghWFqZweD8jXLX1iPDm3r0Ibes+CWNqzbqXTq/62C+YZ/1u
	h+YcD8MJABKZBD1DwwHT2y0sAemkL8OvfTt+V9tFkf/z37UtX/Xa4i2ESWZSaqoJ
	KxMGPT6VDINoBLSJTjzf/Q0CFKdzG9ai9VFUXQ24gv/OYL7PicGkA9sM/Ft9WOfB
	HvPNeFCGLg1cqYcY0Vy63zV5aWWxxpSFUZKbaxnYUZNPbCfktuQSIq9SkXJDGLfE
	zwQU5c2wO2ApPDhVeL4BUgJalkZU4KFCtEuGp26VPfTvu8EbuCdCXT6hqctWr7i5
	qACh659k+u1/kQ==
X-ME-Sender: <xms:mPvzWPcnmApD0_0u7fDnduLGx4PYcAg-qwG1EIcGeyDxtEZjkeDI-A>
X-Sasl-enc: wrwq4IT0qCyQt1t7SqyJJW7fMoffvCZKECpbSM5dvvz4 1492384664
Date: Sun, 16 Apr 2017 23:12:18 +0000
From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: zsh-workers@zsh.org
Subject: Re: unbounded recursive call in a shell script crashes zsh
Message-ID: <20170416231218.GA28022@fujitsu.shahaf.local2>
References: <2960832.nVDpiBkaWZ@kdudka-nb>
 <2420758.31stuSQeAV@kdudka-nb>
 <CAH+w=7atHK+_7fdzxCB4gRkWiKW8zCcTvW-qHM-0fUjH=OsPDQ@mail.gmail.com>
 <2350280.olGvC23INb@kdudka-nb>
 <CAFOazAO2jcj+zPpJuHXtykUE4yGR0FnYA5+-xHgH4nu_gDZgbw@mail.gmail.com>
 <CAFOazAM8N5ZQEv_HtQwt-18M6aNOTEMhGAmYxO0De1cjpjnjXA@mail.gmail.com>
 <170415091456.ZM22606@torch.brasslantern.com>
 <20170416185628.GA25858@fujitsu.shahaf.local2>
 <170416140016.ZM21368@torch.brasslantern.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <170416140016.ZM21368@torch.brasslantern.com>
User-Agent: Mutt/1.5.23 (2014-03-12)

Bart Schaefer wrote on Sun, Apr 16, 2017 at 14:00:16 -0700:
> On Apr 16,  6:56pm, Daniel Shahaf wrote:
> }
> } Hmm.  Would it work to measure the stack space used, by declaring
> } a local variable in main() [...]?
> 
> Aside from it depending on a particular stack architecture which may
> not be shared by all hardware, it doesn't solve the problem of knowing
> how much stack space will be occupied by the average call frame.
> 
> And even if you could manage to divide the available space by the
> average size, that's still not a guarantee you won't run out if a
> number of frames are larger than average.

I originally thought of average inter-frame step size too, but then
I realized that the code could compare how far it is from main() to
RLIMIT_STACK and bail out gracefully if it has, say, less than X KB or
Y% of stack remaining.

But as you say, that's unportable.  (Not undefined behaviour; just not
guaranteed to be correct.)  Also it really shouldn't be an
application-level concern...