“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

#171

Post by stiray » Tue, Mar 31, 2020, 4:36 PM UTC

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…

What is profoundly pissing me off are bunch of hipsters on the internet that are using xyz language and are constantly trying to compare everything to C. We are faster, we are better, we are more portable, we have JIT, we have reflection... and so on.

Who cares what your tool for solving the problem is. Use Java, use JS, use python, go, rust... whatever suits for the task. Why do you want to compare yourself to C. Just stop it. No one with enough expirience in coding will ever care what language you have used to acomplish the task. Unless the task is going to be purely written, slow, buggy, CPU consuming, will have security issues and so on. This can be acomplished with half-baked (I hate the expression, but sorry) coding monkey in any language. Why do you even care about C. It doesnt matter, all that are complaining about it in whatever way possible or compare to it, will probably never be involved in a task where C excels, so why bother?

---

jeffdavis: the problem is that people would like to use wrong tool for the job. And the fact that they cant frustrates them, blaming everything else except the fact that they picked the wrong tool. As you need expirience for picking the right tool. A lot of expirience or rather beeing fluent in all the tools. Which makes it a problem if you dont dedicate a lot of time to this.

---

jeffdavis #2: > choosing the wrong tool really is a great way to understand your tools and the problem more deeply.

YES! Exactly! I did mistakes, a lot of them, like pragma packing the structure and send it to system on other side of network in other endianness. Overwritting EIP number of times before I understood it. Or best one, translating command.com to my language using edit :D Used wrong call convention. But my goal was always to understand assembler. To understand C. To understand C++. And I have made quite a lot of code in all 3. Then learnt any language that crossed my way and it looked like interesting (Rust is still on my list) and used each in at least one project, hobby or not. Now everyone learns one or two languages, without any background knowledge and then starts to preach it, prove that language written in X is faster than language that X is written in and so on. Who cares! It makes me puke.

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

#172

Post by Ididntdothis » Tue, Mar 31, 2020, 4:37 PM UTC

CalChris wrote: post #140

Ididntdothis wrote: post #15

Earlier quoted context omitted.

I think that goes way too far. Assembly is a completely different beast from C and way more complex. There is a lot stuff you can do with assembly that C can’t.

I agree that they are different beasts, but is there anything that assembly can do with data which C can't do? Or are there only control efficiencies which assembly can provide which C can't?

X86 has a lot of instructions that aren’t directly available to C and provide huge speed up. Often the optimizer will use them anyway but there plenty of cases where handcrafted assembly is much faster than anything C can achieve.

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

#173

Post by pizlonator » Tue, Mar 31, 2020, 4:37 PM UTC

jcranmer wrote: post #59

pizlonator wrote: post #17

The problem with the “C is an abstract machine” nonsense is that it’s just not how it works. I get that it’s what the spec says. But C compilers are super careful to compile structured assembly style code without breaking it, even though they don’t formally promise to do so. That’s because lots of large C code based assume structured assembly semantics and probably always will.

