Re: The annotated annotated annotated C standard

On Jan 18, 5:12 pm, "Clive D. W. Feather" <cl...@on-the-
train.demon.co.uk> wrote:
In article
<96af1648-bd91-43d1-a570-dbda544a4...@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
spinoza1111 <spinoza1...@xxxxxxxxx> writes

Here I shall start a review of "The Annotated Annotated C Standard" at
http://www.lysator.liu.se/c/schildt.html, the source of many of the
attacks on Schildt.

If you wanted to discuss my review of the book, it would have been
polite to at least let me know it was happening. I'm not exactly hard to
find, either on the Internet or in real life.

You could have done me the courtesy to warn me by email that you were
about to join the electronic lynch mob here on comp.programming.


My article, and the resulting web page (thanks to Jutta for marking it
up into HTML) were a review of the book. They weren't written as an
attack, though they are indeed critical.

They certainly enabled one.

"many attacks"? I wrote the material in 1994 and edited it slightly in
1995. I don't even recall anyone mentioning it to me in the last 10
years, so I'm intrigued as to why this attack - or counter-attack if you
prefer - has happened now.

The front cover of the book shows, amongst much clutter and someone's
half-eaten muffin, page 147 of the standard.  It is intriguing to note
that, not only is this the obsolete ANSI standard rather than the ISO
standard, but that it corresponds to half of page 146 in the book.

-Nilges->Tsk, tsk, clutter: meant by the illustrator (not Schildt) to
show an orientation towards the needs of the working C programmer
working with multiple nonconformant-in-the-main C compilers. Anything
at all to extend the charge ***? Anything to dehumanize? Contempt
for the body?

Amusement on my part that the cover didn't match the contents.

3.13
-Schildt->##  However, this limits the total character set to 255
characters.

Actually, it limits it to UCHAR_MAX characters, which is at least 255,
but can be more.  There was an opportunity here to explain what
multibyte characters actually are, but it seems to have been missed,
possibly because of the lack of space

-Nilges->This is a favorite hobby-horse of the hortatory Heathfield.

Multi-byte characters? Yes, it was at the time, because they were one of
the less-well-understood aspects of the C Standard (they probably still
are).

Have you ever wondered why things are "less well understood" as
opposed to being crystal clear? Part of your responsibility was making
things easy to explain but with multi-byte characters and sequence
points you managed to make things impossible for even their creators,
you among them, to explain them.


In reality, any C programmer who merely changes what is only a
#define, e.g., a text-replacement macro with file scope, without
auditing EACH AND EVERY LINE for character width dependent operations
such as shift and rotate is incompetent,

On the contrary, the competent C programmer either makes her code not
dependent on character width in the first place, or puts guard tests in
so that it won't compile if there is such a dependency [or she keeps the
code to herself and notes its limitations].

Let's stop pussyfooting around. Most competent females have left the
field because like Julienne here they are offended at the way boys
(not men) in recent years have made it their job as so-called
programmers to destroy people and not actually program. So drop the
gender affectation.

Furthermore, your example is based on a the lower middle class urban
legend that the only kind of programming labor there is, is solo new
development, whereas in C this is most assuredly not the case. In the
case of large multi-author systems, global perturbations have
unpredictable results without a line-by-line audit of all code, and
this is why Herb is right to equate, in the real world, the byte and
the character. Where the specific attributes of a byte are
redefinable, C is a completely inappropriate choice because it doesn't
allow that redefinition to be made in one place, as it would be in an
OO system.



Pragmatically Schildt is telling students what they need
to know.

The book I reviewed is called "the Annotated C Standard", not "the
student's guide to C programming on the x86 family". The C Standard was
carefully crafted to work on a range of machines, some of which are
quite possibly beyond your imagination. One requirement that it does
*not* put on implementations is that UCHAR_MAX is 255.

Although Herb belonged on the standards team, and not you, because he
is more willing to communicate clearly and not obfuscate, he wasn't
parroting the standard or trying to make you look good. Instead he was
trying to explain your mess to the vast majority of real programmers.


It so happens that the (perhaps) commonest implementation has that
value, and that POSIX has also made that choice (after I pointed out the
implications of not doing so, as it happens), but neither of those is
what the Standard is about.

