“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

#111

Post by dirtydroog » Tue, Mar 31, 2020, 3:50 PM UTC

scottLobster wrote: post #58

Tomte wrote: post #44

Earlier quoted context omitted.

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.

How did you draw that conclusion? People have been warning about volatile for years

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

#112

Post by 0xdeadbeefbabe » Tue, Mar 31, 2020, 3:51 PM UTC

Equally dangerous as swimming with piranhas. Programming is so exciting if not self indulgent.

Edit: Oh I get it--your manager, who doesn't believe in leaky abstraction or UB, will beat you if the program fails.

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

#113

Post by alharith » Tue, Mar 31, 2020, 3:51 PM UTC

infamouscow wrote: post #38

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…

It would also be nice if Rust had a specification. Without a spec it's impossible to build a correct alternative Rust implementation.

Just pains me that the Rust team is so oblivious to the fact that they need a spec if they ever hope to have a chance to replace C.

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

#114

Post by 6keZbCECT2uB » Tue, Mar 31, 2020, 3:52 PM UTC

ThrowawayR2 wrote: post #42

alekratz wrote: post #11

Someone told me back in high school that "C is just shorthand for assembly", which I think about a lot. Does anyone else feel that way?

> " Someone told me back in high school that 'C is just shorthand for assembly' " That was true for the PDP-11 that the article series mentions and it was true for the early home computers of the '70s and '80s but it became increasingly less true as processors became more and more complicated under the hood. That's kind of the point of the article series but it's not as big a deal as the author makes it out to be bec…

As other people have pointed out, rather than C being more unlike assembly, processors are more unlike assembly. As such, the abstractions of C map pretty well to a theoretical assembly, even if optimization changes that precise mapping. A possible exception to this is the multicore semantics that are apart of each architecture aren't particularly well represented.

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

#115

Post by dirtydroog » Tue, Mar 31, 2020, 3:52 PM UTC

Rust this, Rust that. Tiresome.

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

#116

Post by overgard » Tue, Mar 31, 2020, 3:52 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.

I'm intrigued that you make that claim when as far as I know most microcode is proprietary and not necessarily documented. Also that claim is highly dependent on which cpu and manufacturer you're talking about, if the cpu needed to be updated, etc.

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

#117

Post by [deleted] » Tue, Mar 31, 2020, 3:53 PM UTC

gruez wrote: post #91

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.

>inability to read uninitialized memory printf("%x", *(int*)0x12345678);

[deleted]

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

#118

Post by gpderetta » Tue, Mar 31, 2020, 3:53 PM UTC

scottLobster wrote: post #58

Tomte wrote: post #44

Earlier quoted context omitted.

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.

for a while Microsoft gave volatile acquire/release semantics, which implied a barrier on non-x86 cpus. They recognized it was a mistake backtracked on that around the time they started their effort to run Windows on ARM.

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

#119

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

gruez wrote: post #91

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.

>inability to read uninitialized memory printf("%x", *(int*)0x12345678);

This is not a well-defined C program though.

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

#120

Post by 317070 » Tue, Mar 31, 2020, 3:54 PM UTC

sys_64738 wrote: post #109

C is like water. Atomically it is the DNA of all other programming languages. There's a reason why C is generally the fastest language with smaller binaries, and there's a reason why language like Python fallback to C for doing anything processor intensive. C will still be here when the latest fad languages of today are long forgotten.

Well, it will be still here in the same way Fortran is still here. I.e. while now it does not seem to bad, there will come a time where people will wonder why anyone put up with coding in C, when it was so prone to making bugs with things that could be automated away. In exactly the same way we now frown on goto statements. But, underneath it all, there will be this layer of C-code on top of this fortran code on top of this assembler code.