Re:Falsehoods programmers believe about undefined behavior
by caf on Monday November 28, 2022 @09:07AM
(#33773778)
No, that transformation is straight-up buggy unless the compiler can also prove that n > 0 (ie by inlining the bar() function into a context where n is always positive).
If you had *p == 0 before calling bar(p, 0) then *p had better not be 1 after!
Re:Falsehoods programmers believe about undefined behavior
by MushyQuadrant on Monday November 28, 2022 @12:45PM
(#33776756)
The first form has no undefined behavior. Since p may be NULL, in general the compiler is not allowed to make that transformation unless it can prove bar never gets called with p=NULL and n=0 (which it probably can't).
If the compiler has some special knowledge of the target architecture which makes the second form behave as if the first form was executed (such as if NULL is a valid address on the target architecture), it may make the transformation, but that still wouldn't cause undefined behavior, because it must behave as if it had the first form.
Can someone with more knowledge chip in? If I define
it might get optimized via loop-invariant code motion to so it could still be UB when called with p=NULL and n=0, right?