This looks like a fairly good read for C programming, but it does seem to be showing it's age and has some (now) misinformation. The Copyright is 1996 to 1999,

This looks like a fairly good read for C programming, but it does seem to be showing it's age and has some (now) misinformation. The Copyright is 1996 to 1999, so from what I've looked at this is all C89, no C99 which is what you'll probably see at this point if you look at some C code. I admit to not having read the entire thing, but I've looked through most of it. A few things that stood out to me: 1. They dance around what a multidimensional array in C actually is, and the line "C does not have true multidimensional arrays." is simply false. I'd let it go, but there's a disconnect from when they go from sections 23 and 23.1 to section 23.2. Section 23.2 is most definitely not a multidimension array. Allocating an actual multidimensional array is actually much simpler, just malloc a block of memory into a pointer to an array: int (*a)[3] = malloc(2 * 3 * sizeof(int)); This allocated array works just like any other multidimensional array in C and can be passed as such, and it's much easier to use then the pointer-to-pointer approach. The pointer-to-pointer approach is the only one shown though, as though it's the only option, even though it's not equivalent. 2. In section 18.1.7, type qualifiers, they say 'const' is fairly rare to see. That may have been true when this was written, but in properly written code today it should be decently common to see, mostly in the case that functions are receiving pointers to data they shouldn't be changing and for string literals that shouldn't be changed. Not using const correctly is a source for lots of annoying compilation warnings and runtime errors. 3. The very end of section 20.1 notes that there is no way to define a variable argument macro. That was true at the time of writing (kinda), but it's not true with C99. 4. In section 18.3.1, the switch statement, everything's perfectly fine except that where it says it's common to use a list of #define's over a switch. It's much better to use an enum type to do so since it can annotate your code a bit better, acts basically the same way, you'll get better compilation warnings from it, and in most cases you can let the compiler assign the numbers for you and thus not risk any conflicts from adding and removing options. For whatever reason, I couldn't find any info on enum's in the entire read, which is a huge red-flag. 5. A lot of their function pointer information involves pointers defined as: int (*p)(); The huge issue with that is that they defined it with an unknown parameter list, and it was intended by the author. There are basically zero times when you actually want to do that, in most cases you should either include the argument types, such as: int (*p)(int); Or put void to indicate no arguments: int (*p)(void);