On 3/9/2021 5:30 AM, Nuo Mi wrote:
On Tue, Mar 9, 2021 at 3:17 AM Chad Fraleigh <ch...@triularity.org> wrote:
On 2/14/2021 10:12 AM, Nuo Mi wrote:
On Mon, Feb 15, 2021 at 2:08 AM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:
Nuo Mi:
---
libavutil/opt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/opt.c b/libavutil/opt.c
index 590146b5fb..c554e9c063 100644
--- a/libavutil/opt.c
+++ b/libavutil/opt.c
@@ -1735,7 +1735,7 @@ const AVClass *av_opt_child_class_iterate(const
AVClass *parent, void **iter)
#if FF_API_CHILD_CLASS_NEXT
FF_DISABLE_DEPRECATION_WARNINGS
if (parent->child_class_next) {
- *iter = parent->child_class_next(*iter);
+ *iter = (void*)parent->child_class_next(*iter);
return *iter;
}
FF_ENABLE_DEPRECATION_WARNINGS
This doesn't look like a fix; you just silenced a warning.
Yes, but this the only way if we do not change the function signature.
Since a major release is "coming up", now could be the time to fix the
signature to '(..., const void **iter)' and eliminate the non-const cast
kludge across the board for these cases.
Are we plan to remove all warnings before the release?
Or more aggressively, is it feasible to treat all warnings as errors in the
future? :)
I was thinking of just the 14 or so opt iterator functions which are
assign to an AVClass.child_class_iterate (and related code in opt.c /
opt.h / their iterate callers), so they no longer have to do a de-const
(void *) cast to update *iter.
Though, it seems av_filter_iterate() and av_bsf_iterate() (maybe
others?) would need to (/should?) be changed too, as they do the same
non-const argument and are directly chained by child_class_iterate
functions.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
