To become a good C programmer (2011)

Stopped reading right there.

The Linux kernel never used standard C, since the very first release (0.01) it already depended on GCC extensions.

> Or how errno came to existence?

This is interesting. According to this book, errno was created because they wanted system calls to work like ordinary C functions:

> Each implementation of UNIX adopts a simple method for indicating erroneous system calls.

> Writing in assembly language, you typically test the carry indicator in the condition code.

> That scheme is great for assembly language. It is less great for programs you write in C.

> You can write a library of C-callable functions, one for each distinct system call.

> You'd like each function return value to be the answer you request when making that particular system call.

This turned out to be unnecessary. For example, many Linux system calls return a signed size_t type with either the result or the negated errno constant. When an error occurs, the C library stub function simply negates that value and assigns it to errno which is likely a thread-local variable.

The C standard library provides many examples of bad design. All the hidden global data, the broken locale handling, the duplication found in so many str* and mem* functions... Freestanding C lacks most of the standard headers and is a better language for it. Understanding the historical context that contributed to these designs is very useful since it allows new languages to avoid repeating these mistakes.

The only problem is that computers have changed a bit in the last 50 years, and C largely hasn't. There are a couple issues:

First, C was designed for single-pass compilers, because the PDP-7 it was designed for was too small to actually run much fancier of a compiler. So C is seriously sub-optimal for optimization in a lot of ways (because the assumption was you weren't going to do compiler optimizations anyway), and there are some user-visible warts like forward declarations that are completely unnecessary today.

Second, the relevant questions with regard to CPU performance have changed a lot. Most notably:

- CPU performance has completely outstripped memory perf, so memory hierarchies and locality are everything

- Parallelism everywhere. Multiple cores, but also deeper instruction pipelines and other such things.

The way those things map to C is completely implicit; they don't show up in the language at all, and getting the machine to do what you want requires knowing things that the code wouldn't suggest at all.

I think if the same people had designed a language for a similar niche today's hardware, a lot of things would be different.

The biggest problem would likely bad code quality standards of earlier periods (lots of budding programmers in the dot com boom wrote a lot of poorly done code that survives today, which is responsible at least in part for Perls reputation as write only), but if you're just deploying your own code, that's less of an issue. Perl can be written to be readable and obvious, it just takes control. In that respect, I imagine it's a lot like C.