Learn C The Hard Way

Maybe "low level" is a bit ambiguous.

I certainly agree that C is most appropriate when you are "low in the stack," just above the operating system and maybe implementing something like a virtual machine. I don't make a habit of writing stuff in C for no reason and the vast majority of programming these days isn't and shouldn't be in C (or C++ for that matter).

However, "low in the stack" is different from "low level" like "I refuse to use modern practices" or "I get to omit half the letters from my function names." You can be coding an on-the-metal kind of thing and still think about it in a high level way.

Other uses of C besides low level programming is:

1. Building static libraries. 2. Building so and dll. 3. Binding those so/dll with higher level languages like Ruby, Python, Perl and PHP.

That is my main use of C these days. I always write the IO, user interface code in higher level languages and put all processing code in a so or dll written in C.

Agreed, but it's still sort of a weird case, I think. The considerations related to things like memory allocation, performance, concurrency, internationalization, security, IO, etc. are pretty different in the kernel.

I was just going off on a generic tangent, obviously I don't know what your book will be like. Just talking about C since it's 1am and vaguely on-topic.

You should stop thinking everyone is attacking you. I think you'd be happier.

Really though, there's no content here. The fact it's been voted to #1 on hackernews shows just how bad things are.

Items should be upvoted on their merit, rather than who did them. Someone writing another book about programming C isn't newsworthy.

He is not criticising you; he's criticising what others that undertook this kind of project have done.

Hey, Zed, can you tell us all how much we're losers because we don't get as many blog post hits as you? The irony was a big hit last time.

hey, you don't know me or shite, but you're a fucking cool guy. probably the most generous dude i've ever not met. cheers!

I'm hoping to make this book ramp up faster than LPTHW, since I'm assuming people have either read that book or know one programming language already. However, I'm also a big proponent of practicing the syntax even if you think you're an expert already. It just makes things way easier later on.

I know what you mean, it took me multiple books and articles to pick up functional programming. 'Seven Languages in Seven Weeks' was a good book - as is the K&P book you mention, but something complete that can teach an existing non-func programmer from the ground up, possibly using multiple languages, would be great

When I said "quite a bit more setup", I had SDL in mind. :) Yes, you can get a raw pointer to a graphics buffer via SDL, but in addition to the extra setup to get a window, you have to make extra calls (such as SDL_Flip or SDL_UpdateRect) to make your changes visible.

I personally have no idea why this stuff hits this site that often. Take this for instance: It is a half-finished manuscript that I announced in a tweet to people who follow me on twitter and asked for it. Already at the top of this set of comments is a dickhead saying he's such a bad ass 'cause he's changed "half a million lines of C code" and he thinks I'm not writing the book correctly because I'm being too low level. He gets all of this from three exercises and three paragraphs in the introduction.

Frankly, I consider hackernews kind of irritating and not useful as a promotional tool. It amounts to about 5% of my traffic for 1 day at best, and I only have to be here because if I'm not answering the petty little idiots who troll here then the rumors spread through my professional circles.

In other words: I could live without this kind of promotion, so it's definitely not "self-promotion".

> Not everyone self-promotes to the same extent as Mr. Shaw, or has other people promote them.

I don't know much about Zed. I've seen his name and articles here on HN, of course. I read you comment and was curious. I found nothing but a URL in his HN profile and zero submissions attributed to him here. From my very brief scan of his comments on HN posts, it seems like they are on topic. He's not hijacking threads.

So here on HN, at least, it appears that others are doing the promoting.

Zed seems to write original essays and he seems to have strong feelings and opinions on topics that interest the hacker crowd. And dude's got a memorable name.

It reminds me of SEO strategy: Write original, compelling articles and you won't need SEO.

can you name 2? doubt it...

I knew time-shared BASIC before learning C in 1978. I was definitely a beginning programmer then, still in high school. Many (probably most) of the programmers I know from the same era learned programming from books that would be dismissed today as too hard for beginners. In the preface to the first edition Kernighan and Ritchie wrote: "This book is not an introductory programming manual; it assumes some familiarity with basic programming concepts like variables, assignment statements, loops, and functions. Nonetheless a novice programmer should be able to read along and pick up the language, although access to a more knowledgeable colleague will help." Of course that was before the internet, when access to a "more knowledgeable colleague" was harder to come by. In 1978 the only other languages someone would know were Fortran, BASIC, COBOL, Pascal, assembly language, etc.

