From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15754 invoked by alias); 4 May 2015 02:34:25 -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: 35026 Received: (qmail 6573 invoked from network); 4 May 2015 02:34:23 -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=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/Qk7f/YOXQXk8hpiaW6YsZQKSSth6bDwcEyb2oEHuFk=; b=hMao3rJd/z7NdD+HEGG0RJZVDijnP48Tl8tFrBjTGgp3I4aDDXx9ClEBBgdWTxTOsc j8W0fgDMzNSVBx6xw1pAxJp/sOzQTCNuKyDbmJrWZpTE0U/0CzW67OQ+DEQ0tgPteOYj NDdTb3UKI0GcEDZaxgR5O9U4pxCFIOfTvw5lqWG9OlsB8hU5VlTbZJCtWHr9wc7clS6k Qv7KwEU1UuMQ/z+FQUDJgYScTRalT2dLiEoS7PwUpE/rIb1fmYQarI3RGBTH+QLKF+e5 RhoZ195xO7WfgUiYxgdWdfbwqf2efyvY9DvkqBPFjFD5NbBxMtV+pq4FeUy6wN8AHpTT Dajw== MIME-Version: 1.0 X-Received: by 10.107.132.223 with SMTP id o92mr25549843ioi.49.1430706858882; Sun, 03 May 2015 19:34:18 -0700 (PDT) In-Reply-To: References: <1430685362-12270-1-git-send-email-mikachu@gmail.com> <20150503222458.53d6d567@ntlworld.com> Date: Mon, 4 May 2015 04:34:18 +0200 Message-ID: Subject: Re: PATCH: Fix two bugs in typeset_setbase From: Mikael Magnusson To: Peter Stephenson Cc: zsh workers Content-Type: text/plain; charset=UTF-8 On Mon, May 4, 2015 at 12:40 AM, Mikael Magnusson wrote: > On Sun, May 3, 2015 at 11:24 PM, Peter Stephenson > wrote: >> On Sun, 3 May 2015 22:43:46 +0200 >> Mikael Magnusson wrote: >>> Perhaps we should apply some limit to the precision of floats? For example, >>> typeset -F 100000000 foo; echo $foo >>> succeeds, and at least in my setup, causes typing at the next >>> commandline to be very slow, because of multiple calls to >>> setunderscore(). It doesn't seem to affect zsh -f. This could also be >>> a case of "don't do that then". :) >> >> Yes, it's not exactly a bug... but I guess it's easy to set it to some >> documented ceiling where it's definitely not going to make a practical >> difference. 100 or 1000? > > Came across this comment while poking around earlier (in > params.c:convfloat()), I guess 1000 should be a very safe limit. > > /* > * The difficulty with the buffer size is that a %f conversion > * prints all digits before the decimal point: with 64 bit doubles, > * that's around 310. We can't check without doing some quite > * serious floating point operations we'd like to avoid. > * Then we are liable to get all the digits > * we asked for after the decimal point, or we should at least > * bargain for it. So we just allocate 512 + digits. This > * should work until somebody decides on 128-bit doubles. > */ Oops, the 310 text speaks of the digits before the decimal point (not sure how I missed it, it's pretty explicit about it). I guess this means the practical limit is different for -E and -F. I don't know enough details for floats to make a reasonable suggestion (but probably doing calculations with multiple thousand digits of precision is not a job for the shell). I've committed my patch and if someone wants to plop in a limit, be my guest (or tell me what to make it). -- Mikael Magnusson