[pcwalton]

You misunderstood the problem. The problem isn't that programmers can't write loops that are easy to optimize. It's rather that, in practice, they don't write loops that are easy to optimize. That's ultimately a problem with the C language.

[dsfuoi]

If the loops can be written and the programmers don't write them, the problem is with the language!?

No, it's pretty clear where the problem is with C, programmers.

[pcwalton]

The easiest way to write the loop is the way that is hard to optimize. This is a fact that is beyond dispute: empirically, programmers use int to index over arrays in for loops without writing asserts. That is in fact a problem with the language.

[dsfuoi]

programmers use int to index over arrays in for loops without writing asserts. That is in fact a problem with the language.

Ok let me get this clear, you're saying that the language is at fault because the programmers don't write correct code. I have no words.

[stouset]

Emphatically yes.

When designing tools for use by humans, you need to accept the fact that humans, with all our failings, will be the ones using the tools. So tools should be made resilient against typical ways in which humans fail.

We've been paying for shortcomings in C's design for decades with bugs and security failures that simply don't happen in other languages. That you refuse to see this is baffling to me.

[pcwalton]

> Ok let me get this clear, you're saying that the language is at fault because the programmers don't write correct code.

Yes.

A good language makes the correct thing the easy thing.

[rdc12]

When a common idiom becomes the wrong way to do something, someone messed up pretty badly (and preexisting idiom at that).

Arguably the designers of amd64 should have caught this before releasing the ABI or the language design could have been specified so this wasn't an issue in the first place.