Chapter 1, A Tutorial Introduction starts at the same place Zed's book starts: hello world. Looking at it now I don't see any reason my 13-year-old son (who knows a very little bit of Python) couldn't learn C from K&R with me explaining things here and there -- the same way I learned C. The recursive descent parser doesn't come up until the end of chapter 5 (out of 8), right after quicksort is implemented with pointers to functions. By then the reader has built up some skills and presumably developed enough curiosity to refer to other books for more explanation of sorting and parsers. For me those were Knuth's "The Art of Computer Programming," especially the third volume with all of the great example code which I busily translated to C.

If you think K&R is too hard for beginners consider how many programmers learned programming from the badly-typeset and somewhat inscrutable "Pascal User Manual and Report" (1974). That was the programming 101 text used at the local university when I was there.

After arguing I read the preface to Zed's book. He wrote "LCTHW will not be for beginners, but for people who have at least read LPTHW or know one other programming language." It seems LCTHW addresses the same audience as K&R after all.

Nope, this book isn't for total beginners. I mean, it might work, but I'm actually telling the total newbs to go read http://learnpythonthehardway.org/ first. My thought is teaching "computational thinking" is easier with a language like Python, so people should start there.

I would hazard to guess its due to two things: 1) a lack of understanding about how the machine works, and in particular the way the memory is organized; and 2) lack of explanation of why anyone would need to use pointers. Introducing pointers in the context of a linked list, or explaining call-by-reference would probably help make things more concrete.

For me, the indirection of pointers was one of the fundamental CS concepts that required real effort to understand.

Before that point, I had never clearly separated the concept of a variable and its value. It took a huge conceptual leap to think about a variable that didn't hold a value, but rather, the location of a value. It took some serious mental gymnastics to deal with pointers n-levels deep.

Mind you, this was actually Perl references, not pointers, so I didn't even have to try to comprehend doing math on them.

After a while, of course, it became second nature.

My favorite aspect of CS is that every so often, I run into a wall of conceptual understanding that requires completely changing how I think in order to move forward. Have you never had moments like this, or were they just different topics?

K&R chapter 5.5, Character Pointers and Functions, explains pointers and shows how they are used in C. It's probably the clearest explanation of pointers ever written, and it doesn't require any understanding of hardware or assembly language (though that would help).

I remember reading those three pages over and over and experimenting with the code until I got it. I probably spent several days studying the pointer chapter back when I was a teenager. The light bulb eventually went on and C pointers made sense -- until learning C my programming experience was mainly with time-shared BASIC. The stepwise refinement of an indexed array version of strcpy() to a pointer-based version is a masterpiece of programming writing -- I still refer programmers I am mentoring to that chapter.

Finishing the strcpy() example with the one-liner

  while (*s++ = *t++) ;

the authors write "Although this may seem cryptic at first sight, the notational convenience is considerable, and the idiom should be mastered, because you will see it frequently in C programs." I've found that programmers either get that line of code or they don't, and those who don't haven't mastered their craft.

    I never really understood why they didn't grasp pointers

The root of the problem is the language designers' loose use of star. "star something" is contained in a phrase that means one thing at declaration, "star something" has a different meaning the rest of the time.

    #include <stdio.h>
    void eg(int i) {
        int *j = &i; // "huh? Put the address of i into *j?"
        *j = *j + 1;
        printf("%d\n", *j);
    }
    int main() {
        eg(4);
    }

With more detail. In the line..

    int *var = something;

.. the system assigns to the pointer. Yet in..

    *var = 6;

.. it assigns to the contents of the pointer.

Common usage creates further room for confusion:

    int *var; // <- this is what people write
    int* var; // <- instead of this

If they'd made the syntax ".int var", and then used * solely for dereferencing, people wouldn't have these problems learning pointers. Consider

    #include <stdio.h>
    void eg(int i) {
        .int j = &i;
        *j = *j + 1;
        printf("%d\n", *j);
    }
    int main() {
        eg(4);
    }

Further confusion comes from (1) special arrangements around string declaration and (2) printf use of %s to expect a string pointer when %d and %f expects (non-pointer) simple int and simple float.

    char* something = "huh? so now this does goe into *something?";