> But C compilers are super careful to compile structured assembly style code without breaking it, even though they don’t formally promise to do so. You have never worked on a C compiler, I take it. All production compilers will at some point turn even straight-line code into a DAG and relinearize it without care to the original structure of code. Any semantics beyond that which is given in the C specification (which…

I work on compilers for a living.

Structured assembly semantics are what C users in a lot of domains expect and production compilers like clang at -O3 will obey the programmer in all of the cases that are necessary to make that code work:

- Aliasing rules even under strict aliasing give a must-alias escape hatch to allow arbitrary pointer casts.

- Pointer math is treated as integer math. Llvm internally considers typed pointer math to be equivalent to casting to int and doing math that way.

- Effects are treated with super high levels of conservatism. A C compiler is way more conservative about the possible outcomes of a function call or a memory store than a JS JIT for example.

- Lots of other stuff.

It doesn’t matter that the compiler turns the program into a DAG or any other representation. Structured assembly semantics are obeyed because of the combination of conservative constraints that the compiler places on itself.

But bottom line: lots of C code expects structured assembly and gets it. WebKit’s JavaScript engine, any malloc implementation, and probably most (if not all) kernels are examples. That code isn’t wrong. It works in optimizing C compilers. The only thing wrong is the spec.

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

#174

Post by vardump » Tue, Mar 31, 2020, 4:37 PM UTC

jcranmer wrote: post #159

vardump wrote: post #149

Earlier quoted context omitted.

OoO and the fact that CPUs really are free to do whatever transformations they deem fit, as long as the end result within limits of memory model is same.

The CPU must conform to the strictures of the ISA, which is a much more stringent specification than the abstract machines of most language specifications. In particular, the state of registers and flags at any given time need to be preserved, even in the presence of external interrupts. Note that several decades ago, there were processors that weren't capable of actually keeping the state correct after a processor e…

> The CPU must conform to the strictures of the ISA, which is a much more stringent specification than the abstract machines of most language specifications. In particular, the state of registers and flags at any given time need to be preserved, even in the presence of external interrupts.

https://en.wikipedia.org/wiki/Tomasulo_algorithm.

So no, the consistent serialized ISA-conforming state might be reconstructed by replaying after the exception (interrupt) arrives.

Alternatively, interrupt might be served only after execution reaches the next checkpoint.

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

#175

Post by Symmetry » Tue, Mar 31, 2020, 4:40 PM UTC

gpderetta wrote: post #34

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…

You are never going to get any guaranteed sensible behaviour for a double free or an use after free [1]. In comparison to those giant issues, all other instances of UB are minor. [1] well, you can today by swapping malloc for a GC-enabled implementation, but the fact is that almost nobody does.

Surely signed integer overflow is also a big problem. And reads from uninitialized memory.

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

#176

Post by [deleted] » Tue, Mar 31, 2020, 4:40 PM UTC

j9461701 wrote: post #104

SuperscalarMeme wrote: post #75

Earlier quoted context omitted.

And I bet you physicists argue that transistors are just abstractions of semiconductors

Which is, in turn, merely an abstraction over the actual quantum physics that governs what's really happening on the silicon. And quantum physics might itself one day may be found to be a higher level abstraction of what's really really going on, as happened with Newtonian physics before it. It's abstractions all the way down. I don't know why they're so maligned by programmers, they're the only way any work gets don…

[deleted]

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

#177

Post by tux3 » Tue, Mar 31, 2020, 4:41 PM UTC

stiray wrote: post #171

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…

What is profoundly pissing me off are bunch of hipsters on the internet that are using xyz language and are constantly trying to compare everything to C. We are faster, we are better, we are more portable, we have JIT, we have reflection... and so on. Who cares what your tool for solving the problem is. Use Java, use JS, use python, go, rust... whatever suits for the task. Why do you want to compare yourself to C. Ju…

> all that are complaining about it in whatever way possible or compare to it, will probably never be involved in a task where C excels, so why bother?

I don't think that's a fair assumption. You may be underestimating the number of developers who have a need for a systems programming language.

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

#178

Post by School-Cotton » Tue, Mar 31, 2020, 4:42 PM UTC

tspiteri wrote: post #134

School-Cotton wrote: post #83

Earlier quoted context omitted.

No, reading uninitialized memory in C is UB.

As far as I know (and I could be wrong), reading uninitialized memory in C is not UB, but gives an indeterminate value, which may be either an unspecified value or a trap representation. If it is a trap representation, accessing it is indeed UB, but if all possible values of your memory are valid, e.g. if you have an unpadded integer where every bit representation means something valid, then it is not UB, though it i…

Thanks, it seems you are right. Sorry that you got downvoted whereas my wrong statement got upvoted; such is the nature of HN.

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

#179

Post by vardump » Tue, Mar 31, 2020, 4:44 PM UTC

Jasper_ wrote: post #164

vardump wrote: post #144

Earlier quoted context omitted.

The example I gave, yes. No assembler code can have anything to do with micro-ops; they're implementation specific. On x86, a lot of instructions are close matches, yet some are removed entirely (say "xor eax, eax") or fused into one micro-op, (like "cmp #123, eax / je "). Future CPUs might even do some data flow analysis to optimize code even further. Say speculative "constant" folding based on runtime profile to re…

Registers are allocated (and renamed) after instruction decode (e.g. what creates micro-ops), in a separate unit. Micro ops themselves do not have renamed registers. See the diagram here https://software.intel.com/sites/default/files/managed/9e/bc...

True. I simplified implementation details for clarity.

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

#180

Post by JdeBP » Tue, Mar 31, 2020, 4:48 PM UTC

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, too, such as single-level storage addressing, tagged architectures, and capability-based addressing.

Thinking that the C language is a representative model for computer history, or indeed for computer architecture, is a bad way of thinking of this. During the 1980s and 1990s there was a lot of shoehorning all of that architectural stuff into C compilers, with extra keywords and the like. (e.g. __interrupt, _Far, _Huge, __based, _Decimal, _Packed, digitsof, precisionof, and so forth)