http://shop.oreilly.com/product/0636920025108.do

It has mixed reviews - my impression from reading it was that if you agree with the author's choice of tools, it's a good read. There's supposedly a new edition coming out in September.

There's also Learn C the Hard Way:

http://c.learncodethehardway.org/book/

I've struggled to find any other modern books on C programming.

Mixed reviews applies to this book as well. For how often I see it recommended on the net these days, I am disappointed at how many annoying little lies it has in it; it's littered with them. It's also very opinionated (and in my opinion some of these opinions are bullshit) and again it likes to impose the author's choice of tools on you, to the point where he doesn't really even bother explaining how to live without them.

It could do a better job of introducing standard C terminology instead of only presenting the ideas the author came up with, and which often conflict with the concepts as defined by C. It could also do a better job of explaining C's pitfalls and UB instead of just making the reader break certain things and see how his Linux/OS X/Valgrind responds.

EDIT n+1: I just skimmed again through half of the book. Zed actually uses bstring in one of his examples. I don't know whether that should be taken as an implicit endorsement or not, but shame on him. Also, his ideas about secure string handling make me cringe. Also, his "safer" string copying function is not correct. In fact the entire book is littered with lies about strings which no doubt contribute to the confusion people have about them. I'm sure he's well intentioned and he makes good points but for someone wanting to learn how to do C cleanly and securely, I just cannot recommend this book.

http://c.learncodethehardway.org/book/ex44.html

I originally wanted to write more and point out some other important things. For example, “long long” never gets mentioned! This is not a good book to learn C. I believe it could be an adequate (or even good) one to train already existent C skills, but it isn't even that at the moment.

Okay, it isn't a final version. We have to wait until next year for that, but LCTHW gets too much positive attention for being just another less-than-mediocre tutorial book on the Internet.

The bstring thing and his safer copy function are still my favorites for the irony of it. He's sounds so condescending when he attacks C strings and an old K&R example. And then goes on to show how to do it wrong, without really even solving the problem he's trying to solve. And he keeps repeating the lie about C strings just being nothing but an array of chars.

I don't know what'd be a better replacement; it depends so much on the use case. I'd say there is no one-size-fits-all solution to string handling in C. For most code which occassionally deals with strings but isn't really focusing on text, the usual standard library functions and BSD extensions are just fine. I mean malloc, free, strdup, strlcat, strlcpy, strchr, strstr, snprintf, and so on.

For my code editor, I wrote my own dynamic text buffer with the goal of supporting large files with binary data in it. This is highly application specific code and wouldn't make a good general purpose string library.

I skimmed through the bstring code long ago, and I recall seeing quite a bit of questionable or hairy code. But abusing undefined behavior for security purpose was the final stake so I gave up and decided I do not want to use or endorse that library. Also, using ints for string lengths is just stupid if your code ever has to interact with the outside world. Why does bstring do this?

EDIT: Actually, let me just quote the (in)security statement here:

> Bstrlib is, by design, impervious to memory size overflow attacks. The reason is it is resiliant to length overflows is that bstring lengths are bounded above by INT_MAX, instead of ~(size_t)0. So length addition overflows cause a wrap around of the integer value making them negative causing balloc() to fail before an erroneous operation can occurr.