5 ms·

> Basically, the overall thrust of this series has been this: C is not the hardware, it’s an abstract machine. But that machine runs on real hardware, and abstr

> Basically, the overall thrust of this series has been this: C is not the hardware, it’s an abstract machine. But that machine runs on real hardware, and abstractions are leaky. If you go too far into “purely only the abstract machine,” you may not be able to accomplish your tasks. If you go too far into “C runs directly on the hardware,” you may be surprised when a compiler does something that you didn’t expect. Seems pretty uncontroversial for “propaganda.”

mpweiher 7y ago
> C is not the hardware, it’s an abstract machine 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.
- gwd 7y ago
  > 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.
  - mpweiher 7y ago
    > 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.
  - throwaway17_17 7y ago
    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.
- afiori 7y ago
  Then C is an ill-defined abstract machine.
- mark-r 7y ago
  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.
cryptonector 7y ago
But is Rust a more faithful model of HW? I'm happy to accept that C sucks (it does) and that Rust and others are superior (they are). But if you stop at the quoted statement, you've not said much. I upvoted the submission blindly, then read it, then un-upvoted it. TFA is not useful. It would have been better to not write TFA at all. There already are many many very good articles about how Rust is better than C.
- M2Ys4U 7y ago
  > But is Rust a more faithful model of HW? As far as I know Rust doesn't claim to be, or have legions of people claiming it is.
- steveklabnik 7y ago
  I don't really understand why Rust is in this discussion at all. This isn't a post about Rust. (And Rust is not really any better than C in this regard. At least, in a vacuum. I guess you could make the argument that it's better because fewer people have false beliefs about it, but that's not an argument I'm making, either in the blog post nor here.)
  - saagarjha 7y ago
    Probably the obvious reason: that anything you write that has even the most tangential relevance to Rust means that people will think you're talking about Rust…
- DasIch 7y ago
  No, it isn't but I don't see anyone making the claim that Rust is a faithful model of the hardware. That's quite common take on C though, which is not that wrong, if you go back in history far enough. It's quite wrong today though.

mpweiher 7y ago

> C is not the hardware, it’s an abstract machine 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.

gwd 7y ago
> 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.
- mpweiher 7y ago
  > 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.
- throwaway17_17 7y ago
  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.
afiori 7y ago
Then C is an ill-defined abstract machine.
mark-r 7y ago
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.

cryptonector 7y ago

But is Rust a more faithful model of HW? I'm happy to accept that C sucks (it does) and that Rust and others are superior (they are). But if you stop at the quoted statement, you've not said much. I upvoted the submission blindly, then read it, then un-upvoted it. TFA is not useful. It would have been better to not write TFA at all. There already are many many very good articles about how Rust is better than C.

M2Ys4U 7y ago
> But is Rust a more faithful model of HW? As far as I know Rust doesn't claim to be, or have legions of people claiming it is.
steveklabnik 7y ago
I don't really understand why Rust is in this discussion at all. This isn't a post about Rust. (And Rust is not really any better than C in this regard. At least, in a vacuum. I guess you could make the argument that it's better because fewer people have false beliefs about it, but that's not an argument I'm making, either in the blog post nor here.)
- saagarjha 7y ago
  Probably the obvious reason: that anything you write that has even the most tangential relevance to Rust means that people will think you're talking about Rust…
DasIch 7y ago
No, it isn't but I don't see anyone making the claim that Rust is a faithful model of the hardware. That's quite common take on C though, which is not that wrong, if you go back in history far enough. It's quite wrong today though.