Of course this comment thread is (judging by the comments so far) going to be mostly about whether Zed Shaw criticizing old fashioned C is right or not or whether the criticizers are right or whatever. Oi... against my better judgement, I'm going to call out a few relatively objectively objectionable points in the book (which are still there, as opposed to the removed K&R chapter):<p>- He repeatedly states that processing an invalid C string can loop infinitely, but it can't - except in extremely rare cases on exotic systems, which seem to be the exact opposite of what he's going for. In reality it will <i>always</i> crash (unless being exploited by an active attacker!). The hentenaar.com post already notes this, but this instance of him being objectively wrong is buried among a huge number of more stylistic and debatable points.<p>The error is not a big deal, since neither looping infinitely nor crashing is desirable, but I can't help but think it demonstrates the author's lack of experience in what he's supposed to be teaching.<p>- Also wrong: "The source of almost all bugs in C come from forgetting to have enough space, or forgetting to put a '\0' at the end of a string." Forgetting to null terminate is a newbie mistake. A claim that almost everything that can be incorrect about a C program comes from a buffer overflow seems obviously spurious, so I'll give the benefit of the doubt and assume he's referring to security problems. In that case, some bugs involve straight buffer overflows, but a good fraction of real-life security bugs involve other things like integer overflows and use-after-free.<p>Also not exactly a big deal - perfectly sufficient to worry about overflows just because they account for <i>many</i> bugs, rather than almost all - but it seems myopic with respect to real world code.<p>- "In fact it's so common and hard to get right that the majority of good C code just doesn't use C style strings." I guess it's technically subjective what counts as "good", but most C codebases use C strings to some extent, so this is pretty misleading.<p>As one example, OpenSSH, despite being very carefully written code that uses a safe buffer API for the low level protocol manipulation, also uses C strings all over the place. As another, Linux is generally considered reasonably high quality, and it makes no effort to avoid C strings. I think you'd have a hard time making a long list of well-known C programs that <i>do</i> use alternative string libraries exclusively. (Note: this has no bearing on whether or not doing so is a good idea.)<p>- "In C, there's not really a 'boolean' type" - there has been since 1999; a lot of code doesn't use it, but since this is aimed at modern C, are you really not even going to mention it?<p>- Type Conversion section doesn't mention (or incorrectly describes, I can't tell which) the "integer promotions"; these are an awful feature and relying on them is awful, but a manual for how implicit conversions are done shouldn't have an incorrect algorithm!