

Deconstructing K&R C - jonathansizz
http://c.learncodethehardway.org/book/learn-c-the-hard-waych55.html#x62-31400055

======
steve8918
_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.

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

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

------
mapleoin
Previous discussions:

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

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

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

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

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

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

~~~
mturmon
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?

~~~
jonathansizz
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.

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

~~~
dalke
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.

