This is unknowable.
Incorrect on two counts.
1. Several easily-fixed errors are definitely fixed in the 4th
edition.
2. Only the 4th edition has come out since I wrote my critique.
I would point out, though, that the 4th edition still has some very
serious misunderstandings in it.
More importantly, he's done nothing to demonstrate the existence of this
alleged malice. Showing that someone was harmed by something doesn't
demonstrate malice; you'd have to show that the *purpose* was to do harm.
Your malice would certainly be plain to an American jury. An attorney
would simply demonstrate that your were envious of Herb's academic
qualifications and angry that McGraw Hill wouldn't pay you enough.
I would in fact describe you as "malicious" both in your conduct
towards Herb and towards me. I offered you a chance to discuss our
differences by way of email even as McGraw Hill offered to pay you an
honorarium, and in both cases you turned these opportunities down.
This was an unfriendly and malicious thing to do.
You are also fond, here, of calling people "morons" and "insane". And
shove your *tu quoque*, Seebach, since I don't label people: I analyze
beliefs and criticise behavior.
There are serious flaws in the C standard, and it's a waste of ink,
since no one understands it here or elsewhere. It doesn't have the
clarity a standard should have because it tried to square the circle,
and wound up labeling running code "undefined" when in most cases this
code has a defined result. That is because it's junk science which
bends over backward to make existing compilers unchangeable so as to
protect vendor profits.
A sensible "C standard" would have in fact defined a new C free of
these problems:
"Examples of undefined behavior are:
accessing outside the bounds of an array
overflowing a signed integer
reaching the end of a non-void function without finding a return
statement, when the return value is used
reading the value of a variable before initializing it
These operations are all programming errors that could occur using
many programming languages; C draws criticism because its standard
explicitly identifies numerous cases of undefined behavior, including
some where the behavior could have been made well defined, and does
not specify any run-time error handling mechanism."
I can see where the programmer could be responsible for "accessing
outside the bounds of an array" or "overflowing a signed integer".
But "reaching the end of a non-void function" and falling off the end
of the world is flat-earth thinking, the unnecessary preservation of
the mistakes of the past and the limitations of old machines. You
should have FORCED vendors to hire compiler developers to FIX this
problem by simply adding a machine language return statement behind
ALL such functions as a guard, or behind functions where the return is
missing. This isn't rocket science.
"Evaluating actual parameters right to left, or left to right, or ****
all, such that a(b, b++) is undefined" is additional malarkey. I
encountered this issue in compiling variable length parameter lists
with no fixed bound in my book compiler, and, since storage is cheap,
I simply built a temporary TABLE so as to evaluate left to right in
the event that a leftward parameter calculated a needed result, and I
did so in Visual Basic.
This was simple in VB .Net. I could see it being a problem in a
compiler running on a limited machine, and in that (unlikely)
scenario, you'd want to emit stacking code in one pass. But this is to
take an absurd delight in living in the past, since it would be
foolish (IMO) to use a limited machine for compilation when large
machines are available...although I learned at Motorola that there's
no upper bound to the foolishness of geeks (the lads in Schaumburg
wanted to use a Z80 to compile when they had an IBM mainframe, in
1979).
As to "reading the value of a variable before initializing it", it is
indeed common practice in many programming languages to let the
programmer take the fall if he creates a variable without assigning
it, and many languages, including modern C, make it easy to initialize
and declare in one line.
The problem in the C99 standard was that you clowns gave this common
situation a pompous and silly name ("trap representation") which both
implied you'd done something other than said "yup, sure is a problem".
As in the case of "sequence points", you named a bug in order to make
it look like you'd done real work. This in your case, I believe, was
because you'd not studied computer science in the uni environment,
where students are given the chance to cultivate integrity.
Naming problems and making them into apparent features and bogus
solutions, and clubs with which to beat both newbies and intelligent
senior programmers new to C (or as in my case, revisiting this zoo) is
what MIS creeps do, not scientists.