C Review

[msb at sq.UUCP]

One more message that couldn't be mailed to "Peter Steele - Acadia"
(PLEASE get your software fixed!)...

All right, speaking as a professional C programmer, here are *my* opinions:

> "... 95% of all C programmers couldn't give you a good
> explanation of the term lvalue..."

True.  And what's more, of the other 5%, they probably split
between two different explanations of what it means.  Either
(a) something that you can put on the left side of "=", or
(b) an expression that designates a genuine object [including,
for instance, an array name, but not something like ++p].

> "... Switch/case could be classified as rarely used and should be
> kept till later."

Garbage.

> "... very few C programmers know much about sizeof..."

Not "very few", but "some".  Your book can help educate them.
sizeof *should* be used in conjunction with malloc and fread,
for instance.

> "... 99%  of  all  professional C  programmers  have no idea
> what typedef is all about, couldn't care less and probably
> won't ever need it."

Well, maybe 85%.  I rarely use it myself; I think it's only useful
in connection with library packages where you want to conceal what
type something is, and in connection with portability definitions
such as size_t (the type of the result of sizeof).

> "... 99%  of  all  professional C  programmers  have no idea
> what the comma operator is all about,

Garbage.

> couldn't care less and
> probably won't ever need it."
> "... Leave the comma operator altogether. An intro book is no
> place for obscure and unmaintainable tricks..."

I tend to agree with this part, to a limited extent.

> "... Pointers to functions ... few C programmers understand
> them or would ever need them..."

Possibly true.  It's certainly one of the more "advanced" parts
of the language.

> "... a C programmer never needs to know what a byte is..."

Well, it's what the value returned from sizeof is measured in.

A few comments of my own.  I hope you guys are following the ANSI
people and their drafts of a C standard.  It would be a good idea
to include in an appendix a summary of the innovations in the latest
draft, identifying it as a draft; for instance, the const modifier and
the signed char type.

If the book is really supposed to be introductory, I hope you will
include an appendix sketching briefly the things you didn't cover
(pointers to functions could well go there, I think, and maybe the
comma operator).  I've seen one introductory C book that didn't 
mention the existence of "short" and "long", thus guaranteeing that
their readers' programs won't be portable if their ints ever go over
32767... I think "long" should be introduced right alongside "int",
but it would have helped if they'd at least put it in an appendix.

Mark Brader, utzoo!sq!msb
#define	MSB(type)	(~(((unsigned type)-1)>>1))