Hacker News Reader

If you're serious about programming in C you'll read multiple books anyway. LCTHW seems like a good starting point to me. It's probably not for everyone. No book I've ever read about anything is. But it gets you to from passive reading to actively playing around fast. And it doesn't throw just code in front of you. It also explains the most basic functions of some of the non OS specific tools you will actually use when you'll be doing serious stuff much later. You can build on that pretty well, because you now know more about what you don't know, which gives you a tremendous advantage in terms of further research.

I've not read Zed's online book. I guess he encourages the use of -Wall and -Wextra when compiling on gcc? That's always smart. Also, cppcheck is a nice tool. If I were going to mention valgrind, I'd mention that too.

Excellent critique, but you show your hand here:

> K&R is an excellent reference, and LCTHW covers some new topics like valgrind, which is great.

Wrong, I already demonstrate that they have an example that is basically strcpy() and I show why it's broken. By the time I'm done with the book I'll have taken apart the entire book and shown that it's the source of most security holes through poor examples.

> However, it fails to point out that some of the exercises are just that; exercises. For example, creating a custom type system in C. Never do this.

Totally wrong. You basically just said that all of gobjects (the foundation of Gnome) should not exist, yet it's a successful object oriented abstraction. You may think that's true, but then you'd be in the vast minority. Without a demonstrated reason why one should never do this, your statement is total bullshit.

> Some other failings include; little attention to testing, no mention of cmake (used in major projects like opencv and clang) or lint(!), criticism of K&R systax (arguably validly so, but industry standard is industry standard).

There's extensive attention to testing, with nearly every exercise having use of valgrind and the inclusion of defensive programming macros not found in most other books PLUS a constant demand to break the code they've just written. In the second half of the book I'll be including the testing suite I use in my own projects:

https://github.com/zedshaw/mongrel2/blob/master/tests/minuni...

This claim is borderline slanderous it's so wrong.

Edit: And cmake is a piece of crap that isn't better than modern make.

> Look there's a lot of good in Learn C the Hard Way. I completely recommend it as a way to learn some C... but don't make the mistake of assuming a new book is better than an old book just because it's new.

Meanwhile, you make the mistake of not questioning the code in K&R when a cursory read finds numerous flaws and buffer overflows. If you feel that people should evaluate all things objectively (I agree!) then do it yourself and actually read K&R again.

And by the way, they updated it several times to remove defects since you probably read it. My copy was only a few years old and I had to update it because they fixed bugs in that copy() function I tear apart (but not enough).

> If you're programming C, read K&R. If you're doing it professionally, you probably also want to read Deep Sea Programming by Peter van der Linden.

I agree, solid recommendations, but I'm going to advocate people read K&R for historical reasons and to practice code review, which is what I'm doing in my book.

Hey, sorry if you took it the wrong way. I'm just pointing out some flaws I see in the text, and I fully acknowledge it's a work in progress and these may be solved over time.

However, I will repeat.

K&R is an excellent text. If you disagree, I dispute your credibility.

I also stand by my comment. Smart people have created strong type systems like gobjects and ctypes in C.

As a programmer, you should unequivocally _never_ do this yourself. C is about reuse, and not reinventing the wheel. Sure, if you want to use a strong type system instead of C++, do so. Do not write one yourself.

> As a programmer, you should unequivocally _never_ do this yourself.

Bullshit. You guys going around throwing your platitudes, shoulds, and nevers at people rarely have any evidence supporting your claims, and usually it just hides a lack of real knowledge.

> Wrong, I already demonstrate that they have an example that is basically strcpy() and I show why it's broken.

strcpy() is not broken. You cannot expect a function to work if you violate its preconditions. Exercise for you: enumerate strcpy's preconditions. And once you know them, you design your program in accord with them.

> There's extensive attention to testing

Testing can only prove the presence of bugs, not their absence. Heavy emphasis on testing leads to coding by trial-and-error, which, I argue, is the prime source of bugs (security and others).

"Hey, I tested it, it works!" What's missing in that statement is that it works for usual test cases. Software breaks on unusual/abnormal inputs. If, e.g., strcpy causes buffer overflow in your program, it is YOUR code that is crap because it didn't ensure proper preconditions. Don't project your incompetence/stupidity on strcpy.

THIS is what programmers should learn.

Your quote from K&R "critique": "And, what's the point of a book full of code you can't actually use in your own programs?" This line of thinking is despicable. A book is supposed to teach people ideas and concepts, not give them ready-made code recipes that they can copy-paste in their own programs.