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