On 7/23/2019 9:39 PM, Kieran Kunhya wrote: >> >> What was the cause of the slow decoding? Does this actually fix it, or >> does it just swipe it "under the carpet"? >> If someone ever found a sample with a different solution, how would they >> know that they shouldn't just remove this again? Without any kind of >> comment on the point of this call, people might assume it's pointless >> nonsense. >> > > A significant proportion of these patches sweep the issue under the carpet. > Not to mention the swathes of annoyed developers > > Kieran
The only very vocal people so far that i could see have been you and Lynne. Everyone else at most didn't find these patches useful, but Lynne especially has been very aggressive to communicate their displeasure about fuzzing related fixes, and unjustifiably so. If some of these patches affect code you're interested into, then suggest nicer looking alternatives, like i did for the recent mpc8 patch. Patches like this one that fixes timeouts during fuzzing are usually validation checks to abort on invalid data early, and in this case they actually force an spec constrain in the correct place. They are hardly clutter. And if they use what you consider magic numbers or heuristics, or "sweep the issue under the carpet", you can always just request a comment to be placed next to them, like Reimar just did, or use some configurable value, like the recently added AVCodecContext.discard_damaged_percentage My point is, instead of complaining about UB fixes, try to be constructive about how to implement them better. Campaigning to migrate the codebase to something else than C and cut the issue from the root is more productive than replying to every other fuzzing fix like this. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
