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