"Ronald S. Bultje" <[email protected]> writes: > Hi, > > 2012/2/1 Måns Rullgård <[email protected]>: >> Janne Grunau <[email protected]> writes: >> >>> On 2012-01-31 11:40:11 -0500, Justin Ruggles wrote: >>>> From: Reimar Döffinger <[email protected]> >>>> >>>> The same as av_fast_malloc but uses av_mallocz and keeps extra >>>> always-0 padding. >>>> This does not mean the memory will be 0-initialized after each call, >>>> but actually only after each growth of the buffer. >>>> However this makes sure that >>>> a) all data anywhere in the buffer is always initialized >>> >>> This feels too hacky and sounds if it's just used to silence "depends >>> on uninitilized value" valgrind warnings. >> >> Indeed, and this is the wrong way to "fix" such things. >> >> [...] >> >>>> /** >>>> + * Same behaviour av_fast_malloc but the buffer has additional >>>> + * FF_INPUT_PADDING_SIZE at the end which will will always be 0. >>>> + * >>>> + * In addition the whole buffer will initially and after resizes >>> >>> also only after buffer growth >>> >>>> + * be 0-initialized so that no uninitialized data will ever appear. >>> >>> the old data which is preserved after a buffer shrink could be also >>> considered uninitialized data. >> >> Not only could, it should. >> >> This patch should not be accepted without a better understanding of >> what problem, if any, it is intended to solve. > > A quick look at fate suggests that this tries to solve the issue of > av_realloc() not giving aligned memory, and thus using this (which > only needs a memcpy() if a new allocation was done) would fix some of > the failures we see after bswap32 was SSE'ified.
Setting memory to zero only to immediately memcpy on top of it strikes me as stupid. -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
