21–30 of 387 posts
Earlier quoted context omitted.
And yet a content-free post is gobbled up on Hacker News.
Steve Klabnik, of Rust fame, has a good history of writing insightful and interesting articles. If you feel he isn't delivering value then feel free to output your own content instead of contributing to drive down the signal/noise ratio of HN's comments section with inane comments on other people's tastes.
So the Rust community is now pushing anything with "Rust" in the title even if it's content free? There's absolutely nothing here other than an announcement that Mr. Kablink decided not to write this blog post. Yet the Rust community dutifully brigade-votes this to the front page.
> 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. Se…
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.
If not, what is it?
Wait until they learn that machine code is not exactly how the computer works either. The hardware is doing things to your code you might not expect.
I'd say "C is not how the computer works ... but it's much, much closer than nearly every other language."
> Tools like [Valgrind] are exceptionally useful and they have helped us progress from a world where almost every nontrivial C and C++ program executed a continuous stream of UB to a world where quite a few important programs seem to be largely UB-free in their most common configurations and use cases...Be knowledgeable about what’s actually in the C and C++ standards since these are what compiler writers are going by. Avoid repeating tired maxims like “C is a portable assembly language” and “trust the programmer.” Unfortunately, C and C++ are mostly taught the old way, as if programming in them isn’t like walking in a minefield.
Actually I look forward for enough momentum to be created in the community, to allow new C standards to change the way undefined behaviors are conceived, and make them as specified as possible, and even when they cannot in reasonable unique ways, to provide reference possible behaviors to select in order to have the least unexpected outcome for the programmer. Especially now that low level programming is abstracting…
Last I checked UB was undefined by the standard, but compilers still need to define their behavior on each architecture. Dictating that all architectures implement UB the same way would have significant overhead, since it would force programs that don’t rely on UB to run in emulation on all but one architecture (at best).
Implementation-defined behavior works as you say, where each compiler can define how it responds to certain circumstances.
Interesting this is less of blog post and more of an announcement that a blog post will not be written.
The self-quote for the thesis for this article comes from a conversation with tptacek in the HN thread from the first post.
This may be a little off topic but it is something that until now I’ve never questioned in my entire career: Is the c in C supposed to stand for “computer“? If not, what is it?
Someone told me back in high school that "C is just shorthand for assembly", which I think about a lot. Does anyone else feel that way?
But assembly doesn't have the following concepts built into it, you have to manage those yourself if you want them:
- The notion of functions and return values. CALL/RET implements subroutines, not functions.
- Linkage that is more complex than jumps or call/returns. The ABI between units of code is something you have to define and do youself.
- The notion of associating types with variables. Variables in assembly are simply labels for memory locations, but don't really constrict action or tell you how many memory locations are in the variable. Types, including valid actions, data widths, etc. are completely up to you and must be done manually in assembly.
Someone told me back in high school that "C is just shorthand for assembly", which I think about a lot. Does anyone else feel that way?
I like this article on this topic: https://raphlinus.github.io/programming/rust/2018/08/17/unde...