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

I’ve mentioned before here, but when I found a reasonable number of bugs in critical library used throughout one of the FAANGs written by their most senior and brilliant engineers by running a fizzier on it for a few hours, my opinion of those languages changed.

Integrating Valgrind and Clang’s checker, and running AFL for many CPU years was critical in unearthing some really funky crashes, hangs, overflows. Without those tools it’s not clear that those bugs would have been fixed. In fact, one of them affected me a few months prior and AFL helped uncover the codepath that was failing.

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.

... 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 immediate next question should be "Why don't you use something else?"

(In my experience, the only sane counter-answer to that last question is "I'm programming on an architecture where the {C/C++} compiler is the only one with any real expressive power that anyone has ported to this physical system." This is an answer I understand; most other answers will raise an eyebrow from me).

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.

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.

gcc/clang offers builtins for most of these. And if you give the compiler the right march parameter it'll quite likely turn your hand-rolled code for these operations into the x64 instruction you're targeting. Try it on Compiler Explorer.

Doesn't the div function do this?

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

> * Missing operations such as popcount, cttz, … or rotates.

Thankfully, these are coming in C++20.

Writing something like:

  sum = x + y;
  if(sum < x || sum < y) {
      ...
  }

Return values in registers are a machine level optimization. Whether something is in a "register" is up to the CPU today on most CPUs. If you set a value in the last few instruction cycles, and are now using it, it probably hasn't even made it to the L1 cache yet. Even if it was pushed on the stack. That optimization made sense on SPARC, with all those registers. Maybe. Returning a small struct is fine.

There's an argument for multiple return values being unpacked into multiple variables, like Go and Python, but that has little to do with how it works at the machine level.

Missing operations such as popcount, cttz, simultaneous div/rem, or rotates.

Now that most CPUs have hardware for those functions, perhaps more of those functions should be visible at the language level. Here's all the things current x86 descendants can do.[1] Sometimes the compiler can notice that you need both dividend and remainder, or sine and cosine, but some of those are complicated enough it's not going to recognize it.

Traps are UB instead of having more predictable semantics.

That's very CPU-dependent. X86 and successors have precise exceptions, but most other architectures do not. It complicates the CPU considerably and can slow it down, because you can't commit anything to memory until you're sure there's no exception which could require backing out a completed store.

[1] https://software.intel.com/sites/landingpage/IntrinsicsGuide...

I'd say "C is not how the computer works ... but it's much, much closer than nearly every other language."

We tend of think of everything as an ideal model in a vacuum, forgetting that in real life that the implementation details are often gory with caches and microcode and fault tolerance and all sorts of hidden details put in there to make things easier to work with or faster.

It’s how the hardware is modeled.

Hardware works as physics allows, at energies we can’t comprehend.

A computer is designed to a spec we can (sort of) comprehend. Spectre and such being evidence we don’t fully comprehend it.

It’s a recursive back and forth of this is a structure, this is the favored algorithm for that structure.

The hardware is the structure. Physics provides the algorithms for operating on that structure.

Thinking like one can see inside the machine always struck me as absolutely ridiculous.

It exists in the world defined by physics. Crawling into our imagination, linking abstract pictures from textures together arbitrarily, doesn’t mean we’ve discovered something new.

We know all kinds of stuff can be modeled on a compute because reality already gave us the math model.

We’re just brute forcing implementation looking for simple models for things we already have

Now if you care about performance, you might not want to ignore the real machine, but it really bis the hardware's job to work like the machine code tells it to. And when it doesn't, that's considered a bug^H^H^H exploit.

Dictating that all architectures implement UB the same way would have significant overhead, since it would force programs that don’t rely on UB to run in emulation on all but one architecture (at best).

[1] well, you can today by swapping malloc for a GC-enabled implementation, but the fact is that almost nobody does.

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 behavior is intentionally left undefined is to enable implementations to do whatever they find best in a given platform. This is not a problem, it's a solution to whole classes of problems.

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

Right now I see more efforts coming out Microsoft and static analysis tool vendors than any WG 14 mailing.

Cell SPUs had explicit user managed cache and host DMA, and Intel ISPC and Unity Burst compiler/ECS (variants of C and C#) are good examples of programming environments that try to more explicitly encourage parallelism and/or optimal cache utilization.

What you mean is that the popular Instruction Set Architectures (x86, ARM) don’t expose these pragmatics. (Though the microcode architectures of the processors executing these ISAs probably do.)

There are other ISAs (e.g. Itanium, most Very Long Instruction Word ISAs) that do expose these pragmatics, constraining what instructions can appear when in an instruction stream. Which in turn means that assembly code for these ISAs needs to be written with awareness of these pragmatics.

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)

Undefined behavior or use of anything not strictly included in POSIX.1c may result in the launch of nuclear weapons.

The self-quote for the thesis for this article comes from a conversation with tptacek in the HN thread from the first post.

main thread -> interrupt processing -> resume main thread.

If you're modifying a variable in the interrupt you should declare it volatile so as to avoid the compiler optimizing it and introducing unexpected behavior. Adding a mutex would just be worthless overhead.

But assembly doesn't have the following concepts built into it, you have to manage those yourself if you want them:

- The notion of functions and return values. CALL/RET implements subroutines, not functions.

- Linkage that is more complex than jumps or call/returns. The ABI between units of code is something you have to define and do youself.

- The notion of associating types with variables. Variables in assembly are simply labels for memory locations, but don't really constrict action or tell you how many memory locations are in the variable. Types, including valid actions, data widths, etc. are completely up to you and must be done manually in assembly.

I like this article on this topic: https://raphlinus.github.io/programming/rust/2018/08/17/unde...

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 because it was already people writing in C were aware of.

1. You do lots of pointer arithmetic. But I don't think being practiced at pointer arithmetic is important for developing as a programmer. Just learn what it is.

2. Local variables in C exist on the stack, not the heap. But I don't think programming in C is a great way to learn about stacks. Except when you try to return a reference to a local variable from a function, everything feels the same as in other languages.

If you're making a list of languages you want to try out, I wouldn't put C above 5th place. I say this as someone who spent 12 years primarily coding in C.

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 the thing that the virtual hardware interface interacts with.

The c3 is the thing inside the hard drive/graphics card/other component that the c2 talks to.

The c4 is the thing inside the processor that pre-processes, jits, or otherwise transforms commands from the c2 for the c3 so the c1 ... ... ...

Is this correct?

https://en.wikipedia.org/wiki/B_(programming_language)

https://en.wikipedia.org/wiki/C_(programming_language)

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.

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 are purely dynamic, mind you) are not considered for preservation. In particular, static intuitions about relative positions (or even the number!) of call statements to if statements or other control flow are completely and totally wrong and unreliable.

This is the main reason why people keep harping on the "C is an abstract machine." When people think of machine code, there is an assumption about the set of semantics that are relevant to the machine code, and that set is often much, much broader than the set of semantics actually preserved by the C specification.