Not sure whether it is controversial or, not, but C is very much not an "abstract machine".
There are languages which define an abstract machine, and the implementations then have to map that abstract machine onto the hardware, making sure to faithfully reproduce the semantics of that abstract machine. Squeak Smalltalk is an example of this, the VM provides the abstract machine and thus images work identically on different underlying hardware.
C isn't like that at all. While there is an abstract machine of sorts defined in the standard, a lot is left out of the standard in UB and IDB that says "just to whatever the hardware does", and the things that are defined are mapped closely to the hardware.
And of course, some people say that "the hardware" doesn't work like that any longer, but that is the interface the hardware presents to its users via its machine language.
> While there is an abstract machine of sorts defined in the standard, a lot is left out of the standard in UB...
This is exactly why, on modern C compilers, you have to start thinking of C as an abstract machine -- because that's what the compiler writers think they're doing.
But unlike abstract machines for older languages designed to be mathematically pure, or new abstract machines for newer languages designed to keep you from making stupid mistakes, the C abstract machine is full of bear-traps, such that if you ignore the "C is an abstract machine" warning, nearly any simple-but-obvious program is probably vulnerable to a dozen UB vulnerabilities.
Hard agree on ‘that’s what compiler writers think they’re doing.’ I don’t even think the concept of C being the ISA for some abstract machine is a bad concept. However, and I think it gets to the heart of your point, the compiler writers only do this or adopt this attitude when it allows them to hand wave. There isn’t the consistency that should be present in an abstract machine implementation.
Now that I’ve rambled, I may make the most of this Stay-at-Home situation and write something up using the C as abstract machine concept.
> because that's what the compiler writers think they're doing.
Yep. And that's why modern compilers are such a shit show.
> any simple-but-obvious program is probably vulnerable to a dozen UB vulnerabilities.
I was shocked (well not really, but it is shocking) when a Googler and member of the C++ standards committee said in a talk (probably some C++ conf) that he works with the best C++ engineers in the world and none of them can write even small amounts of correct code according to the standard.
Head explodes.
Maybe, just maybe, there's something wrong with the standard and how it is interpreted? But apparently the thought never entered his mind.
C does define an abstract machine, but you are expected to map that abstract machine to the underlying hardware rather than to simulate it. The mismatch between the abstract machine and the hardware is where the problems come from.
Not sure whether it is controversial or, not, but C is very much not an "abstract machine".
There are languages which define an abstract machine, and the implementations then have to map that abstract machine onto the hardware, making sure to faithfully reproduce the semantics of that abstract machine. Squeak Smalltalk is an example of this, the VM provides the abstract machine and thus images work identically on different underlying hardware.
C isn't like that at all. While there is an abstract machine of sorts defined in the standard, a lot is left out of the standard in UB and IDB that says "just to whatever the hardware does", and the things that are defined are mapped closely to the hardware.
And of course, some people say that "the hardware" doesn't work like that any longer, but that is the interface the hardware presents to its users via its machine language.