The annotated annotated annotated C standard
- From: spinoza1111 <spinoza1111@xxxxxxxxx>
- Date: Wed, 16 Jan 2008 08:46:33 -0800 (PST)
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.
Here are some examples of Schildt's "errors". The text of "The
Annotated Annotated C Standard" is unprefixed, whereas paragraphs by
Schildt and Nilges are prefixed by our names. This is part one of a
multipart post.
The Annotated Annotated C Standard
C.D.W.Feather
Text quoted directly from the book is indicated by ## in the left
margin.
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?
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.
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, whereas in Java, C Sharp, and
even Visual Basic .Net this is a replacement of a data type name with
block scope. Pragmatically Schildt is telling students what they need
to know.
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 and is a lousy teacher to boot.
Schildt developed a Tiny-C interpreter in 1989 and is a good teacher.
The standard is silent on where constants are. For clarity, Schildt
oversimplifies since numeric constants as an implementation detail
that has nothing to do with either "standard" C or C in practice may
indeed be in non-addressable locations on the stack (members of which,
however, usually have an address inaccessible except to pathological,
if "standard" C code), or inside machine instructions. The point is a
quibble made solely to extend Schildt's rap ***.
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, it is treated as a countable error. I am
disgusted by this. This is amateur editing by people who can't
themselves write.
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). Nobody knows why it's important. It is not. In practice, no
competent programmer calls main(). If it is a serious error for a
given compiler, then it should produce a diagnostic, or, perhaps a new
type of diagnostic: Unfashionable Code.
-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.
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: no
text can provide the "literal" truth...not even the Bible or Qu'ran,
and, *a fortiori*, no goddamn computer book.
5.1.2.2.1
-Schildt-> Though most compilers will automatically return 0 when no
other
## return value is specified (even when main() is declared as
## void), you should not rely on this fact because it is not
## guaranteed by the standard.
Indeed it is not. If main() is declared as void, I don't know of any
compiler that will return 0. Indeed, the standard forbids it to !
-Nilges-> A non-error is counted as an error. You people make me sick
to my stomach and want to throw up.
-Nilges-> And if we must quibble in the style of "CDW Feather", the
compiler doesn't "return" jack ***. There's that lesson about the
beam in thy own eye.
-Nilges-> Schildt gets it mostly right. You get the "compiler" doing
something at run time. Show some class.
5.1.2.3
This section is often called the "as if" rule, because it says that an
implementation may do anything providing that the effect is "as if"
the exact wording of the standard was followed. This is almost
completely ignored in favour of explaining "side effect" and
"automatic storage".
-Nilges-> A matter of style and literary criticism is counted as an
error by people who cannot write. You people make me sick to my
stomach and want to throw up.
5.2.1.2
## Therefore, a multibyte character is a character that requires
## more than one byte.
Ignoring the fact that "character" and "byte" are synonymous in the
standard (something that is not mentioned in the annotations), the
definition of multibyte character is clear that it *does* include
single byte characters.
-Nilges-> A quibble is counted as an error.. And if "character" and
"byte" are synonymous in the standard, then C is useless for
international applications, and is not worth a standard.
## First, the null character may not be used except in the first
## byte of a multibyte sequence.
I read this as meaning that the multibyte character <00><94> is legal
while the multibyte character <94><00> is not. In actual fact, the
standard states that a zero byte must not appear in any multibyte
character other than the null character (i.e. the end of string
indicator). This means that string operations such as strcpy will
work as expected with multibyte character sequences.
There was an opportunity here to explain multibyte characters and how
to use them, something that most books omit. Unfortunately, this one
omits it as well.
-Nilges->A world-class MISTAKE (the FAILURE to support Nuls as
ordinary characters) in C is used to beat the Herbster guy. Again,
people who cannot write try to tell a writer how to write...and count
this nonsense as an error in order to pad a rap ***.
5.2.3
-Schildt-> In other words, one copy of a library function in memory
may
## not be used by two or more currently executing programs.
This is blatant nonsense - on most Unix systems, if the same program
is executing several times, all the code is shared by both processes.
Indeed, many go further and share one copy of the standard C library
among every process on the system.
What this section of the standard is talking about is re-entrancy.
The functions in the library are not re-entrant, and so may not be
called from within themselves. For example:
qsort() cannot be called from within the compare function passed to
qsort();
if a signal can be raised within a library function (perhaps by an
external event such as the user pressing a BREAK key), then the signal
handler must not call that library function.
The latter rule is particularly important: code using malloc must not
call malloc from within signal handlers.
-Nilges->The attackers of Schildt have themselves ignorantly misused
"re-entrancy". "Re-entrancy" does not mean "can be used recursively"
although it implies recursive callability. It means that the re-
entrant code does not include variables that not on the stack but in
its common memory allocated, in C's limited way, outside function
space; local variables occupy new places on the stack when the "re-
entrant" routine is called by itself or concurrently in a new thread,
whereas so-called "global" variables occupy fixed locations allocated
when the first call of the "re-entrant" code is made.
-Nilges->In fact, the use of "re-entrant" by CDW Feather shows a
programming psychology dating to the IBM mainframe era, in which
procedures were "re-entrant" only by accident, and everybody went
"oooooo re-entrant". It's not a proper computer science term, it's a
programming term which reveals ignorance!
-Nilges->The overuse of so-called "global" variables is usually the
mark of an incompetent programmer, and C programmers have no clear
mental distinction between pure procedures and procedures with state.
The association of the procedure with state is something that has to
be discovered by examining a file. Having to know this about "library"
function completely violates common programming sense, because a
"library" needs to be a black box.
-Nilges->Herb is right, depending on multiple nonconformant and
incompatible implementations, as a matter of humane teaching of a
mistake. This was the failure by Kernighan and Ritchie to come to
terms with, and evolve rather than steal, Algol and the stack, and
thereby to enable code that would keep state in overly global
variables with file scope.
-Nilges-> As such, Kernighan and Ritchie extended the lifetime of a
major mistake in "the infantile disorder", Fortran, which was to fail
to recognize the meaning of a procedure with state, versus a stateless
procedure.
-Nilges-> Herb gives the safest possible advice because the C
programmer does not know the complexity of any given library function,
and whether it has state. In fact, this is a major defect of nearly
all non-OO languages: it is impossible to tell whether a library
function has state, whereas this is made clear, in C Sharp, by the use
of the static keyword as part of its public contract...which forces
the programmer to keep the contract, not only with the compiler, but
also, and more importantly, with the user.
-Nilges-> You cannot malloc() inside of malloc() inside of a signal
handler. This is obscene, but it is implied by what Herb says. And
what stinks even more is that the programmer has to "know" about an
error.
end of commentary, rest by Nilges
This is the end of part One as I walk through the annotated-annotated
C standard, which in reality is an unethical and uncollegial attack on
a computer author, probably mounted for commercial gain, both to
promote a competing book, and to maintain the illusion that
"standardizing C will bring it back to life". It is written by people
who unlike Herb don't know what goes on in sufficient detail at
compile and run time, and replace this aporia in their knowledge by
folk "wisdom" and their own brand of obscene and idolatrous techno-
worship, a form of religion which requires, in its blindness, a new
Spanish Inquisition.
Nobody expects a Spanish Inquisition, but these in fact have been a
feature of a world which, as Dijkstra prophesied, is in the process of
collapse owing to the unmastered complexity of its data systems, a
collapse which emerged when (as a consequence of the lack of modern
data systems at the FBI) the World Trade towers collapsed, and
continues today when subprime tranches become unlinked in data bases
from actual debtors.
The hunt is on for people to blame, and they are fair game for trumped-
up charges based on trivia, and their God-given powers of expression,
by people who deny their God-given hermeneutic power and like apes
pretend that words are things.
I shall continue to post extensions this "annotated annotated
annotated" document because at this point, I am sick to my stomach at
the treatment of Schildt and I want to throw up. It's par for the
course in a field in which students are forced to learn their elder's
mistakes as if those mistakes were Holy Writ, a pedagogy, which Herb
tries to avoid, which creates nasty little clerks such as many of the
people who here vandalize contributions.
Edward G. Nilges
.
- Follow-Ups:
- Re: The annotated annotated annotated C standard
- From: Clive D. W. Feather
- Re: The annotated annotated annotated C standard
- From: Clive D. W. Feather
- Re: The annotated annotated annotated C standard
- From: Richard Heathfield
- Re: The annotated annotated annotated C standard
- Prev by Date: Re: Herbert Schildt, author of The Complete C++ Reference (NOT C Unleashed) rehabilitated on wikipedia
- Next by Date: Re: A note on computing thugs and coding bums
- Previous by thread: Escape character treatment in string library functions
- Next by thread: Re: The annotated annotated annotated C standard
- Index(es):