Re: Malcolm's new book - Chapter 1 review

Malcolm McLean wrote On 08/06/07 15:55,:
[...]

However you draw the conclusion that because you disagree with the decision
over size_t, there are weaknesses, which you lack the ability to discover,
within the rest of the work. That seems to me pure bluster.

Malcolm has justifiably complained that the overall
quality of "Basic Algorithms" may be mis-estimated due
to a few prominent errors discussed elsewhere in this
thread. If readers took a wider view, a more comprehensive
sample, they would realize that the few much-deplored
pimples are really just beauty spots. "Oh rash, that
judgest from half the whole!" as Katisha puts it. So I've
taken a longer look, reading the entirety of the book's
opening chapter, "Some Simple Functions." Herewith, my
report of what I found:

The book begins with a non-conforming implementation of
strlen(). It's kind enough to point out the nonconformity,
and goes on to provide a conforming replacement -- but one
wonders what purpose the bogus version serves, other than
to add thickness to the book.

It also claims that strlen() is a "pure function" in
contrast to a "procedure," and gives an unusual definition
for the latter. Nowhere does it mention that the claim of
purity applies only to the two implementations he exhibits,
and need not apply to the Standard strlen() function.

The book's implementation of mystrdup() compels a C99
compiler to emit diagnostics. It also misses out on a
chance at better performance by using strcpy() instead of
memcpy(). But then, the book says that the code it offers
is not highly optimized; perhaps that disclaimer should be
in a more prominent, introductory spot instead of buried
in the commentary on strlen().

At about this point, the text draws attention to some
coding conventions. Among them: the use of the identifier
`answer' to hold a function's return value. Oddly enough,
this mention is the last appearance of "answer" in the
chapter; the rest of the functions do not follow the
stated convention.

There's an fgets() replacement that seems never to
have been tested. Aside from the diagnostics the compiler
is required to emit, there's a backwards test that results
in double-freeing or in dereferencing NULL. Then there are
some baffling stylistic decisions: Why use fgetc() instead
of getc(), why invite bugs by writing buffer sizes and size
increments twice instead of once, why spell NULL as 0, why
put up with the slowness on very long lines when effective
countermeasures are easy?

Next, the book offers a function that is supposed to
remove all white space from a string. As seems to be the
usual case, the compiler must greet this code with a cheery
diagnostic message. Also, the code has a bug that should
not entrap an experienced C programmer. A function to remove
leading and trailing white space from strings elicits the
usual compile-time diagnostic, repeats the bug of the previous
function, and adds a new bug of its own. A remark in the text
indicates that the author was aware of the second bug, but
chose to print it rather than to fix it. Well, he did warn
that the code was not intended to handle "extreme or unusual
inputs" -- another warning that ought to have been written in
a prominent place and in large, bold type rather than buried
in the middle of a paragraph. By defining "extreme and unusual"
as "anything that exposes bugs in the code," the author
absolves himself of all responsibility -- and respectability.

A function to condense runs of white space to single
space characters elicits the usual compiler diagnostic and
repeats the beginners' bug a third time.

Next, the book offers a function to determine whether
a year is or is not a leap year. For a change, no compile-
time diagnostics are required. On the other hand, the
function takes a hopelessly naive view of a complex topic:
the adoption of changes to calendar standards took place at
different times in different regions. For instance, the
book announces that 1900 was not a leap year -- but in
Russia and Greece, 1900 *was* a leap year!

The book makes a fuss about respecting the Standard's
name space by not naming this function isleapyear() -- why
this same fastidiousness does not extend to the strxxx()
functions remains a mystery.

There follows a peculiarity: A day-of-the-week function
that the author confesses he does not understand. The code
was "lifted from the net," says the book, but does not say
whether it was lifted from a reliable or from an unreliable
source. The text says it's all right to use a function you
don't understand, provided you "trust the author" -- but
since the author is unnamed, we do not have the means to
tell whether he is trustworthy.

There follows an explanation of a procedure for finding
the date of Easter, credited to Gauss. This reader had not
heard of Gauss having worked on the problem, and finds it
hard to imagine that it would have interested Gauss: after
all, the best Gauss could hope to do with a formula already
in use would be to simplify it. But perhaps he did do so;
the formula given in the book certainly looks shorter than
the algorithm invented by Aloysius Lilius and Christopher
Clavius almost two centuries before Gauss' birth; I admit
I have not taken the time to ascertain whether the brevity
is merely notational (nor whether the book's formula agrees
with the official one).

The book next offers two macros (mentioning two more,
but not implementing them). The most obvious thing about
the book's macros is that their names consist entirely of
lower-case letters. While this is legal in C, it is far
more usual to name macros in upper-case -- some coding
standards, in fact, insist on this. The macros the book
offers aren't wrong, exactly, just in poor taste.

Oh, and the two that are shown are not safe from side-
effects. There is no mention whatsoever of this rather
important fact: The upshot is that we are offered macros
that have the potential to misbehave *and* are disguised to
look like non-macros (the book even refers to them as
"functions").

The chapter closes with an argument that putting code
in libraries that can be shared by many programs is a Bad
Thing; the "right" way to re-use code is to paste a copy
wherever you happen to need one. (No, I am not making this
up!) And just for laughs, the chapter ends with an English
error.

Statistical summary of "Some Simple Functions:"

- Number of function implementations shown: ten

- Number of functions that require compile-time
diagnostics: five

- Number of functions with bugs (beyond required
diagnostics) spotted by this reader: four

- Number of functions with bugs known to the author
(but published anyhow): one

- Number of macro implementations shown: two

- Number of bad macro implementations shown: two

- Influence of this more extensive reading on the
reader's opinion of the book: negative

--
Eric.Sosman@xxxxxxx
.

Relevant Pages

  • Re: size of a sizeof(pointer)
    ... I *would* call it a compiler (provided it produced an ... "assembler" that translates the C++ to machine code). ... this indicates a bug in the compiler. ... Diagnostics from later passes are ...
    (comp.lang.c)
  • Re: Text box throws an Error 7 Out of Memory with less than 27K in it!
    ... I'd have to agree with Bob here, ... >> those exact numbers and then concatenates that many more, ... I used to work supercomputer compiler support at CDC. ... > My favorite such bug at CDC was a benchmark that ran instantaneously. ...
    (microsoft.public.vb.enterprise)
  • Re: Bug in latest IAR MSP430 compiler optimization???
    ... It has been assigned bug id EW20095, and it will be fixed in the ... The tests compiler companies do are quite extensive. ... register allocation when combined with post-incs and rollup. ... IAR use an industry standard test suite like this (that you don't ...
    (comp.arch.embedded)
  • Re: Salford compiler: Assigning a value to a constant expression is invalid
    ... a bug, it is not usually wise, I think, to assume that it's a compiler bug. ... -|> I'd suggest submitting a self-contained source code file to Salford Support. ... So all I had to do in that case was send the routine and ...
    (comp.lang.fortran)
  • Re: Another computer algebra system : smib
    ... Certainly sometimes a bug is discovered only after a program is ported to a new environment -- a bug that existed in the old environment too, but just had not been exercised. ... Spending time porting a program is ... If the code is a command line drive program, then there should be few differences between for platform A and code for platform B. If one uses portable thread libraries, then if code breaks on platform B, but not on A, I would certainly think it is worth while spending time on platform B to find the problem, as it is highly likely to be a logical error in the program. ... The fact this is new code, I would not release it with over 1600 warnings messages from the compiler. ...
    (sci.math.symbolic)