[FFmpeg-devel] [PATCH 5/7] ffmpeg: dynamically allocate stream_maps

[Aurelien Jacobs]

On Wed, Aug 18, 2010 at 10:57:41PM +0200, Michael Niedermayer wrote:
> On Fri, Aug 13, 2010 at 08:24:18PM +0200, Aur?lien Jacobs wrote:
> > From: Aurelien Jacobs <aurel at gnuage.org>
> > 
> > ---
> >  ffmpeg.c |    8 +++++---
> >  1 files changed, 5 insertions(+), 3 deletions(-)
> > 
> > diff --git a/ffmpeg.c b/ffmpeg.c
> > index dcaaecf..9e55f01 100644
> > --- a/ffmpeg.c
> > +++ b/ffmpeg.c
> > @@ -117,8 +117,8 @@ static AVCodec **output_codecs = NULL;
> >  static int nb_output_files = 0;
> >  static int nb_output_codecs = 0;
> >  
> > -static AVStreamMap stream_maps[MAX_FILES*MAX_STREAMS];
> > -static int nb_stream_maps;
> > +static AVStreamMap *stream_maps = NULL;
> 
> > +static int nb_stream_maps = 0;
> 
> unneeded

It is actually used. Hidden behind the GROW_ARRAY() macro :-(
So yes, I understand why you don't like such kind of macro...

> also are you sure that this and the other patches arent full of exploitable
> bugs?
> previously the arrays where as large as any access could be because there
> was a global hard limit ...
> 
> have you checked that all accesses to the arrays are safe?

Yes, I've checked all accesses.

First of all, all those arrays are written only in parse_options() and
in a second time, they are only read in transcode().
The streamid_map[] array is an exception to this rule, but I've also
carefully checked all it access.
Each write to those arrays are preceded by a grow_array() call, to make
sure the array is big enough, and each read is either bounded by an
already existing check or by a check that I added.

So I'm confident that those patches are not full of exploitable bugs.

Aurel