[H-GEN] The perennial book thread

[Greg Black]

[ Humbug *General* list - semi-serious discussions about Humbug and     ]
[ Unix-related topics. Posts from non-subscribed addresses will vanish. ]

On 2003-10-29, Jason Parker-Burlingham wrote:
> Greg Black <gjb at gbch.net> writes:
> 
> >   * The Elements of Programming Style, Kernighan & Plauger
> >   * The Practice of Programming, Kernighan & Pike
> 
> I picked up a well-worn copy of "Software Tools" by Kernighan and
> others a few weeks ago (at the Ithaca library book sale, one of the
> largest around) for a few bucks; when I skimmed it at the sale I
> thought all the example programs were in C but turns out that no, it's
> RATFOR.  Could've fooled me!

ST was written in 1976, around the same time that C was being
developed by DMR.  All those guys knew each other and there was
a lot of cross-pollination of ideas, so it's not surprising that
ST's language was based on C (although it's really Fortran) and
that the tools look like Unix tools.  There's still a BSD port
of Ratfor around; and I guess there's a Linux version too.  (Not
that I'd actually use it unless I was a Fortran programmer.)

> >   * Unix Network Programming, Stevens
> >   * Advanced Programming in the Unix Environment, Stevens
> 
> Stevens is a god.  I have the Sockets and X11 network programming
> book, and used to have a copy of APitUE until it grew legs.  I did so
> enjoy that book.

Stevens is dead, sadly; and he was definitely less godlike than
usual when he wrote APitUE which has a significant number of
plain wrong code examples.  But I still love the book because
it's such an easy read (meaning that it's the kind of book I
take to bed) and because I can identify the errors as I read and
so don't waste time trying to follow him down dead ends.

Usually, when I take aim at Stevens, people want to know why I
think I know more than him; I don't, but I can recognise some of
his mistakes, as he could have had he looked at the code with
fresh eyes.

On p.19 of my 1992 edition, the signal handler in program 1.8 is
undefined according to C standard of the time.  Section 7.7.1.1
says, inter alia: "the behaviour is undefined if the signal
handler calls any function in the standard library other than
the signal function itself ..."  There's more important stuff
after that, but I can't be bothered typing it all in.

Earlier in the same program, there is the following code:

    while (fgets(buf, MAXLINE, stdin) != NULL)
        buf[strlen(buf) -1] = 0;   /* replace newline with null */

Mostly, this is OK, but if I type in a longer line than MAXLINE,
then it will be something other than the newline that gets
clobbered.  This is not a huge thing, in that it's hard to see
how one might exploit it -- but it's indicative of hastily
written code and it's just that sort of code that we all need to
learn not to write.  And it's one more instance of a comment
being harmful: casual readers will see the comment, nod wisely,
and move on.  But the comment does not describe the code.

Cheers, Greg (who really does love Stevens)

--
* This is list (humbug) general handled by majordomo at lists.humbug.org.au .
* Postings to this list are only accepted from subscribed addresses of
* lists 'general' or 'general-post'.  See http://www.humbug.org.au/