I note that your extracts omitted the following piece of the
introduction:

    Many of these comments might appear to be relatively trivial.  In
    response to this, I can only point out that the book is commenting
    on a very carefully designed document, and one that has to be read
    precisely.  If the annotator cannot get things right, then the book
    is not just useless, but is a positive danger to those who do not
    have the time to read and analyse every word of the standard.  In
    other contexts, such as a tutorial on C, some of the errors in this
    book could be allowed to pass, but not in this.


Your standard isn't Holy Writ. It is instead a report on the doomed
effort to make a silk purse out of a sow's ear so that corporations
could still make money by vending C compilers, stamped USDA prime in a
deceptive fashion, since to make C appropriate for any new development
of any sort, you'd have to throw it out and start over. No programming
language without textual static nesting of "functions" or preferably
classes to n levels is worth using. The only reason why C Sharp is
viable is that although its functions cannot be nested (a function
cannot be defined in a function) classes and other structures can be,
relegating the function to a detail.

Therefore, you were asking Herb to mindlessly repeat your nonsense. He
made the brave choice not to do so, and not to give you a respect you
did not earn.

That statement can't be repeated too often. This is a book replicating -
and then annotating - a technical standard. When you play in that game,
you get to play by its rules, and one of those rules is that every
little detail matters.

NOT when those details are so unhelpful as to say that a construct
which a maintenance program may have to deal is "undefined". Not when
those details are weasel words.



3.14
-Schildt->  An object is either a variable or a constant that resides
at a
##  physical memory address.

In C, a constant does not reside in memory, (except for some string
literals) and so is not an object.

-Nilges->These types of dogmatic statements show that the speaker has
no compiler or interpreter experience

Wrong.

and is a lousy teacher to boot.

Perhaps, though the University of Cambridge was happy when I taught
computer programming, and more recently people were happy to pay large
sums of money to have me teach them.

Vulgar little sod, aren't you? Money talks? I taught C at Princeton.
Big deal. I would have rather had had the time to write the Tiny C
interpreter which showed a better understanding of C than teaching it
would show. As it happened, I had to content myself with writing a
fully object-oriented compiler for my book in a language superior to
C, which happens to be Visual Basic .Net. VB .Net is superior to C
because there's simply no nonsense and no need to support legacy
features, Basic having for the most part having escaped
"standardization".




Schildt developed a Tiny-C interpreter in 1989 and is a good teacher.

He may be - I've never had him try to teach me.

However, on the evidence of his book, he's not a good Standards person.

What on EARTH is a good Standards man? Somebody who brags that he
developed C Sharp's standard but doesn't have to lower himself to use
it?



The standard is silent on where constants are.

[...]

True, and I accept that in implementations a constant may end up in some
kind of memory.

But *in the C Standard* it is not an object and does not reside in
memory. Since "object" is a key concept in the Standard, this matters.

It is completely misused in your Standard, because you don't know what
an object is, and has been since C++, perhaps since Simscript. You use
the word irresponsibility and have no standing when you charge Herb
with doing violence to it for this reason.



5.1.1.3
The standard is clear that diagnostics are required when syntax rules
and constraints are violated, and are optional otherwise.  This is not
covered at all.  Instead we get the vague statement that

-Schildt->  The standard requires that a compiler issue error messages
when
##  an error in the source code is encountered.

without discussing the different kinds of errors.

-Nilges->Although this is NOT an "error" at all, the purpose being to
ruin Schildt's reputation,

Nonsense. It's a *criticism* of his writing.

...by a nonwriter and an amateur literary critic.

The Standard requires
rather fewer error messages than people expect. At the time I was

Oh, the Standard requires rather fewer error messages than mere
mortals expect? And reverses the direction of languages like Ada,
Pascal, Modula, Oberon, Eiffel, even C Sharp, which won't let you
mindlessly proceed? And this is an advance?

writing, this was one of the major discussion points on the C Standard
and, I felt, deserved treatment.

And it is an error on Schildt's part: there are a huge number of errors
- and types of errors - in source code where the Standard does *NOT*
require that the compiler generate an error message.

it is treated as a countable error.

