C is the way

http://c.learncodethehardway.org/book/learn-c-the-hard-wayli3.html#x4-3000
I'm going to guess that you come from a language for weaklings 1. One of those "usable" languages that lets you get away with sloppy thinking and half-assed hackery like Python or Ruby. Or, maybe you use a language like Lisp that pretends the computer is some purely functional fantasy land with padded walls for little babies. Maybe you've learned Prolog and you think the entire world should just be a database that you walk around in looking for clues. Even worse, I'm betting you've been using an IDE, so your brain is riddled with memory holes and you can't even type out an entire function's name without hitting CTRL-SPACE every 3 characters you type.
Zed Shawn got it right.

This shit is terrible. If you want to learn C the hard way, read C99.

They claim C is not a language for weaklings, but then one of the first things they do (4) is tell you to use Valgrind to ``report on all of the horrible mistakes you made''. Relying on Valgrind or other debugging tools is the hallmark of a weak programmer ( http://lwn.net/2000/0914/a/lt-debugger.php3 ).

Arrays and pointers are confused in (10).

(13) has a bad case of specifying things by trying to explain how a compiler works. Not only is it complete bullshit, it also raises more questions than it answers. http://existentialtype.wordpress.com/2011/04/02/functions-are-values/

(16) has the same problem as (13).

(17) introduces malloc. For some reason they use assert to handle out-of-memory condition, even though that's retarded. The return value of strdup is not checked.

(18) introduces a die function that relies on errno being zero if there was no error, which is wrong. Dumping memory to disk is terrible! rewind and fclose are not checked for errors. (18.2) is full of complete lies again. Ask Zhivago.

As an aside, http://benpfaff.org/writings/clc/malloc-sizeof.html

In (19), line 79 is unnecessary.

In (20), _object_h, _ and _ex19_h are reserved identifiers in file scope because they start with an underscore. strdup is not checked, leading to undefined behaviour when the description is printed. Curiously, it is recognized the description can be NULL in Object_destroy. This may just be ``defensive coding'', which is unnecessary because free will ignore NULL. process_input may have buffering problems, asking for input before the prompt is flushed. Assuming the second character is ENTER is sloppy. Line 163 of ex19.c is useless. I find typedefing structs distasteful.

In (21), __dbg_h__ is not a valid identifier. The return value of fclose is not checked.

In (22), the descriptions of the integer types are shit. register does not force anything.

(23),(24)-(54) are almost empty. (55) is a worthless, stupid and half-finished rant.

This may be a little too harsh since it's just a public draft.