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".