Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“C is how the computer works” is a dangerous mindset for C programmers

words.steveklabnik.com

Post reply on HN
Print view View original

51–60 of 387 posts

Re: “C is how the computer works” is a dangerous mindset for C programmers

#51

Post by xgiok78xh »

spicymaki wrote: post #8

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.

It’s not how the hardware works.

It’s how the hardware is modeled.

Hardware works as physics allows, at energies we can’t comprehend.

A computer is designed to a spec we can (sort of) comprehend. Spectre and such being evidence we don’t fully comprehend it.

It’s a recursive back and forth of this is a structure, this is the favored algorithm for that structure.

The hardware is the structure. Physics provides the algorithms for operating on that structure.

Thinking like one can see inside the machine always struck me as absolutely ridiculous.

It exists in the world defined by physics. Crawling into our imagination, linking abstract pictures from textures together arbitrarily, doesn’t mean we’ve discovered something new.

We know all kinds of stuff can be modeled on a compute because reality already gave us the math model.

We’re just brute forcing implementation looking for simple models for things we already have

Re: “C is how the computer works” is a dangerous mindset for C programmers

#52

Post by [deleted] »

antirez wrote: post #6

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…

[deleted]

Re: “C is how the computer works” is a dangerous mindset for C programmers

#53

Post by icedchai »

Tomte wrote: post #40
icedchai wrote: post #31

Earlier quoted context omitted.

Yes, except it's "less abstract" than any other language in mainstream use...

You're right. But that wasn't my point. My point was that C isn't the close-to-the-machine language that many programmers think it is. That other languages don't qualify, either, is beside the point. Ruby or Java aren't mistaken to be close-to-metal. Point in case: you don't even see anything about Harvard vs. von Neumann architecture in portable C sources. Not to speak of micro code or anything like that.

Ruby and Java aren't mistaken to be close-to-metal because they aren't. C is primarily about memory access and structure at a relatively low level. How do you explain that most operating system kernels and device drivers are written in C? Again, C is much closer to the machine than anything else in mainstream use. The C "abstract machine" is mostly a myth.

Re: “C is how the computer works” is a dangerous mindset for C programmers

#56

Post by pdimitar »

ThrowawayR2 wrote: post #24
spicymaki wrote: post #8

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.

Agreed, The example the author uses in his previous post on the topic talks about cache-unaware code but it's perfectly possible to write cache-unaware code in machine language as well. I'd say "C is not how the computer works ... but it's much, much closer than nearly every other language."

I feel your statement is actually much closer to the danger. C is pretty close to the hardware indeed and that misleads people into thinking that C is actually exactly how the hardware works. It's a very easy trap to fall into and I've seen many colleagues do just that.

Re: “C is how the computer works” is a dangerous mindset for C programmers

#57

Post by Tomte »

icedchai wrote: post #53
Tomte wrote: post #40

Earlier quoted context omitted.

You're right. But that wasn't my point. My point was that C isn't the close-to-the-machine language that many programmers think it is. That other languages don't qualify, either, is beside the point. Ruby or Java aren't mistaken to be close-to-metal. Point in case: you don't even see anything about Harvard vs. von Neumann architecture in portable C sources. Not to speak of micro code or anything like that.

Ruby and Java aren't mistaken to be close-to-metal because they aren't. C is primarily about memory access and structure at a relatively low level. How do you explain that most operating system kernels and device drivers are written in C? Again, C is much closer to the machine than anything else in mainstream use. The C "abstract machine" is mostly a myth.

Again, I don't dispute that C is much closer to the metal than Java.

I'm disputing that the C execution model is adequately and exhaustively modelling the idiosyncracies of real existing modern hardware, where "modern" means "almost anything in my lifetime".

Re: “C is how the computer works” is a dangerous mindset for C programmers

#58

Post by scottLobster »

Tomte wrote: post #44
scottLobster wrote: post #39

Earlier quoted context omitted.

"Concurrent access" isn't actually an accurate description of what's going on. Microcontrollers are generally single-core, single-threaded devices. The most common pipeline goes main thread -> interrupt processing -> resume main thread. If you're modifying a variable in the interrupt you should declare it volatile so as to avoid the compiler optimizing it and introducing unexpected behavior. Adding a mutex would just…

The C language until very recently didn't know about threads or other kinds of concurrency. So the compiler was technically free to assume that the interrupt is never called. It's nowhere in the call tree that originates at main(). Of course, it didn't do that. Because vendors imparted their compilers with additional knowledge about common programming patterns and uses that aren't standard C .

So there are vendors out there that alter the behavior of volatile to act like a mutex in multi-threaded environments but don't tell anyone? Ugh.

Well, TI doesn't do that thankfully. At least not for the MSP430.

Re: “C is how the computer works” is a dangerous mindset for C programmers

#59

Post by jcranmer »

pizlonator wrote: post #17

The problem with the “C is an abstract machine” nonsense is that it’s just not how it works. I get that it’s what the spec says. But C compilers are super careful to compile structured assembly style code without breaking it, even though they don’t formally promise to do so. That’s because lots of large C code based assume structured assembly semantics and probably always will.

> But C compilers are super careful to compile structured assembly style code without breaking it, even though they don’t formally promise to do so.

You have never worked on a C compiler, I take it. All production compilers will at some point turn even straight-line code into a DAG and relinearize it without care to the original structure of code. Any semantics beyond that which is given in the C specification (which are purely dynamic, mind you) are not considered for preservation. In particular, static intuitions about relative positions (or even the number!) of call statements to if statements or other control flow are completely and totally wrong and unreliable.

This is the main reason why people keep harping on the "C is an abstract machine." When people think of machine code, there is an assumption about the set of semantics that are relevant to the machine code, and that set is often much, much broader than the set of semantics actually preserved by the C specification.

Re: “C is how the computer works” is a dangerous mindset for C programmers

#60

Post by rhinoceraptor »

rumanator wrote: post #35
antirez wrote: post #6

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…

> allow new C standards to change the way undefined behaviors are conceived, Of all the potential issues that might be attributed to C, undefined behavior (UB) is the one that creates few to no problems at all. To me, complaining about UB is like complaining about the quality of a highway once they intentionally break through the guard rails and start racing through the middle of the woods. The reason why some behavi…

This is like saying there's nothing dangerous about guns, because it takes a human to make them dangerous.

C is not unsafe if you only write safe code. But humans are fallible, and "just don't write unsafe code" is not a solution.

Post reply on HN