The document talks about C89, even though the last Copyright year is 2003. Isn't it about time that we start movin on? Where are the restricted pointers, the flexible array member and so on?
And, by the way, I think the comment at the bottom of page 27 is not correct:
The qualifier const can be added to the left of a variable or parameter type to declare that the code using the variable will not change the variable. As a practical matter, use of const is very sporadic in the C programming community. It does have one very handy use, which is to clarify the role of a parameter in a function prototype...
Actually, the use of const is encouraged as it helps the compiler to catch more errors as well as to enable some optimizations.
The qualifier const can be added to the left of a variable or parameter type
If you have the declaration
char* str;
Adding const to the left of the type doesn't make the variable immutable:
const char* str;
This indicates that str will point to a character or string which must not be mutated. str itself can be reassigned. To make str immutable, you need
char* const str; // immutable pointer to mutable string
or
const char* const str; // immutable pointer to immutable string
Const does tend to be used little in pure C, though you pretty much can't escape it in C++ code. (I also use it a lot in C, and have type warnings/errors cranked up to max)
I just spent the past 4 months programming a library in C89. I would have MUCH preferred C99 if only for inline variable declaration.
The key issue for my project was being cross platform. Since Microsoft's compiler does not implement C99 and never will, my hands were tied.
Now that's just my library. Other programers might be willing to decide case by case which features of C99 to use. Still if the document dates back to 2003 then C99 support everywhere would have been even more primitive. C89 would thus be the right decision for a introduction to C to avoid confusion.
I suppose I could but that'd be too complicated for my taste. In fact I wouldn't even need to go that far. Many of the most useful things are implemented as extensions to C89 in the popular compilers. Instead I stuck to pure C89 which I knew would be universally implemented. I like knowing that I can set GCC to ansi + pedantic and have a reasonable expectation of no drastic surprises.
C89 is primitive but charming in the simplicity. For instance while I disliked being forced to declare a function's variables before any code I now see that it encouraged me to keep functions very small. I would find ways to use fewer variables. Instead of 'for(int i = 0; i < max; i++)' I would use 'while(--max >= 0)', anything to avoid moving my cursor to the top of the function.
On the other hand I miss C++'s exceptions. Checking for errors all over the place gets ugly and bloats the codebase. What would otherwise be a two line copy operation between two objects gets two if blocks added which handle the miniscule chance of memory allocation failure in some other deeper frame.
The comment about const is correct in C. C++ created this dichotomy between const and non-const objects that makes life harder for everyone, but is needed because of how the language and libraries are organized. In C, const is used only with const strings and other data that is truly immutable, as well as a hint about the use of parameters.
And, by the way, I think the comment at the bottom of page 27 is not correct:
The qualifier const can be added to the left of a variable or parameter type to declare that the code using the variable will not change the variable. As a practical matter, use of const is very sporadic in the C programming community. It does have one very handy use, which is to clarify the role of a parameter in a function prototype...
Actually, the use of const is encouraged as it helps the compiler to catch more errors as well as to enable some optimizations.