[FFmpeg-devel] [PATCH 03/12] mdct: remove temporary array in ff_kbd_window_init()

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> On Thu, Jun 24, 2010 at 01:58:04AM +0100, M?ns Rullg?rd wrote:
>> Michael Niedermayer <michaelni at gmx.at> writes:
>> 
>> > On Thu, Jun 24, 2010 at 01:35:06AM +0100, M?ns Rullg?rd wrote:
>> >> Michael Niedermayer <michaelni at gmx.at> writes:
>> >> 
>> >> > On Thu, Jun 24, 2010 at 12:37:34AM +0100, M?ns Rullg?rd wrote:
>> >> >> Michael Niedermayer <michaelni at gmx.at> writes:
>> >> >> 
>> >> >> > On Wed, Jun 23, 2010 at 06:26:41PM +0100, Mans Rullgard wrote:
>> >> >> >> The intermediate values can be stored in the output array, avoiding
>> >> >> >> the need for a variable-length array.
>> >> >> >
>> >> >> > this can write into static arrays and thus introduces a race condition
>> >> >> 
>> >> >> Quite.  Which would you prefer then, 1) malloc/free or, 2) always
>> >> >> allocating a [1024] array (largest size used)?  Option 2 would use 4k
>> >> >> (float) or 8k (double) of stack space, which is IMO a bit larger than
>> >> >> what's comfortable.  It would of course not change anything compared
>> >> >> to current code so should be safe.
>> >> >
>> >> > as its speed irrelevant init code iam ok with malloc()
>> >> 
>> >> Using malloc complicates error handling though.  The function
>> >> currently returns no status (since it cannot fail), and the callers
>> >> obviously do not check it.
>> >> 
>> >> Since allocating a 1024-element array is fine now, it should be OK
>> >> even if hardcoded.  Do you forsee larger sizes being required in the
>> >> future?
>> >
>> > The future is in perpetual motion, iam not capable to say anything
>> > with certainity but i feel some remote danger. Maybe some dark plan of the
>> > high comiitee or some noble warrior whos heart was not strong enough
>> > while walking to close to darkness.
>> > One of them might create a spec that requires a larger window.
>> 
>> Try to be serious for once.  If I read that correctly, you're saying
>> you don't know of anything that would need a larger window, and are
>> certainly not working on any such code at the moment.  I therefor
>
> yes
>
>> propose setting the max size to 1024 and stating this clearly with a
>> comment and a #define.  If we ever need it larger, we can deal with it
>> then.
>
> please make it an assert too

Done.

-- 
M?ns Rullg?rd
mans at mansr.com