tor 2024-05-30 klockan 20:49 +0300 skrev Rémi Denis-Courmont: > Le torstaina 30. toukokuuta 2024, 19.48.13 EEST Tomas Härdin a écrit > > It is not a "theoretical" UB - that's not how UB works. > > It is a *theoretical* UB if you can not prove that it leads to > misbehaviour in > any *practical* use. In theory, all UB is *potentially* fatal. > Emphasis on > potentially.
The issue is that compilers can change without notice > > Any compiler doing > > basic value analysis will find it, and is therefore free to do > > whatever > > it wants, for example deleting all calls to av_clipl_int32_c(). > > That is formally true. But it is also formally true that, by that > same logic, > since there is most certainly some UB instance left elsewhere in the > codebase, > the entirety of libavutil could be elided by the compiler. I mean, part of what I'm doing with my little value analysis experiment is finding these instances of UB throughout lavu and fixing them, so that no compiler will perform what we might consider dubious or unexpected optimizations. It is far more powerful than fuzzing when it comes to discovering bugs I'm looking at rational.c at the moment, and there are definitely some dubious codepaths. There have also been fixes for signed overflow in rational.c already. I wouldn't be surprised if there are more corner cases that can be triggered by some demuxer or decoder that fuzzing hasn't discovered yet Maybe in some glorious future we'll have a version of C where signed overflow is defined behavior /Tomas _______________________________________________ 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".