I can't speak for your friends, but while I had zero problems with pointers conceptually, I still had trouble using them in C. The problem wasn't the simple case of declaring a pointer and taking its reference, the difficulty came when the programs got complex and required agreement between function declarations, actual parameters in calls, and use within the functions.

Mainly because variable declarations are "backwards" in C. People try to read code left to right, but C declarations should be read right to left. Pile one things like the dual use of the static keyword, typedefs, and having multiple consts in a declaration figuring out the type of a variable can be a real chore. Dan Saks has a great article that hits on just the issues with const. http://dansaks.com/articles/1998-06%20Placing%20const%20in%2...

C is difficult, yes. Dangerous - I don't know in what sense. I manage to get more exceptions in my Python, Ruby code, owing to undefined variables or incorrect types, than I get segfaults in C.

The main issue with C is it takes some time before you are ready to take it head on. An experienced C programmers would have his repertoire of generic data structures library with time complexity guarantees (programs without hashes, expandable lists and operations on them are a pain), will know how to properly use function pointers to do that dependency injection thing other programmers are raving about, separate interface from implementation, know the build environment, know how to use structures and function pointer to build abstractions etc.

But before that, C takes much work to produce little. For someone starting programming, the learning curve is steep. Or more like, the gratification is really, really delayed. It takes some time before he can take on a real world project(it does in the high level languages as well, but the initial progress is faster).

The negative connotations of the word aside, it seems perfectly reasonable to call C dangerous. Without that "danger", you couldn't write an OS kernel, a language runtime, or various other low-level code we need on our systems; on the other hand, when writing higher-level code that doesn't need that level of raw access, it seems useful to remove the possibility of a broad class of mistakes.

See also Rusty Russell's rules about "easy to use versus hard to misuse". I find C easy enough to use, but also easy to misuse.

C's scheme is much easier for me than objective-C's, mainly because of autorelease.

That's nothing to do with C as a language, but rather to do with relevant APIs, which can be difficult to read at times.

If you're thinking of arrays as second class citizens, you're thinking of the language incorrectly. Rather you should realize there are no arrays, only pointers to chunks of memory and arithmetic operations.

It is possible to program C with a functional mindset, but the syntax does get in the way. The function syntax does not distinguish between parameters that are modified but you can by convention, and use of structs to bundle stuff up. You can pass function pointers liberally. In the end though the number of use cases for C is smaller now, and you should be able to avoid it for large projects and only use it for small pieces.

C is not the best way to manipulate information, as you have noticed. It's abstractions are all wrong. On the other hand, C is great for computer engineering, as opposed to computer science.

If you are writing firmware, for example, the exact sequence of memory writes is critical. Program the hardware registers in the wrong order, and the device doesn't work. Access the FIFO the wrong way, and your ISR has a data race. Hiding memory access from the programmer is useless when accessing memory correctly is the problem. C is pretty much the only usable language for this kind of work.

The guys writing kernels and system-level libraries face similar issues.

So, C is stateful because the hardware is stateful. C has raw pointers because the hardware has raw pointers. C doesn't manage memory for you because you don't want C to manage memory for you. This all makes sense when you realize that C was invented for writing operating systems.

So, while I do understand your criticism, I think you are looking at this from the wrong angle. The electrical engineering guys build the hardware, and the C guys make the hardware boot up. Fancy functional programming languages are useless without real machines to run on, and C makes those machines go. It's part of the plumbing, just like transistors. Plumbing may be messy and unpleasant, but even the architects designing skyscrapers need to know how it works.

Programming boils down to paying attention to details. C is an extremely small, simple, predictable and malleable [] language that makes you painfully aware of that fact. For me, it is a pleasure to read well-written C code, for example the NetBSD kernel. There's a lot to learn there about elegance and good design.

[] malleable in the sense of bottom-up programming and defining your own "vocabularies". When I develop in C (and C++) I usually solve the problems 75% bottom-up and 25% top-down. With bottom-up approach, it is easy to stay focused at the problem at hand and write mostly bug-free code. The "top-down" bits just put pieces of the puzzle together.

Late to that party, but I'll give my $0.02 regardless.

