On Mon, Feb 15, 2021 at 2:04 AM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:
> Carl Eugen Hoyos:
> > Am So., 14. Feb. 2021 um 18:00 Uhr schrieb Paul B Mahol <
> one...@gmail.com>:
> >>
> >> On Sun, Feb 14, 2021 at 5:58 PM Carl Eugen Hoyos <ceffm...@gmail.com>
> wrote:
> >>
> >>> Am So., 14. Feb. 2021 um 17:53 Uhr schrieb Nuo Mi <nuomi2...@gmail.com
> >:
> >>>>
> >>>> ---
> >>>> libavformat/protocols.c | 4 ++--
> >>>> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>>>
> >>>> diff --git a/libavformat/protocols.c b/libavformat/protocols.c
> >>>> index 7df18fbb3b..0b43f66baf 100644
> >>>> --- a/libavformat/protocols.c
> >>>> +++ b/libavformat/protocols.c
> >>>> @@ -111,10 +111,10 @@ const AVClass
> >>> *ff_urlcontext_child_class_iterate(void **iter)
> >>>>
> >>>> const char *avio_enum_protocols(void **opaque, int output)
> >>>> {
> >>>> - const URLProtocol **p = *opaque;
> >>>> + const URLProtocol *const *p = *opaque;
> >>>>
> >>>> p = p ? p + 1 : url_protocols;
> >>>> - *opaque = p;
> >>>> + *opaque = (void*)p;
> >>>
> >>> I suspect that this is wrong, only avconv's protocols were const.
> >>>
> >>>
> >> That is not valid explanation.
> >
> > The warning is a regression since a merge commit from Clement (?),
> > FFmpeg's protocols are not const iirc.
> >
> It is irrelevant whether they are const: The above warning exists
> because avio_enum_protocols returns a pointer to nonconst that points to
> an entry of the const url_protocols array (i.e. it points to a const
> pointer (that points to something const, but that doesn't matter)).
> There are two ways to fix this: The first is by only giving the user a
> pointer to const which requires changing the function signature. I once
> sent such a patch, see
>
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20190821090438.10260-2-andreas.rheinha...@gmail.com/
> .
> The second way requires casts. The typical way to do so is to give the
> user an index in the array of protocols (by casting the pointer to
> intptr_t).
>
I think give the user an int may be better than a pointer. we do not need
to change the signature and we can check the boundary.
>
> - Andreas
> _______________________________________________
> 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".
