From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id D1E6C4B1AF for ; Mon, 1 Jul 2024 18:50:35 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id A7B0C68D7A0; Mon, 1 Jul 2024 21:50:32 +0300 (EEST) Received: from btbn.de (btbn.de [144.76.60.213]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 4EAA668D409 for ; Mon, 1 Jul 2024 21:50:25 +0300 (EEST) Received: from [authenticated] by btbn.de (Postfix) with ESMTPSA id 4C4BA28000900 for ; Mon, 1 Jul 2024 20:50:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rothenpieler.org; s=mail; t=1719859824; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=E5kME2bD46pFt9Ao9gLUrfJq/KalQ9YXNMEPQrivT28=; b=hvvUaL8twt2SLxmsqlsACScNIq2OoyYAK1C5kdf97PAJ0Uy4O3md4UeK33NuFlH3Mutg3v Lv6LPDLVtobbke1x9DBJM/uLUYia/d0PX7jVOz8ANnwZp1WyDPz8EASy8abwOlv3N87L4J r4nFevwHOxF2ukYCj4e09fCDsjLjgz1+F4wzxUDapsVhdYPXDTy9+8BKZDw7KH/ozkAUK5 HqXTXQGZiZSdWWXmdZpsLXtge6YSx9ZX2fQvSW0+/6oFzGvONfcHyMJowBmZpeRXsSYjDO jJ1IHyNWciDwlH92H2aHIBH4QrEd8HcKnJabIubTSjflZ/vd+V91o/1qEhUEGA== Message-ID: <2e923434-4c36-4921-b728-acdc4dd39233@rothenpieler.org> Date: Mon, 1 Jul 2024 20:50:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: ffmpeg-devel@ffmpeg.org References: <20240701133923.GF4991@pb2> Content-Language: en-US From: Timo Rothenpieler In-Reply-To: <20240701133923.GF4991@pb2> Subject: Re: [FFmpeg-devel] [RFC] av_rescale() coverity X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: 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. > before this i thought iam mostly done with my coverity work. > now truth is, the STF text speaks about 673 issues at the time and not > what appears after the work started, but it makes me a bit sad if i categorize > ~700+ issues and then fix the ones that are bugs just to find coverity > hallucinate 200 new issues a month that ill have to leave open for future > efforts. > > I did not expect that years of ignoring coverity accumulate 673 issues and > then suddenly the rate of new issues to shoot up like this. I kind of expected > that i can fix all new issues appearing during the work with insignificant extra effort > > thx > > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".