On Fri, Mar 10, 2017 at 06:50:34PM +0100, Hendrik Leppkes wrote: > On Fri, Mar 10, 2017 at 3:24 PM, Michael Niedermayer > <mich...@niedermayer.cc> wrote: > > Fixes: 732/clusterfuzz-testcase-4872990070145024 > > > > See: [FFmpeg-devel] [PATCH 2/6] avcodec/dca_xll: Fix runtime error: signed > > integer overflow: 2147286116 + 6298923 cannot be represented in type 'int' > > Found-by: continuous fuzzing process > > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg > > Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc> > > --- > > libavcodec/dca_xll.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/libavcodec/dca_xll.c b/libavcodec/dca_xll.c > > index 6cebda35e4..0fe90c7348 100644 > > --- a/libavcodec/dca_xll.c > > +++ b/libavcodec/dca_xll.c > > @@ -1312,7 +1312,7 @@ static int combine_residual_frame(DCAXllDecoder *s, > > DCAXllChSet *c) > > } else { > > // No downmix scaling > > for (n = 0; n < nsamples; n++) > > - dst[n] += (src[n] + round) >> shift; > > + dst[n] += (unsigned)((src[n] + round) >> shift); > > } > > } > > > > audio samples are typically signed, using negative values too, is this > really safe to just cast it like that, without modifying the value in > the end?
signed and unsigned operations for +,-,*,<< are identical on twos complement with in and output data types matching and twos complement (strictly speaking in the signed case some are undefined in C ...) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel