Deconstructing K&R C

http://c.learncodethehardway.org/book/learn-c-the-hard-waych55.html#x62-31400055

by jonathansizz • 14 years ago

36 12 14 years ago

c.learncodethehardway.org

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.

dalke2• 14 years ago

Quoting the author, zedshaw, in one of those links from mapleoin: "Just for the record, I am as sick of this part of the book showing up on HN as everyone else. I do not post it here, other people do, and I apologize in advance for it showing up here all the time half-finished."

mturmon• 14 years ago

Because the chapter you linked to is so terribly incomplete, it's unlikely that the present discussion will be any more enlightening than the other discussions.

Why don't you summarize and extend those earlier discussions in your own post, and link to that?

jonathansizz2• 14 years ago

Yeah, my apologies; I didn't realize this was a duplicate post. I thought there was an automated filter based on the URL, but I guess a quick Google search would've shown that there were previous submissions of this same item.

mapleoin• 14 years ago

Previous discussions:

http://news.ycombinator.com/item?id=3448573

http://news.ycombinator.com/item?id=3048672

http://news.ycombinator.com/item?id=3648907

JoelMcCracken• 14 years ago

The thing about K&R is that it effectively communicates the hacker spirit to the student.

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.

smoyer• 14 years ago

I'm not disagreeing with the author but ...

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.

steve8918• 14 years ago

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."

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.

tibbon• 14 years ago

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?

I agree that the book still does have value, but the current state of its code can be frustrating if someone is just learning.

dalke2• 14 years ago

Ain't going to happen. An old-ish comment from the author on github:

"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.

aeurielesn• 14 years ago

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.

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.

eranki• 14 years ago

NULL-terminated strings are understood to be the only acceptable way to pass around strings in C.

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.

Deconstructing K&R C

Related Stories