Alright, I'll bite, because you make some good points. Having reconsidered, I'm not entirely sure I'm in the right here anyway.

> using bits undefined behavior intended to account for platform differences to actually distort programs.

You can't really distort a program that doesn't have a valid interpretation to begin with.

> Yes. So what? The spec is harmful. It is a bad spec. It doesn't reflect C as actually written.

The spec is written to be cross-platform, and C as it is actually written typically is not cross-platform. Which is fine, actually, since generally programs don't need to run on both bare metal on a microcontroller and on a supercomputer. Portable between similar-purpose processors is enough.

The spec probably shouldn't reflect C as it is written anyway, rather C should be written to reflect the spec....

> memset, memcpy, look and act like normal functions and only have this weird undefined behavior by special dint of the relevant standards.

Can't any function do anything if that's part of its contract? We can write a div(x,y) function that deletes System32 if you divide by 0, and just say that division by zero is undefined.

> There's no reason on modern systems to make arbitrary pointer arithmetic undefined.

Fair enough.

> There is no reason to make signed integer overflow undefined either

That one is actually rather important for performance though.

> (Except, that is, for loop optimization, but that's a bullshit and lame excuse that compiler writers use to avoid having to do real bounds inference.)

https://gcc.gnu.org/contribute.html

> memset(0,0,0) to any honest person means "do nothing to zero bytes"

Yes, we really need more honest people to write compilers.

I think appealing to “honest person” or “what most people would expect” etc is a weak argument. Sometimes the correct behavior isn't what people expect, and sometimes there is no correct behavior.

> memset and memcpy of NULLs can occur in normal program logic, sometimes surprisingly

I believe that'd be an error condition. Check for NULL before you memcpy to NULL. Frankly though the circumstances where you memcpy or memset something that even could be NULL is pretty rare. Usually it's something recently allocated (stack or heap).

> Specify that it returns zero or the original value, but don't allow the compiler to consider it unreachable, trap, or do other random shit.

That would be reasonable. Perhaps some things, such as shifting, could be implementation-defined. I did, I think, ignore the idea that some undefined things could just be unspecified in my original rant.

> That's not the case with the undefined behavior that compiler writers currently exploit.

Perhaps not in all cases, but in many cases there is a good reason for undefined behavior being undefined: it doesn't make sense in the context of the C abstract machine. Derefencing a NULL pointer, for example, may be perfectly valid on an embedded CPU with no memory protection. C isn't defined to “how this should work on my x86_64 Macbook Pro,” it's defined to “how this should work—or not work—on the C abstract machine.” If on some particular implementation of the C machine that means “delete this basic block at compile time” then so be it. You're not entitled to tell compiler writers how to interpret undefined behavior.

> The tone of your post and others like it is intolerable. It is precisely victim blaming.

Yes, the evil evil compiler writers are conspiring to look good in benchmarks and poor programmers are the victims. Victims!

You are so damn ungrateful it hurts. You're not a fucking victim.

> Practically every program, even extremely well-tested ones like SQLite, contain undefined behavior.

I keep pondering whether this is a problem or not. If the compiler can't prove that it's undefined at compile time, then it just depends on the processor and the only problem is that your program is not portable to obscure special-purpose architectures. On the other hand, the fact that any non-trivial program needs to invoke undefined behavior is pretty damning evidence that the spec is insufficient.

I think, ultimately, I concede that the C standard is flawed. But please get over your fucking entitlement complex about how compiler writers take more liberties with UB than you would.