Quoting Nicolas George (2019-12-31 15:01:03) > Anton Khirnov (12019-12-29): > > Maybe I missed something, but I am not aware of the UB-ness of signed > > overflow being a practical problem. Typically, your computation will > > return a meaningless result. You would get a similarly meaningless > > result from the analogous perfectly well-defined unsigned computation. > > > > to be clear: I am not objecting against fixing UB, but clarifying my > > 'theoretical gain' comment above. > > It seems you have missed some of the drama that happened on this list > recently. Michael and others have been intent on fixing the UB caused by > integer overflows, including cases that I personally find futile. > > But I do not consider this case futile: a channel number will typically > be used as an array index, and an invalid value will cause an invalid > memory access and a segmentation fault, or an exploitable memory > corruption. > > What makes signed overflows, which are UB, worse than unsigned > overflows, which are completely specified, is that you cannot guard > against it. For example, if your write: > > if (ch < 0 || ch >= nb_channels) > return AVERROR_BUG; > > you think you are safe, but if the compiler detects that ch cannot be > negative without overflow, it will silently discard the ch<0 test. Then, > if the overflows does happen, there is no protection against invalid > memory access. > > And this is not theoretical: I have seen entire blogs and twitter > accounts dedicated to posting examples of actual cases where an > optimizing compiler produces very unintuitive code because there is a > tiny UB in the middle.
How is it any better in the unsigned case? You do a well-defined unsigned overflow and end up with an invalid channel count (which might even look sane). -- Anton Khirnov _______________________________________________ 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".
