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? :)
>
>
> -Chad
> _______________________________________________
> 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".
_______________________________________________
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".
