Deconstructing K&R C

<i>Many people have looked at this copy function and thought that it is not defective. They claim that, as long as it's used correctly, it is correct. One person even went so far as to say, "It's not defective, it's just unsafe." Odd, since I'm sure this person wouldn't get into a car if the manufacturer said, "Our car is not defective, it's just unsafe."</i><p>Sorry, but the logic of this statement is 100% wrong.<p>Car seatbelts are intended for people above a certain weight, maybe 60 lbs. If you place a baby in a seatbelt, and you get into a car accident, the baby will likely die. Does that make a car seat belt "defective"? No, it doesn't. It means that the seat belt was used in an improper way.<p>The code is not defective, it's just unsafe. If you use the copy function in an improper way, you will likely get a crash. The implicit rules of the function are that the inputs are NULL-terminated strings, of a limited size. If you don't follow the rules, then you could very likely get bad behavior.<p>To call the copy code "defective" is completely wrong.

I'm not disagreeing with the author but ...<p>I wonder what we'll think of your book in 40 years. I suspect we won't even remember it. I'd be surprised if it wasn't upstaged by another book. Perhaps one that spends a chapter deriding your work?<p>But mostly I wanted to comment on how you lumped together "style" (and implied best-practices) with outright bugs. I learned a lot from K&#38;R in part because I experimented with the code samples in the book. And I worked around the bugs during that exercise.<p>But style and best-practices evolve as we learn. It shouldn't really shock us that both the accepted style and the recognized best-practices are different today than 40 years ago.<p>I can't explain why the bugs in the book weren't corrected in subsequent reprintings ... that's something to ask the publisher.

The thing about K&#38;R is that it effectively communicates the hacker spirit to the student.<p>When I went through K&#38;R, I already had enough programming knowledge to "know" most of the problems he mentioned existed. K&#38;R didn't try to show how to write the most correct, robust C function or program, but it <i>did</i> manage to get me to love C.<p>C is a hard language to do much with. It takes hours to do in C what can be done in seconds in other languages. That's fine; it is intended to be an implementation language. The thing is, at the time the student is learning C, he normally is not ready to start implementing things. At Uni, we didn't start working on operating systems or programming languages for at least another year after the class that introduces the student to C.<p>The thing that C does actually do well for a student is that it makes things much less mysterious. That, to me, is the the beauty behind K&#38;R. It removes the mysteries of the standard libraries, and by the time I finished, I felt like I could start working on an operating system without feeling completely overwhelmed. Even though I never did, that practical knowledge has served me well when doing any kind of programming.

Previous discussions:<p><a href="http://news.ycombinator.com/item?id=3448573" rel="nofollow">http://news.ycombinator.com/item?id=3448573</a><p><a href="http://news.ycombinator.com/item?id=3048672" rel="nofollow">http://news.ycombinator.com/item?id=3048672</a><p><a href="http://news.ycombinator.com/item?id=3648907" rel="nofollow">http://news.ycombinator.com/item?id=3648907</a>

NULL-terminated strings are understood to be the only acceptable way to pass around strings in C.<p>safercopy() will not be writing or reading garbage from memory, but the strings produced as output are not going to be well-formed unless the caller is being just as careful. e.g., safercopy gives me a string that I probably can't pass into printf, or to ANY C library for that matter.

I really think the author could have been able to express his point without the need to call any other book "buggy." Great books are able to claim "that pedestal" alone without this kind of references.<p>That "finely honed eye for defect" you refer to, you can have it after going to any <i>great</i> C book (including K&#38;R C). By the end of the book, you should know what things were wrong before on the way.<p>Reflexion is something you do while you are reading.

I know that we've already had a link to this book on the front page, but I think that the subject matter of this chapter warrants a separate discussion on HN.

While the book isn't under a permissive license (afaik), I have to wonder if the authors would accept putting it under a Creative Commons license so that we could put it on a Github repo, publicly patch and maintain it?<p>I agree that the book still does have value, but the current state of its code can be frustrating if someone is just learning.