From: "Tomas Härdin" <git@haerdin.se>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [WIP] False positives on Coverity
Date: Wed, 15 May 2024 10:06:18 +0200
Message-ID: <77408fbf565ed4f178e32fbd984e0087904c0a47.camel@haerdin.se> (raw)
In-Reply-To: <70CB0DD5-F4CE-4863-8365-9E7BF52D6A2C@remlab.net>
tis 2024-05-14 klockan 14:28 +0300 skrev Rémi Denis-Courmont:
>
>
> Le 14 mai 2024 10:37:20 GMT+03:00, "Tomas Härdin" <git@haerdin.se> a
> écrit :
> > Formal methods would be better than the heuristics coverity uses.
>
> That sounds like wishful thinking, or at least a distant pipe dream.
> Lets stick to what is possible and realistic today, please.
WP is a pipe dream yes, but Eva is quite near being practical. We can
add test entrypoints protected by #defines for various modules in the
codebase. lavu comes to mind. I might submit a patchset for this as a
conversation starter.
> And I don't think that it would be reasonable to require that every
> FFmpeg developer be able to update the hypothetical formal proofs
> whenever they make a code change.
I think this entirely depends. Much like we don't allow breaking FATE,
there is no reason to allow breaking low-level stuff covered by ACSL
contracts. For example if the AVRational functions are given a valid
rational (positive den), they should return a valid rational as well.
I should add that Eva can produce false positives as well. This can be
avoided to some extent by giving it less gas when developing and more
in FATE.
/Tomas
_______________________________________________
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".
next prev parent reply other threads:[~2024-05-15 8:06 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-13 23:38 Michael Niedermayer
2024-05-14 7:37 ` Tomas Härdin
2024-05-14 11:28 ` Rémi Denis-Courmont
2024-05-15 8:06 ` Tomas Härdin [this message]
2024-06-08 16:01 ` Michael Niedermayer
2024-06-08 19:49 ` Vittorio Giovara
2024-06-08 22:49 ` Timo Rothenpieler
2024-06-09 13:10 ` Vittorio Giovara
2024-06-09 22:04 ` Michael Niedermayer
2024-06-10 12:37 ` Vittorio Giovara
2024-06-10 12:40 ` Timo Rothenpieler
2024-06-10 12:45 ` Vittorio Giovara
2024-06-11 15:46 ` Michael Niedermayer
2024-06-09 22:02 ` Michael Niedermayer
2024-07-11 23:55 ` Michael Niedermayer
2024-07-12 23:20 ` Michael Niedermayer
2024-07-25 14:41 ` Michael Niedermayer
2024-08-12 17:40 ` Michael Niedermayer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=77408fbf565ed4f178e32fbd984e0087904c0a47.camel@haerdin.se \
--to=git@haerdin.se \
--cc=ffmpeg-devel@ffmpeg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git