[FFmpeg-devel] [PATCH 03/12] mdct: remove temporary array in ff_kbd_window_init()
Thu Jun 24 03:34:46 CEST 2010
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  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
please make it an assert too
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel