On Tue, 7 Jan 2025 at 16:19, Frank Mehnert <frank.mehn...@kernkonzept.com> wrote: > > On Dienstag, 7. Januar 2025 15:55:28 MEZ Kjetil Oftedal wrote: > > On Tue, 7 Jan 2025 at 15:33, Frank Mehnert > > <frank.mehn...@kernkonzept.com> wrote: > > > [...] > > > > > > With offset=1 and x=0xffffffff'fffffff, y will 0, so y does not belong to > > > the same object as x. There is no other value of x which could lead to a > > > result y<x with offset=1! > > > > > > The comparison tests the wrap around and adapts end_ptr in that case. > > > > > > Again: If there was a wrap around, then the pointer arithmetic operation > > > was wrong (undefined behavior). Hence, we can remove the test plus the > > > code > > > which is executed if the test succeeds. > > > > [...] > > > > I see the point. I just don't agree with the conclusion. > > As I see it the LLVM group is claiming that if there is any possiblity for > > UB, > > even if it is dependent on input arguments, then it is always UB, and > > the compiler can > > remove code as it sees fit. (Which will be a nightmare for security code) > > I admit I thought so some time ago but in my opinion you do a wrong > conclusion: > > There is a test in the code. > > The result of the test can _only_ be true if the code before the test > triggered undefined behavior. > > In other words, if the test succeeded, then we can be sure that the test > compared two pointers belonging to different objects -- which is undefined > behavior. > > Therefore, the compiler is fine removing the test because the compiler does > not support the case where the test result is true. > > If the test result is false, everything is fine, both objects may or may not > point to different objects, but the compiler assumes that they do. But: If > the test result is false, end_ptr does not need an adaption, therefore that > line can be optimized out. > > TBH, I'm still convinced that the compiler is right. :-) > > Frank > -- > Dr.-Ing. Frank Mehnert, frank.mehn...@kernkonzept.com, +49-351-41 883 224 > > Kernkonzept GmbH. Sitz: Dresden. Amtsgericht Dresden, HRB 31129. > Geschäftsführer: Dr.-Ing. Michael Hohmuth >
Let us flip the variables around and review: E.g. if ( str < end_ptr ) instead of if ( end_ptr < str ) Should the compiler then always evaluate the clause to true? end_ptr might still be lower than str due to overflow in the artihmetic. Best regards, Kjetil Oftedal _______________________________________________ devel mailing list -- devel@uclibc-ng.org To unsubscribe send an email to devel-le...@uclibc-ng.org
