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

91–100 of 387 posts

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

#91

Post by gruez »

dooglius wrote: post #65
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…

Not really, assembly language is extremely close to microcode, much much closer than it is to C. C has a whole bunch of baggage like pointer provenance, inability to read uninitialized memory, doesn't understand cache aliasing, etc that don't fit hardware well.

>inability to read uninitialized memory

    printf("%x", *(int*)0x12345678);

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

#92

Post by scottLobster »

dpc_pw wrote: post #66
pdimitar wrote: post #56

Earlier quoted context omitted.

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.

M............................................C M..............................................Java Look. C is much closer to how the machine (M) works.

Give that Java is written in C++ which is in turn an extended version of C, I'm not sure that chart is entirely to scale.

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

#93

Post by sweeneyrod »

anarazel wrote: post #63
rumanator wrote: post #35

Earlier quoted context omitted.

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

Implementation defined behaviour is not the same as undefined behavior.

And unspecified behaviour is (slightly) different again.

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

#94

Post by aequitas »

deelowe wrote: post #67
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.

Even binary code isn't "how the computer works" these days.

Never has been. Deep down 1's and 0's are still analog voltages, subject to capacity and inductance, on a tiny wire between transistors. Without proper timing you end up reading the voltage half way between ascending from 0 to 1 and who knows what value you end up with.

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

#95

Post by jonhohle »

oconnor663 wrote: post #25

My favorite take on the severity of the UB problem, https://blog.regehr.org/archives/1520 : > 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…

Static analysis tools should be the standard part of any build process, but especially with C/C++.

I’ve mentioned before here, but when I found a reasonable number of bugs in critical library used throughout one of the FAANGs written by their most senior and brilliant engineers by running a fizzier on it for a few hours, my opinion of those languages changed.

Integrating Valgrind and Clang’s checker, and running AFL for many CPU years was critical in unearthing some really funky crashes, hangs, overflows. Without those tools it’s not clear that those bugs would have been fixed. In fact, one of them affected me a few months prior and AFL helped uncover the codepath that was failing.

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

#96

Post by mpweiher »

gwd wrote: post #71
mpweiher wrote: post #22

Earlier quoted context omitted.

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

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

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

#97

Post by derefr »

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.

> Assembly isn’t

What you mean is that the popular Instruction Set Architectures (x86, ARM) don’t expose these pragmatics. (Though the microcode architectures of the processors executing these ISAs probably do.)

There are other ISAs (e.g. Itanium, most Very Long Instruction Word ISAs) that do expose these pragmatics, constraining what instructions can appear when in an instruction stream. Which in turn means that assembly code for these ISAs needs to be written with awareness of these pragmatics.

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

#98

Post by M2Ys4U »

cryptonector wrote: post #78
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…

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.

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

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

#99

Post by afiori »

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…

Then C is an ill-defined abstract machine.

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

#100

Post by steveklabnik »

jstrong wrote: post #79
steveklabnik wrote: post #27

Earlier quoted context omitted.

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.

Hehe :)

I mean, I guess you could argue that it's produced an interesting discussion. There's actually a pretty interesting question here: is the purpose of a site like this to distribute interesting news, or foster interesting discussion? I personally feel like it's more the former, but maybe the latter matters too.

Post reply on HN