Deconstructing K&R C
c.learncodethehardway.org
c.learncodethehardway.org
Sorry, but the logic of this statement is 100% wrong.
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.
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.
To call the copy code "defective" is completely wrong.
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?
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&R in part because I experimented with the code samples in the book. And I worked around the bugs during that exercise.
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.
I can't explain why the bugs in the book weren't corrected in subsequent reprintings ... that's something to ask the publisher.
When I went through K&R, I already had enough programming knowledge to "know" most of the problems he mentioned existed. K&R didn't try to show how to write the most correct, robust C function or program, but it did manage to get me to love C.
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.
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&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.
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.
That "finely honed eye for defect" you refer to, you can have it after going to any great C book (including K&R C). By the end of the book, you should know what things were wrong before on the way.
Reflexion is something you do while you are reading.
Why don't you summarize and extend those earlier discussions in your own post, and link to that?
I agree that the book still does have value, but the current state of its code can be frustrating if someone is just learning.
"Before [fossil] I wanted to publish my stuff I had two choices: Give my data to services like github, bitbucket, launchpad and then deal with all the whiners who don't like whatever I chose like somehow that makes their tribe inferior."
He has some code on github, but see http://sheddingbikes.com/posts/1306816425.html where he explains that it's mostly because his collaborators prefer it.
Finally, read http://zedshaw.com/essays/why_i_gpl.html to see the author's view of people who request a license change. Basically, he doesn't like those people.