This fixes ubsan runtime error: signed integer overflow: 8388608 +
2140274688 cannot be represented in type 'int'
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Include macros.h explicitly in common.h so that external code using
FFALIGN does not break. It was already implicitly included through
version.h. Include macros.h in lls.h and internal.h for FFALIGN.
lls.h was including common.h only for FFALIGN and internal.h was
missing the include for FFALIGN. `make checkheaders` did not catch it
because it's an internal header.
The function is renamed to ff_rint64_clip()
This should avoid build failures on VS2012
Feel free to changes this to a different solution
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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 <rsbultje@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
This is of use for defining comparator callbacks. Common approaches like
return x-y are not safe due to the risks of overflow.
Furthermore, the (x > y) - (x < y) trick is optimized to branchless
code.
This also documents this macro accordingly.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
This macro avoids the undefined corner case with the *_MIN values
Previous version Reviewed-by: Ganesh Ajjanagadde <gajjanag@mit.edu>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
there already is a function, av_clip_uintp2() that clips a signed integer
to an unsigned power-of-two range, i.e. 0,2^p-1
this patch adds a function av_clip_intp2() that clips a signed integer
to a signed power-of-two range, i.e. -(2^p),(2^p-1)
the new function can be used as a special case for av_clip(), e.g.
av_clip(x, -8192, 8191) can be rewritten as av_clip_intp2(x, 13)
there are ARM instructions, usat and ssat resp., which map nicely to these
functions (see next patch)
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
programs using ffmpeg that are compiled with -Wshorten-64-to-32
gives a warning when using header files common.h and rational.h
cast 64-bit truncated values to (uint32_t) to avoid the warning
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
As far as I can tell the code should not change behaviour
depending on locale in any of these places.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This removes inline av_log2 and av_log2_16bit from the public API,
instead exporting them as regular functions. In-tree code still
gets the inline and otherwise optimised variants.
Signed-off-by: Mans Rullgard <mans@mansr.com>
Fixed-point audio codecs often use saturating arithmetic, and
special instructions for these operations are common.
Signed-off-by: Mans Rullgard <mans@mansr.com>
Casting the left-most byte to unsigned avoids an undefined
result of the shift by 24 if bit 7 is set. This affects
the rm demuxer.
Signed-off-by: Mans Rullgard <mans@mansr.com>
On some versions of gcc, these weren't always getting inlined due to hitting
the inline cap limit in some files. This is generally bad, as most of these
functions are smaller inlined than not.
(cherry picked from commit eb3755a5aa)
On some versions of gcc, these weren't always getting inlined due to hitting
the inline cap limit in some files. This is generally bad, as most of these
functions are smaller inlined than not.