[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: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
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.

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