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
signature.asc
Description: PGP signature
_______________________________________________ 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".
