“C is how the computer works” is a dangerous mindset for C programmers
words.steveklabnik.com
“C is how the computer works” is a dangerous mindset for C programmers
1–10 of 387 posts
Re: “C is how the computer works” is a dangerous mindset for C programmers
#2So 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.
Re: “C is how the computer works” is a dangerous mindset for C programmers
#3Interesting this is less of blog post and more of an announcement that a blog post will not be written.
Re: “C is how the computer works” is a dangerous mindset for C programmers
#4So 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.
Seems pretty uncontroversial for “propaganda.”
Re: “C is how the computer works” is a dangerous mindset for C programmers
#5Interesting this is less of blog post and more of an announcement that a blog post will not be written.
And yet a content-free post is gobbled up on Hacker News.
Re: “C is how the computer works” is a dangerous mindset for C programmers
#6Actually 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 away, exactly but not only because of Rust itself, we need a C that is more C than what it became in recent years. After all we don't really need to change the language, but just the new specifications and the compilers implementations of UB.
Re: “C is how the computer works” is a dangerous mindset for C programmers
#7There's the computer, and then there's the computer, and then there's the computer and then there's the computer:
The computer is the thing that has the web browser running on it.
The computer is the thing that has the code editor running on it.
The computer is the thing that has the compiler running on it.
The computer is the thing that provides a virtual hardware interface for running programs.
The computer is the thing that the virtual hardware interface interacts with.
The computer is the thing inside the hard drive/graphics card/other component that the computer talks to.
The computer is the thing inside the processor that pre-processes, jits, or otherwise transforms commands from the computer for the computer so the computer ... ... ...
Re: “C is how the computer works” is a dangerous mindset for C programmers
#8Wait 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.
Re: “C is how the computer works” is a dangerous mindset for C programmers
#9It's far past time to put C to bed. D, Go, Java, Zig, etc. are all languages that one can use to do approximately C-like things without as much danger. I am tired of seeing a literal Twitter feed of memory unsafety security bugs [0]. We can do better.
Re: “C is how the computer works” is a dangerous mindset for C programmers
#10C has never been "how the computer works", its abstract model is way too… well, abstract.
But there is an interesting catch to it: because C is so important, and programmers at large know so little "real C", vendors do their damndest to make it work for them.
A well-known microcontroller forum in Germany is constantly pushing that you need to make your code safe in the case of concurrent access to a variable by a main loop and an interrupt. By making it volatile.
Strictly speaking that's plain wrong. You need some kind of mutex.
Practically speaking, no embedded C compiler vendor would dare use an "optimizing opportunity" and surprise his customers there.