UB is not impossible; I think the author is being a little cheeky there. But the standard does grant compilers extreme liberties as far as how they deal with programs which can execute UB. LLVM's choice of what to do with that liberty, in this case, seems to be to assume the UB is unreachable and continue legally optimizing the program under that assumption. That's not a wrong assumption according to the definition of C.

It's debatable whether it's a good assumption. But not wrong.

> UB is clearly undesirable, but assuming it is impossible and deducing other outcomes must be meant are clearly wrong assumptions by the compiler writer.

Compilers can and absolutely do assume that UB is impossible in this code (no integer overflow) and deduce other outcomes must be meant (the loop operates on contiguous memory):

  void foo(char* arr, int32_t end)
  {
    for (int32_t i = 0; i != end; ++i)
      arr[i] = 0;
  }

(Based on code from the gist comments.)

Assuming undefined behavior is impossible is a way for the compiler to optimize code. In fact, it is the main reason why UB exists.

It is exemplified by the C++23 std::unreachable() function, its description is "invokes undefined behavior". It is intended to mark part of the code that are unreachable, so that they don't appear in optimized builds, but may appear in debug builds. It is an explicit use of "the power of UB", an optimizing compiler considers that calling std::unreachable() is impossible, so all code paths that lead to it can be safely pruned. In an debug build, the code may be generated anyways, and the compiler will chose something sensible for what happens when it is called, typically a crash, but it can be anything, it is UB.

From where I stand many of do-what-i-mean programming languages are doing just great in distributed computing, Web and mobile OSes, taking over roles that used to be done in C and C++ during the last century.

A better way to phrase it is that UB means "anything can happen". This, by definition, includes calling the function even though the pointer is null.

I think 'anything can happen' needs to be extended to the C standards committee's bank accounts.