3 ms·

So it should never do function inlining, or replace multiplication by two with a bit shift? Because both of them quite fit "invisibly modifying non-dead code du

So it should never do function inlining, or replace multiplication by two with a bit shift? Because both of them quite fit "invisibly modifying non-dead code during translation". > or it could do what you fracking told it to, consequences be damned Yes, that's precisely what happens. The point is agreeing on what you "told it". The agreement stipulated in the standard is that in some cases (when you hit UB) you're effectively not agreeing on anything, i.e., the compiler can do what it want. If that's not what you like, please let me know what should be mandated in the case of the fragment I wrote above, and how a compiler could offer that guarantee in an efficient and effective manner.

torstenvl 3y ago
As to your first point: fair. It shouldn't modify it in a semantically material way. > that's precisely what happens No, it really isn't. Numerous compilers do static analysis to identify code that could be UB and then mangle it to mean something entirely different or eliminate it entirely. And if the compiler really did already do this, you wouldn't need to resort to... > the compiler can do what it want[s] Under current standards, yes, but that's a circular and nonsensical argument. You can't base your argument on what the standard permits when the very content of what the standard should be is the topic of discussion. > please let me know what should be mandated I already responded. The ANSI C standard is clear, and the modification to that language in subsequent ISO standards is, in my opinion, ill-advised.