On Fri, Mar 01, 2013 at 10:45:41PM +0100, Anton Khirnov wrote:
> On Fri, 01 Mar 2013 21:44:49 +0100, Diego Biurrun <di...@biurrun.de> wrote:
> > On Fri, Mar 01, 2013 at 09:35:24PM +0100, Anton Khirnov wrote:
> > > On Fri, 01 Mar 2013 20:59:21 +0100, Diego Biurrun <di...@biurrun.de>
> > > wrote:
> > > > On Fri, Mar 01, 2013 at 08:50:31PM +0100, Anton Khirnov wrote:
> > > > > On Thu, 28 Feb 2013 21:25:01 +0100, Diego Biurrun <di...@biurrun.de>
> > > > > wrote:
> > > > > > --- a/libavcodec/internal.h
> > > > > > +++ b/libavcodec/internal.h
> > > > > > @@ -67,7 +68,7 @@ typedef struct AVCodecInternal {
> > > > > > * Internal sample count used by avcodec_encode_audio() to
> > > > > > fabricate pts.
> > > > > > * Can be removed along with avcodec_encode_audio().
> > > > > > */
> > > > > > - int sample_count;
> > > > > > + attribute_deprecated int sample_count;
> > > > > > #endif
> > > > >
> > > > > Internal API -> no point
> > > >
> > > > Why? Devs can still go ahead and misuse deprecated API w/o noticing.
> > > > The warnings are supposed to prevent that ...
> > >
> > > Since they are private, the only reason they are kept is that they still
> > > have
> > > some use. So you will add spurious warnings.
> >
> > Well, yes, that's the whole point: Add warnings for each use. That might
> > motivate people to fix the warnings and deter new uses of deprecated
> > functionality being introduced.
>
> The point is -- if that stuff is not removed, it's because it CANNOT be
> removed
> until the major bump. There is no way to "fix" those warnings, other than
> bumping major.
Do you by "that stuff" refer to the API itself or to its users? Of course
the API cannot be removed before bumping major ..
The one remaining use of the struct member will generate a warning, yes,
but that is intentional. At least it is the price to pay for avoiding
that new accidental uses of that member are added. They will be noticed
by now triggering a warning...
Diego
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
