Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!adam.pika.mit.edu!scs
From: scs@adam.pika.mit.edu (Steve Summit)
Newsgroups: comp.lang.c
Subject: Re: Wanted: advice on a good C textbook
Message-ID: <12725@bloom-beacon.MIT.EDU>
Date: 17 Jul 89 00:07:32 GMT
References: <20298082@osu-20.ircc.ohio-state.edu> <9900013@bradley>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: scs@adam.pika.mit.edu (Steve Summit)
Lines: 68

In article <9900013@bradley> vijay@bradley.UUCP writes:
>If you do not want to deal with K&R, then I suppose the best
>book would be "A Book on C" by Ira Pohl. I do not remember the
>ISBN or the publishers...

Oh, dear.  The problem with this book, among other things, is
that it tries to teach you to be a "C guru;" to immerse you in
minutiae about word size, byte order, and character sets (ASCII
vs. EBCDIC).  (There are also a number of unfortunate errors,
such as an observation that it is not necessary to cast a
non-char pointer being passed to free(), "because no warning
results... and the routine works properly.")

Merely mentioning word size and other such difficulties, and
exhorting the student to avoid them, would be fine, and indeed
any good book on C should do so.  This book, however, encourages
you to explore the subject quite deeply; many of the exercises
ask you to write programs to discover your machine's word size,
to explain why programs with intentional overflow problems
misbehave as they do, etc.  Many of the (deliberately
machine-dependent) examples contain unannounced VAXisms (e.g.
passing long ints to printf %d) and would fail in ways other
than intended when attempted by the already mystified student on
other machines.

If you find yourself, while writing a real program, skirting the
edge of a machine dependency (and they do come up in practice),
and if you've never been taught how to write a machine-dependent
program, you'll be forced to go on and discover the correct,
portable implementation.  If you do know how to, and if you know
all of your machine's particular idiosyncracies, it's just too
tempting to write the machine-dependent program now, and deal
with the portability problem later.  When you (or, worse, someone
else) eventually do try to port it, forgetting all of the
embedded dependencies, the porting task becomes miserable indeed.

Why do so many C authors and teachers become so immersed in
implementation details, only to then have to dig their way out of
all the problems introduced?  Why not just teach how to avoid the
troublesome areas in the first place?  (K&R, invariably denounced
in these requests for "beginner's C books," does so nicely:
"...if you don't know how [machine-dependent details] are done on
various machines, that innocence may help to protect you.")

(Zork players may recall a button in the control room of Flood
Control Dam #3 which floods the room with water, and that the
contents of a nearby crumpled tube -- toothpaste -- can,
astonishingly enough, be used to patch the leak and prevent
drowning.  One of the implementors tells the story of the amateur
adventurer who believed that, during every game, the button had
to be pressed and the hole patched, before going on to hunt for
other treasures.  Why not just not push the button in the first
place?)

So as to keep this posting from being wholly negative, I'll
mention that one good introductory C book I know of is
Programming in C, by Lawrence H. Miller and Alexander E. Quilici,
John Wiley & Sons, 1986, ISBN 0-471-81875-5.  (I don't claim it's
the best one, not having exhaustively surveyed the field.)  It
does contain numerous suggestions about good programming style
(and things to avoid).

For the record, A Book on C is by Al Kelly and Ira Pohl,
published by the Benjamin/Cummings Publishing Company in 1984,
ISBN 0-8053-6860-4.

                                            Steve Summit
                                            scs@adam.pika.mit.edu