HN Books @HNBooksMonth

Expert C Programming: Deep C Secrets https://www.amazon.com/Expert-Programming-Peter-van-Linden/d...

Entertaining and informative. Highly recommended.

⬐ pdw

It was a brilliant book, but I feel it's too stuck in the early 90s to recommend today. It's a pity.

⬐ Abishek_Muthian

Could you explain a bit more about why you feel its outdated and if there's a quirky book for modern C?

⬐ pdw

The other commenter said that it's a joy to read and that's certainly true. If you're interested in software folk tales and such, it's worth getting.

I still see it recommended as a practical book however and indeed the book bills itself as "the second book you need on C", the book that will cover topics that other C books don't explain or explain poorly. But it's much too outdated to serve that purpose. In practice it means chapters discussing differences between K&R C and ANSI C and deep-dives into details of SunOS and MS-DOS compilers.

Some of the material has become misleading because the C language has evolved. For example, there's a lot of discussion about pointers and arrays, as can be expected. But there's no mention of strict aliasing and pointer provenance (these rules existed in C89, but compilers at the time didn't exploit them yet for optimization). And of course no variable-length arrays (introduced in C99). So you're not going to learn what you need to know in today's world.

The book also has almost no discussion about safety. The Morris worm is mentioned, but just as a piece of historical trivia. Browsing it now, I don't even find any discussion about buffer overflows.

⬐ Abishek_Muthian

Thanks for taking the time to explain your comment.

⬐ rramadass

Strongly disagree; The book is still highly relevant today.

Just because there is more unnecessary cruft and complexity in today's systems and tools does not mean the fundamentals/techniques are invalidated.

⬐ pyuser583

That book is a joy to read. Doesn’t matter if it’s even accurate. Read it because it’s fun!

⬐ wernsey

Thanks. Inspired by your comment, I went to see if it was available on archive.org. It was [0]

I've been feeling nostalgic lately and playing around with Turbo C in DOSBox, so I'll definitely check it out.

[0] https://archive.org/details/1.-expert-c-programming-deep-c-s...

"The C Programming Language" from K&R is something everyone should read, even if they are not fond of C.

"Expert C Programming" [1]. Not up to date, but written from a C compiler writer standpoint. A lot of references to why C (and libs) are the way they are.

[1] https://www.amazon.com/Expert-Programming-Peter-van-Linden/d...

⬐ carols10cents

How does K&R back up the claims you've made here?

I really enjoyed Expert C Programming (https://www.amazon.com/Expert-Programming-Peter-van-Linden/d...).

This is a fun book to start with "Expert C Programming Pete van Linden" https://www.amazon.com/Expert-Programming-Peter-van-Linden/d...

I really enjoyed "Deep C Secrets" as an intermediate C book:

Expert C Programming: Deep C Secrets https://www.amazon.com/dp/0131774298/

A little dated, still lots of relevant knowledge though.

⬐ sifoo

One of my all time C favorites.

⬐ geokon

What I liked about this book is that it's very upfront about how messed up C is. I read about half of it and it made me never want to write any C ever again.

An especially memorable part for me was how it took 3 pages of language lawyering to explain why this doesn't compile:

    foo(const char **p) { }

    main(int argc, char **argv)
    {
    foo(argv);
    }

⬐ int_19h

I don't see this as a good example of "how messed up C is". It doesn't compile because you're violating const correctness, and any other language with similarly sound correctness requirements would flag it in a similar way. If anything, this is one of those rare cases where C chooses correctness over convenience.

It takes quite a bit to explain because the "common sense" is that if one level of pointer indirection allows you to pass non-const where const is expected, then two levels shouldn't be any different. But common sense is wrong, and the compiler is right. And it doesn't require any language lawyering, either - all you need to do is slightly tweak the example to show why exactly it is unsafe.

⬐ rcxdude

A better example of messed up in that example is how it's not a compile-time error (but is very nasty undefined behavior) for the function without an explicit return type (so defaulting to int) to end without returning anything.

⬐ int_19h

Compilers can - and, indeed, do - diagnose UB as compile time errors, or at least warnings (which you can then turn into errors if you want) all the time.

Now, it is not undefined behavior for the function to not return anything despite having a return type. It is UB for the caller to try to use the returned value, but in this case it's not actually used.

The implicit int feature is really very much deprecated (in fact, it was already removed in C99, almost 20 years ago!). If, for some mysterious reason, you're trying to compile code like that, it's probably very old code dating to before C was an ANSI standard, and void return type was a thing. In such code, it would be pretty common for functions to not return anything, because semantically they don't - it was just a quirk of the language that there was no notion to express a non-value-returning function back then, and so returning an (undefined) int became idiomatic. In C89, this entire behavior was retained largely because backwards compatibility was necessary. C99 finally fixed it.

This is the book for this particular subject:

https://www.amazon.com/Expert-Programming-Peter-van-Linden/d...

Every C programmer should have this on their bookshelf!

# Deep C programming

http://www.amazon.com/dp/0131774298/?tag=akhn-20

Talks about all the weird historical C design decisions.

# 21st century C programming

http://www.amazon.com/dp/0131774298/?tag=akhn-20

Discusses the language and some of the best practices.

⬐ tonetheman

Deep C is wonderful.

⬐ sfrailsdev

21st century C programming, as I recall, will get you set up a dev environment with tooling, which can be hard for an entry level C programmer. It also covers useful tools and libraries.

It's also a fairly good C book in general, though I don't know that I'd want to try to learn a computer language from it.

This is covered in "Expert C Programming: Deep C Secrets"

https://www.amazon.com/gp/product/0131774298

How is this?

Some random guy suggested this to me to take my C to the next level: Expert C Programming: Deep C Secrets

https://www.amazon.com/Expert-Programming-Peter-van-Linden/d...

⬐ hackerboos

I've seen that book recommended a lot. Check online for the errata if your book doesn't have an errata insert.

21st Century C is another good one.

⬐ 616c

I mean I laughed. But yes, tptacek worship, even from wannabes like me, is annoying (perhaps even to him).

My point was can someone steer us to good materials. I proferred what I heard hoping others would correct me and other posters.

I like the premise of LCTHW. Why not show me small projects that are simple to compile, but sucky and basic, and ask me to gradually fix him.

I went through a few chapters, and it is good. I am just lazy. But the projects are small. If somene fleshed this out into something more thorough, it would help sucky learners like me everywhere!

⬐ tptacek

Yeah, it's pretty weird.

CII is a great, great C book though.

What's the rush?

http://norvig.com/21-days.html

Learning C is difficult because you need to know how the machine actually works. Trust me, there are no shortcuts. The year can be 2036, learning C will be the same.

With that said, these books are excellent:

http://www.amazon.com/Programming-Language-Brian-W-Kernighan...

http://www.amazon.com/Expert-Programming-Peter-van-Linden/dp...

http://www.amazon.com/Primer-Plus-6th-Developers-Library/dp/...

⬐ GregBuchholz

The Peter van Linden book: Expert C Programming is available on-line:

http://www.madar.com.pl/demo/expert.pdf

"Deep C Secrets" is quite good.

http://www.amazon.com/Expert-Programming-Peter-van-Linden/dp...

I concur .. another good book that will teach you more about C in a productive way, is "Expert C Programming- Deep C Secrets":

http://www.amazon.com/Expert-Programming-Peter-van-Linden/dp...

⬐ WYSIMOLWYG

I just finished reading "Expert C Programming", and thus far it's been the best C book I've read! You'll learn a lot about the intricacies of the language, and you'll actually laugh while reading some sections (most C books can be quite boring and dull).

Disclaimer: I've only been writing C for a bit over two years (so still very new), and my list of C literature consists mainly of the following books:

  - K&R
  - Mastering Algorithms with C - Kyle Loudon
  - Understanding and Using C Pointers - Richard Reese
  - Test Driven Development for Embedded C - James W. Grenning
  - Expert C Programming: Deep C secrets - Peter van Linden

Expert C Programming: Deep Secrets (http://www.amazon.com/Expert-Programming-Peter-van-Linden/dp...)

Advanced C: Tips and Techniques (http://www.amazon.com/Advanced-Techniques-Hayden-Books-Libra...)

35 years ago, when I was told my 2nd freshman course in programming would be in Pascal, I bought the _Pascal User's Manual and Report_, read through it in one sitting, managed to remember most of it (Pascal is a small language) and was able to program in it - at a beginner level, of course. K&R is roughly the C equivalent. If you want the language and nothing but, then it should do you nicely.

My personal favorite, because it explains better (so I think) and dives into a little more depth where K&R leaves you to extrapolate on your own, is Peter van der Linden's "Expert C Programming" (Deep C Secrets): http://www.amazon.com/Expert-Programming-Peter-van-Linden/dp... . Also, I enjoy the author's entertaining style, and think it aids learning.

More of a general (i.e., not embedded systems specific) book on C is "Deep C Secrets", by Peter Van Der Linden.

Amazon link: http://www.amazon.com/Expert-Programming-Peter-van-Linden/dp...

⬐ ndesaulniers

This is an excellent book...but I would not recommend it to beginners. Read "Head First C" first, then maybe this book. Would also recommend "21st Century C."

⬐ fit2rule

An excellent book, and one which stands right next to K&R in my opinion, as a standard reference book on the subject of the C language. It still has much relevance today - many C projects I've seen being written by the new generation of developers could benefit from having this book become standard reference material everywhere. I can't recommend it enough.

C would be worth studying, as would some books around and about C. (Peter van der Linden's Expert C Programming comes to mind.) Even if you don't actually use C much, it's been a standard for a long time, with lots of interesting heritage.

http://www.amazon.com/Expert-Programming-Peter-van-Linden/dp...

Everyone else's advice to learn by doing is great, but there is also _Expert C Programming_ by Peter van der Linden:

http://www.amazon.com/Expert-Programming-Peter-van-Linden/dp...

The presentation's "Deep C" pun is a reference to this book, and if you make it all the way to slide 444 you'll see it mentioned as further reading. It's a wonderful book for understanding C (not C++) and what's really going on.

⬐ bloodorange

It'll take a team of ten authors and a couple of decades to write something of that kind for C++.

Though the language is full of horrors, I still quite enjoy C++ (esp. with C++11 and am looking forward to some C++14 features...)

⬐ qznc

I know at least one guy, who is on it. http://herbsutter.com/gotw/

⬐ bloodorange

Nice! Thanks for the link.

Just FYI, If you know C and you want to take it to the next level, then Expert C Programming:Deep Secrets is one of the best books out there.

http://www.amazon.com/Expert-Programming-Peter-van-Linden/dp...

I never got into C because of books like "Expert C Programming"[0], knowing they exist tells me that theres a ton of "gotchas", and life is too short for that if I'm not really crazy about it in the first place.

Then again, as far as actual grammars go, I've heard C++ is bad enough that the compilers are the standard, and that if you want to be "compliant" with real world C++ code you copy every feature [1] of GCC.

[0]: http://www.amazon.com/Expert-Programming-Peter-van-Linden/dp...

[1]: ftp://ftp.trailing-edge.com/pub/rsx11freewarev2/rsx81b/374001/jargon.txt

⬐ cmccabe

Almost every language has a book titled "Expert $LANGUAGE". If a language doesn't have one of those, it's probably either very new, or nobody actually uses it, or both.

C and C++ are good for doing low-level stuff. If you don't want to do low-level stuff, then you should not worry about them. But in that case, you might also want to avoid commenting about them :)

clang is copying gcc's features because most of them are good features, and standards bodies move slowly. This is kind of an odd thing to criticize C++ for, since a lot of newer languages don't even have a standard, but just a reference implementation. It's hard to criticize your neighbor for living in a tent when you live in a sleeping bag.

⬐ unimpressive

>Almost every language has a book titled "Expert $LANGUAGE". If a language doesn't have one of those, it's probably either very new, or nobody actually uses it, or both.

I said books. I got that vibe in general from the people I met who claimed to be C wizards. Incredibly offputting.

>C and C++ are good for doing low-level stuff. If you don't want to do low-level stuff, then you should not worry about them. But in that case, you might also want to avoid commenting about them :)

I was going to delete my original comment because reading it over it felt like a bad idea. (I don't like jumping into ignorance induced shitstorms.)[0][1]

>This is kind of an odd thing to criticize C++ for, since a lot of newer languages don't even have a standard, but just a reference implementation.

I should have put "features" in quotes. I was specifically using the definition in the old jargon file. [2] So what I really meant to say is that the compilers end up supporting each others bugs for compatibility reasons.

As for reference implementations, if the reference implementation is for all practical reasons the only implementation, then you don't need a standard.

[0]: The comments I got in response are interesting enough that I'm actually glad I didn't.

[1]: EDIT. My ignorance.

[2]: See footnote on the last post, I should have made that more clear or used different terminology.

⬐ cmccabe

So what I really meant to say is that the compilers end up supporting each others bugs for compatibility reasons.

Example?

⬐ unimpressive

There was an "I heard" in that original context. Back in the great grand parent post. I might be able to find some examples, but since I don't have one off hand I'd rather drop the conversation.

So that's what I'm going to do unless I suddenly get the urge to go running through clangs commit log.

K&R is great! For a really deep understanding how pointer and arrays are related I also recommend Expert C Programming by Peter van der Linden (http://www.amazon.com/Expert-Programming-Peter-van-Linden/dp...)

OK, if you don't have any real experience in low-level embedded coding (relevant to device drivers), RTOS or OS design in general, file systems, data structures, algorithms, interfaces, etc. And, if you have "hobby level" experience with Assembler, C and C++. And, if your intent is to write a desktop OS, from the ground up, without making use of existing technologies, drivers, file systems, memory management, POSIX, etc. Here's a list of books that could be considered required reading before you can really start to write specifications and code. Pick twenty of these and that might be a good start.

In no particular order:

1- http://www.amazon.com/C-Programming-Language-2nd-Edition/dp/...

2- http://www.amazon.com/The-Answer-Book-Solutions-Programming/...

3- http://www.amazon.com/The-Standard-Library-P-J-Plauger/dp/01...

4- http://www.amazon.com/C-Traps-Pitfalls-Andrew-Koenig/dp/0201...

5- http://www.amazon.com/Expert-Programming-Peter-van-Linden/dp...

6- http://www.amazon.com/Data-Structures-In-Noel-Kalicharan/dp/...

7- http://www.amazon.com/Data-Structures-Using-Aaron-Tenenbaum/...

8- http://www.amazon.com/Mastering-Algorithms-C-Kyle-Loudon/dp/...

9- http://www.amazon.com/Code-Complete-Practical-Handbook-Const...

10- http://www.amazon.com/Design-Patterns-Elements-Reusable-Obje...

11- http://www.amazon.com/The-Mythical-Man-Month-Engineering-Ann...

12- http://www.amazon.com/The-Programming-Language-4th-Edition/d...

13- http://www.amazon.com/The-Standard-Library-Tutorial-Referenc...

14- http://www.amazon.com/API-Design-C-Martin-Reddy/dp/012385003...

15- http://www.amazon.com/The-Linux-Programming-Interface-Handbo...

16- http://www.amazon.com/Computer-Systems-Programmers-Perspecti...

17- http://www.amazon.com/System-Programming-Unix-Adam-Hoover/dp...

18- http://www.amazon.com/Memory-Programming-Concept-Frantisek-F...

19- http://www.amazon.com/Memory-Management-Implementations-Prog...

20- http://www.amazon.com/UNIX-Filesystems-Evolution-Design-Impl...

21- http://www.amazon.com/PCI-System-Architecture-4th-Edition/dp...

22- http://www.amazon.com/Universal-Serial-System-Architecture-E...

23- http://www.amazon.com/Introduction-PCI-Express-Hardware-Deve...

24- http://www.amazon.com/Serial-Storage-Architecture-Applicatio...

25- http://www.amazon.com/SATA-Storage-Technology-Serial-ATA/dp/...

26- http://www.amazon.com/Beyond-BIOS-Developing-Extensible-Inte...

27- http://www.amazon.com/Professional-Assembly-Language-Program...

28- http://www.amazon.com/Linux-Kernel-Development-3rd-Edition/d...

29- http://www.amazon.com/Version-Control-Git-collaborative-deve...

30- http://www.amazon.com/Embedded-Software-Primer-David-Simon/d...

31- http://www.amazon.com/Programming-Embedded-Systems-C/dp/1565...

32- http://www.amazon.com/Making-Embedded-Systems-Patterns-Softw...

33- http://www.amazon.com/Operating-System-Concepts-Abraham-Silb...

34- http://www.amazon.com/Performance-Preemptive-Multitasking-Mi...

35- http://www.amazon.com/Design-Operating-System-Prentice-Hall-...

36- http://www.amazon.com/Unix-Network-Programming-Sockets-Netwo...

37- http://www.amazon.com/TCP-Illustrated-Volume-Addison-Wesley-...

38- http://www.amazon.com/TCP-IP-Illustrated-Vol-Implementation/...

39- http://www.amazon.com/TCP-Illustrated-Vol-Transactions-Proto...

40- http://www.amazon.com/User-Interface-Design-Programmers-Spol...

41- http://www.amazon.com/Designing-Interfaces-Jenifer-Tidwell/d...

42- http://www.amazon.com/Designing-Interfaces-Jenifer-Tidwell/d...

43- http://www.amazon.com/Programming-POSIX-Threads-David-Butenh...

44- http://www.intel.com/p/en_US/embedded/hwsw/software/hd-gma#d...

45- http://www.intel.com/content/www/us/en/processors/architectu...

46- http://www.intel.com/p/en_US/embedded/hwsw/hardware/core-b75...

47- http://www.hdmi.org/index.aspx

48- http://en.wikipedia.org/wiki/Digital_Visual_Interface

49- http://www.amazon.com/Essential-Device-Drivers-Sreekrishnan-...

50- http://www.amazon.com/Making-Embedded-Systems-Patterns-Softw...

51- http://www.amazon.com/Python-Programming-Introduction-Comput...

52- http://www.amazon.com/Practical-System-Design-Dominic-Giampa...

53- http://www.amazon.com/File-Systems-Structures-Thomas-Harbron...

54- ...well, I'll stop here.

Of course, the equivalent knowledge can be obtained by trial-and-error, which would take longer and might result in costly errors and imperfect design. The greater danger here is that a sole developer, without the feedback and interaction of even a small group of capable and experienced programmers could simply burn a lot of time repeating the mistakes made by those who have already trenched that territory.

If the goal is to write a small RTOS on a small but nicely-featured microcontroller, then the C books and the uC/OS book might be a good shove in the right direction. Things start getting complicated if you need to write such things as a full USB stack, PCIe subsystem, graphics drivers, etc.

⬐ tagada

The guy don't want to write a perfectly designed OS, neither he wants to design a RTOS by the way ... He didn't even specify whether his OS would be multitask. If not, no need for any scheduling at all, huh ... he just "writes his own OS". It's a fun experience, very rich and very teaching. But at least now, we all can admire the wideness of all your "unlimited knowledge" especially in terms of titles of books. Afterall, no needs for creating a new OS, if you get all your inspiration from things that already exists. You will end with Yet Another Nix ... Not sure he wants a YanOS, though.

Without talking about filesystems, drivers, memory managment or existing norms and standards (which it seems he wants to avoid ... which is not that stupid ... all having been designed 40 years ago ... who knows maybe he'll have a revolutionary idea, beginning from scratch), going from scratch with no exact idea of where you go could be a good thing. Definitely. You solve the problem only when you face them. Step by step, sequentially. Very virile, man.

I would advice the guy to start obviously with the boot loader. Having a look at the code of GRUB (v1), LILO, or better yet, on graphical ones (BURG, GAG or this good one XOSL which is completely under GUI - mouse pointer, up to 1600x1200 screens, and many supported filesystems, written in ASM ... it could actually be a hacking basis for a basic OS on itself) could be a great source of inspiration, and beginning to play directly with the graphical environment.

You could also have a look on these things http://viralpatel.net/taj/tutorial/hello_world_bootloader.ph... and of course on Kolibri OS http://kolibrios.org/en/?p=Screenshots

⬐ tagada

Blah, blah, blah ...

Better advice would be: Try, make mistakes, learn from them, continue.

Way, way, way less discouraging, pessimistic and above all pedantic.

⬐ derefr

> If the goal is to write a small RTOS on a small but nicely-featured microcontroller, then the C books and the uC/OS book might be a good shove in the right direction. Things start getting complicated if you need to write such things as a full USB stack, PCIe subsystem, graphics drivers, etc.

I've always wondered if there could be created some way to skip this step in [research] OS prototyping, by creating a shared library (exokernel?) of just drivers, while leaving the "design decisions" of the OS (system calls, memory management, scheduling, filesystems, &c.--you know, the things people get into OS development to play with) to the developer.

People already sort of do this by targeting an emulator like VirtualBox to begin with--by doing so, you only (initially) need one driver for each feature you want to add, and the emulator takes care of portability. But this approach can't be scaled up to a hypervisor (Xen) or KVM, because those expect their guest operating systems to also have relevant drivers for (at least some of) the hardware.

I'm wondering at this point if you could, say, fork Linux to strip it down to "just the drivers" to start such a project (possibly even continuing to merge in driver-related commits from upstream) or if this would be a meaningless proposition--how reliant are various drivers of an OS on OS kernel-level daemons that themselves rely on the particular implementation of OS process management, OS IPC, etc.? Could you code for the Linux driver-base without your project growing strongly isomorphic structures such as init, acpid, etc.?

Because, if you could--if the driver-base could just rely on a clean, standardized, exported C API from the rest of the kernel, then perhaps (and this is the starry-eyed dream of mine) we could move "hardware support development" to a separate project from "kernel development", and projects like HURD and Plan9 could "get off the ground" in terms of driver support.

⬐ robomartin

A lot depends on the platform. If the OS is for a WinTel motherboard it is one thing. If, however, the idea is to bypass driver development for a wide range of platforms it gets complicated.

In my experience one of the most painful aspects of bringing up an OS on a new platform is exactly this issue of drivers as well as file systems. A little google-ing quickly reveals that these are some of the areas where one might have to spend big bucks in the embedded world in order to license such modules as FFS (Flash File System) with wear leveling and other features as well as USB and networking stacks. Rolling your own as a solo developer or even a small team could very well fit into the definition of insanity. I have done a good chunk of a special purpose high-performance FFS. It was an all-absorbing project for months and, realistically, in the end, it did not match all of the capabilities of what could be had commercially.

This is where it is easy to justify moving into a more advanced platform in order to be able to leverage Embedded Linux. Here you get to benefit and leverage the work of tens of thousands of developers devoted to scratching very specific itches.

The down-side, of course, is that if what you need isn't implemented in the boad support package for the processor you happen to be working with, well, you are screwed. The idea that you can just write it yourself because it's Linux is only applicable if you or your team are well-versed in Linux dev at a low enough level. If that is not the case you are back to square one. If you have to go that route you have to hire an additional developer that knows this stuff inside out. That could mean $100K per year. So now your are, once again, back at square one: hiring a dev might actually be more exoensive than licensing a commercial OS with support, drivers, etc.

I was faced with exactly that conundrum a few years ago. We ended-up going with Windows CE (as ugly as that may sound). There are many reasons for that but the most compelling one may have been that we could identify an OEM board with the right I/O, features, form factor, price and full support for all of the drivers and subsystems we needed. In other words, we could focus on developing the actual product rather than having to dig deeper and deeper into low-level issues.

It'd be great if low level drivers could be universal and platform independent to the degree that they could be used as you suggest. Obviously VM-based platforms like Java can offer something like that so long as someone has done the low-level work for you. All that means is that you don't have to deal with the drivers.

To go a little further, part of the problem is that no standard interface exists to talk to chips. In other words, configuring and running a DVI transmitter, a serial port and a Bluetooth I/F are vastly different even when you might be doing some of the same things. Setting up data rates, clocks, etc. can be day and night from chip to chip.

I haven't really given it much thought. My knee-jerk reaction is that it would be very hard to crate a unified, discoverable, platform-independent mechanism to program chips. The closest one could possibly approach this idea would be if chip makers were expected to provide drivers written to a common interface. Well, not likely or practical.

Not an easy problem.

⬐ derefr

> It'd be great if low level drivers could be universal and platform independent to the degree that they could be used as you suggest. Obviously VM-based platforms like Java can offer something like that so long as someone has done the low-level work for you. All that means is that you don't have to deal with the drivers.

Another thought: if not just a package of drivers, then how stripped down (for the purpose of raw efficiency) could you make an operating system intended only to run an emulator (IA32, JVM, BEAM, whatever) for "your" operating system? Presumably you could strip away scheduling, memory security, etc. since the application VM could be handling those if it wanted to. Is there already a major project to do this for Linux?

That was good. Also, "Deep C Secrets": http://www.amazon.com/Expert-Programming-Peter-van-Linden/dp...

I may be using the word 'modern' a bit liberally here, but these are all more recent than K&R at least. 'C A Reference Manual' I think is what a lot of people really want out of a C book and 'Expert C'/'C Traps and Pitfalls' both help with all of the less intuitive parts of the language that you don't really get out of K&R.

C A Reference Manual http://www.amazon.com/Reference-Manual-Samuel-P-Harbison/dp/...

Expert C http://www.amazon.com/Expert-Programming-Peter-van-Linden/dp...

C Interfaces and Implementations http://www.amazon.com/Interfaces-Implementations-Techniques-...

C Traps and Pitfalls http://www.amazon.com/C-Traps-Pitfalls-Andrew-Koenig/dp/0201...

The Butt-Ugly Fish Book has a great section on this: http://www.amazon.com/Expert-Programming-Peter-van-Linden/dp...

In fact it's filled with great sections - go read it if you haven't.

After K&R, I highly recommend Peter van der Linden's Expert C Programming (http://www.amazon.com/Expert-Programming-Peter-van-Linden/dp...). It's fun to read (yes, really), and you'll understand the language better for it. C is fairly quirky, and this book helps navigate those quirks.

For example, I bet most people who claim to "know" C can neither explain the difference between arrays and pointers, nor clarify where they cannot be used interchangeably. I was lucky to have read that book early on in my days of C, so I actually know the answer.

not for learning, but as a reference to keep on your desk when programming in c - harbison + steele http://www.careferencemanual.com/

this is also worth reading once you've got the basics down - http://www.amazon.com/Expert-Programming-Peter-van-Linden/dp...

⬐ maw

I second the recommendation of van der Linden's book. It was through that book, along with lots of programming and experimentation, of course, that I finally understood C.

This is like a never ending issue. One way to start the path to a better practice of C is to read http://www.amazon.com/Expert-Programming-Peter-van-Linden/dp... after you finished http://www.amazon.com/Programming-Language-Prentice-Hall-Sof...