[FFmpeg-devel] [PATCH 00/26] Major library version bump

[Marton Balint]

On Mon, 23 Jan 2023, Anton Khirnov wrote:

> Quoting Marton Balint (2023-01-23 23:41:11)
>> On Mon, 23 Jan 2023, Anton Khirnov wrote:
>>> Quoting Marton Balint (2023-01-21 23:00:52)
>>>> AVCodecContext->frame_number should be changed to int64_t. I guess you
>>>> could do something similar which was done for buffer_size_t, but that
>>>> seems like a lot of extra work and ifdefry for questionable benefit.
>>>
>>> Not breaking callers seems like a very solid benefit to me.
>>
>> I am not sure if I see your point, during unstable, you can break callers,
>> and I planned to do the change during unstable.
>
> My understanding of this instability period is that it's mainly for ABI
> changes like reordering struct fields and such, you're still not allowed
> to arbitrarily break random APIs. The entire point of having deprecation
> periods is that callers can prepare in advance and never actually be
> broken.

If some fields or API is deprecated, then yes, it makes sense. But if no 
deprecation / replacement API is provided, then how will anybody prepare?
For type changes, fields are usually not deprecated. Ifdefs are only used 
to prepare the changes for the next API bump. For example, buffer_size_t 
was in the codebase for 2 months only.

It is not that big of a deal to make a patch if #ifdefs, I just really 
don't see the benefit.

An actual problem however, is that printf() like functions expect type 
specifiers, and unlike buffer sizes, there is a good chance the users 
sometimes print AVCodecContext->frame_number or 
AVFrame->xxx_picture_number, which will become undefined behaviour. And 
yes, the compiler will usually warn, but still, type changes can cause 
silent breakage. But using #define API guards will not fix this, whenever 
you change the type, code will get broken, I am not sure if anything can 
be done about it.

Regards,
Marton

>
> -- 
> Anton Khirnov
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>