The best resource I've found was "The Unix Programming Environment," which goes beyond the C language and into using common libraries and organizing C projects with make and other tools.

Other than that, some food for thought on use of C in the real world is this article by Rob Pike, "Notes on Programming in C:"

http://www.lysator.liu.se/c/pikestyle.html

I've found some books like Maguire's "Writing Solid Code" and McConnell's "Code Complete" to be helpful, but your best resources are probably the source code to systems similar to your definition of 'real'. Depending on this definition, I'd suggest looking at the source for SQLite (compact and rock solid), Apache (customizable request handling), Perl (for polymorphic data types), and Linux (a big modular system). Basically, pick any of the open source tools you use, and see how they've solved the problem you are interested in!

I learned all I know of C from doing the projects for CS167/9 at Brown. The lectures, and more importantly, the project assignments, are online:

http://www.cs.brown.edu/courses/cs167/lect.old.08.shtml http://www.cs.brown.edu/courses/cs167/asgn.shtml

The single most glossed over topic in C textbooks how to avoid using fixed-sized buffers and arrays, and instead use dynamic allocation of string buffers, arrays, and dynamic list structures. Kenneth Reek's book "Pointers on C" is excellent for understanding this in vivid detail. You can not read that book and then claim to be confused by pointers ever again.

Look at successful open source projects and read the source.

Some successful open source projects have dreadful source, though.

There are several threads on HN recommending source to read. (Off the top of my head, I'd recommend the source for Lua and OpenBSD's userland utilities.)

Lua is often recommended, but the one I've seen the most praise for is SQLite.

Lua a nice start, here is a walk-through that I have saved from somewhere:

- lmathlib.c, lstrlib.c: get familiar with the external C API. Don't bother with the pattern matcher though. Just the easy functions.

- lapi.c: Check how the API is implemented internally. Only skim this to get a feeling for the code. Cross-reference to lua.h and luaconf.h as needed.

- lobject.h: tagged values and object representation. skim through this first. you'll want to keep a window with this file open all the time.

- lstate.h: state objects. ditto.

- lopcodes.h: bytecode instruction format and opcode definitions. easy.

- lvm.c: scroll down to luaV_execute, the main interpreter loop. see how all of the instructions are implemented. skip the details for now. reread later.

- ldo.c: calls, stacks, exceptions, coroutines. tough read.

- lstring.c: string interning. cute, huh?

- ltable.c: hash tables and arrays. tricky code.

- ltm.c: metamethod handling, reread all of lvm.c now. You may want to reread lapi.c now.

- ldebug.c: surprise waiting for you. abstract interpretation is used to find object names for tracebacks. does bytecode verification, too.

- lparser.c, lcode.c: recursive descent parser, targetting a register-based VM. start from chunk() and work your way through. read the expression parser and the code generator parts last.

- lgc.c: incremental garbage collector. take your time.

That's from Mike Pall's guide to the Lua source, if you're curious. (He's the author of LuaJIT.)

I've heard that too, but haven't read any of its source myself. (The OpenBSD userland is particularly good because it has a lot of utilities that are useful but small, and whose code can be read in isolation.)

I have a lot of praise for SQLite the product, but wouldn't extend it to using the source as a learning aid.

I would. The approach to testing is fantastic, the style is extremely consistent, the comments and commentary are well thought out, and I find it a good compromise between clarity and efficiency. Why wouldn't you recommend it?

>Some successful open source projects have dreadful source, though.

Still a good learning experience, but yeah, it would be preferable to choose something well known for quality code. I learnt a lot from programming an apache2 module. Supposedly the apache code isn't the best C project available, but there are some interesting real-world aspects of it.

I'm trying to do this myself--I taught myself C, but still can't write any non-trivial programs. Some people find C easy to comprehend, and think naturally in terms of pointers. Not me.

Gnu Ed's source code is quite easy to read. Plan 9's utilities also have very clear, concise source code.

Like what? Memcache is written in C, right? Python itself?

Anyone actually follow this method want to chime in?

PostgreSQL is the best large C codebase I've ever seen.

Look for anything where there are multiple groups using some backend. libpurple is pretty good, both in that it's not perfect, but it's pretty good.

Anything where there's just one group using it lets too much stuff get through.

i think the key is to find something secure (and thus, "correct") and not doused with tons of portability goo (ifdefs, etc.)

look at openssh, but the one in openbsd's tree and not the portable branch. for that matter, any of the openbsd-developed daemons (openbgpd, openntpd, etc.) at http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/ or usr.bin/ssh for openssh.

any of the openwall projects are also small and easy to work with - http://www.openwall.com/

Secure & correct programs don't always have a nice code.

For example qmail is probably the most secure smtp server around. But the code is not easy to read.

Pretty much all the stuff Dan Bernstein writes is secure and correct. But his coding style is just too weird for me and many others.

yes, i avoided listing djb's stuff for that very reason.

I imagine you'd get the most utility out of looking at the source of a system doing something similar to what you're trying to build.