[FFmpeg-devel] [PATCH 0/2] first steps to resolving float to int undefined behavior

[Ronald S. Bultje]

Hi,

On Sun, Nov 1, 2015 at 1:03 PM, Ganesh Ajjanagadde <gajjanagadde at gmail.com>
wrote:

> Floating point to integer conversion is well defined when the float lies
> within
> the representation bounds of the integer after discarding the fractional
> part.
> However, in other cases, unfortunately the standard leaves it undefined.
> In particular, assuming that it saturates in a sane way is a dangerous
> assumption.
>
> In light of recent events, I would not have bothered if this was a merely
> theoretical
> issue, and that common environments saturate correctly. Sadly, x86 (for
> example)
> converts casts to a cvttsd2si instruction which saturates numbers >
> INT64_MAX to
> INT64_MIN. This is mathematically completely bogus.
> http://blog.frama-c.com/index.php?post/2013/10/09/Overflow-float-integer
> gives
> a nice overview of the issue.
>
> 1/2 adds an av_clipd64 API for this purpose to clip a float to an integral
> range.
> Obviously it will be slower than a cvttsd2si, but there is no option if
> one wants
> safe and well-defined behavior. Of course, if one knows a priori that a
> float
> lives in the integral type's range, then there is no issue. Safe speedups
> are
> entirely possible, but API should be finalized first IMHO.
> Most common anticipated usages are clipping to [INT64_MIN, INT64_MAX] or
> [INT_MIN, INT_MAX].
> I have given some thought as to whether a separate av_clipd32 API (for
> example)
> is necessary. It seems to me to not be the case, since an IEEE-754 double
> is
> guaranteed to represent exactly integers up to ~ 2^53.
> Similarly, av_clipf64 and the like also seem unnecessary, since a double
> is guaranteed
> to represent all the values a float does. Such an API may be useful for
> performance
> though; I do not know how/what float to double conversions entail and at
> the
> moment ignore such complications.
>
> 1/2 also accordingly documents av_clipd64.


So, is this a bug in llrint, or is this a failure to use llrint, or is this
different from llrint? It sounds to me that llrint should be used, not our
own alternative.

Ronald