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

[Andreas Rheinhardt]

Derek Buitenhuis:
> On 21/08/2019 10:04, Andreas Rheinhardt wrote:
>> +#if FF_API_NONCONST_ENUM_PROTOCOLS
>>  const char *avio_enum_protocols(void **opaque, int output)
>> +#else
>> +const char *avio_enum_protocols(const void **opaque, int output)
>> +#endif
> 
> Do we actually allow breakage like this (even at major bumps)?
> 
> That is, you are not using a new function name, but breaking an existing
> function signature. As far as I know, this is not somthing that we, or
> semver, allow.

There have been several such breakages in the past, at least in relation
to const:
Looking through some headers with git blame leads to the following
commits which add const to the type of the pointed-to type:
9b07d34e, b90d7840, 53abe324, c4ba5198, 069cf86d, 0d34dbc2, 5bb3f882,
adb0e941, 0a0f19b5, 2d3acbfe, 74aeb6b5, 7215fcf8, 77cc958f, 4a37d4b3,
cc4c2420, 0020c54c.
2d3acbfe furthermore changed the return value of a public function from
AVCodecDescriptor * to const AVCodecDescriptor *; f2c86705 and 5c439b41
did something similar.

Except for f2c86705, none of these commits bumped any version. None
added an APIchanges entry; 5c439b41 was the only one that waited until
the next major version bump with its changes.

Furthermore, several such changes are planned for libavformat. Just
search for ff_const59 in avformat.h. 3aa6208d even changed AVInputFormat
** to const AVInputFormat **. (I pondered whether I should piggyback on
this (and use ff_const59 myself), but in the end decided against it. I'd
choose differently now.)

Furthermore, I don't see where semver disallows changing the signature
of a function. After all, breaking changes are explicitly allowed at
major version bumps. But we should probably add an entry in APIchanges
for this change and all the other ff_const59 changes.

(Looking through APIchanges also leads to 2c031741 and 84c03869, but
given that the latter of these only incremented minor despite breaking
API/ABI and the former didn't increment the version at all despite
breaking API/ABI makes them bad precedents. Lest I forget: av_malloc()
and other memory-allocation functions did not start with size_t parameters.)

- Andreas

PS: Actually, there are a couple of functions that need const:
av_find_best_stream() provides a way to get a pointer to a non-const
AVCodec (it casts the const away internally); and
av_input/output_audio/video_device_next() needs either be modified to
work with const or be deprecated altogether (as the other _next-APIs
have been).