From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5238 invoked by alias); 10 May 2017 14:46:13 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 41092 Received: (qmail 13137 invoked from network); 10 May 2017 14:46:13 -0000 X-Qmail-Scanner-Diagnostics: from mailout2.w1.samsung.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(210.118.77.12):SA:0(-5.0/5.0):. Processed in 1.471435 secs); 10 May 2017 14:46:13 -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=-5.0 required=5.0 tests=RCVD_IN_DNSWL_HI, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: p.stephenson@samsung.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at samsung.com does not designate permitted sender hosts) X-AuditID: cbfec7f4-f79806d000001279-d4-591327ab45ba Date: Wed, 10 May 2017 15:45:55 +0100 From: Peter Stephenson To: Eduardo Bustamante , zsh-workers@zsh.org Cc: Eduardo Bustamante Subject: Re: Zsh parser infinite loop in chuck from utils.c on malformed input Message-id: <20170510154555.2a07d67b@pwslap01u.europe.root.pri> In-reply-to: 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+NgFvrOIsWRmVeSWpSXmKPExsWy7djP87qr1YUjDX7t17Y4fuYMu8XB5odM DkweO2fdZfdYdfADUwBTFJdNSmpOZllqkb5dAlfGg4dXGQt+cFc8vXCLqYHxJGcXIyeHhICJ xPf+14wQtpjEhXvr2boYuTiEBJYySkx6/R7K+cwo0Xh6CgtMx7NvG1khEssYJXaeug9V9Y9R YsPeFcwQzhlGiUs797JAOGcZJX73zWIF6WcRUJVY/WYTmM0mYCgxddNssO0iAvYS3w/tBbOZ BbQk+q/uYgexhQUCJLb97QGaysHBC1TTOs8RJMwpECxxbN13NhCbX0Bf4urfT0wQ59lLzLxy BmwMr4CgxI/J91ggRupIbNv2mB3ClpfYvOYt2KESApPZJfasW84KMl9CQFZi0wFmiDkuEq+W rmCHsIUlXh3fAmXLSFye3A0Nin5GiSfdvhBzZjBKnD6zgw0iYS3Rd/si1C98EpO2TWeGmM8r 0dEmBFHiIfF3xWX2CYxKs5CcOgvJqbOQnLqAkXkVo0hqaXFuemqxiV5xYm5xaV66XnJ+7iZG YHI4/e/4lx2Mi49ZHWIU4GBU4uE9wS4cKcSaWFZcmXuIUYKDWUmEd5MEUIg3JbGyKrUoP76o NCe1+BCjNAeLkjgv16lrEUIC6YklqdmpqQWpRTBZJg5OqQZGU7mgX0ePPDe9U2ZwMFN2zuXK 2Pzel0k/Wvg3qygoqd+eL79km3m65sPZc4487P3y8eqs5y73Ty6Ybnnv9mEW1+vvvuisW/p2 iW1n1qZHq/QUC51UPcWO3pGJ1DxVe2Hv56akFZ/3lb64dvhR9N3D+6vTi+fn3v0nqMTw7ftc znUPPn44/sjh7hUlluKMREMt5qLiRABNMAW3CgMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDIsWRmVeSWpSXmKPExsVy+t/xq7qn1IUjDc48VrQ4fuYMu8XB5odM DkweO2fdZfdYdfADUwBTlJtNRmpiSmqRQmpecn5KZl66rVJoiJuuhZJCXmJuqq1ShK5vSJCS QlliTimQZ2SABhycA9yDlfTtEtwyHjy8yljwg7vi6YVbTA2MJzm7GDk5JARMJJ5928gKYYtJ XLi3nq2LkYtDSGAJo8SuD9OhnAYmidMvv7NAOOcYJc4v2weVOcsosebLDLB+FgFVidVvNoHZ bAKGElM3zWYEsUUE7CW+H9oLZjMLaEn0X93FDmILC/hJ3Ji1EMjm4OAFqmmd5wgS5hQIltjU vYwVYv4cJolFpxaCzeQX0Je4+vcTE8St9hIzr5wBm8krICjxY/I9Fpj5m7c1sULY8hKb17xl BrGFBNQlbtzdzT6BUWQWkpZZSFpmIWlZwMi8ilEktbQ4Nz232EivODG3uDQvXS85P3cTIzDm th37uWUHY9e74EOMAhyMSjy8J9iFI4VYE8uKK3MPMUpwMCuJ8G6SAArxpiRWVqUW5ccXleak Fh9iNAUG0kRmKdHkfGA6yCuJNzQxNLc0NDK2sDA3MlIS55364Uq4kEB6YklqdmpqQWoRTB8T B6dUA6PbPbXU1ssCx/6IbJ2eeVVEP/LcNd9pmZs2+WxZd7G51UVQP+qnVPEhvQqz+L6Drp4m AZUiFbNm8F0Oe8n2JkCArVElZlnLf/7N259YLGmzX93DYRN7Qfjmr29Wvzvrfjuw2zkte7FO btEauU+Hv5jrBbJVK9s05JmKGYSlui2+kMQWFqD3QomlOCPRUIu5qDgRAPUDyjvPAgAA X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20170510144603eucas1p154150b786b44fc7a25dcb60789a54ef3 X-Msg-Generator: CA X-Sender-IP: 182.198.249.180 X-Local-Sender: =?UTF-8?B?UGV0ZXIgU3RlcGhlbnNvbhtTQ1NDLURhdGEgUGxhbmUb?= =?UTF-8?B?7IK87ISx7KCE7J6QG1ByaW5jaXBhbCBFbmdpbmVlciwgU29mdHdhcmU=?= X-Global-Sender: =?UTF-8?B?UGV0ZXIgU3RlcGhlbnNvbhtTQ1NDLURhdGEgUGxhbmUbU2Ft?= =?UTF-8?B?c3VuZyBFbGVjdHJvbmljcxtQcmluY2lwYWwgRW5naW5lZXIsIFNvZnR3YXJl?= X-Sender-Code: =?UTF-8?B?QzEwG0VIURtDMTBDRDA1Q0QwNTAwNTg=?= CMS-TYPE: 201P X-HopCount: 7 X-CMS-RootMailID: 20170510142145epcas4p1249de50a9a8d98af301ba6a69cb75a19 X-RootMTR: 20170510142145epcas4p1249de50a9a8d98af301ba6a69cb75a19 References: <170509234322.ZM7806@torch.brasslantern.com> On Wed, 10 May 2017 09:20:47 -0500 Eduardo Bustamante wrote: > On Wed, May 10, 2017 at 1:43 AM, Bart Schaefer > wrote: > [...] > > This probably should have been a parse error because the { } are not > > balanced, but I'm guessing the parser returns a complete expression > > when it hits EOF. Anyway, parameter expansion is one of the few things > > that happens in noexec, and those %%%% in the flags list mean to treat > > all that garbage as a prompt ... so I suspect it's not actually in an > > *infinite* loop, just one that is going to repeat 3333333333333333333 > > times. > > I see. Is there a particular reason parameter expansion is performed > when noexec is on, and is there a way to disable expansions too? The problem is NO_EXEC is all things to all people; in the case of a shell there isn't really "just" a syntax check, because it's too flexible. The result of a parameter expansion can in some cases have a significant effect on what you're doing, in particular if the command to execute is part of it. Being able to parse a parameter substitution is itself quite an important check; and there's no fundamental difference in the code between looking through the parameter substitution and changing the arguments based on what you find. The name NO_EXEC, rather than, say, SYNTAX_CHECK, is significant. Adding an additional mode that does even less is certainly possible, but not necessarily of very wide applicability. pws