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 Mike -- 'Very funny, Scotty. Now beam down my clothes.' --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
