Zed Shaw on Deconstructing K&R C

The book is still unfinished/alpha, but he's started work on this final chapter already.
http://c.learncodethehardway.org/book/learn-c-the-hard-waych55.html

When I was a kid I read this awesome book called "The C Programming Language" by the language's creators, Brian Kernighan and Dennis Ritchie. This book taught me and many people of my generation, and a generation before, how to write C code. You talk to anyone, whether they know C or not, and they'll say, "You can't beat "K&R C" . It's the best C book." It is an established piece of programmer lore that is not soon to die.

I myself believed that until I started writing this book. You see, "K&R C" is actually riddled with bugs and bad style. Its age is no excuse. These were bugs when they wrote the first printing, and the 42nd printing. I hadn't actually realized just how bad most of the code was in this book and recommended it to many people. After reading through it for just an hour I decided that it needs to be taken down from its pedestal and relegated to history rather than vaunted as state of the art.

I believe it is time to lay this book to rest, but I want to use it as an exercise for you in finding hacks, attacks, defects, and bugs by going through "K&R C" to break all the code. That's right, you are going to destroy this sacred cow for me, and you're going to have no problem doing it. When you are done doing this, you will have a finely honed eye for defect. You will also have an informed opinion of the book's actual quality, and will be able to make your own decisions on how to use the knowledge it contains.

In this chapter we will use all the knowledge you've gained from this book, and spend it reviewing the code in "K&R C" . What we will do is take many pieces of code from the book, find all the bugs in it, and write a unit test that exercises the bugs. We'll then run this test under Valgrind to get statistics and data, and then we'll fix the bugs with a redesign.

This will obviously be a long chapter so I'm going to only do a handful of these and then I'm going have you do the rest. I'll provide a guide that is each page, with the code on it, and hints to the bugs that it has. Your job is to then tear that piece of code apart and try to think like an attacker trying to break the code.

I think his approach is a Good Thing that the software world needs, but probably will dismiss anyway merely because of his curly brace style.

>Now, in the context of the entire program in the original "K&R C" example, this function will work correctly. However, the second this function is called with longest and line uninitialized, initialized wrong, without a trailing '\0' character, then you'll hit difficult to debug errors. '
>purposely try to break the program with undefined and wrong behavior
>Error of the book for not predicting some neckbeard in 2011 from breaking the baby program in Chapter 1
I'm sure if i go through his `online' book i'll find a code snipit he uses and be able to show flaws in it and how it's considered bad.

>55.1.2 Stylistic Issues
not a single fuck given

but probably will dismiss anyway merely because of his curly brace style
Why would that happen? It's 1TBS.

The main problem I see with his approach is that he's pointing out trivial things, not something that would actually show that K&R is not a good book to learn C from.
The only real shortcoming of K&R is that it doesn't teach modern user application development, but that's okay in my opinion; better to teach the lower level systems programming, since the rest is the same with more abstraction.

Zed Shaw is shit.

This "learn x the hard way" fad is going to die sooner or later.

Then you see me use a loop to accidentally initialize it wrong.
That's your own fucking fault, idiot.

This code is incredibly error prone because you can't easily tell where the pair of if-statements and the while-loop are paired.
Whoever wrote this obviously is either half-blind or has not read enough C code. It's perfectly clear that if you don't see a brace it's one statement, otherwise there is (and should be) multiple statements following.

The guy makes my blood boil. They quite clearly said that the programs in each section are not necessarily proper - they are intended to teach you new concepts as they are being introduced, using only what has been taught up to this point.

the guy just want some attention.

That's the guy who made http://programming-motherfucker.com/, right? And you're taking anything he wrote seriously‽

his opinion on always having braces to avoid error seems good, even though i omit braces frequently

>>9
I omit them always. If I have an if statement that requires two or more lines, I write two or more if statements.

>>6
Don't let that cretin get to you, just be glad you have a way of identifying retards (who will obviously follow him and suck his dick everyday).

I said it before, and I'll say it again. Zed Shaw is an idiot.

The following copy function is found in the very first chapter and is an example of copying two strings. Here's a new source file to demonstrate the defects in this function.
[...]
// initialize it but make a classic "off by one" error
Is he really complaining about the fact that the function becomes erratic with corrupted data?

Hey guys I'm such a skilled and expert programmer look at all these problems I can find with K&R, none of them are actually real problems and are merely stylistic issues -- but look at me!

