On Fri, Nov 13, 2015 at 7:29 AM, Ronald S. Bultje <rsbul...@gmail.com> wrote: > Hi, > > On Thu, Nov 12, 2015 at 9:46 PM, Ganesh Ajjanagadde <gajjanaga...@gmail.com> > wrote: >> >> The rationale for this function is reflected in the documentation for >> it, and is copied here: >> >> Clip a double value into the long long amin-amax range. >> This function is needed because conversion of floating point to integers >> when >> it does not fit in the integer's representation does not necessarily >> saturate >> correctly (usually converted to a cvttsd2si on x86) which saturates >> numbers >> > INT64_MAX to INT64_MIN. The standard marks such conversions as undefined >> behavior, allowing this sort of mathematically bogus conversions. This >> provides >> a safe alternative that is slower obviously but assures safety and better >> mathematical behavior. >> API: >> @param a value to clip >> @param amin minimum value of the clip range >> @param amax maximum value of the clip range >> @return clipped value >> >> Note that a priori if one can guarantee from the calling side that the >> double is in range, it is safe to simply do an explicit/implicit cast, >> and that will be far faster. However, otherwise this function should be >> used. >> >> avutil minor version is bumped. >> >> Reviewed-by: Ronald S. Bultje <rsbul...@gmail.com> >> Signed-off-by: Ganesh Ajjanagadde <gajjanaga...@gmail.com> >> --- >> libavutil/common.h | 31 +++++++++++++++++++++++++++++++ >> libavutil/version.h | 4 ++-- >> 2 files changed, 33 insertions(+), 2 deletions(-) >> >> diff --git a/libavutil/common.h b/libavutil/common.h >> index 6f0f582..4f60e72 100644 >> --- a/libavutil/common.h >> +++ b/libavutil/common.h >> @@ -298,6 +298,34 @@ static av_always_inline av_const double >> av_clipd_c(double a, double amin, double >> else return a; >> } >> >> +/** >> + * Clip and convert a double value into the long long amin-amax range. >> + * This function is needed because conversion of floating point to >> integers when >> + * it does not fit in the integer's representation does not necessarily >> saturate >> + * correctly (usually converted to a cvttsd2si on x86) which saturates >> numbers >> + * > INT64_MAX to INT64_MIN. The standard marks such conversions as >> undefined >> + * behavior, allowing this sort of mathematically bogus conversions. This >> provides >> + * a safe alternative that is slower obviously but assures safety and >> better >> + * mathematical behavior. >> + * @param a value to clip >> + * @param amin minimum value of the clip range >> + * @param amax maximum value of the clip range >> + * @return clipped value >> + */ >> +static av_always_inline av_const int64_t av_rint64_clip_c(double a, >> int64_t amin, int64_t amax) >> +{ >> +#if defined(HAVE_AV_CONFIG_H) && defined(ASSERT_LEVEL) && ASSERT_LEVEL >= >> 2 >> + if (amin > amax) abort(); >> +#endif > > > Why not use assert or av_assert?
It was copy pasted from the clip functions (which all follow this strange pattern), and I assumed there was a good reason for this. Maybe something to do with it being in avutil/common? > > Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel