Despite what many think, I'd say the "The C Programming Language (2nd Edition - ANSI C)" by Brian Kernighan & Dennis Ritchie (K&R) book is still a good introduction to C. It doesn't go into best practices, or other forms of more advanced C programming, but it teaches C well. I'd pair it with "Understanding and Using C Pointers: Core Techniques for Memory Management" by Richard M Reese to get a good understanding of the pointer underpinnings of C. They are both small, well written and easily digestible.
I read the first edition of K&R when it came out, and switched to C for a computer algebra system that got me tenure as a math professor. K&R is a religious scripture, and remains the benchmark against which I measure all other programming books. It's in the same league as the aspirational SICP, and a far easier read.
In college I'd programmed Fortran on punched cards. APL was like dropping acid, and I worked one summer as a commercial APL programmer, but it wasn't appropriate for what I needed. Pascal didn't quite fit either. C was in that context mind-blowing. The future had arrived! I had full access to the machine!
If one is learning to become a plumber, one might not be so interested in how plumbing worked in 1840. If however, one is a herding dog, and needs serious work to avoid getting bored and destructive, reading K&R would put C in historical context.
Later, as I depended on C, I bought each edition of C: A Reference Manual by Harbison and Steele, and read it as if I were studying to be a lawyer.
I now program in Haskell, and wish I was equally versed in Clojure and Rust. If I were returning to C, I'd instead choose Rust. For my work, I have a free choice.
> I bought each edition ... and read it as if I were studying to be a lawyer
This made me laugh. I always described it as feeling like a collector/completist, but lawyer works too.
Visitors to my home office (back in the dark ages) would often comment on the growing set of editions of "UNIX System Administration Handbook", lined up side by side on my shelf.
Honestly at some point in editions 3 through 6, I was just buying the new ones for the shelf art.
I will be a contrarian - but as you pointed we are many - and recommend against K&R. C is a simple language to learn but a hard language to master.
C has few concepts. You can learn to write C in an hour with a couple of web pages. Then you have to learn how to implement the most useful data structures but that’s not difficult either. What’s hard is writing safe code in a maintainable way and K&R does very little to teach you that properly.
The C89/99 standard is rather small, it is relatively easy (certainly compared to C++) to know it almost fully. But the devil is in the details, it is very important to fully understand how C treats pointers, and how close to the hardware the language is, this is where the caveats are.
C doesn’t do anything particularly strange with pointers. Most of the weirdness comes from arrays not actually being arrays and sizeof being a primitive with a surprising behaviour in my experience. Apart from that you have to understand the difference between the stack and the heap and how your system treats malloc (well understanding that it can fail goes a long way) but that’s pretty much it.
There are probably some sharp corners I’m not thinking of around type conversions but that’s the kind of thing you expect from a strongly typed language.
Most of the caveats are in how compilers treat C rather than how close it is to the hardware to be honest.
Indeed C doesn't do much with pointers, it is very close to a cpu register containing a memory address. If you are used to higher level languages, it is odd. You can simply cast a pointer to one type to a pointer to another type. This is very often used to introduce OO like behaviour, but you need to understand how it works under the hood. Pointer arithmetic is sensitive to types though, so C is a bit smart in that way.
I've read a lot of books about programming over the many decades I've been doing this, and the K&R book still stands out as one of the best examples of how to do a good job of documenting the tool you've just built. The K&R book gave me the heuristic of "read the book by the folks who wrote the language". That heuristic turned out to be mostly wrong. But the book has stood the test of time.
I read The Awk Programming Language shortly after K&R and came away with the idea that I should consider reading whatever Kernighan (co)wrote. I don't think I got further than The Practice of Programming but that was three winners in a row...
Here's another vote for K&R. If you want to understand why C and UNIX were so successful, it comes down to simply excellent communication. And remember - no web, no internet, no WYSIWYG word processors, etc. at the time.
To appreciate C properly, I think at some point you need to become a bit of a historian. Look at BCPL. Look at what assembly listings looked like or old Fortran. Read some of the very early papers from C and UNIX history. Check out Lions' commentary on UNIX. When you see a little of the problem C was invented to solve, it becomes a lot easier to understand why it is what it is. There's a lot of angst about why C allows Bad-Thing-X or doesn't have New-Fancy-Thing-Y. Nobody seems to remember what a change it brought to writing systems code.
Then you can compare it to things written in modern C (C99+) and see that yes it has evolved quite nicely and can, if used correctly, be a nice application language too.
If you are starting with C I second this. C is a really good language to learn because it is not as far from what a cpu does. You end up understanding more of the workings. When someone says "garbage collection" you understand. In my opinion understanding an assembly language and C are fundamental to programming.
Fully agree that reading K&R is a must, because it puts C in context, it gives you the background that explains why C is like it is. Also, as a non-trivial bonus, it teaches you, by example, how to write great technical documentation.