This shit reminds me of Joel Atwood and the "I'm not a good programmer, but all good programmers say they are not a good programmer." rubbish. I mean honestly, fuck off already.

>>13
The funny thing is, strcpy() would behave the same way.

Maybe he should use Java instead if he wants to be treated like a baby.

Dear Zed Shaw,

If you are reading this, my honest advice would be grabbing a copy of K&R and reading it (I mean the entire thing, not just "reading" "through" it for an hour). Playing around with "learn C in 24h" and "valgrind for dummies" tutorials is not a way to cultivate your programming skills, and certainly not to become a self-taught expert capable of producing better documentation than the creators of the language themselves.

Low regards,
Anonymous

Zed Shaw on Deconstructing SICP

The book is still unfinished/alpha, but he's started work on this final chapter already.
http://c.learnschemethehardway.org/book/learn-scheme-the-hard-waych55.html

When I was a kid I read this awesome book called "Structure and Interpretation of Computer Programs" by the language's creators, Hal Abelson and Gerald Sussman. This book taught me and many people of my generation, and a generation before, how to write Scheme code. You talk to anyone, whether they know Scheme or not, and they'll say, "You can't beat "SICP" . It's the best Scheme book." It is an established piece of lithpfag lore that is not soon to die.

I myself believed that until I started writing this book. You see, "SICP" is actually riddled with bugs and bad style. Its age is no excuse. These were bugs when they wrote the first printing, and the 42nd printing. I hadn't actually realized just how bad most of the code was in this book and recommended it to many people. After reading through it for just an hour I decided that it needs to be taken down from its pedestal and relegated to history rather than vaunted as state of the art.

I believe it is time to lay this book to rest, but I want to use it as an exercise for you in finding hacks, attacks, defects, and bugs by going through "SICP" to break all the code. That's right, you are going to destroy this sacred cow for me, and you're going to have no problem doing it. When you are done doing this, you will have a finely honed eye for defect. You will also have an informed opinion of the book's actual quality, and will be able to make your own decisions on how to use the knowledge it contains.

In this chapter we will use all the knowledge you've gained from this book, and spend it reviewing the code in "SICP" . What we will do is take many pieces of code from the book, find all the bugs in it, and write a unit test that exercises the bugs. We'll then run this test under Valgrind to get statistics and data, and then we'll fix the bugs with a reparenthesization.

This will obviously be a long chapter so I'm going to only do a handful of these and then I'm going have you do the rest. I'll provide a guide that is each page, with the code on it, and hints to the bugs that it has. Your job is to then tear that piece of code apart and try to think like an attacker trying to break the code.

I think his approach is a Good Thing that the software world needs, but probably will dismiss anyway merely because of his  style.

This thread has been closed and replaced with the following thread:

Subject: Compiling C code with a Python compiler
Name:
Email:

It doesn't work.

If it ain't K&R, it's shit.

>>19
K&R is ^_awesome.

"Learn C The Hard Way" (LCTHW) is a book by Zed A Shaw about C programming. It extends his "Learn Code The Hard Way" series, a collection of books aimed at helping beginners learn to code, ostensibly the hard way.

Despite their name, Zed's books present an authentic and forthright dialogue, demonstrating the effectiveness of traditional pedagogy in a modern context.

The books are targeted at novice programmers. To experienced coders, Zed notes, "You won't learn anything from it since the entire book is me telling you to do repetitive boring tasks." This, along with the patronising nature of the books has earned them disdain among veteran coders.

The most common criticism of the books comes relates to a chapter in Learn C The Hard Way, titled "Deconstructing 'K&R C'". In this chapter Zed's arrogance and perversity are put on full display. Zed attempts a critique of the time honored and widely regarded book, "The C Programming Language" by Brian Kernighan and Dennis Ritchie. Zed falls far short of providing any actual substance and as a result has, in one of the most disgraceful displays in modern history, was outcast from the programming communities and censured on /prog/, newsyc, /r/programming and LTU.

Zad, Zed, Zedd, Zadd, Shaw, Shore, Shor

PDF, HTML, ePub, TeX, eBook, Kindle, azw, HTM, doc, docx

Ha ha ha, sooo much butthurt in this thread, it's hilarious.

Take this shit back to reddit.

Note again, that the above was a review of the book, "Learn C The Hard Way" by Zed A. Shaw. It was not a PDF download link or an Amazon (amazon.com) store link.

