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

71–80 of 387 posts

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

#71

Post by gwd »

mpweiher wrote: post #22
beervirus wrote: post #4

Earlier quoted context omitted.

> 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…

> 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 abstra…

> 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.

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

#72

Post by Impossible »

hyperpallium wrote: post #41

Is the world ready for lower-level languages ? e.g. cache-aware. (assembly isn't) In a way, GPU shader languages "fit" parallel GPU architecture (though not cache-aware). Maybe... limited loop code-length to fit in cache; No pointer chasing (though you can workaround anything in a TM). Some java subsets for very limited hardware might be instances.

GPU languages have some cache aware constraints, especially if you're working with the graphics pipeline vs compute where you have more constrained inputs and outputs. Shared memory is also often used as a user managed cache.

Cell SPUs had explicit user managed cache and host DMA, and Intel ISPC and Unity Burst compiler/ECS (variants of C and C#) are good examples of programming environments that try to more explicitly encourage parallelism and/or optimal cache utilization.

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

#73

Post by namibj »

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…

Your wording only works for "implementation defined", not "undefined". Both exist in the standard, and the former is quite sane to use. E.g., on any normal architecture, specifying signed integer overflow to be implementation defined would have been great, though on e.g. the JS-style machine that abuses IEEE floats in limited range as integers, addition get's weird once the point floats to the left of where you'd normally write it by hand (in non-scientific notation).

  y = x;
  x += 1;
  x -= 1;
  true == (x != y);
But I don't know of any actual integer machine that would want integer overflow to actually be UB.

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

#74

Post by gens »

C is a high level language.

C is close to how a computer works.

Assembly is the next step down, and is not nearly as hard as the internet would lead you to believe.

Step down from that; read a book like "Computer Architecture: A Quantitative Approach", and learn about cpu-s and memory (also Agner Fog's site, official amd and intel doc, many other).

Down from that is electronics (logic gates, 8bit adder, etc., down to transistors and capacitors).

And beyond is physics.

Everything else is either computing theory or buzzwordy bullshit.

To repeat: C is a high level language, no matter what anyone says.

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

#75

Post by SuperscalarMeme »

bluetomcat wrote: post #61

"Real hardware" is also an abstract machine. Until you get to the level of each individual transistor, it's hardware abstractions all the way down. Caches, reorder buffers, load and store buffers, instruction decoding are all abstract concepts sitting at a much higher level than the individual transistor. Those abstractions are there mostly for the purpose of speeding up code execution, but also for enabling hardware…

And I bet you physicists argue that transistors are just abstractions of semiconductors

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

#76

Post by [deleted] »

gens wrote: post #74

C is a high level language. C is close to how a computer works. Assembly is the next step down, and is not nearly as hard as the internet would lead you to believe. Step down from that; read a book like "Computer Architecture: A Quantitative Approach", and learn about cpu-s and memory (also Agner Fog's site, official amd and intel doc, many other). Down from that is electronics (logic gates, 8bit adder, etc., down to…

[deleted]

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

#77

Post by jerf »

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…

"like complaining about the quality of a highway once they intentionally break through the guard rails"

Your metaphor brings to mind an image of someone who can see the guard rail, and then deliberately chooses to expend quite non-trivial effort to break them. This is not an accurate metaphor.

As I'm not in the metaphor fix-up business, because I believe they tend to mess us up in precisely this sort of way, let me simply directly point out this gets it backwards. The default is that you will write a program shot through with undefined behavior, and you must make quite substantial, intellectually-challenging efforts above and beyond the intellectual challenge of writing something in C at all that at least sometimes works, to write your program in a way that doesn't have UB in it. It has no resemblance to driving down a road in a normal fashion and then bashing guard rails down.

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

#78

Post by cryptonector »

beervirus wrote: post #4
fortran77 wrote: post #2

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…

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.

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

#79

Post by jstrong »

steveklabnik wrote: post #27
MivLives wrote: post #3

Interesting this is less of blog post and more of an announcement that a blog post will not be written.

Yes, I did not expect this to get posted here, for this reason. The first post got a ton of attention, the second one not so much. The self-quote for the thesis for this article comes from a conversation with tptacek in the HN thread from the first post.

I consider myself a Steve Klabnik fan and even I was surprised to see this at the top of HN haha. Just goes to show you can never really predict how these things will go.

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

#80

Post by [deleted] »

overgard wrote: post #20

To be fair, even assembly language isn't how the computer works (gets translated into micro code). Not to mention other integral components like the GPU that are coded in an entirely different model. I think what's fair to say is: the "abstract C machine" tends to have a minimal amount of concepts on top of the machines instruction set, compared to other languages, and generally provides the least friction if you nee…

[deleted]
Post reply on HN