From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24442 invoked by alias); 29 Sep 2014 15:24:37 -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: 33279 Received: (qmail 6845 invoked from network); 29 Sep 2014 15:24:25 -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 Message-id: <140929082408.ZM6204@torch.brasslantern.com> Date: Mon, 29 Sep 2014 08:24:08 -0700 In-reply-to: <20140929110420.52cc66f8@pwslap01u.europe.root.pri> Comments: In reply to Peter Stephenson "PATCH: safe numeric import" (Sep 29, 11:04am) References: <20140925141133.49a7127b@pwslap01u.europe.root.pri> <22772.1411740194@thecus.kiddle.eu> <20140926210818.3ac1bf20@pws-pc.ntlworld.com> <20140929110420.52cc66f8@pwslap01u.europe.root.pri> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: "Zsh Hackers' List" Subject: Re: PATCH: safe numeric import MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Sep 29, 11:04am, Peter Stephenson wrote: } } OK, how about this? When we're doing the import, all numbers, integer } or floating point, are imported straight, without an evaluation. This looks fine to me. (I'm surprised that there never seems to have been an IPDEF6 before.) } Currently we suppress all errors from parameters at this stage, though } we could make a special case and output errors when we truncate a } numeric import because we ignored anything after an initial constant. I could go either way on this one. On the one hand it'd potentially be nice to get a warning if someone is shoving a strange value through SHLVL or something. OTOH there's no reason to expect it to work so in a non-malicious circumstance it shouldn't be necessary.