I won't defend C: it's all that you say. I think one of the acknowledged reasons for C's longevity is that it is impedance-matched for UNIX because they grew up together, and for various reasons UNIX is popular with hackers; therefore C is popular. C is deeply rooted within UNIX, partly because the ABI has been so stable for so long. If you want to write a library for UNIX, you generally target C because anything else will run into a quagmire of cross-compiler incompatibility issues. That means all the good libraries on UNIX are written in C or present a C ABI/API. The easiest language to use a C library from is... C. Or C++. So application writers (and tool writers) have often favoured C as well, although the rise of interpreted languages such as Python, Perl, and Ruby has changed that a bit. Also, the C/C++ toolchains have tended to be more advanced than those of other languages.

So, C is still with us, but for reasons that don't have as much to do with its merits as a language as with its merits as a platform (when coupled with UNIX).

using gdb?

One of the first programs I tried to write in C++ (my first language) was a chess game. I eventually hacked it together, but it wasn't pretty.

The hardest part for me was learning the patterns necessary to do anything, and specifically to do it remotely well.

For example maybe one of the exercises could be some kind of board game, where you demonstrate how you translate "the ideas" into "the C code"? For example just because you know that a Knight can move two-plus-one spaces doesn't mean you have any idea where that code should be inserted into the program's structure, or how to write it in such a way where you avoid overrunning an array. (The naive solution would crash when the Knight tries to move off the board.)

Translating ideas -> C code was easily my hardest task when I was first starting out.

dedicate some later chapters to ramping the reader onto assembler, the stack (and smashing it) and instructions

there are a lot of C devs who don't understand what it is their code is producing, and how an application and memory are managed

My experience as an interviewer showed that in addition to the things you listed, people often fail to grasp binary representation of numbers in a computer at all.

This most often comes up when people are asked to do some binary manipulation of numbers, i.e.:

  unsigned u = 19;
  unsigned v = u >> 1;

"v" is now 9, and to really understand it one must grasp how numbers are represented in binary under the hood.

People also fail to understand strings:

  char* s = "string literal";

To some, it's absolutely opaque that the first byte "s" points to contains 0x73, and that represents "s" in ASCII.

