Bram Moolenaar wrote: >> On 09/04/2008 17:27, Mike Williams wrote: >> >>> On 09/04/2008 17:16, Bram Moolenaar wrote: >>> >>>> Francois Ingelrest wrote: >>>> >>>> >>>>> On Wed, Apr 9, 2008 at 5:30 PM, Bram Moolenaar <[EMAIL PROTECTED]> wrote: >>>>> >>>>>> Easy to reproduce. Turns out that this line causes it: >>>>>> >>>>>> sprintf(tmp, format, f); >>>>>> >>>>>> Here "format" is "%f" and "f" is your value 1e+308. The result is an >>>>>> awful long string of numbers. I suppose it's about 308 digits. How big >>>>>> does "tmp" need to be to hold any result here? I don't think %f has a >>>>>> way of specifying a maximal field width. >>>>>> >>>>> You could use snprintf() to specify the maximum length of tmp. >>>>> >>>> Unfortunately, snprintf() is not available everywhere, and the >>>> implementations are not always working in a portable way. >>>> >>>> The code actually is inside vim_snprintf(), which is the Vim >>>> implementation of snprintf(). But it still uses sprintf() to do the >>>> difficult work. >>>> >>>> I guess that 1e308 is about the largest number supported by "double". >>>> At least for me 1e309 results in "infinity". Would it be safe enough to >>>> use a buffer of about 350 chars? Or are there platforms where "double" >>>> can be much bigger? >>>> >>> Intel FPU's have 80 bit reals supporting IEEE 754 double extended >>> precision, with an absolute exponent range of 16384. And then there are >>> 128 bit reals as well ... You have to draw the line somewhere ;-) >>> >> Ugh, apologies, 16384 is the binary exponent value, this maps to (if my >> brain is working) a upper range limit of ~1x10^4932. For completeness >> IEEE 754 128 bit real has an upper range limit of ~1X10^6144. >> >> There are other fp representations with even greater range >> > > OK, so we do need to worry about this. > > This patch to message.c, replacing the previous one, should do it. > Hello!
I applied the first patch, and it worked. However, the second one... vim71/ djinni? patch -p0 < ../diff_float2.ptch patching file src/message.c Hunk #2 FAILED at 3823. Hunk #3 succeeded at 3819 with fuzz 2 (offset -53 lines). Hunk #4 succeeded at 4000 with fuzz 2 (offset 84 lines). Hunk #5 succeeded at 3965 (offset -53 lines). Hunk #6 FAILED at 4113. Hunk #7 succeeded at 4618 with fuzz 2 (offset 116 lines). Hunk #8 FAILED at 4772. 3 out of 8 hunks FAILED -- saving rejects to file src/message.c.rej Regards, Chip Campbell --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
