[FFmpeg-devel] [PATCH 1/3] lavformat: Prepare to make avio_enum_protocols const correct

Fu, Linjie linjie.fu at intel.com
Fri Mar 20 03:58:00 EET 2020


> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Andreas Rheinhardt
> Sent: Wednesday, March 18, 2020 21:29
> To: ffmpeg-devel at ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 1/3] lavformat: Prepare to make
> avio_enum_protocols const correct
> 
> Fu, Linjie:
> Yes, updating the callers is necessary (as I already said in the commit
> message), but easy. The typical old call is (the ... usually includes a
> loop):
> void *opaque = NULL;
> char *name;
> 
> ...
> name = avio_enum_protocols(&opaque, flag);
> ...
> 
> Changing the type of opaque to const void* will make this code
> const-correct. (The opaque now points to one of the constant pointers in
> the url_protocols array, so the user having a pointer to nonconst to
> them is wrong.)
> 
> - Andreas
> 
> PS: The reason that the callers need to update their code is that there
> is no automatic conversion from type ** to const type **, so that an
> explicit cast is required. Such an automatic conversion would be
> dangerous as it could be used to remove const from any pointer without a
> cast. See http://c-faq.com/ansi/constmismatch.html
> PPS: There would be another way to get rid of this warning: Instead of
> making the void **opaque store a pointer to a pointer to a const entry
> of the url_protocols array one make the opaque point to a value of type
> uintptr_t that stores an index in the url_protocols array. This would
> still require a cast, but it would not cast const away. But I don't
> really like this approach, as forcing the user to use pointers to const
> void makes it clearer that the user is not to meddle with the opaque.

No more concerns, this fix looks reasonable.
Thanks for the kind elaborations.

- Linjie


More information about the ffmpeg-devel mailing list