On Thu, Sep 08, 2011 at 10:24:40AM +0200, Kostya Shishkov wrote:
> On Thu, Sep 08, 2011 at 09:57:04AM +0200, Laurent Aimar wrote:
> > On Thu, Sep 08, 2011 at 09:09:14AM +0200, Kostya Shishkov wrote:
> > > On Wed, Sep 07, 2011 at 09:43:03PM +0200, Laurent Aimar wrote:
> > > > ---
> > > > libavcodec/wavpack.c | 4 ++--
> > > > 1 files changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/libavcodec/wavpack.c b/libavcodec/wavpack.c
> > > > index 62f6880..0a70c4c 100644
> > > > --- a/libavcodec/wavpack.c
> > > > +++ b/libavcodec/wavpack.c
> > > > @@ -841,12 +841,12 @@ static int wavpack_decode_block(AVCodecContext
> > > > *avctx, int block_no,
> > > > }
> > > > switch(id & WP_IDF_MASK){
> > > > case WP_ID_DECTERMS:
> > > > - s->terms = size;
> > > > - if(s->terms > MAX_TERMS){
> > > > + if(size > MAX_TERMS){
> > > > av_log(avctx, AV_LOG_ERROR, "Too many decorrelation
> > > > terms\n");
> > > > buf += ssize;
> > > > continue;
> > > > }
> > > > + s->terms = size;
> > > > for(i = 0; i < s->terms; i++) {
> > > > s->decorr[s->terms - i - 1].value = (*buf & 0x1F) - 5;
> > > > s->decorr[s->terms - i - 1].delta = *buf >> 5;
> > > > --
> > >
> > > Since s->terms is used elsewhere it's better just to set it to zero inside
> > > that if() IMO.
> >
> > The idea was to not have a value of s->terms that is greater that the size
> > of the
> > associated array which cannot be with this patch.
>
> true
>
> > I don't know if setting it to 0 here make sense or if it wouldn't be better
> > to set
> > it to 0 elsewhere as I am not the maintainer.
>
> It's initialised here and on error it would use random (last correct) value
> for it. Not that it really matters since decoding won't start anyway because
> of decorrelation terms not being decoded.
I can send a patch setting s->terms to 0 but it would make the case of
WP_ID_DECTERMS a special case (other errors in WP_ID_* errors do not reset
their associated variables).
As you prefer.
--
fenrir
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
