learning C (was: Re: ambiguous ?)

[Doug Gwyn]

In article <456 at s5.Morgan.COM> amull at Morgan.COM (Andrew P. Mullhaupt) writes:
>OK, so how can I avoid following commonly available bad rules or
>mispractices in C programming? ... I am not satisfied with writing
>merely functional programs; I want them to be clear and clean and
>run everywhere. I want them to be easy to maintain and upgrade.
>Where can I turn to get the kind of advice ...?

Harbison & Steele is okay.  My personal favorite is Kernighan & Ritchie,
which teaches these things more by refusing to teach the contrary than
by making a lot of noise about it.  Plum Hall (1 Spruce Av, Cardiff NJ
08232, (609)927-3770) are probably the oldest firm specializing in C
instruction, and they publish some very good C programming texts that
go into more detail in these areas than K&R.  I have heard good reports
also about Lapin's book on portable C programming, but I haven't
reviewed it.

Many of the tricks of the trade have been explained by several
experienced C programmers in this newsgroup.  There is of course
also a lot of silliness, bad advice, and just plain noise here.
You need to evaluate the suggestions for yourself and develop a
notion of who the reliable sources are.

>Also: is there a logical exegesis of a fairly full subset of C? 
>For example, a set of proof rules in the literature somewhere?

Not so far as I know, although you might check an index to SIGPLAN
Notices.

A company called Metaware has produced a formal semantic specification
for one full dialect of C; their compiler is derived from it.

However, I'm rather skeptical of the practical value of such work
for the concerns that you have.

>I have for years been complaining about the difficulty of unbound
>pointers in this regard, but I am perhaps out of date. (Did the 
>ANSI standardization affect this problem? I'm pretty sure it
>didn't, but I cannot give an authoritative reference.)

Tell me what the problem IS, and perhaps I can answer.  Remember
that C's emphasis is less academic and more practical than most
programming languages.  Just because a clean theoretical model
wouldn't fully cover all valid uses of pointers in C doesn't
mean that there is necessarily a practical problem with its
pointer facility.

>There have been graduate courses for years where every jot and tittle
>of PL/I or Algol 68 are thrashed out in agonizing detail. Anyone
>ever done this for C? 

Gee, I certainly hope not.  That's not a topic worthy of being made
into a graduate course.

>... I just want to know where can I get the straight dope on C short
>of the standard itself, (if possible).

The Standard defines the language, and it's relatively readable
(in fact, using English could be considered a deficiency); the
accompanying Rationale document helps one understand why some
things were specified the way they were.  (Most of the rest are
understandable as directly reflecting the committee's charter.)
The book "Standard C" by P.J. Plauger and Jim Brodie (Microsoft
Press, 16011 NE 36th Way, Box 97017, Redmond WA 98073-9717), ISBN
1-55615-158-6, constitutes a very thorough description of Standard
C, probably the closest you're going to find to an "exegesis".

Keep in mind that Standard C is a recent development, and there are
numerous compilers still in use that support some old-fashioned C
dialect unstead of Standard C.  Therefore, for practical purposes
you ought to consider the impact of older C environments when you
develop software that might be ported to them.  With any luck,
this will be a rather minor consideration after a couple more years.