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 ;-) TTFN Mike -- My wife says I never listen to her - or something like that. --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
