[FFmpeg-cvslog] r20485 - in trunk/libavcodec: lsp.c lsp.h qcelpdec.c
Mon Nov 9 18:07:07 CET 2009
M?ns Rullg?rd wrote:
> vitor <subversion at mplayerhq.hu> writes:
>> Author: vitor
>> Date: Mon Nov 9 13:06:19 2009
>> New Revision: 20485
>> Do not hardcode filter order in ff_acelp_lspd2lpc()
>> Modified: trunk/libavcodec/lsp.c
>> --- trunk/libavcodec/lsp.c Mon Nov 9 10:11:35 2009 (r20484)
>> +++ trunk/libavcodec/lsp.c Mon Nov 9 13:06:19 2009 (r20485)
>> @@ -155,20 +155,19 @@ static void lsp2polyf(const double *lsp,
>> -void ff_acelp_lspd2lpc(const double *lsp, float *lpc)
>> +void ff_acelp_lspd2lpc(const double *lsp, float *lpc, int lp_half_order)
>> - double pa, qa;
>> - int i;
>> + double pa[lp_half_order+1], qa[lp_half_order+1];
> Sorry I didn't spot this earlier, but we really should avoid
> variable-length arrays. Compilers do the silliest things with them.
> For instance, gcc will not inline a function with a VLA.
I can vaguely understand why a compiler would do that (at least if the
caller do not pass the length as a constant).
> compilers call malloc() to allocate the array, and still some silently
> miscompile the code. That is in addition to being an inherently bad
> idea. If the allocation fails, you have no chance in hell of
I suppose the compiler is trying to work-around stupid coders that
allocate several MB this way :p
> In this case, I would suggest setting a sensible upper limit, maybe 8
> or 16, and using fixed-size arrays.
Fine by me, patch attached.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1242 bytes
Desc: not available
More information about the ffmpeg-cvslog