I was not counting errors. If I were, I would have counted every single
time he used "void main()" or assumed that a byte is 8 bits. But, since
I was writing a critical review of the book, I simply pointed it out the
first time and left it at that.

No, you weren't. You were building a charge ***. Had you exercised
self-restraint and restricted yourself to the few actual errors, you
would have made an impact. But Job One was bringing someone down.



Furthermore, I freely accept that some of my criticisms were over his
choice of what to cover. That's not an error, it's a choice of the
author. I merely feel - as I have the right to - that he made the wrong
choice.

Again, I note how your extracts carefully omit my introductory
statement:

    When I state that no mention is made of a topic, this indicates that
    I feel that the topic is at least as important as ones that were
    commented on; quite often this refers to the features of the
    standard which are less easy to understand.

I am
disgusted by this. This is amateur editing by people who can't
themselves write.

PKB problem. You seem to not understand the difference between "edit"
and "review".





5.1.2.2
-Schildt->  You are therefore free to declare main() as required by
your
##  program.

This statement is immediately followed by the example:
   void main (void)

even though the text of the standard directly opposite states that
this is undefined.  Indeed, the text I quote makes me wonder whether
Schildt believes that:
   struct foo { int i; double d; } main (double argc, struct foo
argv)

is permitted !
Most of the examples in the book declare main() as void.  I won't
bother to point them out individually.

-Nilges-> Everybody knows this to be unfashionable (see Stroustrup's
FAQs).

On the contrary, many of us know what the issue is and why the Standard
made the statement it does.

Your problem here is that your hero screwed up big time. Does he think
that the C90 Standard allow "void main (void)". If the answer is "yes",
then he can't read the words right in front of him. If the answer is
"no", then he is lying to his readers. Which is it?

He's not my hero. Most people in programming repel me. However, I am
repelled even more when computer science is distorted into a
personality competition. I really just don't care about this main()
issue because it is marginal. At least his error concerning block
scope is important, and you should have focused on this.



Let me help you further. Here's the actual wording from the C90
Standard:

            The function called at program startup is  named  main.
       The  implementation declares no prototype for this function.
       It can be defined with no parameters:

               int main(void) { /*...*/ }

       or with two parameters (referred to here as argc  and  argv,
       though  any  names  may  be  used,  as they are local to the
       function in which they are declared):

               int main(int argc, char *argv[]) { /*...*/ }

Nobody knows why it's important.

You mean that you don't know why it's important. All of us who - perhaps
through a typo - have accidentally declared main with a different type
know that there's an issue.

Clue time. Most of us have outgrown the command line...even in
embedded systems.


It is not. In practice, no
competent programmer calls main().

Irrelevant. This is about how the programmer declares main, not how she
calls it.

...which is why it is created by a halfway decent code editor. You
made a mountain out of a molehill to trash Schildt.


And while calling main is unlikely in most code, I've known situations
where it's been the right thing to do.

If it is a serious error for a
given compiler, then it should produce a diagnostic,

Perhaps it should. However, contrary to what your hero says, it isn't
required to.

or, perhaps a new
type of diagnostic: Unfashionable Code.

If you think that's a new concept, you are sadly lacking in experience,
education, or both.

-Nilges-> The lack of compassion, the lack of a sense of proportion,
and the artifact worship is the nastiest sort of geekdom at its worst.

Oh dear, you're starting to froth. You don't seem to understand the
point of a review, and you certainly don't seem to understand the
context in which the original review was written.

Even if a given set of programmers is misled by Schildt (which hasn't
been established at all) they are not held harmless "just because it's
in a book". They are responsible for interpretation as we all are:

So it's not Schildt's fault for writing a book that directly ...

Errata appear in all books. You could have gotten yours in had you
exercised self-restraint and not targeted Schildt. But precisely to
the extent you seem to be a nonprogrammer (at least in C Sharp) who
nonetheless standardizes programming languages for lesser mortals, you
don't seem to understand either genuine computer science (which would
not make order of evaluation violate simple precedence to save post or
pre increment) OR the structure of large programs.

You and your buddies defined a number of situations as "undefined" and
yet at the same time took the position that C need not produce many
error messages.


read more »- Hide quoted text -

- Show quoted text -

.