On Sun, Oct 02, 2016 at 10:59:31PM -0400, compn wrote: > vp3 is a decoder written 10+ years ago by a dev who is no longer > active in ffmpeg. > > we have many decoders and encoders (and other code) in ffmpeg that have > not been audited (to my knowledge). > > i know this isnt an excuse for not looking at the code. just letting > you know the history.
Sure, I know the code is old (it is even documented as such). > please dont think carl's tone is unpleasant, maybe he is just > incredulous. Thanks for this comment. I am well aware of how hard it is to weight emotion-loaded expressions, especially when someone else looks wrong in one's expected area of competence. > carl has tested and verified thousands of bugs for ffmpeg. carl also > fixes some of them. I was quite aware of Carl's qualities, but they are surely nice to mention. > carl would like to reproduce the bug. reproducing the bug with an easy > command line, on a dev computer usually makes the bug finding and fixing > quicker. Sure. This is though (in my very humble opinion) a special kind of bug, where Carl did not have to chase the "offending code" in the C library (it is not the C library which is at fault) but directly look at libavcodec/x86/vp3dsp.asm and the places where it is used. OTOH everything seems to go very well and I am looking forward to some elegant solution, with confidence. > > To give you an example of successful code auditing, the corresponding > > UB-problem in libtheora was properly fixed without anybody at Xiph > > having to install musl. > > That's why I still believe that auditing the code is more useful than This can look misleading, sorry for that. I meant, auditing particular parts of the code, for the actual, identified problem. > > hunting once again the hard-to-pinpoint symptoms of the already known > > cause. > > do you have any suggestions for how the ffmpeg project could do > successful code audits? I would like to, but regrettably I do not have any bright ideas about this "in general". Auditing is hard. To look at the assembler routines and check for a particular UB, whether the FPU state is restored before calling C library, this has a limited scope and is what I suggested. > i really dont see much enthusiasm for line by line code auditing within > ffmpeg. in fact, i'd say people would rather re-write an entirely new > piece of code than try to clean up the old code. this isnt a knock on > anyone or any piece of code, just my observation. I can only agree with every word. Regards, Rune _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel