Well when K&R C was released the compiler landscape did look very different. I'm sure back then you could get away with a lot more UB than nowadays, where LLVM and GCC will use every millimetre of leeway you give them to break your programs.

The memetic nature of the term "K&R" also seems to have resulted in a lot of people who think Kernighan created Unix, and don't know who Ken Thompson is.

K&R was a very interesting read for me, but not actually for the description of the C language, but because it describes why certain features in C look the way they do, and because it is also surprisingly and refreshingly critical towards the language (e.g. it basically admits that the function pointer syntax was a mistake).

It also corrected my oversimplified view that C is a simple and small language simply because it is an old language, but it was already a simple and small language compared to other languages in the late 60's 'programming language zoo'.

All the code examples are deeply rooted in the 80's programmer mindset though, and are not very relevant for "modern C".

It's hard to take someone seriously or believe that they've even read the material when they say stuff like this. K&R (2nd ed.) is constantly calling out undefined behavior, etc. and gives you information you need to start out on a path to be a real stickler about the language.

I spent time on my own learning C from K&R since the CS program at my school didn't expose anyone to C (or C++) during the first year. Later, in e.g. the computer architecture course or the data structures course when C was being used liberally (and sloppily), and as I was running across lots of C in the wild, I was continually frustrated by the frequency I saw people relying on common-but-undefined behavior that's explicitly identified as unsafe/unreliable in K&R.

Here's my advice to the original poster:

If you come across unsubstantiated comments telling you to ignore K&R for all the bad things it contains, then ignore those. Or you can ask for evidence of the bad things they say about it. It's become a meme in the last few years to write meatless swipes about how bad K&R is, but in all the times I've asked for evidence of the things it's purportedly rife with, no one has ever produced anything. The most egregious thing I know of is that it uses `gets` and `puts` in some places—while taking extra effort to tell you it's wrong to use them. This is arguably exactly how do-not-do-this wisdom should be imparted.

There is one criticism that holds true about K&R, if you're being generous (to the naysayers, that is), which is that it really does just teach you C the programming language (with some extra stuff about the UNIX system interface at the end). It's not a general software engineering book. You don't learn about build tools or how to structure large, maintainable programs. It exposes you to the fact that C has various nooks and crannies, and it teaches you them, and that's all it really tries to be.

> which is that it really does just teach you C the programming language

A gross misrepresentation that, taken at face value, can only lead to a perpetuation of disasters committed by the sort of C programmers that K&R has produced in droves.

Just because there are a few mentions of undefined behavior in K&R, doesn't mean the concept is addressed or even identified as an issue. There is not a single mention of the "C abstract machine" (what is that, the K&R C programmer wonders), pointer provenance, aliasing, or pretty much any aspect of the language that has emerged in the last 20 years as of supreme importance to correctness and security.

As someone else wrote in this thread, the entire book is hopelessly obsolete and should be retired to the annals -if not the garbage bin- of history.

> pointer provenance

But what could a book last updated in the 1980s have to say about this subject? The phrase falls out of DR260 (Defect Report #260 in the ISO C standard) which wasn't even raised until this century.

Here's the mention of "provenance" from what WG14 (the committee for the C standard) wrote for DR260 back in 2001:

"the C Standard does not prohibit an implementation from tracking the provenance of the bit-pattern representing a value"

Vague right? And it's technically true, the C standard says nothing whatsoever about this subject. Of course it also doesn't have anything to say about which Pony is Best [Princess Celestia is Best Pony, don't @ me]

You might assume after DR260 the C standard was fixed. Presumably C11 and so C++ 11 and modern languages in this family all spell out how provenance works exactly right?

Nope.

The status quo is that the standard appears to say pointers are basically just addresses, but they clearly aren't in practice in your C or C++ compiler. If you raise bug reports about this, your compiler vendor will say it's provenance and, if you're persistent and they don't just stop answering you, eventually point to DR260, the unresolved defect from 2001.

There are folks trying to produce a consistent model which is somewhere in the ballpark of what programmers expect to work versus what compiler vendors actually deliver, so that both will be happy or, if not happy, at least both will agree on what the situation is. This model is some variation of what's called "Provenance Not Via Integers" but it must have exceptions because clearly sometimes provenance is transmitted via integers, and how that works must be explained too. WG14 did not take this work for C23, but it will become a Technical Specification in the C23 era. If compilers implement this TS, and if programmers prefer having at least the guarantees from the TS over a shrug emoji then perhaps some day it becomes part of the standard itself.

K&R mentions that you can't go around pointing to things of the wrong type (but C programmers do it anyway, and then doubtless you'll say K&R didn't warn them) and that you can't use pointer arithmetic to get at objects which are out of bounds (again, C programmers do it anyway).

The language is unsafe, and it's poorly designed in various ways by modern standards, but the OP didn't ask "What language should I learn?" they have apparently set their heart on learning C and so it's very strange to imagine the goal is to learn a good modern language which C isn't.

The question that I'm answering is "Best book to learn C in 2022?". K&R written as you say in the 1980s (the first edition in the 70s) is not that book, there is far better written material out there: One can get a solid grounding in C reading Seacord's books and John Regehr's blog without even needing to know who K and R are.

I'm guessing from some of the comments to my posts that some people are upset due to K&R being their first introduction to C (or their first introduction to technical writing) which leads to emotional responses that miss the point.

So let me re-iterate that point. K&R is a terrible C book in 2022, and should not be recommended as an introduction to the language. It wraps C in a veneer of simplicity-hiding-untold-complexity which leads readers thinking that the language is much safer and much easier to deploy than reality dictates. This is disastrous and something that we should point out and drive newcomers away from.

> One can get a solid grounding in C reading Seacord's books and John Regehr's blog without even needing to know who K and R are.

I'm not familiar with John Regehr - At least recently, Regehr's blog appears to be extremely low level (relative to C at least). Reading about the IR in LLVM or the ARM machine code which makes a spinlock go isn't a "solid grounding in C". It's fascinating - but it's not about C. Perhaps he used to write more about C?

Robert Seacord though, I just don't see it. I think you've recommended Seacord because you're thinking about what you'd need to write good software in C in 2022. But if we wanted to write good software in 2022 we shouldn't use C for that task in the first place. That's my point here. "Secure Coding in C" goes on the shelf next to "Agile Development using the Waterfall Model" and "Version Control using Visual SourceSafe". In each case these should be one paragraph inside, "Better not I think".

My assumption is that the OP is curious about the language, to the extent maybe they'll solve Advent of Code in it or something, not that they're about to write or maintain serious C software.

> I'm guessing based on the comments to my posts that some people are upset due to K&R being their first introduction to C (or their first introduction to technical writing) which leads to emotional responses that miss the point.

That's a shamelessly self-serving assumption.

When confronted with a claim/argument that is not favorable to your position, you have (at least) two options: one involves employing humility and intellectual honesty in an earnest attempt to resolve the conflict, and another involves inventing a convenient narrative in order to avoid the conflict. An example of the latter would be a stand-up comic who consistently bombs on stage and chooses to cope with it by telling themselves that the audiences are just too sensitive for the comic's edgy-but-otherwise-brilliant material. An example of the former would be for the comic to at least entertain the idea that their sets always bomb because the jokes are shit. Your response (which amounts to "u just mad") indicates that you seem to have taken this approach.

You have made a fact claim. You said that K&R "doesn't even attempt" to cover undefined behavior. That claim has been disputed. The next step for you to do is not to change the subject by questioning the motives and emotional maturity of those who have disputed the claim, but rather to substantiate it.

(For the sake of completeness: K&R was neither my first introduction to C nor my first introduction to technical writing—not that it matters.)

Agreed. It's also worth pointing out that Effective C is the most current in terms of being up to date with present-day C standards.

K&R is so obsolete it's now wrong about some things. It's a pretty good read sometime down the road - when you can recognize its shortcomings - but it's not a book from which to start learning C.

The above is a utterly clueless post and is best ignored.

To the OP:

K&R Ansi C is one of the best book to learn "Fluent C". The code is terse, no-frills and to-the-point. It is not a "Software Engineering" book so you have look elsewhere for that. Also without an understanding of the language, its runtime services and system interfaces (eg. ABI) it is pointless to look at Security/UB and hence don't bother about it in the beginning; You can get to it later.

In summary, read K&R C along with any other books that you like.