Might as well get in early for some agerank juice on the Sepples book too. Learn C++ The Hard way, is a future book to be written by Zed A. Shaw which will cover the abhyorrent programming language C++, commonly referred to as "sepples". The book will cover classes, template programming, object oriented programming, C++0x, C++1x, and a variety of other pertinent topics.

I haven't read either book. I will come forward and say that immediately. Having said that, the arguments espoused in this thread are refutable with just the fragments shown and some general background in programming.

Lots of kids are trying to be edgy here by flaming some guy who will never hear from them, showing empty bravado about how they are willing to live up to the consequences of their avoidable (programming) errors, or just acting as if they don't make them.

This a horse which has been beaten to dust, after countless reanimations. If you are using computational tools which don't assist you as a human, the least you can do is setup everything up yourself as to not burn your hair or somebody else's in the future.

By drilling into newbies's heads the idea that you should consider how you will fuck up tomorrow while trying to understand and use the programs you wrote today -in the end, to consider one's own human limitations, about the main reason to use computers in the first place- Zed Shaw is doing a huge favor to programmers of tomorrow and today.

Yes, it may be nitpicking of a great book, but considering how you idiots are foaming at the mouth because of that, it goes to show that it was necessary in the first place.

>>21
You should re-read a missive by Sussman to this board. It spoke of the perils of idolization of a revered figure, rather than soberly and rationally considering their contributions.

>>15
You so badass.

>>2,13
You speak as if strcpy's behavior in face of that edge case was a property of the Universe rather than some guy's design decision in spite of all its inconvenience.

>>27
a missive by Sussman to this board
Where can I see that?

>>28
http://dis.4chan.org/read/prog/1202913500/1

Zed Shaw hasn't read his SICP K&R.

>>27
flaming some guy who will never hear from them
Zed will read this thread at some point, it is inevitable.

It's all well and good if he wants to make the point that programs should be resilient, one might expect he would give examples of code that is not, K&R included. The problem is that he uses it as an exercise in self gratification, either through malice or ignorance pretending that the authors of K&R didn't expressly ignore the ``bugs'' he describes for the sake of brevity.

In fact, "This is the failing of the book. While the code works in the book, it does not work in many other situations leading to difficult to spot defects." can be said of any book ever written. K&R could have a chapter that is exactly the same, instead referencing ``bugs'' in LCTHW. Of course they don't, and they wouldn't, as the smoke, mirrors, and ensuing battle of egos is not useful for their students.

>>8
THE RED
IT HURTS

THE DUBS
THEY HURT

HAX MY ANUS

Burn the witch!

Didn't Zed make virtually the same arguments about Dive Into Python and also release his own Python book? I think this guy just wants attention for his shitty books.

Zed = Zhivago same.

>>36
Isn't his "Learn Python the hard way" the book most programmers recommend to learn Python?

>>38
No, Dive Into Python and Think Python are.

>>39
I think I have been trolled or I listened to the wrong advicers then...

Currently at exercise 9 of that book. I think I'm going to keep going and later take a look at those books you said.

>>39,40
I have not read "Dive Into Python" mythelf, but I want to point that Python community one-upped thothe ruby fairieth with our Mark Pilgrim. It'th one thing to perform an internet thuithide due to impending deanonymithation, but it takes a whole 'nother breed of a queer to do it for no reathon at all, with flourish, using an exquithite HTTP error code for your removed stuff. Eat that, faggoths!

>>41
What are you talking about

if we have

struct point {
    int x;
    int y;
};

struct rect {
    struct point pt1;
    struct point pt2;
};

struct rect r, *rp = &r;

then these four expressions are equivalent:

r.pt1.x
rp->pt1.x
(r.pt1).x
(rp->pt1).x


minimalism, yay!

>>43
Now consider

&r.pt1.x
&r.pt1
&rp->pt1.x
&rp->pt1
&(*rp).pt1.x
&(*rp).pt1

He's referring to him purging his online presence.
http://diveintomark.org/

<jjones2234> K&R is riddled with bugs, see: http://c.learncodethehardway.org/book/learn-c-the-hard-waych55.html
<twkm> jjones2234: i'm not very impressed with the critique.
<jjones2234> twkm: neither was I, I was planning to troll with it but honestly I don't think it's quite worth my time.
<twkm> it isn't worth it.