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

211–220 of 387 posts

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

#211

Post by saagarjha »

andrepd wrote: post #195
jcranmer wrote: post #123

One of the blog posts I keep meaning to write is in the vein of "Why C is not portable assembly." Ironically, most of my points about C failures aren't related to UB at all, but rather the fact that C's internal model doesn't comport well to important details about machines: * There's no distinction between registers and memory in C. A function parameter that is "register volatile _Atomic int" is completely legal and…

There's no "bitcast" operator that changes the type of a value without affecting the value. The most common workaround involves going through memory and praying the compiler will optimize that away (while violating strict aliasing semantics to boot). Access through a union allow the same region of memory to be interpreted as different types. No support for multiple return values (in registers). There's structs, but t…

> Access through a union allow the same region of memory to be interpreted as different types.

…only in C.

> No mainstream compiler will ever not optimise that.

Actually, it's mandated by the System-V ABI for structures of an appropriate size.

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

#212

Post by btilly »

JdeBP wrote: post #180
btilly wrote: post #124

A good way to think of it is that C is how computers worked 40 years ago. A lot has changed since then, but computers put up a lot of effort to pretend that they still work similarly, and most other programming languages have put up a lot of effort to figure out how to make things work for a "C computer".

40 years ago was the home computer revolution. A lot of computers did not work like that. They had things like segmentation, zero pages, workspace register files, shadow registers, BCD arithmetic, and software interrupts. A few years later they had things like heterogeneous multiple processors, PAD, and trap/interrupt gates. The big iron of the time (and a few years later) had some things that did not work like C, to…

Well, the original C was pretty much exactly how a PDP-11 worked. And the PDP-11 was a source of design inspiration for the original Intel x86 and Motorola 68000 chips.

So there were computer chips sold in the 1970s that worked a lot like C thinks. You are right that there were also ones that didn't.

Going forward from close to 1980 you added more and more features to all architectures that diverge.

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

#213

Post by kevingadd »

andrepd wrote: post #195
jcranmer wrote: post #123

One of the blog posts I keep meaning to write is in the vein of "Why C is not portable assembly." Ironically, most of my points about C failures aren't related to UB at all, but rather the fact that C's internal model doesn't comport well to important details about machines: * There's no distinction between registers and memory in C. A function parameter that is "register volatile _Atomic int" is completely legal and…

There's no "bitcast" operator that changes the type of a value without affecting the value. The most common workaround involves going through memory and praying the compiler will optimize that away (while violating strict aliasing semantics to boot). Access through a union allow the same region of memory to be interpreted as different types. No support for multiple return values (in registers). There's structs, but t…

Using a union still has the going-through-memory problem, though. I spent a day or two trying to coax clang into doing the efficient thing with a union a couple years back when I could have gotten the job done in 30 minutes with raw assembly (alas...)

RE: Return values, you'd be surprised. You can't assume you'll get properly optimized code for something like that in WebAssembly for example, despite the fact that you're using an industry-standard compiler (clang) and runtime (v8 or spidermonkey).

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

#214

Post by vardump »

Jasper_ wrote: post #206
vardump wrote: post #189

Earlier quoted context omitted.

Microcode on x86? Don't forget to also greet our friends such as RDTSCP, CPUID, RDMSR, POPCNT (on some models) etc. Also remember to check ENTER, BOUND, etc. out in the museum vitrine. But yeah, microcoded instructions are relatively rarely executed.

I can't find any evidence that RDTSCP is microcoded. That would defeat the whole purpose of a high-performance counter. Any source?

I can't find any primary source, but I'm pretty sure about it.

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

#215

Post by rhinoceraptor »

rumanator wrote: post #70
rhinoceraptor wrote: post #60

Earlier quoted context omitted.

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.

> This is like saying there's nothing dangerous about guns, because it takes a human to make them dangerous. If you want to go with that analogy, UB is a kin of you intentionally pointing your gun to your foot, taking your time to aim it precisely on your foot, and in spite of all the possible warnings and error messages that are shouted at you... You still decide that yes, what you want to do is to shoot yourself in…

