From: Anton Khirnov <anton@khirnov.net>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH] all: Don't set AVClass.item_name to its default value
Date: Mon, 25 Dec 2023 11:21:00 +0100
Message-ID: <170349966005.1197.18118321711098584989@lain.khirnov.net> (raw)
In-Reply-To: <tencent_0113F2536CD5C549032EBA6542330BE84B05@qq.com>
Quoting Zhao Zhili (2023-12-25 10:27:59)
>
>
> > On Dec 25, 2023, at 16:38, Anton Khirnov <anton@khirnov.net> wrote:
> >
> > Quoting Kacper Michajlow (2023-12-24 11:41:52)
> >> On Fri, 22 Dec 2023 at 14:57, Anton Khirnov <anton@khirnov.net> wrote:
> >>>
> >>> Quoting Andreas Rheinhardt (2023-12-22 14:48:45)
> >>>> Avoids relocations.
> >>>>
> >>>> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
> >>>> ---
> >>>
> >>> Maybe mention that it's not needed after
> >>> acf63d5350adeae551d412db699f8ca03f7e76b9.
> >>
> >> This is not the only user of this API, no?
> >>
> >> I have a question for my own curiosity. This is ABI (and API) breaking
> >> change,
> >
> > It is not. This item was not guaranteed to be set, which was actually
> > the reason I wrote the patch that this one refers to.
>
> There is no problem to relax a restriction inside libavutil. However, since there is
> no explicit documentation on whether item_name can be null or not, user may make
> incorrect assumptions and depend on item_name not being null. I don’t think break
> user’s code suddenly is a good idea, although we can say it’s break since the beginning.
My point is that the restriction never existed. There were always
AVClass instances that did not set that pointer. There were fewer of
them, but they did exist.
--
Anton Khirnov
_______________________________________________
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:[~2023-12-25 10:21 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-22 13:48 Andreas Rheinhardt
2023-12-22 13:57 ` Anton Khirnov
2023-12-24 10:41 ` Kacper Michajlow
2023-12-25 8:38 ` Anton Khirnov
2023-12-25 9:27 ` Zhao Zhili
2023-12-25 10:21 ` Anton Khirnov [this message]
2023-12-25 10:47 ` Zhao Zhili
2023-12-27 14:19 ` Kacper Michajlow
2023-12-28 23:42 ` Marton Balint
2023-12-29 2:01 ` Zhao Zhili
2023-12-22 15:11 ` Rémi Denis-Courmont
2023-12-22 16:13 ` Andreas Rheinhardt
2023-12-22 16:20 ` Rémi Denis-Courmont
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=170349966005.1197.18118321711098584989@lain.khirnov.net \
--to=anton@khirnov.net \
--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