John Beckett wrote:
> Bram Moolenaar wrote:
>> OK, so Borland doesn't have round() and trunc().  I rather 
>> not have a Vim version with only part of the floating point 
>> support.  The easy solution is to disable it for Borland in 
>> src/feature.h:
>>
>>      #ifdef FEAT_NORMAL
>>      # define FEAT_EVAL
>>      # if defined(HAVE_FLOAT_FUNCS) \
>>          || (defined(WIN3264) && !defined(__BORLANDC__) \
>>          || defined(MACOS)
>>      #  define FEAT_FLOAT
>>      # endif
>>      #endif
> 
> It's worse than that. I imagine there are several old compilers that fully 
> support
> floating point and strtod(), yet do not have the C99 round() and trunc(). On 
> one
> Windows system I tried, the Microsoft Visual C++ 6.0 has this problem (and it 
> has a
> strtod() that fully works).
> 
> It's a shame that Vim supports a lot of old systems, yet would have to 
> exclude those
> systems from supporting floats, even if they can do everything except round() 
> and
> trunc(). Also, you won't know what those systems are until people get around 
> to
> reporting a compile warning or link error, as has been done here.
> 
> An alternative would be something like the following, which attempts to 
> implement
> the missing functions in one line. The code below gives round(-2.5) as -3.0, 
> whereas
> the simpler floor(f+0.5) gives -2.5.
> 
> *** src/eval-org.c
> --- src/eval.c
> ***************
> *** 14629,14634 ****
> --- 14629,14635 ----
>   #ifdef FEAT_FLOAT
>   /*
>    * "round({float})" function
> +  * Ignore possibility that (f + 0.5) might overflow.
>    */
>       static void
>   f_round(argvars, rettv)
> ***************
> *** 14639,14645 ****
>   
>       rettv->v_type = VAR_FLOAT;
>       if (get_float_arg(argvars, &f) == OK)
> !     rettv->vval.v_float = round(f);
>       else
>       rettv->vval.v_float = 0.0;
>   }
> --- 14640,14646 ----
>   
>       rettv->v_type = VAR_FLOAT;
>       if (get_float_arg(argvars, &f) == OK)
> !     rettv->vval.v_float = (f >= 0 ? floor(f + 0.5) : -floor(-f + 0.5));
>       else
>       rettv->vval.v_float = 0.0;
>   }
> ***************
> *** 17024,17030 ****
>   
>       rettv->v_type = VAR_FLOAT;
>       if (get_float_arg(argvars, &f) == OK)
> !     rettv->vval.v_float = trunc(f);
>       else
>       rettv->vval.v_float = 0.0;
>   }
> --- 17025,17031 ----
>   
>       rettv->v_type = VAR_FLOAT;
>       if (get_float_arg(argvars, &f) == OK)
> !     rettv->vval.v_float = (f >= 0 ? floor(f) : -floor(-f));
>       else
>       rettv->vval.v_float = 0.0;
>   }
> 
> John

I think Bram already did something like this.

There is no possibility of an overflow. 0.5 will be well below the
precision of the float before an overflow could occur (somewhere in the
order of 1e308), so adding 0.5 will never bump it over to inf anyway.

Ben.



--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply via email to