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

[Michael Niedermayer]

On Tue, Jan 24, 2023 at 12:22:52AM +0100, Marton Balint wrote:
> 
> 
> 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.

if you want to avoid this then, new type, new identifer

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20230124/4d52e531/attachment.sig>