Quoting Marton Balint (2023-01-24 01:06:46) > On Tue, 24 Jan 2023, Michael Niedermayer wrote: > > 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: > >>>>> 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 > Sure, but do we want AVFrame->coded_picture_number64, > AVFrame->display_picture_number64
Are these even useful for anything? The don't seem like they belong in AVFrame. -- Anton Khirnov _______________________________________________ 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".
