Re: The annotated annotated annotated C standard part 2

Round 2, eh?

In article <491254cd-4619-43a5-b7c1-11644509c374@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, spinoza1111 <spinoza1111@xxxxxxxxx> writes
-Schildt-> A compound statement is a block of code.

A nice sounding statement, but totally meaningless. A compound
statement is a block of code beginning with { and ending with the
matching }. For example, the body of a function is a compound
statement.

And it's still a totally meaningless statement. Not all blocks of code are compound statements, but you wouldn't know it from Schildt's book.

-Nilges-> Schildt is "block" with a formal scientific meaning which it
acquired during the development of Algol

If he's using "block" in that sense, then it behoves him to explain so.

Of course, the C Standard uses "block" to mean exactly the same thing as "compound statement", so Schildt's statement makes even less sense if I take your interpretation.

That
Kernighan and Ritchie were slightly unclear on this concept is
indicated by their decision to make semicolon into a terminator
(except in the profoundly flawed, and profoundly non-orthogonal for
statement) and not a separator as in Pascal.

You mean "as in Algol". Well, perhaps you should study CPL and BCPL and their treatment of the semicolon.

This was something that annoyed me when I first started programming in C. However, I eventually realized that it was a religious matter rather than a substantive one, and I now have a *slight* preference for semicolon as terminator.

-Nilges-> To the computer-science illiterate, "block" has lost its
Algol meaning, a profoundly important meaning which acknowledges the
human ability to reify rather than accepting a pre-reified
administrated world, but Herb appears to remember this:

I think you're projecting, since there's no evidence of this in the book.

the critics
have been half-educated totally inside one profoundly flawed language
and from within this bubble they mock Herb's broader experience like
fools.

<snort> From your posting style, I suspect that I was programming in Algol before you were born, let alone mewling and puking in your nurse's arms (see, I can do Shakespeare too). I've even used Jensen's Device in anger. Nor is my experience limited to the Algol family.

Languages are a tool. You pick them up and put them down as necessary.

5.2.4.2
-Schildt-> First, notice that a character is defined as 8 bits (1
byte).
## All other types may vary in size, but in C a character is always
## 1 byte long.

Certainly a character is always 1 byte long, since that is what a byte
is defined as. However, nowhere does the standard require a byte to
be 8 bits; an implementation with 47-bit bytes can conform to the
standard.
The assumption that 1 byte = 8 bits occurs at several other points in
the book. I won't always bother to point it out.

-Nilges-> To say that C can with anything but clumsiness handle wider
(or narrower) characters is false, since it is so falsely "powerful"
that to change a C program to handle other than 8 bits implies a line
by line audit. Herb is pragmatically correct.

Both you and he seem to have forgotten the 10th Commandment (though I doubt you'll get the reference). Of course, the competent programmer has no trouble writing code that works correctly with byte sizes other than 8 bits, or with non-two's-complement arithmetic.

The average callow youth in this industry has probably never met anything other than 360-derived architectures, so can perhaps be forgiven for writing with those assumptions. Heck, I sometimes do it myself when I decide to. But when I do, it's a deliberate decision, not the result of ignorance abetted by bad teaching.

6.1
The book carefully talks about tokens, and then proceeds to mention
preprocessing tokens, while totally failing to note the difference, or
why both concepts exist. I would have thought that this was exactly
the sort of thing annotation was all about.

-Nilges-> Once again, amateur writers and literary critics second-
guess an experienced writer. There's a pretty obvious difference
between "processing tokens" and "tokens" which has nothing to do with
C,

Thus showing how little you know. Consider "1and".

6.1.1
## No other keywords are allowed in a conforming program.

False. Other keywords are allowed,
[...]
Of course, no other keywords are allowed in a strictly conforming
program.

-Nilges-> Once again, a phony error is invented to extend the rap
***.

Given that Schildt seems to have a 386 mind, I thought he'd want to talk about how MSDOS compilers add their extra keywords.

6.1.2
If one is going to mention that only the first six characters of
external names are significant, one should also mention that the case
of those six characters is not.

-Nilges-> Once again, amateur and half-literate people second-guess an
experienced writer and imply that this is a technical error.

Yes, I'm second-guessing him. Why mention half a rule and not the other half; it implies to the average reader that there is only that half. Bad pedagogy.

6.1.2.1
-Schildt-> * File scope begins with the beginning of the file and
ends with
## the end of the file
## * Block scope begins with the opening { of a block and ends with
## its associated closing }.
This is not true:
[...]
-Nilges-> Although the passage is taken out of context,

Oh? What context do you believe needs to be restored? I'm all ears (metaphorically speaking).

this may be an
actual error on Schildt's part,

It is.

based on perhaps a confusion with PL/
I. But note that if the programmer believes Schildt, the narrower rule
will pragmatically work for him. He won't "shadow" i as above, and
this probably will make his code more readable.

Or will write code that goes wrong (I can find code that has one meaning according to the Standard and another according to Schildt). But if it's meant to be a "narrower rule", then it should have said so *and* the limitations explained. After all, this isn't a beginners' book, it's a book about the C Standard.

6.1.2.2
-Schildt-> Identifiers with external linkage are accessible by your
entire
## program

Once again this is in error - for example, an identifier with external
linkage is not accessible in a translation unit that uses the same
name with internal linkage. The point of linkage is to indicate when
the same identifier refers to the same object, yet the annotations
omit this entirely.

Again, a curious omission for an annotation.

-Nilges-> It is bad practice, period, to use identifiers in this way,

Arguably. But, more importantly, it's sometimes unavoidable.

and this is why the abandonment of a systematic Hungarian notation
(using, in my practice, upper case Hungarian prefixes for global
variables) is a bad idea.

<s***> Hungarian notation is another of those perversions propagated by those who think that syntax controls semantics.

Herb clearly means, here, ceteris paribus,

If this is a teaching book, then the good teacher explains rather than leaving it to the student to be misled.

If this is a book about the Standard, then it ought to explain what the Standard says rather than misrepresenting it.

--
Clive D.W. Feather | Home: <clive@xxxxxxxxxx>
Tel: +44 20 8495 6138 (work) | Web: <http://www.davros.org>
Fax: +44 870 051 9937 | Work: <clive@xxxxxxxxx>
Please reply to the Reply-To address, which is: <clive@xxxxxxxxxx>
.

Loading