[Ffmpeg-devel] [PATCH] some lzo optimizations and test code

[Michael Niedermayer]

Hi

On Sat, Jan 27, 2007 at 12:56:38PM +0100, Reimar D?ffinger wrote:
> Hello,
> attached code avoids checks for input buffer end where not needed due to
> padding (up to 5% speedup when decompressing e.g. my mplayer binary, 85
> bytes smaller code size) and adds test code.
> It might (did not think that properly about it) require the input buffer
> to be padded a bit more to avoid crashes on invalid data, but it is not
> above FF_INPUT_BUFFER_PADDING_SIZE.
> I would apply the two parts separately of course.
> Does it look fine to you?

does this not cause a truncated compressed stream to end up with random
trash at the end instead of just a truncated decompressed stream?


> And any comments about moving it to libavutil? 

ok

something entirely different ...

checks like
if(dst + cnt > c->out_end)

are not entirely safe
if for example the dst array has a address close to MAX_UINT then dst+cnt
can overflow easily making the conditon false
at first it looks harmless as the code has to segfault when it wraps around
and accesses NULL but in a multithreaded program this is not enough another
thread might use something which is after the output buffer but before the
point where a segfault will stop the program ...

changing that to (dst + cnt > c->out_end || dst + cnt < dst) should
prevent this and a optimizung compiler should be able to make
quite efficient code out of it

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070127/d4f967ac/attachment.pgp>