Marton Balint: > > > On Thu, 4 Apr 2024, Michael Niedermayer wrote: > >> Fixes: signed integer overflow: 65792 * 65312 cannot be represented in >> type 'int' >> Fixes: >> 67819/clusterfuzz-testcase-minimized-ffmpeg_dem_WADY_fuzzer-5236100912185344 >> >> Found-by: continuous fuzzing process >> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg >> Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc> >> --- >> libavformat/pcm.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/libavformat/pcm.c b/libavformat/pcm.c >> index 051e86dd464..a774dbc3726 100644 >> --- a/libavformat/pcm.c >> +++ b/libavformat/pcm.c >> @@ -41,7 +41,7 @@ int ff_pcm_default_packet_size(AVCodecParameters *par) >> /* Don't trust the codecpar bitrate if we can calculate it >> ourselves */ >> if (bits_per_sample > 0 && par->sample_rate > 0 && >> par->ch_layout.nb_channels > 0) >> if ((int64_t)par->sample_rate * par->ch_layout.nb_channels < >> INT64_MAX / bits_per_sample) >> - bitrate = bits_per_sample * par->sample_rate * >> par->ch_layout.nb_channels; >> + bitrate = bits_per_sample * (int64_t)par->sample_rate * >> par->ch_layout.nb_channels; > > LGTM, thanks. > > I wonder why we usually cast the second operand and not the first to 64 > bit, since cast has higher precedence than multiplication, it should not > matter, should it? >
Presuming that all variables here have integer conversion rank <= int64_t (true here for normal systems), then it does not matter: Casting the first operand would automatically promote all the other operands to int64_t, too; but if you add the cast to the last operand only, the first multiplication will be performed with ints only. - Andreas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".