On Thu, May 30, 2024 at 08:49:12PM +0300, Rémi Denis-Courmont wrote: > Le torstaina 30. toukokuuta 2024, 19.48.13 EEST Tomas Härdin a écrit : > > > > Are you saying that UB is acceptable? You know the compiler is free > > > > to > > > > assume signed arithmetic doesn't overflow, right? If so then what > > > > other > > > > UB might we accept? > > > > > > He did not say that... He said we should switch to a better > > > implementation rather than trying to fix the existing potentially > > > buggy one. > > > > I have a fix for demonstrable UB and Rémi is problematizing it. > > Andreas made cosmetic arguments against this patch before I had even seen the > patch, forget comment on it. >
> > 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 If the function doesnt get called with values triggering UB then its not UB. If the function gets called with values triggering the signed overflow then its UB And its a bug unless the applications intended behavior is undefined. also i would not bet on that the function produces the correct output for input values that trigger UB on every platform The case where this really could be a problem is if its used with compile time constants that would trigger the overflow because in these cases the optimizer can assume the whole codepath leading to it can be removed. IMHO we should simply fix UB instead of arguing over how bad it could be or when. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin
signature.asc
Description: PGP signature
_______________________________________________ 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".