OpenBSD has almost a singular focus on security, and even they have vulnerabilities. If they can't write safe C 100% of the time, what hope does anyone else have?

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

#216

Post by saagarjha »

vbezhenar wrote: post #210
jcranmer wrote: post #123

One of the blog posts I keep meaning to write is in the vein of "Why C is not portable assembly." Ironically, most of my points about C failures aren't related to UB at all, but rather the fact that C's internal model doesn't comport well to important details about machines: * There's no distinction between registers and memory in C. A function parameter that is "register volatile _Atomic int" is completely legal and…

Is there any low level language, which is actually close to modern x86_64?

The only language close to modern x86_64 is x86_64 itself. Well, no, not really, because assembly instructions get dispatched as micro-ops…

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

#217

Post by jeffdavis »

jcranmer wrote: post #123

One of the blog posts I keep meaning to write is in the vein of "Why C is not portable assembly." Ironically, most of my points about C failures aren't related to UB at all, but rather the fact that C's internal model doesn't comport well to important details about machines: * There's no distinction between registers and memory in C. A function parameter that is "register volatile _Atomic int" is completely legal and…

"There's no "bitcast" operator that changes the type of a value without affecting the value."

Technically, you are supposed to use unions for that, though it's a pain. The PostgreSQL codebase is compile with -fno-strict-aliasing so that a simple cast will get the job done, but obviously that's technically out of spec.

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

#218

Post by armitron »

jcranmer wrote: post #203
shadowgovt wrote: post #183

Earlier quoted context omitted.

> Be knowledgeable about what’s actually in the C and C++ standards ... turns out to be an extremely tall order; the 2017-11-17 working draft of the C++ standard is 1,448 pages in PDF format. At some point, I wonder when programmers who are required to care about correctness throw up their hands and say "This language isn't reasonably human-sized for a user to know they're using it correctly." At which point the imme…

> the 2017-11-17 working draft of the C++ standard is 1,448 pages in PDF format. To be fair, that contains both language documentation and library documentation. The language specification portion itself is only ~400 pages, which is smaller than the Java Language Specification and JS's specification (both about 700-800 pages, although JS does include its [meager] standard library in there).

When it comes comprehensibility, the C++ standard is orderS of magnitude more difficult than the JLS due to the numerous interdependencies and layers upon layers of cruft. There is no single, cohesive model to understand. That is the fatal flaw of C++ and I guess what led to Stroustrup's couple-of-decades-too-late "Remember the Vasa!" proclamation.

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

#219

Post by pdimitar »

amiga_500 wrote: post #207
shadowgovt wrote: post #183

Earlier quoted context omitted.

> Be knowledgeable about what’s actually in the C and C++ standards ... turns out to be an extremely tall order; the 2017-11-17 working draft of the C++ standard is 1,448 pages in PDF format. At some point, I wonder when programmers who are required to care about correctness throw up their hands and say "This language isn't reasonably human-sized for a user to know they're using it correctly." At which point the imme…

C++ should only be used as a last resort. It's complex, development is slower, the tooling is poor, some universities have stopped teaching it. It's very hard to hire good C++ devs, and they are typically not cheap. I manage a c++ team btw. Our app has to be fast.

As your parent said, this is also an answer I can understand.

Still, have you guys looked at alternatives -- and seriously evaluate them? Rust, Zig, Nim, D, others?

If you tell me "we can't afford to, we have too much work" then that's also a valid answer (for a while at least).

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

#220

Post by saagarjha »

toolslive wrote: post #201
scottLobster wrote: post #92

Earlier quoted context omitted.

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.

> Java is written in C++. I think you're talking about the JVM. Anyway, some processors have native support: https://en.wikipedia.org/wiki/Jazelle

Jazelle is very dead, FWIW.
Post reply on HN