Quoting Zhao Zhili (2023-12-25 10:27:59) > > > > On Dec 25, 2023, at 16:38, Anton Khirnov <an...@khirnov.net> wrote: > > > > Quoting Kacper Michajlow (2023-12-24 11:41:52) > >> On Fri, 22 Dec 2023 at 14:57, Anton Khirnov <an...@khirnov.net> wrote: > >>> > >>> Quoting Andreas Rheinhardt (2023-12-22 14:48:45) > >>>> Avoids relocations. > >>>> > >>>> Signed-off-by: Andreas Rheinhardt <andreas.rheinha...@outlook.com> > >>>> --- > >>> > >>> Maybe mention that it's not needed after > >>> acf63d5350adeae551d412db699f8ca03f7e76b9. > >> > >> This is not the only user of this API, no? > >> > >> I have a question for my own curiosity. This is ABI (and API) breaking > >> change, > > > > It is not. This item was not guaranteed to be set, which was actually > > the reason I wrote the patch that this one refers to. > > There is no problem to relax a restriction inside libavutil. However, since > there is > no explicit documentation on whether item_name can be null or not, user may > make > incorrect assumptions and depend on item_name not being null. I don’t think > break > user’s code suddenly is a good idea, although we can say it’s break since the > beginning.
My point is that the restriction never existed. There were always AVClass instances that did not set that pointer. There were fewer of them, but they did exist. -- 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".
