[FFmpeg-devel] [PATCH 2.0/3] libavformat/protocols.c: avio_enum_protocols(): Add more const-correctness

[Michael Witten]

| Michael Witten:
|
|   > -const char *avio_enum_protocols(void **opaque, int output)
|   > +const char *avio_enum_protocols(void **const opaque, const int output)
|
| Andreas Rheinhardt:
|
|   > This thing makes nothing more const-correct at all; C uses call be
|   > value, so we only deal with our own copy of opaque which we may modify
|   > as we please.
|   > The reason for the const-incorrectness lies in the fact that this
|   > function makes *opaque point to something const (namely an entry in a
|   > const list of pointers (each pointing to a const protocol, but that is
|   > irrelevant)), so that the user now has a pointer whose pointed to-type
|   > is not const-qualified, despite the actual target being const.
|   > See here:
|   > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20190821090438.10260-2-andreas.rheinhardt@gmail.com/
|   > for how to fix the const-correctness if one wants to keep the general
|   > design of the functions. See libavformat/allformats.c,
|   > libavcodec/allcodecs.c, libavfilter/allfilters.c for the other approach
|   > (that involves storing an index in the pointer).
|   >
|   > - Andreas

* The general design of the functions has not been altered by this series.

* The previous patch fixed the const incorrectness as warned by the compiler.
  This patch merely improves the const correctness in general.

* We don't want to modify those parameters as we please, and so we'd like
  to ask the compiler to remind us of that fact as necessary.

  It's const-correct in the sense that it expresses the following fact: Those
  variables are not going to be changed; if there is no intention to modify a
  variable, then it's good practice to mark that variable as const.

  Because this function is being edited, it's a good time to sprinkle
  the 'const' keyword around, as a matter of mental hygiene.

Sincerely,
Michael Witten