Hi, On Sun, Nov 1, 2015 at 6:15 PM, Ganesh Ajjanagadde <gajjanaga...@gmail.com> wrote:
> On Sun, Nov 1, 2015 at 6:12 PM, Ronald S. Bultje <rsbul...@gmail.com> > wrote: > > Hi, > > > > On Sun, Nov 1, 2015 at 1:03 PM, Ganesh Ajjanagadde < > gajjanaga...@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. > > Not a bug, just a standard "undefined behavior" cop-out from the > standards committee. We need to roll our own: all standard functions > cop out when it does not fit in the integer range, and Intel (and > others) have wonderfully exploited the cop-out: see e.g the link I > gave and my other reply. So how are we going to define "correct" behaviour? Let's take your INT64_MAX + 100 example. INT64_MAX is nowhere near the correct answer. Now what? Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
