[FFmpeg-devel] [PATCH] [libavutil] Add saturated add/sub operations for int64_t.

[Dale Curtis]

On Wed, May 13, 2020 at 3:55 PM Michael Niedermayer <michael at niedermayer.cc>
wrote:

> On Fri, May 08, 2020 at 05:21:06PM -0700, Dale Curtis wrote:
> > On Wed, May 6, 2020 at 7:03 AM Michael Niedermayer
> <michael at niedermayer.cc>
> > wrote:
> >
> > > On Mon, May 04, 2020 at 04:06:56PM -0700, Dale Curtis wrote:
> > > > On Mon, May 4, 2020 at 3:39 PM Michael Niedermayer
> > > <michael at niedermayer.cc>
> > > > wrote:
> > > >
> > > > > On Mon, May 04, 2020 at 02:19:47PM -0700, Dale Curtis wrote:
> > > > > > On Mon, May 4, 2020 at 1:48 PM Michael Niedermayer
> > > > > <michael at niedermayer.cc>
> > > > > [...]
> > > > >
> > > >
> > > > You snipped out the example I provided,
> > >
> > > yes because it was messed up from linebreaks which made both variants
> > > unreadable
> > >
> >
> > Sorry, here's it in pastebin: https://pastebin.com/raw/p1VyuktF
>
> for the purpose of the start_time adjustment
> I cannot think of a case where this code would trigger with a real
> undamaged
> file. The resulting timestamp should be representable as 64bit int.
> It being not representable kind of points to something being wrong
> on the input to this expression
> If it is an issue just in this packets timestamp which is used then
> just ignoring that and using the next one would be a possibility
> Similarly when anything else is wrong which could be corrected
> subsequently.
> If its a fuzzed and broken beyond repair file anything would be fine
> as value or also erroring out.
>
> I presume we have this being hit with a fuzzed file and not a real
> file, so the whole discussion about what would be best for real
> file error robustness is a bit hypothetical. OTOH for fuzzed
> files it doesnt really matter much what is done.
> So i have not much of an oppinion on what to do here.
>

Thanks for the reply. The issues all involve fuzzed files as you suspected.
Since you don't have an opinion, it seems best to just keep the API
consistent with the existing av_sat_(add|sub)32 functions and land the
patch above (sat_math_v4.patch) as is. Are there any more outstanding
issues to resolve?

- dale