Re: [FFmpeg-devel] [PATCH 1/5] lavu/common.h: Fix UB in av_clipl_int32_c()

["Tomas Härdin" <git@haerdin.se>]

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-request@ffmpeg.org with subject "unsubscribe".