On Sun, 2011-12-18 at 19:19 +0100, Luca Barbato wrote: > On 18/12/11 18:53, Uoti Urpala wrote: > > On Sun, 2011-12-18 at 17:20 +0000, Mans Rullgard wrote: > >> - int age; > >> + attribute_deprecated int age; > > > > IMO setting attribute_deprecated immediately is a bad idea. > > Why?
For reasons including the ones that were given immediately below, of course. > > Unless you want your application to break when used with libavcodec > > compiled yesterday you can't remove mentions of the field immediately. > > Who exactly? Anyone who uses the code (for internal Libav use you of course don't need to care about previously compiled libavcodec as the sources can be assumed to stay in lockstep). > > Thus warnings like this produce clutter that only hides real issues > > unless you disable deprecation warnings completely or add redundant > > version checks. In this case removing code setting the field now rather > > than later doesn't even give any benefit whatsoever: setting it causes no > > harm and there is no new API to test. > > Let me try to make the whole thing more understandable: > > - a custom get_buffer would have to set it in order to be compatible > with the past (it could set it depending on FF_API_AVFRAME_AGE or > equivalent version check, I think) This would require changing the code twice: first to add a version check to avoid a warning (using FF_API_AVFRAME_AGE would be a bad idea as having that left in the code would break again when the define is removed in the future), then remove the check and the code under it. That's not reasonable for trivial API changes like this. > - not setting it would break the older code. > > - setting it would trigger a warning in the new code. > > You are suggesting not to have it attribute_deprecated for a bit since > it would just add another warning you can't do much for. Yes. It should not produce a forced warning now. Having a separate method to request warnings for everything that is scheduled to be changed in the (possibly distant) future would be more appropriate. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
