[FFmpeg-devel] [PATCH] RV30/40 decoder

Ivan Kalvachev ikalvachev
Mon Sep 17 18:29:43 CEST 2007


2007/9/17, Michael Niedermayer <michaelni at gmx.at>:
> Hi
>
> On Mon, Sep 17, 2007 at 01:16:06PM +0100, Steve Lhomme wrote:
> > Kostya wrote:
> >> On Mon, Sep 17, 2007 at 11:34:17AM +0200, Michael Niedermayer wrote:
> >>> Hi
> >>>
> >>> On Mon, Sep 17, 2007 at 08:19:50AM +0300, Kostya wrote:
> >>>>>> +    cw = av_mallocz(size * 2);
> >>>>>> +    syms = av_malloc(size * 2);
> >>>>>> +    bits = av_malloc(size);
> >>>>> these could as well use use arrays on the stack, simplifying the source
> >>>> Table sizes vary from 16 to 1296 elements. I suspect that it's easier to
> >>>> allocate
> >>>> memory instead of remembering where 1296 came from.
> >>> then use
> >>> int bits[size];
> >> I did not know this was possible. I will give it a try.
> >
> > Not every compiler can handle this.
>
> true, only ANSI and ISO C compilers can compile ANSI and ISO C, ffmpeg is
> written in ANSI/ISO C thus requires a ANSI/ISO C compiler
> you cant compile it with a pascal, ada, fortran, basic, ... compiler

Still I find the usage of variable size stack arrays as sign for bad coding.
If you want to put assert or non-debug check of the size you are
forced put the declaration after the code (or use new block{} that is
even uglier) .
There are some limits how large the stack may grow, but they are OS
and application dependent.
And off-by-one errors are much harder to spot and debug. e.g. valgrind
won't complain, gcc -fstack-protector may catch incorrect writes but
not reads.




More information about the ffmpeg-devel mailing list