From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2555 invoked by alias); 10 May 2017 14:21:14 -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: 41091 Received: (qmail 25452 invoked from network); 10 May 2017 14:21:14 -0000 X-Qmail-Scanner-Diagnostics: from mail-it0-f51.google.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(209.85.214.51):SA:0(0.5/5.0):. Processed in 1.739658 secs); 10 May 2017 14:21:14 -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.5 required=5.0 tests=FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RCVD_IN_SORBS_SPAM, SPF_PASS,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.1 X-Envelope-From: dualbus@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.214.51 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=161JFLC8MeOjrQeRApXDkMXLKKZKCuDHtju4LCFOeww=; b=RJcTa/06g00C44yxnv3sHhllaB+4M7pKGMVb9LwaEsiYPv9KVVCOGQ7njJPkOD3YXR VOo3HhiOgatjGZz8x9YjoAar89MIfowCDtl3VUlpk+Rx0xV6kdO2oxpToqiv7b1dcKiZ Revkf2+HsU3ZyauGnpGFMmt5ft4XlHEqZivck6Yh0W9gNHBpjDUDSn1DQL0yQOIp/2s4 rTmlDmcHpw4FQP4F1ByhMd1e590MJ4SWRD4IqyH/yTXYyWG5LZZ/LR97VviV6xccpajt XDE6OqIcGGoMbgUagHhGfptuAQUyaXYHZm9xG6uKup4k9mYXlz3WxKn651jDS3w5eRwo 85Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=161JFLC8MeOjrQeRApXDkMXLKKZKCuDHtju4LCFOeww=; b=nBxyoRTqpe84K3rM0ple+7cWY7s4PAzeAeR01j0fG8NjNrJYN2LxYoI1rIOAqW8WPX NzBd8UwGZ5YkAk1AYIyQLRqCAbA3DRH+Iu0R83w4PY5cABmXCY+WQFES5phzA8VFXLbq ij1GMZz5ze1h58KpQVFecT9YVlR99SurL55IU8GEUD33J58WQSNi/W8GqcJ4fk05fGJm B5skB/RXohpTSn1bnX9aYCGVQ3PkoDvh8rEwRA6cN1JWmOtXgTbn0FiNM7dKAtR21gWB WavAbF2qIaF6JEz9feXTScpo5mXIRKBYKvUti9k6vqvFhCsA8HhaY1ReYRH+Nzlat42K 5YOA== X-Gm-Message-State: AODbwcCCnhQVfxUNxYnfYZ8ilaCjV8gr0T6k+gQAriPSRaNMeRAe/vgi v6CXKo82TKjAVaZt60vNM8QqxIPmfA== X-Received: by 10.36.77.141 with SMTP id l135mr1597406itb.88.1494426067382; Wed, 10 May 2017 07:21:07 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <170509234322.ZM7806@torch.brasslantern.com> References: <170509234322.ZM7806@torch.brasslantern.com> From: Eduardo Bustamante Date: Wed, 10 May 2017 09:20:47 -0500 Message-ID: Subject: Re: Zsh parser infinite loop in chuck from utils.c on malformed input To: Bart Schaefer Cc: zsh-workers@zsh.org Content-Type: text/plain; charset="UTF-8" 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? (I'm interested in finding parsing problems, so this specific case will most likely slow down the fuzzing).