[FFmpeg-devel] [PATCH] lavf/protocols: Fix compile warning of discarding 'const' qualifier from pointer target type
Andreas Rheinhardt
andreas.rheinhardt at gmail.com
Wed Mar 18 06:51:55 EET 2020
Linjie Fu:
> Signed-off-by: Linjie Fu <linjie.fu at intel.com>
> ---
> libavformat/protocols.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/protocols.c b/libavformat/protocols.c
> index f1b8eab..cb19f77 100644
> --- a/libavformat/protocols.c
> +++ b/libavformat/protocols.c
> @@ -95,9 +95,9 @@ const AVClass *ff_urlcontext_child_class_next(const AVClass *prev)
>
> const char *avio_enum_protocols(void **opaque, int output)
> {
> - const URLProtocol **p = *opaque;
> + URLProtocol **p = *opaque;
>
> - p = p ? p + 1 : url_protocols;
> + p = p ? p + 1 : (URLProtocol **)url_protocols;
> *opaque = p;
> if (!*p) {
> *opaque = NULL;
>
1. The actual problem with this code is not that the URLProtocols are
const (which they are), but that the pointers in the url_protocols array
are constant pointers (to const URLProtocol); yet the way things are
right now the user gets a non-const pointer to these const pointers (to
const URLProtocol).
2. It follows from this that changing the type of p in the way you did
it is actually unnecessary (if one wanted to solve the problem by
casting const away, you could cast url_protocols to (const URLProtocol
**) (from const URLProtocol * const *)) and a step in the wrong
direction (given that the underlying URLProtocol is const).
3. Casting const away is generally a sign of bad design and this is no
exception. The signature is wrong, the opaque should be const void**, so
that the user never gets a chance to get a pointer to nonconst to
something that is actually const.
4. See [1] for an approach that fixes the underlying issue.
- Andreas
[1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/248675.html
More information about the ffmpeg-devel
mailing list