On Mon, Jul 01, 2024 at 08:50:24PM +0200, Timo Rothenpieler wrote:
> On 01.07.2024 15:39, Michael Niedermayer wrote:
> > Hi all
> > 
> > coverity seems to have started to do a new thing. Namely if theres a
> > return statement it assumes it can independant of everything occurr
> > 
> > an example would be av_rescale() which on overflow returns INT64_MIN
> > 
> > also with the right flags av_rescale() will pass INT64_MIN and INT64_MAX through
> > from the input
> > 
> > So coverity since a few days seems to treat every av_rescale() call as if it returns
> > INT64_MIN and INT64_MAX. coverity doesnt care if that return statement is reachable or
> > if the flags even include the execution path.
> > 
> > An example is this:
> >              AVRational time_base_q = AV_TIME_BASE_Q;
> >              int64_t next_dts = av_rescale_q(ds->next_dts, time_base_q, av_inv_q(ist->framerate));
> >              ds->next_dts = av_rescale_q(next_dts + 1, av_inv_q(ist->framerate), time_base_q);
> > 
> > Here coverity as a initial statement claims next_dts is INT64_MAX
> > and next_dts + 1 would overflow
> > 
> > 
> >      8. function_return: Function av_rescale_q(ds->next_dts, time_base_q, av_inv_q(ist->framerate)) returns 9223372036854775807.
> >              9. known_value_assign: next_dts = av_rescale_q(ds->next_dts, time_base_q, av_inv_q(ist->framerate)), its value is now 9223372036854775807.
> >      331            int64_t next_dts = av_rescale_q(ds->next_dts, time_base_q, av_inv_q(ist->framerate));
> > 
> >      CID 1604545: (#1 of 1): Overflowed constant (INTEGER_OVERFLOW)
> >      10. overflow_const: Expression next_dts + 1LL, which is equal to -9223372036854775808, where next_dts is known to be equal to 9223372036854775807, overflows the type that receives it, a signed integer 64 bits wide.
> > 
> > 
> > another example is this:
> > 
> >      #define AV_TIME_BASE            1000000
> >      pts = av_rescale(ds->dts, 1000000, AV_TIME_BASE);
> > 
> > coverity hallucinates pts as a tainted negative number here nothing says anything about
> > the input ds->dts (and thats what would matter)
> > 
> > In the past coverity provided a detailed list of steps on how a
> > case is reached. One could then check these assumtions and mark things
> > as false positive when one assumtion is wrong. (coverity was most of the time
> > wrong)
> > 
> > Now coverity just hallucinates claims out of the blue without any
> > explanation how that can happen.
> > 
> > Iam a bit at a loss how to deal with this and also why exactly this
> > new behavior appeared.
> > 
> > Has anyone changed any setting or anything in coverity ?
> > 
> > The number of issues shot up to over 400 on the 22th june
> > "194 new defect(s) introduced to FFmpeg/FFmpeg found with Coverity Scan."
> 
> Do you mean May?
> Cause that's when I enabled also giving a Windows-Build to Coverity:
> https://github.com/FFmpeg/FFmpeg-Coverity/commit/3116e6960406f01f96d934516216bb3b402122fc
> 
> Before that, only Linux was analyzed.

no the 194 appeared in june

I did saw some other spike of issues appear month? earlier or so but these seemed
mostly old issues that where detected prior already.
and i dont see it in teh numbers coverity mails me

Only other spike i can find in the numbers was 11 feb 2024
103 new defect(s) introduced to FFmpeg/FFmpeg found with Coverity Scan.

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates