It’s lower performance in the one situation of iterating on an 8bit ASCII string for programs written 30 years ago but faster in more common uses. Multibyte doesn’t matter when everything is 64 bit. A 64 bit length counter is long enough for everything but the most edgy of edge cases. You take a performance hit if you aren’t aligned.

Can you tell where the end of this string is: “ABCDEFGH”? What about now: “ABCD\0EFGH”?

No because unicode and binary formats means a string can contain anything.

You answered your own question. Strings with length are better than null terminated. It is a mistake in the original C language library and probably a hack because the pdp11 used asciz format.

So the language is not as low level as it was before.

But it’s the hardware that has changed not C. As I said, with his argument Assembly isn’t a low level programming language either.

Besides, early risc cpus from the 80’s had out of order write back so this isn’t new. By the 90’s all risc were ooe. The first was the ibm 360 from the 1960’s.

I’d say C is still in the same place on the abstraction ladder it’s always been, but the floor is deeper nowadays (and the top probably higher as well).

I agree!

The author is confusing two completely different things and comes to a wrong conclusion.

He states that C isn’t low level because CPU are much more complex today. But those aren’t related. His argument would be no different if he claimed assembly isn’t a low level language.

That the CPU speculatively executes instructions and maintains many levels of cache doesn’t change that C is low level. Even if you wrote a program in OP codes you can’t change that.

There was a single paragraph to support his argument that was optimizing compilers can create machine code wildly different than what might be expected.

Then he goes off on a complete tangent of how C isn’t good for parallel processing which has nothing to do with his thesis.