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

191–200 of 387 posts

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

#191

Post by throwaway_pdp09 »

eternalban wrote: post #168
School-Cotton wrote: post #83

Earlier quoted context omitted.

No, reading uninitialized memory in C is UB.

No. It is not "undefined behavior". The "behavior" here is assignment (reading memory). It always will behave precisely and consistently: it _will_ assign the "indeterminite" value of the un-initialized memory. Using such an "indeterminite value" in other operations (e.g comparison per the link Steve B. posted above: https://www.ralfj.de/blog/2019/07/14/uninit.html ) is the UB bit.

> [reading memory} always will behave precisely and consistently

What is the point of not making it UB? You can't AFAICS possibly rely on any useful way on it behaving 'precisely and consistently' so just make it UB anyway?

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

#192

Post by throwaway_pdp09 »

Jasper_ wrote: post #154
dooglius wrote: post #148

Earlier quoted context omitted.

Maybe you have a different definition in mind than I do? I'm using microcode to mean sequences of micro-ops. Wikipedia [0] seems to agree, "the microcode is a layer of hardware-level instructions that implement higher-level machine code instructions or internal state machine sequencing in many digital processing elements". My understanding is that with a couple exceptions (IIRC mov and zeroing xor are treated special…

I don't have the patience to go fix Wikipedia, but microcode is a patching system (it's what "processor microcode updates" means). Most of the time, that's adjusting chicken bits and other flags. Instructions can be implemented in microcode, but they are really, really slow so it's typically done for security reasons or to emulate some new features that don't require fast performance. Micro-ops are part of the micro-…

I don't think wikipedia is broken, so plz don't fix. The definition of microcode matches my understanding. I've never heard it used as a patching system per se, ever.

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

#193

Post by xkriva11 »

Some time ago, I saw an article that described a very crazy hypothetical architecture that still fits the C standard and uses the undefined behaviors in various insane ways. It was named like "Computer platform from hell" or so. Unfortunately, I was not able to find it again. Does anyone know about something like that?

I think that the hegemony of C for low-level programming is harming us significantly because it puts the other models to obscurity. Try to write in C for something like F21 chip or J–Machine...

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

#194

Post by chrisseaton »

BenjiWiebe wrote: post #182
chrisseaton wrote: post #84

Earlier quoted context omitted.

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

Wouldn't this do it? int a; printf("%d", (&a + sizeof(int )));

...but that isn't a well-defined program, is it?

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

#195

Post by andrepd »

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 that means returning via memory because, well, see point 1.

No mainstream compiler will ever not optimise that.

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

#196

Post by [deleted] »

TomMarius wrote: post #143
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.

That is no argument in this discussion, IMHO - what does it change? The discussion is about the language (and in case of Java, the runtime) and it's machine abstraction, which is nearly the same for Java and C, even if JVM was written in Lisp.

[deleted]

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

#197

Post by stonemetal12 »

snazz wrote: post #82
dpc_pw wrote: post #66

Earlier quoted context omitted.

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?

I don't see why it would. Given what modern CPUs do to make memory fast and safe, pointer arithmetic is a ridiculous simplification that has no bearing in reality.

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

#198

Post by shadowgovt »

csours wrote: post #150
fctorial wrote: post #107

Earlier quoted context omitted.

There's the c1(physical computer), and then there's the c2(os runtime), and then there's the c3(silicon) and then there's the c4(turing machine): The c1 is the thing that has the web browser running on it. The c1 is the thing that has the code editor running on it. The c1 is the thing that has the compiler running on it. The c2 is the thing that provides a virtual hardware interface for running programs. The c3 is th…

Sure, but you can also run non-trivial code in the web browser. I wasn't being super-precise with my comment, and my point is that there is no one thing that "is the computer". There are many computers in your computer, and many definitions of what a computer is. I've never had to go below the HAL, or inside the JIT, but to some people that's where "the" computer really is. If that's where the computer really is, the…

The trick is to expand the definition of "tell the computer what to do."

You can tell the computer what to do by writing a program that passes through six levels of abstraction before the fate of any electrons is affected by what you wrote.

You can also tell the computer what to do by pushing a lot of keys on a keyboard. We're lucky; our keyboards have like a hundred keys on them. Some of our predecessors had eight switches and a ninth key or switch to "ACCEPT" the current switch-bank state.

You can also tell the computer what to do by causing patterns to be stored on magnetic or optical media and read back later.

You can also tell the computer what to do by plugging a wire into the back of it and varying voltages on that wire using another machine a hundred miles away.

Part of the art of programming is knowing that there are no bright, solid lines between these ways to tell a computer what to do (but for a given task, some are clearly more applicable than others ;) ).

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

#199

Post by BubRoss »

lidHanteyk wrote: post #9

It's far past time to put C to bed. D, Go, Java, Zig, etc. are all languages that one can use to do approximately C-like things without as much danger. I am tired of seeing a literal Twitter feed of memory unsafety security bugs [0]. We can do better. [0] https://twitter.com/LazyFishBarrel

Don't forget modern C++ and the well designed but forgotten Clay language. The reality is that go and java aren't system languages, they are just fast.

More than that though the C and C++ competitors don't have the tools and libraries.

When all these new languages get made, they never ease back on the language part and prioritize the next rough area. The language is argued about debated and added to with features for years or decades. Meanwhile build systems, guis, text editing with suggestions and syntax checking etc. all go into the pile of being a mess of half supported tools pieced together as an exercise in frustration for the brand new curious user.

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

#200

Post by lisper »

shadowgovt wrote: post #183
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…

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

> I wonder when programmers who are required to care about correctness throw up their hands

I did that over 20 years ago and have never looked back.

Post reply on HN