Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Nicolas George <george@nsup.org>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH 00/22] Deprecate av_uninit
Date: Fri, 11 Apr 2025 11:32:48 +0200
Message-ID: <Z_jhwK9YvbORpnJU@phare.normalesup.org> (raw)
In-Reply-To: <tencent_FD0F684EF3FBD37FF5D36902AEB105437305@qq.com> <tencent_2E0DD0B5E6CFA7CCAAA4532B9C428B87A606@qq.com>

Zhao Zhili (HE12025-04-11):
> With UB, the compiler can remove branch check and assign some random
> value to it, which cannot be detected by valgrind.
> 
> For ab792634197e, the UB is there for decades and never detected by
> valgrind, and the warning is silenced by av_uninit.

You make a valid point, but my own point still stands: your change make
it harder to find bugs by removing the difference between “I put this
initialization there because it is the right value” and “I put this
there because the compiler is too stupid to figure it on its own”.

I have to ideas to accommodate both issues:

- Have a FATE instance with valgrind and optimizations disabled, so that
  the compiler does not optimize the code away because of the UB and
  valgrind catches the bug.

- Initialize to 0xDEADBEEF and add av_assert2(val != 0xDEADBEEF) at the
  place where it will be used.

The second one might be fragile, but less than an UB.

> By the way, logic bug isn’t equal to UB, so I’m not hiding UB.

Yes you are.

> Who put av_uninit in the code means there is no logic bug. If there is,
> the patchset fixed UB or replaced UB by deterministic logic error, which
> can’t be worse.

The deterministic logic error is not worse, but it is not better either,
and it is harder to detect.

> If there is, the patchset fixed or makes the issue deterministic.

This patches fixes NOTHING, I hope we agree on it. What you did is
basically equivalent to removing an assert that fails and hoping the
code that comes later will be fine.

Making the bug deterministic is not better if it makes it harder to
detect.

> We don’t initialized all variables when declaration. But if there is a
> sometimes-uninitialized warning, there is some reason for compiler.
> Uninitialized warning isn’t the same as deprecated or unused, it should
> never be ignored in my opinion.

You are wrong on this, the compiler is often unable to figure out that
the code always sets the variable before reading it when the developer
can prove it. Compilers are getting better, but they are still far from
perfect, and av_unused is precisely there for that lack of perfection,
and needs to stay there.

Regards,

-- 
  Nicolas George
_______________________________________________
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".

  reply	other threads:[~2025-04-11  9:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-11  7:55 Zhao Zhili
2025-04-11  8:36 ` Nicolas George
2025-04-11  9:00   ` Zhao Zhili
2025-04-11  9:32     ` Nicolas George [this message]
2025-04-11  9:36       ` Zhao Zhili
2025-04-11  9:52         ` Nicolas George
2025-04-11  9:19   ` Zhao Zhili
2025-04-11 11:01     ` Andreas Rheinhardt

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=Z_jhwK9YvbORpnJU@phare.normalesup.org \
    --to=george@nsup.org \
    --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