Re: PATCH: Fix two bugs in typeset_setbase

[Mikael Magnusson <mikachu@gmail.com>]

On Mon, May 4, 2015 at 12:40 AM, Mikael Magnusson <mikachu@gmail.com> wrote:
> On Sun, May 3, 2015 at 11:24 PM, Peter Stephenson
> <p.w.stephenson@ntlworld.com> wrote:
>> On Sun, 3 May 2015 22:43:46 +0200
>> Mikael Magnusson <mikachu@gmail.com> 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