[snips]
You really are quite a nasty person.
No, he's not.
Schildt, as just one example, wrote The Annotated ANSI C Standard, a book
ostensibly intended to make the ANSI standard clearer and more
approachable. It did so by presenting excerpts from the standard on one
page, then discussing each on the facing page.
Despite this - despite having the relevant portion of the standard staring
him straight in the face while writing the discussion of it - he produced
things which are in some cases simply oversights and the like, but in
other cases actually flat-out wrong, in no way derivable from what he's
supposedly annotating.
For example, in 5.1.2.2, he claims that you can define main as required
for your program, giving the example of void main(void), despite the
facing page - the standard - explicitly stating that no, sorry, this is
not valid.
The book is rampant with such flaws; it is a *bad* book, plain and simple.
Now take Malcolm's book. In terms of explaining algorithms, it might be
perfectly well and good. In terms of doing so _in C_, however, it falls
flat on its face, repeatedly.
He notes, in one place (see his page) "The prefix “str†is reserved by
ANSI". So he *knows* that he's not supposed to use this prefix. He then
proceeds, on the same page (on the web, at least) to define a function
strcount, in direct violation of the rule he, himself, has just explained.
On the same page, he writes " Firstly, the ANSI standard specifies that
strlen() must return a size_t, rather than an integer, to guard against
being passed a string longer than the range of an integer."
Er, no, actually, this does not guard against anything; rather, it simply
allows strlen to return a correct size for a string, if that size exceeds
that which can be stored in an int. However, that aside, he has explained
exactly why the str functions use size_t - because ints simply can't cut
it.
So what does he do? Right; his strcount function returns an int, which he
has already explicitly pointed out is the wrong type, and why.
Any technical book can contain errors. Any can contain mistakes. People
are human, we don't expect perfection from them. Authors, in particular,
walk a fine line between presenting things which are "correct" in the
nit-picking sense, and things which are actually comprehensible to mere
mortals, and they will, at times, likely find themselves sacrificing
absolute strict correctness for clarity and vice versa.
This book, however, presents - in two separate instances in a single
chapter - not simply giving up strict correctness, but going out of its
way to explain a requirement or restriction, then promptly ignoring it
entirely, as if such things simply did not matter when writing code.
The author is obviously well aware of the issues involved; he explicitly
points them out. "str" is reserved. int can't handle the maximum lengths
involved. He documents these... then ignores them.
This is a *bad* book, there are no two ways about it. The flaws in it are
not mere oversights or errors; the author himself admits the code (and
thus the book) is written with his own personal anti-size_t view in mind,
which wouldn't be so bad if he had actually contemplated the effects of
that choice, but it is readily apparent he didn't, nor did he, apparently,
make the risks involved in that decision explicit to the reader.
The result is code that is actively dangerous. Code which discards data,
code which fails in strange and unpredictable ways, code which simply
cannot be used as is, yet which is both sufficiently appealing to
appeal to a novice and sufficiently broken to screw up said novice's
application, without so much as a warning such as "This function can only
handle N bytes of data or corruption will occur" or "your data doesn't
actually matter, so using this function will simply discard it if it feels
like."
It is bad *by design*, because it is not merely a book on algorithms, but
a book on algorithms *and* the author's weird take on proper types,
violation of standard requirements and the like. The author simply
doesn't give a toss about such things and presents this lack of concern as
if it were acceptable practise for a professional - i.e. someone qualified
to write such a book.
It is, in exactly one sense, a good book; it is a good example of how
*not* to do such things. Unfortunately, it seems to lack the appropriate
cover sticker warning the reader of the dangers contained within.
