[Ffmpeg-cvslog] r6733 - trunk/libavformat/mov.c

[Michael Niedermayer]

Hi

On Thu, Oct 19, 2006 at 12:45:31PM +0200, Baptiste Coudurier wrote:
> michael wrote:
> > Author: michael
> > Date: Thu Oct 19 12:05:36 2006
> > New Revision: 6733
> > 
> > Modified:
> >    trunk/libavformat/mov.c
> > 
> > Log:
> > dont mess with ByteIOContext internal variables (fixes showdown2.mov)
> > 
> > 
> > Modified: trunk/libavformat/mov.c
> > ==============================================================================
> > --- trunk/libavformat/mov.c	(original)
> > +++ trunk/libavformat/mov.c	Thu Oct 19 12:05:36 2006
> > @@ -1348,7 +1348,7 @@
> >  #ifdef CONFIG_ZLIB
> >  static int null_read_packet(void *opaque, uint8_t *buf, int buf_size)
> >  {
> > -    return -1;
> > +    return buf_size;
> >  }
> >  
> 
> Nice it does work indeed. However isn't that dangerous ? Each time
> fill_buffer will be called it will return buf_size and if atom.size is
> fucked by any way (we read it from file), that will lead to memleak.
> 
> Maybe memory should be handled differently by ByteIOContext.

i cant see any obvious memleaks which are caused by my change, so please
elaborate how that should lead to a leak ...

also note, if the uncompress() fails then you will have a leak but that
was already there before my change

also it seems that just duplicating some atoms will lead to a leak
as theres no check if something has already been allocated and loaded
its generally just a malloc() + fill array
it should rather be if(array) fatal_error; malloc(); fill it

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is