“C is how the computer works” is a dangerous mindset for C programmers • Hacker News Board

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

#81

Post by radarsat1 » Tue, Mar 31, 2020, 3:38 PM UTC

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.

> pointer provenance, inability to read uninitialized memory

what do you mean by these two? not sure about the former. as for the latter, of course you can read uninitialized memory, unless you mean something else?

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

#82

Post by snazz » Tue, Mar 31, 2020, 3:40 PM UTC

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.

Java’s GC and lack of pointer arithmetic should push it a little further to the right, no?

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

#83

Post by School-Cotton » Tue, Mar 31, 2020, 3:40 PM UTC

radarsat1 wrote: post #81

dooglius wrote: post #65

Earlier quoted context omitted.

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.

> pointer provenance, inability to read uninitialized memory what do you mean by these two? not sure about the former. as for the latter, of course you can read uninitialized memory, unless you mean something else?

No, reading uninitialized memory in C is UB.

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

#84

Post by chrisseaton » Tue, Mar 31, 2020, 3:41 PM UTC

radarsat1 wrote: post #81

dooglius wrote: post #65

Earlier quoted context omitted.

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.

> pointer provenance, inability to read uninitialized memory what do you mean by these two? not sure about the former. as for the latter, of course you can read uninitialized memory, unless you mean something else?

Can you write a well-defined C program that reads uninitialised memory?

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

#85

Post by scottLobster » Tue, Mar 31, 2020, 3:41 PM UTC

pdimitar wrote: post #56

ThrowawayR2 wrote: post #24

Earlier quoted context omitted.

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.

So no disrespect to your colleagues, but they work in C and don't understand the relationships between C --> ASM --> Machine Code --> Hardware?

That's... disturbing. Hope they're not building medical devices.

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

#86

Post by School-Cotton » Tue, Mar 31, 2020, 3:41 PM UTC

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.

Another major way in which assembly language is closer to the hardware than C is the presence of explicit SIMD instructions.

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

#87

Post by steveklabnik » Tue, Mar 31, 2020, 3:42 PM UTC

radarsat1 wrote: post #81

dooglius wrote: post #65

Earlier quoted context omitted.

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.

> pointer provenance, inability to read uninitialized memory what do you mean by these two? not sure about the former. as for the latter, of course you can read uninitialized memory, unless you mean something else?

For the first, https://blog.regehr.org/archives/1621

For the second, https://www.ralfj.de/blog/2019/07/14/uninit.html

(the second one is a bit more Rust focused but the core idea is the same)

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

#88

Post by vardump » Tue, Mar 31, 2020, 3:42 PM UTC

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.

No, it really isn't on anything modern, like ARM SoCs or x86 CPUs. The number of times I've hit my head to wall trying to understand what the heck the CPU is doing for a given sequence of instructions, like why the number of cycles or memory bandwidth required is way different from my expectation.

A modern CPU willy nilly reorders instructions, stores, and creates new "virtual" registers out of thin air to dissolve stall inducing dependency chains. It can also split instructions, fuse them together and even entirely remove some instructions -- as long as it doesn't affect the end result.

Generally (within limits of CPU memory model) the only thing you're guaranteed is that eventually the result is what you'd expect from sequential execution. That of course applies on the core you're running on, otherwise you naturally need to synchronize with other cores.

Luckily there are tools to find out, which work to some extent, IF you can run it on same CPU model (and really, whole system, incl. memory subsystem!) as what you're interested in.

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

#89

Post by adrianN » Tue, Mar 31, 2020, 3:42 PM UTC

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…

What happens when you reach outside of an array or access memory after it was freed falls under UB and those are the most serious problems about the C family of languages.

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

#90

Post by takeda » Tue, Mar 31, 2020, 3:42 PM UTC

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.

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

It is, but what happened though, is that assembly/machine language no longer is as close to the real machine as it was in the past, it is an abstraction on top of micro code.

The high level languages that you mentioned are further away, and competition abstracted away from the assembly.