Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: unbounded recursive call in a shell script crashes zsh
- X-seq: zsh-workers 40984
- From: Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: Re: unbounded recursive call in a shell script crashes zsh
- Date: Sun, 16 Apr 2017 23:12:18 +0000
- 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==
- In-reply-to: <170416140016.ZM21368@torch.brasslantern.com>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- 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>
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...
Messages sorted by:
Reverse Date,
Date,
Thread,
Author