As a teaching assistant for a class (http://www.cs.cmu.edu/~410/) where students write a whole lot of code in C, please introduce the address-of (&) operator and explain how to obtain pointers without using malloc(). Do this before the concept of the heap is ever introduced at all.

Be careful when explaining the compiler and how a program actually runs. I've found that a lot of student problems come from "the compiler is magic" when it really isn't (maybe related to my other surprised comment below, about how people "don't get C"--they attribute too much magic to the compiler.) Maybe even emphasize that every piece of C code can be translated in a fairly easy fashion to a pretty small amount of assembly.

For the preprocessor, emphasize that it is a solely textual replacement, with no symbolic evaluation. Explain why:

    #define FOO BAR + BAZ

or

    #define MAX(x,y) (((x) < (y)) ?  (y) : (x))

will go horribly wrong (the first in 5*FOO, the second in MAX(x++, y++)).

imho, please do have a look at "expert c programming" it is quite nice. the conversational style of the book makes it very enjoyable to read.

The arrow operator and identifiers with leading underscores seem to be glossed over or skipped fairly often in education. It's intimidating to look at code that uses them if you don't know what they are.

In my opinion the thing that many new C developers have trouble with is how large the gap between what their implementation does can be from what the standard says. I think newer C programmers are used to languages that specify a lot more than C does. Try It And See is generally not a useful response for a C question.

The first problem is the notion of absolute precision and detail required to do even the simplest task. The next is how syntax relates to such notions. Then comes mapping the syntax to the task. If they don't grok variables at this point, they're not going anywhere. A lot don't. Above all is the imperative of completion: if they don't make it work somehow, it doesn't work period. I'll try to salvage their work, tell them what to fix, and accept resubmissions - but if it doesn't work, it inherently won't pass the low bar for success.

I'm not sure if this is going to be pure C or a mix of C/C++, but if you're sticking to pure-C, here's a chapter idea: using containers in C.

This is the big selling point for C++ : the convenience of STL. In all the projects that I worked, it was one of the important reasons to choose C++ over C.

Yes, this focuses less on the language itself and more on the ecosystem around it, but I figured if you have an entire chapter dedicated to "make", then this makes sense as well.

I've watched and spoken to a large number of beginning C and C++ programmers (and beginning programmers in general) during their first terms of programming in university. I've noticed a few common problems, and I think they all stem from not understanding the details of how a program runs on a real machine:

- The concept of a variable, and variables changing over time, seems quite difficult for people to grasp even when explained a few different ways. "x = 5" followed by "x = 12" proves quite mystifying, and "x = x + 1" even more so. People seem to have the most success with the idea that declaring a variable "int x" creates a location x which can hold an int, and you can put things in that location.

- Pointers actually don't seem to trip that many people up initially, once they get to that point. However, I don't think people actually understand exactly what they do, so much as memorize the rules for dealing with them. The same idea of a location to put something applies here too.

- Any case where the same function gets called more than once often ends up tripping people up; this applies particularly to recursion, but it can happen even when just calling the same function several times. In particular, this often interacts badly with people's understandings of variables. People need some understanding of scope.

- Combining several of the above, it would help to have clear explanations of the interactions between pointers, locations, and functions. Bonus for explaining what goes horribly wrong if a pointer refers to something that goes out of scope. That concept requires understanding several different pieces of C and putting them together.

I was taught C at Uni, but this was after having done a semester of x86 assembly language so we already had a good grounding in pointers, how addresses work etc. This was our textbook http://oreilly.com/catalog/9780937175231

When learning a new language, the syntax and exercises which explore this come to me fairly quickly. The difficulties are (a) learning the best way of structuring large blocks of code using the new syntax and tools, and (b) for new programmers: understanding how to convert conceptual rules in my head into algorithms.

If you set out to only teach the language syntax and paradigms you are leaving a beginner with a lot of extra work before they can start or contribute to meaningful projects. This is the reason that people learn so much from reading other people's code in open-source projects: most writers skim over trying to teach the most fundamental skill of programming.

I do believe it is possible to teach practicalities in addition to theory and if you attempt to do this, you will be doing a lot more than most writers have done in the past.

Too often we think of C in terms of commands. C is a matter of _operators_. Consider "=", say in the statement

y=1+x=3;

Why and how this works is foreign to most beginners. Likewise (ok, this is C++ but the point remains)

cout<<1+x;

Isn't a command to display 1+x. The output is the result of inserting the computed value into couture. There is a semantic difference.

Groking operators early is key to understanding C well.

> it's not going to rape your family, it'll just crash

Well, if it hits undefined behavior it could in fact rape your family, the standard allows for that.

It'll crash and potentially allow code execution if the rest of the args are user coercible. Check out the first few chapters of The Shellcoder's Handbook for examples.

Thanks for the explanation. I've never seen/had to use %d with integers. I've only used it with %.Nd for floats/doubles.

Right, but I've never seen it used with integers. %.2d is probably the most common format I've seen. Messing up your format strings is a common exploitation vector, so I was wondering if he had typo'd that or otherwise used it accidentally.

That's awesome to hear. I actually know a bit of C, but it has been years since I used it - so this book seems like a good one to read to 'reboot' my C skills.

I'll definitely be waiting anxiously for you to finish.

Good luck!

It doesn't take a VM language or an interpreted lanugage to get libraries working well. Take a look at Haskell's Cabal system and Hackage package library. It works pretty good and doesn't use a VM.

With C and C++, you'll have to use your operating system's package management to get all the important libraries (or build them by hand from Git sources, etc), then have a build system that configures the build environment and searches for all the libraries and other dependencies. It's not as nice as using a dedicated tool for this, like Gem and Bundler in Ruby but usually you get the job done - unless you work on Windows and don't have a package manager.

There are so many, in fact, that choosing one becomes a confusing array of choices in itself.

"It's not the despair, Laura. I can handle the despair. It's the hope I can't stand." (No apologies at all to John Cleese or to anybody else.)

> Why a string must end with a 0 byte.

Unless it's a pstring or you're working with assembly, other language, etc.

But yes there is a lot to learn with C you don't necessarily get with higher level languages in most cases.

May be a good idea to mention some of them. `valgrind` and `lint` comes to mind. On second thoughts, `lint` can be dropped; compiler warnings are good enough for a beginner(in fact, good enough for experienced programmers; subjective).