Son of Snarky Tirade: a response to Seebach's new CTCN: part 1
spinoza1111
Complete Nonsense" at http://www.seebs.net/c/c_tcn4e.html. Further
parts of my complete reply will be forthcoming.
Introduction
“Back in 1996, having heard horror stories about Herbert Schildt's C:
The Complete Reference, I decided to check it out. I flipped the book
open; I found glaring errors. I paged through it. I found more glaring
errors. In short, the book had lived up to the hype; it was awful.
Being a pedantic sort, and having just recently started having a web
site, I wrote about it, in the previous version of this page.”
I’m afraid that this matter, for Seebach, has remained for fourteen
years, a parlor game. Literate people tend not to “flip books open”
and find “errors” so readily unless they are experts in their fields,
and for the most part not even then; and Seebach is no such expert. He
has, by his own admission, taken no computer science classes and has
no academic certification. Instead, he has held a sequence of jobs as
a programmer, specializing in unix-Linux, which disqualifies him from
commenting on a book directed at all C programmers. He also served on
the C99 standard.
Schildt’s book is not great, but we know that some C programmers find
it useful. Schildt’s book contains errors, but they often manage to be
useful errors.
But the issue is not Schildt. It is Seebach’s behavior, which is
obsessive and stalking but “rational” in that Seebach seems to be
stalking Schildt in a zero-sum game where he has tried to establish a
reputation as a good programmer, which we now know is unwarranted, by
destroying another person’s reputation.
This type of behavior creates software crises and, as seen in many
American programmers, has destroyed their productivity, since most
American programming environments are characterized by Seebach’s
behavior. It is normed deviance.
“Time passed. People forgot about it. A 4th edition of the book came
out (back in 2000), but I didn't even know this. Until, more recently,
I started hearing queries and concerns. My half-baked page, thrown
together in an afternoon, had become the topic of Fearsome Disputes.
People were arguing over whether it was any good. Worse, people were
arguing that the flaws (and there are some, certainly) in my web page
somehow showed that the book wasn't utter crap.”
No, Peter. We found that the flaws on the page and in the code you
submitted to clc in recent years means that you have no standing as a
critic. This means you are stalking.
We discovered that you constantly make very basic errors; you cannot
use switch() statements in a structured fashion, you cannot write a
one-line version of strlen without an off by one error. In writing,
you are very clumsy with words: whereas a careful writer would use
“apparently clear” owing to the received usage of “clear” [1], you
called Schildt “clear” which was to shoot yourself in the foot: you
fashion clumsy neologisms such as illucid which etymologically use
words to mean the reverse of what the closest verb means: and, most
perniciously, you cannot disambiguate a NPOV tech review from a
stalking attack.
[1] OED online: Clear: Of words, statements, explanations, meaning:
Easy to understand, fully intelligible, free from obscurity of sense,
perspicuous.
In ordinary language, intelligent listeners and readers do not find
falsehood “easy to understand” because when someone says something
false, ordinary listeners and readers do not understand why he said
it, because in ordinary language that is in Habermas’ sense not self-
seeking bullshit (such as the special and inhuman way language is used
in many business offices) there is a common altruistic search for
agreement and truth. Seebach, a self-confessed ADHD autist, does not
understand this.
Language in what Jurgen Habermas calls the lifeworld is not a debate.
It is a survival mechanism in which we get useful work done (as in a
structured walkthrough) by trying to understand things as meaningful
and true with no little decency and charity.
Yet as Habermas (a German philosopher, look him up now) knows, people
for individual rather than collective survival also use language
competitively as you do so: to get ahead, and fuck the group or their
fellow human being where necessary. This "operational" use, in
Habermas, is said to "colonize the lifeworld". For example, in
structured walkthrough, lifeworld helped the operational, but the
lifeworld in structured programming was defeated because individual
participants would put the worst possible interpretations on what
their competitors said in order to Look Good.
This is based on a (discredited) model (completely discredited) of
language in which language is like a formal calculus or math in which
statements can be "clear and false", whence your clumsy mistake.
“Well, it is. And the 4th edition, while it fixes some of the errors
reported (including the infamous void main which Schildt long defended
as not being an error), preserves some, introduces others, and
continues to be an exceptionally bad book.”
Truly literate and urbane people don’t think there are many “bad”
books. However, in my experience, incompetent programmers (which is to
say most American programmers) are always making snarky remarks, not
only about computer books, but about books, literature, literacy, the
humanities, classical music, art, and non-white people.
“I am no longer some random guy who likes C. I spent about a decade on
the C committee—and unlike Schildt, I actually showed up, submitted
papers and proposals, worked to resolve defects, and otherwise
contributed to the process. I am no longer the mildly autistic kid who
had never really studied writing or communication; I'm now a mildly
autistic adult with years of experience writing and communicating,
including experience writing publishable material.”
You have published one book, a piece of a book not well-received (C
Unleahsed) and a variety of articles. So, as it happens, have I. You
also worked on the C99 standard. I believe that vendor pressure
“opened” the standard to incompetents because vendors, above all,
wanted their compilers to be certified as “standard” with as few
changes as possible by people as ignorant as possible, who wouldn't
take stands and engage in "academic" debate.
"Don't Make Me Think!" - best seller along with "Who Moved My Cheese?"
To do this, they allowed unqualified people to contribute, and as a
result, the standard doesn’t properly determine C’s semantics, which
any language standard must do.
“So if people want a better-written page on the topic, well, I'm
willing to provide one. Readers may also appreciate Clive Feather's
very helpful review of Schildt'sThe Annotated ANSI C Standard, which
also illustrates that Schildt does not seem to have a good grasp on
the C language.”
I’m afraid that Clive appears to be a bit of a politician, and his
review was a copycat drive by shooting.
“In comp.lang.c, some recent discussions of this led to an
observation. Flip C:TCR open to a random page. You will probably find
an error. This game is easier with the 2nd and 3rd editions, because
of the prevalence of the incorrect void return type for main(), but
even in the fourth edition, there's plenty of room for fun. I've
sorted these in numerical order.”
The void return type is in fact compiled even on standard compilers.
It’s unacceptable for a “standard” language in order to have loopholes
in the form of several levels of warning messages, which many C
compilers have, because one language has not been thereby defined:
several have.
The C FAQ hides the language of the standard which permits
freestanding environments where the name and type of the function
called at program startup is implementation defined. Any compiler
which allows a void main, and most do (some with weasel warnings) is
standard, because it’s running in a freestanding environment. It is in
fact a lie to say that the standard forbids void main; it does not (in
allowing freestanding environments) and cannot. The lie was propagated
by Linux evangelists who want all code to run under a copy of unix, a
1970s OS.
It’s absurd for you to think that a programming language standard can:
1. Fail to deterministically specify semantics as we’ll see, and
2. Dictate to programmers. You see, a deterministic standard would
refuse to compile a void main with no bullshit, but this is not done
by the C standard which is deliberately nondeterministic, both in
allowing freestanding and hosted environments and in many other ways.
“Don’t void” is not a programming language standard, because a
programming language standard defines as fully and usefully as
possible the syntax and semantics of a language.
It doesn’t tell programmers not to use features that compile at some
level of error messaging, and which on any system where the OS does
not use the value express meaning. That is a set of stylistic rules
for good C programming at best, and a childish in-joke at worst.
Page 51
“Here's a fairly typical example of the kind of thing you get wrong if
you don't have much real experience with portability:”
Schildt: “As bits are shifted off one end, zeroes are brought in the
other end. (In the case of a signed, negative integer, a right shift
will cause a 1 to be brought in so that the sign bit is preserved.)”
Seebs: “Clear, lucid, but not actually true. What happens when you
right-shift a signed, negative number, is "implementation-
defined" (C99, 6.5.7, paragraph 5); that is to say, the implementation
has to document what happens. While the behavior Schildt describes is
one of the common choices, other systems have been known to shift in
zeroes. There may be other behaviors out there. This ties in somewhat
with Schildt's comments about the use of two's complement
representations, where the behavior he describes is common but not
actually required.”
This is like my C student “Otto” who constantly annoyed the other
students. He constantly disrupted the flow of exposition because of
his resentment that his mainframe assembler skills were out of date.
Schildt could have written “zeroes are shifted in when the number is
positive; when the number is negative, ones may be shifted in
depending on the implementation of C and whether twos-complement
arithmetic is in use”.
But: any competent editor would have rejected my rephrase. Why?
Because the rephrase is nondeterministic language and nondeterministic
language is precisely what beginner and intermediate programmers do
not want to hear. They understand as intelligent human beings that
there are exceptions that prove the rule.
Interestingly, this phrasing, which expresses what you want Herb to
say, is strikingly similar to your assignment of db_header in your
queue.c code; that assignment likewise contains a non-deterministic
aporia, or hole if you please.
Note that my rephrase fails to tell the programmer what will happen in
fact. A teacher owes it to his students to provide positive knowledge.
You seem to be down a quart on International Baccalaureate Theory of
Knowledge and you seem not to have taken or comprehended a class in
the philosophy of science.
Instead, you have a folk philosophy of science. Like Creationists, you
crave the mantle of scientific authority, yet even as many
Creationists are one of the sets “uneducated boob”, “failed
autodidact” or “academic fraud”, you’re actually completely uneducated
in computer science.
Therefore, your science has regressed to saws, shibboleth,
classification and taxonomy formation.
Prior to the Enlightenment, and in the middle ages and Renaissance,
much of what passed for science was naming, rules drafting and
taxonomy. The “names” of traditional grammar such as “gerund”, which
for so many generations of students have confused and concealed rather
than revealed, and many of the lists (of syllogistic forms and
informal fallacy) of informal logic, while useful, confuse and mislead
because they are names and not theories, and are easily replaced by
equivalently “true” systems.
Biology during this era was the naming and classification of animals
and plants. Anthropology during this era was the naming and
classification of “races” with infamous results.
Creationism doesn’t “get” the value of theory formation, not only for
religious reasons but also because theory formation is liberating. It
allows people to think for themselves, and avoids the scholastic
sadism of memorizing arbitrary taxonomies and rules.
However, in service of a nonexistent “standard C” in which we’ll all
use Linux and supposedly fight the power of Microsoft (while not
noticing that we’re enslaved to a new god), the FAQ approach regresses
to naming, which as we see in the example of racism produces shaming,
as opposed to theory formation, which promotes participation,
confirmation, refutation, affirmation and joy.
A “theory” of real C must acknowledge that it exists in several
dialects, only one of which requires avoidance of void main().
Suppose someone writes a brilliant, cutting edge, efficient and well
structured program with one flaw: it has void main().
The problem isn’t in the program. It is in anyone, and you know who
you are, who dully applies the intolerant FAQ approach (related as
FAQs are to the worst kind of religious fundamentalism, at times
sounding like a religious catechism with sing-song answers mindlessly
droned) and not only says “bad program” but usually runs to the
personal and ritual shaming of the programmer.
Peter, if you had taken tuition in International Baccalaureate Theory
of Knowledge or philosophy of science, you would be familiar with Sir
Karl Popper. In simultaneous reaction to cruder forms of Marxist
bullshit and the Logical Positivist theory that “meaningful statements
must be verifiable”, Popper developed a more robust theory.
This is that to have meaning, statements must be falsifiable.
Herb’s statements have this property, as do most meaningful and useful
statements about such an inchoate artifact as C.
This means that you are disrupting the class if, without any academic
qualification in computer science, you provide counterexamples while
the rest of the class is struggling to remember an image of the most
common case: the shift of an ordinary positive number.
The fact that you can find errors in Schildt but not in the Standard
(which although nondeterministic in many real-world situations
including pre and post increment evaluation and the evaluation of
actual parameter values, is, especially for you, necessarily true by
definition) means that Schildt is a teacher, while the Standard is a
dead PDF…and you’re a disruptive and repulsive stalker.
In Popper’s sense, Schildt is meaningful because he can be falsified.
The Standard, like the Soviet constitution, can never be falsified.
Oops.
Professor Walter Lewin of MIT proves the theory of kinetic energy and
its conservation by rigging a lead ball to swing towards is face,
accepting the risk of calculation error. Schildt took the risk of
explaining C to programmers outside of the unix and linux world. Both
make gestures that are meaningful and useful, even courageous because
falsifiable.
You have a childish theory of language which you try to dignify as a
fashionable disease, but the fact is “zero bits are shifted in unless
the number is negative, where ones are shifted in unless twos
complement is in use, and if twos complement is not in use, I do not
know what happens” can be symbolized as follows:
Z: zero bits are shifted in
N: the number is negative
S1: one bits are shifted in
T: twos complement is in use
WTF: I don’t know what happens
Symbolizing, my rephrase of Herb is: Z || (T && N && S1) || WTF
Whereas Herb doesn’t say this, but here and elsewhere leaves these
underdetermined conditions unaddressed in order to avoid confusion;
the real crime was yours insofar as you didn't address them in C99.
The confusion was created by C “standardization” in order grant a
plenary approval to multiple compilers as a result of vendor greed.
This confusion cannot be redressed by a single computer author, and if
you as you say were on the committee for ten years, you made this
mess.
Note that any part of the formalized statement of how rotation works
can be said to be “false”, and you can autistically snip any statement
or code example out of context to “prove” a lie or error.
But the big lie is your bizarre theory of language. In teaching we say
false things; trivially we say something false after the not sign in
“~A” and something that may be false before the or in A || B.
But this is silly. You’re worse than silly. The only proper judgement
of a book which isn’t kiddie porn in a free society is the market.
Sure, the same tolerance should be extended to criticism, but not when
that criticism meets, as yours does, the tests for a malicious libel.
The purpose of the whole text is to educate a disparate number of C
programmers, some of whom need to conform to Linux and others, to
Windows.
Page 259
“Here's what I found the first time I tried flipping the 4th edition
book to a random page. This is page 259 in the 4th edition, or 251 in
the 3rd edition. (The only difference between them is the declaration
for main.)”
“The following program uses freopen() to redirect stdout to a file
called OUTPUT:”
#include <stdio.h>
int main(void)
{
char str[80];
freopen("OUTPUT", "w", stdout);
printf("Enter a string: ");
gets(str);
printf(str);
return 0;
}
“In general, redirecting the standard streams by using freopen() is
useful in special situations, such as debugging. However, performing
disk I/O using redirected stdin and stdout is not as efficient as
using functions like fread() and fwrite().”
This is not an error on Herb’s part. It’s a matter of “efficiency”
which will vary according to platform and implementation.
Two can play the silly game of “portability”, “efficiency”, and using
a non-determined assertion to “refute” a deterministic assertion that
is generally but not always true. Saying that “to redirect is not as
efficient as using functions” is no more a part of the C Standard than
is twos complement, so, the reader might ask, what gives you the right
to refute what’s a simple code example with something that might not
be always true?
But it’s quite possible that my finding many of your assertions “non-
deterministic” seems to you, in your smugness, to be the ravings of a
madmen, and you may get similar spirits to agree if you select a small
number. It may even seem strange to an educated computer scientist.
You see, as a computing autodidact, you never understood, as far as I
can see, the concept of a non-deterministic automata, algorithm, or
assertion, because (for example) when a mere programmer like you needs
to construct a lexical analyzer, based on a DFA or deterministic
finite automaton, he need only know the deterministic part of a richer
theory.
An NDFA can only be simulated by a useless program doing random number
generation, therefore it’s technically unnecessary to understand the
academic transformation of the grammar to an NDFA and from thence to a
DFA. The mere programmer today is better advised to find a good
algorithm that combines these steps.
But the mere programmer without education in computer science lost an
opportunity to separate statements like “actual parameter evaluation
order is undefined in C” versus “actual parameter evaluation order is
strictly left to right in my C compiler”. To him, the previous
statement is true therefore somehow “better than” the more narrow
statement, or “most modern C compilers evaluate left to right”.
He, and many ordinarily educated computer scientists, doesn’t realize
that the first statement cannot be falsified, and is so uselessly true
as to constitute a criminal mistake in a vendor greed-driven standard.
He doesn’t have the academic training in logic to recognize a class of
statements that are true but non-falsifiable and therefore without
merit or standing in engineering.
What shall we do, what shall we do, with all this useless beauty? –
Elvis Costello
1. “The printf command does not send a newline, nor is the stream
flushed. On many systems, doing this to the console would not display
the prompt until some later point. (See Newlines and Output.)”
The intent is clear as in understanding and truth. Herb is merely
expressing his intention to allow, on the many systems where the
printf works, the user to enter the data on the same line.
In a profession in which the grave and senior deliver so many bugs,
for example in which the pompous Keith Thompson of clc gravely
approved your one-line, off by one strlen, your false perfection and
useless beauty, a standard which you so signally fail to self-apply,
creates bugs.
Suppose Herb had been told by a user that the input as typed must
appear on the same line. You’d assault his professionalism in a
walkthrough based on the possibility that in some systems, omitting a
newline in a printf might not “push” the data out. You’d be “right”
but nothing would get accomplished.
Of course, there is probably a way of doing this, but the non-
obviousness is a flaw in C.
It would be a bug in the runtime for it to wait to “print” until eof.
It is contrary to the entire stream-of-characters io text model of C
to “wait” until end of line. In other words, you trash a guy because
of an error in C which you and others failed to fix in C99.
“For that matter, the file was opened in text mode, not binary mode.
In text mode, you may have to provide a newline at the end of your
output; since it is permissible for an implementation to require this,
you should always do it, especially in sample programs in a book
purporting to teach C.”
In other words, the standard gave a plenary indulgence or get out of
jail free card to buggy compilers owing to vendor greed. And you fell
for it. Or did it.
And your advice is wrong. Any number of programs need to print
characters in a loop using printf in the loop, and delaying the
newline until the loop is complete. To follow your advice, the
programmer would have to allocate a buffer, and “buffer” creation is
usually a sign of incompetence and a source of bugs.
An ethical standard for a programming language would not impose such a
silly limitation on intelligent programmers. Herb is describing how to
use C, not your silly shibboleths.
2. “The gets() function is dangerous, and should never be used; it has
no provision for preventing input data from overrunning the buffer
given to it. (This may seem "harmless", but a reference book should
not illustrate such bad habits.) Schildt acknowledges the dangers
elsewhere in the book, but uses it anyway. (Note that gets() is
officially deprecated, as of Technical Corrigendum 3 to C99; it's not
even present in the C201X drafts anymore.)”
3. “The gets() function strips the newline from a line of input;
however, printf() does not add one, so the line printed by printf()
will be missing its newline.”
4. “For that matter, it's incredibly dangerous to pass an arbitrary
string as the first parameter to printf -- if the user happens to
enter something like %ssomewhere in the string, your program is likely
to behave unexpectedly, or crash. So that should have been
printf("%s", str) or more likely puts(str).”
5. “No error check on freopen().”
6. “The first item in this list was misleading. See, I implied that
the prompt would have gone to the console, assuming that freopen()
succeeded. Of course, it wouldn't; it would have gone to the just-
opened file "OUTPUT" instead.”
7. “The comment about using stdin and stdout being "less efficient"
has no particular basis in reality. It's not even coherent; you can
use fread() and fwrite() with those streams; the presented dichotomy
between redirected standard streams and the other file I/O functions
is not a real dichotomy. It's like saying that usingint isn't as
efficient as using + and -.”
“What this tells you is that this code was never actually tried;
printing the prompt is incoherent after the freopen(), and the
mismatch between input and output would have been caught by even
casual testing. This is an atrocious example. This should never have
been written, let alone made it past whatever presumed technical
review might have happened.”
Not all illustrative examples are “actually tried” for the same reason
that a math professor doesn’t have to prove every example on the
blackboard. Not all illustrative examples are “actually tried” in a
software planning session, which is more akin to a classroom or
introductory text than software writing. I for one got heartily sick
of people who in high level design try to be prematurely clever.
Knuth and Dijkstra both define “programming” as the communication of
an intent as to the use of a computer to another human being. In this
example, that was the meta-intent and it does the job of showing
redirection. On specific platforms, the debugging (like a proof in
some math classes) was left to the reader.
An administrative decision was probably made NOT to test all the code
because of a lack of time. I can think of two ways this somewhat
questionable administrative decision, probably no more questionable
than corners cut in your book, can be defended.
In my own book (Build Your Own .Net Language and Compiler Apress
2004), owing to lack of time, I made such a decision; I decided that
all major objects in the Quick Basic interpreter would have and pass
stress tests built in to the class, and I promise the reader that all
code would work, which it has, I believe, for most readers. Some book
errata were received and posted at Apress. But in the people who
responded to my invitation to get updates and information about new
compilers, nobody has reported any code errata.
The first defense of a similar decision in Schildt’s case is that it
is literally impossible, owing to Ritchie’s failure to think through
the semantics of his language (order of evaluation of preincrement in
pathological cases being an example) and then owing to your failure to
confront vendor greed in C99, to create examples that will work for
all C compilers…even all standard C compilers, owing to the cowardly
use of non-deterministic, plenary language in the C99 standard. Most
so-called “portable” C is portable only between linux and unix. For
true portability you have to use Java.
I hereby challenge you to code a version of the Schildt code that is
guaranteed to work without any change on all POSSIBLE compilers,
because “portability” doesn’t mean blindly following a set of rules of
thumb and shibboleths. It means working without change not on some
platforms, or many platforms, but on all or almost all conforming
platforms. This goal was approached in a satisfactory by C Sharp and
Java. C completely misses it. C programs must be “ported” by someone
who’s an expert in C.
Based on the code you have posted at clc this year, I don’t think you
can code portable examples based on Schildt. Therefore, you need to
stop stalking him.
Page 264
“Another "let's just flip the book open and see what we get".
Peter, quit fucking around. You and Richard, as seen on clc, started
this adolescent “flip the book open” game just last week, the first
week of April 2010. This doesn’t constitute a serious technical review
and cannot be referenced in Wikipedia without a serious violation of
“biographies of living persons”.
“This example also occurred in the 3rd edition on page 262, although
it wasn't quite the same.”
Schildt: “In this way, if you need to change the size of the array,
you will need to change only the #define statement and then recompile
your program. For example:”
#define MAX_SIZE 100
/* ... */
float balance[MAX_SIZE];
/* ... */
for(i=0; i<MAX_SIZE; i++) printf("%f", balance[i]);
/* ... */
for(i=0; i<MAX_SIZE; i++) x =+ balance[i];
“The last line of this example is new in the fourth edition. So,
what's wrong with this one?”
1. “The printf loop has no newlines or spaces, so all the numbers
would be run together. Not a huge problem with the code as such, but
certainly a shoddy bit of work.”
2. “Usually, when the size of an array is called MAX_SIZE, that
implies that the actual size may well be some smaller value. This is a
nitpick; we could reasonably assume that the implication is that the
whole array has been initialized.”
3. “There hasn't been an =+ operator in C since the 1970s.”
“You might think the =+ wouldn't compile, but in fact, it will. C89
standardized the ‘unary +’ operator, which exists only for symmetry
with a leading - used on negative numbers. Thus, this is equivalent to
x = +balance[i] which is in turn equivalent to x = balance[i], so the
last loop is precisely equivalent to the non-loop statement x =
balance[MAX_SIZE - 1]; (at least, assuming that x isn't volatile...).
Oops.”
Two nits and a typo. Don’t break your arm patting yourself on the
back. And had you not preferred being a creep and a stalker to McGraw
Hill’s offer that you tech review the document for typos, there’d be
no typo.
“Again, this kind of stuff should never have made it past any kind of
review.”
I guess you missed the point about macro substitution that was made.
The purpose was not to show off, it was simply to provide an example
of macro substitution.
Page 264, again.
“While looking for the previous example in the 3rd edition, I happened
to look at the example after it. This is on page 264-265 of the 4th
edition, and 262-263 of the 3rd edition”
“This form of a macro is called a function-like macro. For example:”
#include <stdio.h>
#define ABS(a) (a) < 0 ? -(a) : (a)
int main(void)
{
printf("abs of -1 and 1: %d %d", ABS(-1), ABS(1));
return 0;
}
“When this program is compiled, a in the macro definition will be
substituted with the values -1 and 1. The parentheses that enclose a
ensure proper substitution in all cases. For example, if the
parentheses around a were removed, this expression”
ABS(10-20)
“would be converted to”
10-20 < 0 ? -10-20 : 10-20
“after macro replacement and would yield the wrong result.”
“Ahh, Mr. Schildt. So close, and yet, so far. Here's a little thought
experiment:”
printf("ABS(-3) - 1): %d\n", ABS(-3) - 1);
“See how that works? (It prints 3, not 2.) Schildt forgot the most
important part of parenthesizing a function-like macro; you must
parenthesize the entire definition. He had a great opportunity here to
cover the reasons for both parentheses around the entire definition,
and parentheses around each individual macro argument. He missed it,
instead claiming that the partial solution worked correctly "in all
cases", which it does not.”
I in fact discussed this whole issue last week and I suspect you stole
the idea while screwing up by using the misnomer “function-like” as
we’ll see, since having looked over your code for (not really) finding
and replacing %s, your queue.c abomination of desolation, and your
celebrated strlen boner, I do not think you are that type of
programmer who, first and foremost, follows his own rules and eats his
own dog food.
No, I think you are a far more common type, as common as dirt.
I think you’re the irritating office loudmouth who terrorizes younger
and women programmers for their infractions. Then, when his parallel
failings are found in his code, he pulls a new rule out of his hat:
that in a pinch, at the crisis, real men know that there’s “not enough
time to worry about nits”, although we usually can tell he fucked up
and is making excuses. In other words,
The Fascist is he
In a permanent state of emergency
Who writes a beautiful Constitution
Shortly after the revolution,
Admonishing all
Prelapsarianly but after the Fall,
To respect the rights of Man:
But for the duration he will shitcan
The rights of citoyen…and citoyenne.
My practice is more complex. I classify macros into expression-type
(intended to return an expression) and block-type.
“Function-like” is a complete misnomer, far more serious and far more
revealing of a complete lack of computer science education, than any
of Schildt’s solecisms. This is because the material intended for
return by abs is NOT A FUNCTION; it is a C expression which is
intended to return the absolute value.
Two can play the pedant game
‘Twas you that tried Herb Schildt to shame
Now, since your own dog food you don’t eat
Try some of this nice crow meat.
A function, in C, is sometimes inline and usually not. It has actual
and formal parameters which are called by value in all cases. Whereas
the intent of a macro is to do a textual substitution using parameters
called by name.
It is merely true that both are attempts to express a mathematical
function, something which is different from either. But “expression-
type” expresses the real effect and intention, which is to return some
sort of valid C expression, ideally one that can be reused, and which
will work as expected, anywhere a C expression is valid.
The alternate type could be called “statement list-type” or “block-
type” according to taste:
#define E(a) { a = 0; printf(“%s\n”, “a set to 0”; }
In the above I’ve used my own standard for “block-type” macros, which
is to always (without exception) encase them in curly brackets.
Another suggestion that handles a few more problems:
#define E(a) do { a = 0; printf(“%s\n”, “a set to 0”; } while(0);
This was suggested on clc to me some months ago by a very talented
programmer who is sadly being slowly more and more corrupted by the
mob rule of the corporate programming world, since when I credited him
with another suggestion on code I had contributed to clc, he asked me
to remove the credit. I noticed at Bell-Northern Research that people
who get programming jobs in corporations immediately regress to the
ethics and manners of 14 year olds, and can only conclude that this
programmer didn’t want to be associated with someone who was unpopular
because he’d so criticized the thugs in residence at clc.
But Seebach lacks the literacy, constructive spirit and urbanity as a
stalker to helpfully describe good practice. And … it turns out that
the practice is not necessary.
Most macros are developed for internal use in a specific piece of code
by the same programmer who is going to use them. He could easily be
expected, if far better at C than Seebach, to just remember to rather
compulsively add parentheses to expression-type macros and braces to
block-type macros.
Or…in many real-world educational contexts, he could forget the whole
thing. It is an advanced issue and students can be simply told that
macro calling is a text operation and take it from there.
At this point, I shall end the first part of my reply to Seebach’s
Snarky Tirade.
Willem
) This is my reply (part 1) to Peter Seebach's new edition of "C: the
) Complete Nonsense" at http://www.seebs.net/c/c_tcn4e.html. Further
) parts of my complete reply will be forthcoming.
<snip>
) At this point, I shall end the first part of my reply to Seebach?s
) Snarky Tirade.
Your *entire* reply consisted of nothing but ad-hominem attacks.
It reads like you desire to find fault with every little thing that
Seebs writes and if you can't, you go for the man behind the words.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
spinoza1111
> spinoza1111 wrote:
>
> ) This is my reply (part 1) to Peter Seebach's new edition of "C: the
> ) parts of my complete reply will be forthcoming.
> <snip>
> ) At this point, I shall end the first part of my reply to Seebach?s
> ) Snarky Tirade.
>
> Your *entire* reply consisted of nothing but ad-hominem attacks.
OED: "Ad hominem": A phrase applied to an argument or appeal founded
on the preferences or principles of a particular person rather than on
abstract truth or logical cogency.
1599 R. PARSONS Temp. Ward-Word vi. 79 This is an argument..which
logicians call, ad hominem. 1633 W. AMES Fresh Suit I. x. 105 Some
arguments, and answers are ad hominem, that is, they respect the thing
in quæstion, not simply, but as it commeth from such a man. 1748
HARTLEY Observ. on Man I. iii. §2. 359 The Argument here alleged is
only one ad hominem. 1787 BENTHAM Def. of Usury viii. 83 This argument
ad hominem, as it may be called.
No, when I taught Introduction to Logic using Copi, "ad-hominem" was
carefully described not to mean any argument which uses personal
characteristics, or even one with rhetorical invitations to perform
midair reproduction. It means "invalid" arguments (arguments in which
the conclusion doesn't follow from the premises) in which the premise
is the bad character of the person making the assertion you would like
to refute in a matter unrelated to his character.
Copi's central, organizing notion in Introduction to Logic is the idea
of a valid argument, one in which the conclusions cogently follow from
the conclusion, and one that can be tested easily for validity using
propositional logic: if the premises can be true while the conclusion
is false, the argument is invalid.
"Your honor, how can we take the word of a witness who is well known
to be the town drunk?" "Objection, your honor, the witness was sober
at the time, and he saw Injun Joe kill the victim; his testimony in
the court has standing by way of all known rules of evidence".
The most common Internet use of of "ad hominem" means:
"An unpopular person is sayin' bad things 'bout me or a popular guy
whom we all like, and he talks like fag, and his shit's all fucked up.
Thinks he's so smart, I'd whip his ass. Fuckin' guy is fucked.
Besides, I or one of my friends have a Master's degree and we don't
understand fucker's prose.".
An real ad hominem argument, to be so, must be invalid in that the
premise can be true and the conclusion false. A bad man can witness a
crime in progress and if he has no interest in the outcome his word is
as good as a good man.
I have not attacked Seebach's character as such, nor have I reasoned
FROM my conclusion that his behavior "in the matter of Herb Schildt"
TO the conclusion that he's wrong about the role of examples in a
computer book, or any other matter. Instead, I have reached the
conclusion that his behavior constitutes harassment, stalking and
libel of Schildt based on his misrepresentation of what Dr McClean has
found to be a biased document as a fair and neutral criticism. I have
reached this conclusion from my study of Seebach's code which is
rather less competent than the code in Schildt but is presented as
working code and not examples of code, as is Schildt.
For textbook examples of ad hominem, see Seebach's indirect replies to
me. They start with the axiom that I'm a moron and/or insane, and
invite the reader to draw the obvious conclusion that I must be wrong.
But this argument has two flaws. One is textbook ad hominem. The other
is textbook inconsistency because Seebach claims to have ADHD and
adult autism, which in traditional terms is being an "insane moron".
That is: a modern spirit of tolerance allows more people to have
personality quirks whereas in the "old" days (as recently as the
1970s) those people were unemployable.
Seebach relies on a sort of urban legend, popular in programming, that
one can be uncertified academically, be dumb or forgetful, and even
have quirks traditionally used as markers, in conservative
communities, of insanity but still good, here at programming.
But while this dog food has some problems, Seebach won't eat it with
regards to people who he hasn't taken a shine to.
Ad hominem arguments are often also question-begging petitio
principii. It is axiomatic for Seebach that I'm an insane moron, so no
matter how much research I do, no matter what I say, he will dully
repeat that I can't be "right", because I'm an insane moron. How could
I be right? Besides, a lot of people (wow, order 1.0e1) agree with
him.
Another useful logical fallacy is tu quoque, which usually emerges
with a third party seeing, or thinking she sees, a parallel mistake
such as a misspelled word in a grammar analysis that shows that the
plural was incorrectly used.
False charges of ad-hominem, petitio principii, and tu quoque are in
fact the stock in trade of many here.
>
> It reads like you desire to find fault with every little thing that
> Seebs writes and if you can't, you go for the man behind the words.
Hmm. Should I call him an insane moron and be done?
No, Seebach, out of the blue, in 1996, started a rumor about Schildt
out of pique that McGraw Hill wouldn't give him a lot of money to tech
review (the facts are certified by Seebach, although the "pique" is a
natural interpretation of the facts). He went for every little thing
including Herb's vivid description of what goes on at runtime using a
"stack", a word, Peter felt, Herb shouldn't use.
But: I wouldn't call this ad hominem. Surprise! That's because Seebach
did not start with the premise that Schildt was an "insane moron".
Instead, Seebach ineptly tried to do the right thing, which was to
demonstrate by error finding that Schildt was in general a "bad"
author, even though in terms of Schildt's total output across several
programming languages, Seebach has to date only found trivia, and
stylistic violations of coding standards necessitated or enabled by
Seebach's own failure to help standardize C semantics...not just its
syntax.
In the general programming community, Seebach was greeted with many
yawns and not a few horse laughs. He did find order 1.0e2 individuals
to support and cite him strictly within the Linux community owing to
C's prestige within that community, and that community's desire to
control C. That community's citation of CTCN-3 and CTCN-4 caused copy
and paste replication as well as Clive Feather's copycat drive-by on
The Annotated C Standard which has made the "evidence" only "large" to
"morons" who know not what they spew.
This has created a massive amount of misunderstanding over the years,
most seriously an ongoing violation of Wikipedia's policies on
Biographies of Living Persons. It's probably created a lot of bad
code, and unnecessary changes to code, although as a humanist I think
a man's reputation more important than code.
For example, since one cannot according to Seebach do printf to stdout
without newline, I can well imagine that a lot of buffers are
overflowing in loops that could be more naturally coded, on most C
platforms, using character output...which is certainly in the spirit
of C, while requiring a newline is an intellectual fossil, a survival
of mainframe "unit record" thinking.
So, mijn Heer, you take good care,
And get wise as regards ad hominem:
It's not what you think and say it is
It's a species of invalid argumentatium,
In which the conclusions don't follow,
The argument's hollow,
From the premises nothing does come,
Save sobbing, and the crunch of bone.
Willem
) OED: "Ad hominem": A phrase applied to an argument or appeal founded
) on the preferences or principles of a particular person rather than on
) abstract truth or logical cogency.
)
) 1599 R. PARSONS Temp. Ward-Word vi. 79 This is an argument..which
) logicians call, ad hominem. 1633 W. AMES Fresh Suit I. x. 105 Some
) arguments, and answers are ad hominem, that is, they respect the thing
) in qu?stion, not simply, but as it commeth from such a man. 1748
) HARTLEY Observ. on Man I. iii. ?2. 359 The Argument here alleged is
) only one ad hominem. 1787 BENTHAM Def. of Usury viii. 83 This argument
) ad hominem, as it may be called.
)
) No, when I taught Introduction to Logic using Copi, "ad-hominem" was
) carefully described not to mean any argument which uses personal
) characteristics, or even one with rhetorical invitations to perform
) midair reproduction. It means "invalid" arguments (arguments in which
) the conclusion doesn't follow from the premises) in which the premise
) is the bad character of the person making the assertion you would like
) to refute in a matter unrelated to his character.
And that is exactly what you did.
Your 'refutations' were based upon (your perceptions of) Seebach
as a person and had nothing to do with the criticisms themselves.
Your text is a textbook example of argumentam ad-hominem.
Seebs
> spinoza1111 wrote:
> ) This is my reply (part 1) to Peter Seebach's new edition of "C: the
> ) Complete Nonsense" at http://www.seebs.net/c/c_tcn4e.html. Further
> ) parts of my complete reply will be forthcoming.
> <snip>
> ) At this point, I shall end the first part of my reply to Seebach?s
> ) Snarky Tirade.
> Your *entire* reply consisted of nothing but ad-hominem attacks.
This is excellent news. One of my goals was to explain the technical
details well enough that there would be less room for nitpicking against
my document. Another was to, while preserving many nitpicks, identify
them as such and point out their limitations. I appear to have done so.
> It reads like you desire to find fault with every little thing that
> Seebs writes and if you can't, you go for the man behind the words.
The straw man behind the words, for the most part. I do think it would
be fascinating to meet the seebs he writes about, though!
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Malcolm McLean
> ) the conclusion doesn't follow from the premises) in which the premise
> ) is the bad character of the person making the assertion you would like
> ) to refute in a matter unrelated to his character.
>
> And that is exactly what you did.
> Your 'refutations' were based upon (your perceptions of) Seebach
> as a person and had nothing to do with the criticisms themselves.
>
> Your text is a textbook example of argumentam ad-hominem.
>
hominem fallacy is to assert that an argument is wrong or invalid
because of the person who is making it. However we do this all the
time. No-one's bothered what some schoolkid says about the deficit
reduction plan. If some central banker says "this is the only policy
which will reduce the deficit without substantial economic
dislocation", everyone sits up and takes notice.
"Seebs has no computer science qualifications" is a classic case of
the ad hominem fallacy that everyone makes, and in fact we have to
make, because we can't give equal time to everyone who asserts
something. We have to weight the more worthy speakers.
Seebs
> Ad hominem is a bit more subtle than it might first appear. The ad
> hominem fallacy is to assert that an argument is wrong or invalid
> because of the person who is making it. However we do this all the
> time. No-one's bothered what some schoolkid says about the deficit
> reduction plan. If some central banker says "this is the only policy
> which will reduce the deficit without substantial economic
> dislocation", everyone sits up and takes notice.
Yes. However, *formally*, this is the ad hominem fallacy.
> "Seebs has no computer science qualifications" is a classic case of
> the ad hominem fallacy that everyone makes, and in fact we have to
> make, because we can't give equal time to everyone who asserts
> something. We have to weight the more worthy speakers.
It would be if this were an issue where it were in any way difficult
for an ordinary practitioner in the field to evaluate the claims made.
Since it's not, and since every practitioner who has looked at the claims
confirms them, the presenter becomes irrelevant.
Moi
> On Apr 11, 9:03 pm, Willem <wil...@turtle.stack.nl> wrote:
>> spinoza1111 wrote:
>>
>> ) This is my reply (part 1) to Peter Seebach's new edition of "C: the )
>> Complete Nonsense" athttp://www.seebs.net/c/c_tcn4e.html. Further )
>> parts of my complete reply will be forthcoming.
<snip bad acid trip>
You can't use "void main()"
; main returns float.
> So, mijn Heer, you take good care,
Heer should not be capitalised. Capitalised "Heer" refers to God,
which is probably not your intention when you address Willem.
Willem has previously pointed this out to you, but you seem immune to
constructive critique.
Also, nowadays "mijnheer" is usually spelled as "meneer".
HTH,
AvK
Nick Keighley
> On 2010-04-11, Willem <wil...@turtle.stack.nl> wrote:
>
> > spinoza1111 wrote:
> > ) This is my reply (part 1) to Peter Seebach's new edition of "C: the
> > ) parts of my complete reply will be forthcoming.
> > <snip>
> > ) At this point, I shall end the first part of my reply to Seebach?s
> > ) Snarky Tirade.
> > Your *entire* reply consisted of nothing but ad-hominem attacks.
>
> This is excellent news. One of my goals was to explain the technical
> details well enough that there would be less room for nitpicking against
> my document. Another was to, while preserving many nitpicks, identify
> them as such and point out their limitations. I appear to have done so.
>
> > It reads like you desire to find fault with every little thing that
> > Seebs writes and if you can't, you go for the man behind the words.
>
> The straw man behind the words, for the most part. I do think it would
> be fascinating to meet the seebs he writes about, though!
>
> -s
> --
spinoza1111
> spinoza1111 wrote:
>
> ) OED: "Ad hominem": A phrase applied to an argument or appeal founded
> ) on the preferences or principles of a particular person rather than on
> ) abstract truth or logical cogency.
> )
> ) 1599 R. PARSONS Temp. Ward-Word vi. 79 This is an argument..which
> ) logicians call, ad hominem. 1633 W. AMES Fresh Suit I. x. 105 Some
> ) arguments, and answers are ad hominem, that is, they respect the thing
> ) in qu?stion, not simply, but as it commeth from such a man. 1748
> ) HARTLEY Observ. on Man I. iii. ?2. 359 The Argument here alleged is
> ) only one ad hominem. 1787 BENTHAM Def. of Usury viii. 83 This argument
> ) ad hominem, as it may be called.
> )
> ) No, when I taught Introduction to Logic using Copi, "ad-hominem" was
> ) carefully described not to mean any argument which uses personal
> ) characteristics, or even one with rhetorical invitations to perform
> ) midair reproduction. It means "invalid" arguments (arguments in which
> ) the conclusion doesn't follow from the premises) in which the premise
> ) is the bad character of the person making the assertion you would like
> ) to refute in a matter unrelated to his character.
>
> And that is exactly what you did.
> Your 'refutations' were based upon (your perceptions of) Seebach
> as a person and had nothing to do with the criticisms themselves.
Emotionally, perhaps (I can't stand him) but not logically.
Independently of my dislike (which is based on being repeatedly called
an "insane moron") I find that Seebach is stalking Schildt based on
trivia. I have shown this. Again, an ad hominem argument is NOT an
argument that concludes that someone's wrong, even if that person is
popular here, and his numerous mistakes and vicious attacks make his
remote friends look like they might have poor judgement.
spinoza1111
> On 2010-04-11, Malcolm McLean <malcolm.mcle...@btinternet.com> wrote:
>
> > Ad hominem is a bit more subtle than it might first appear. The ad
> > hominem fallacy is to assert that an argument is wrong or invalid
> > because of the person who is making it. However we do this all the
> > time. No-one's bothered what some schoolkid says about the deficit
> > reduction plan. If some central banker says "this is the only policy
> > which will reduce the deficit without substantial economic
> > dislocation", everyone sits up and takes notice.
>
> Yes. However, *formally*, this is the ad hominem fallacy.
Incorrect. It's the nonfallacious use of authority. In your reasoning,
it's logically fallacious not to listen to the schoolkid because the
schoolkid MIGHT confirm to your own compensatory fantasy of being an
authority despite your lack of qualifications. It is not ad hominem to
do what we've done: simultaneously weigh (1) your lack of formal
academic qualifications, (2) your own serious coding errors, (3) the
failure to standardize C semantics and (4) the triviality of the
issues you raise.
spinoza1111
wrote:
Not quite my point. IF he'd made valid and important criticisms which
constituted a positive contribution to the field, I'd be the first, as
someone who's taught at university without a post BA degree, to waive
this requirement in his favor.
But as it happens he's stalked a single writer who's obviously "mass
market" in the sense that Schildt dumbed down C for programmers of
average skill, and Seebs has made far more serious mistakes, signally
the confusion of Linux and C. In his stalking, Seebs does not emerge
as an independent expert, reliable on C. Instead, he emerges as just
another dreary programmer of average skill who needs to use saws and
shibboleth to detect problems, and fails to detect problems in his own
code. In some cases, Seebs' shibboleths uglify praxis; for example, it
appears we're not to use printf() to output characters in a loop
without newlines. It was my interpretation that we'd have to use an
Ugly Buffer, but the consequence is this.
It is as I have said a conclusion and not a premise that Seebach is a
dork. We as always are ready to listen for insight from him but we
don't get it. We get it from Bacarisse who doesn't agree with us, but
from Seebach we get off by one code and claims that are false.
Colonel Harlan Sanders
<spino...@yahoo.com> wrote:
>On Apr 11, 10:52 pm, Willem <wil...@turtle.stack.nl> wrote:
>>
>> And that is exactly what you did.
>> Your 'refutations' were based upon (your perceptions of) Seebach
>> as a person and had nothing to do with the criticisms themselves.
>
>Emotionally, perhaps (I can't stand him) but not logically.
>Independently of my dislike (which is based on being repeatedly called
>an "insane moron")
But you ARE acting like an insane moron....
> I find that Seebach is stalking Schildt based on
>trivia. I have shown this.
See, this is where you prove you are an "insane moron".
In recorded fact, Seebach wrote a one page critique of a book 14 years
ago. Occasionally the subject of Schildt's books came up, so for
convenience he put the CTCN page on his site so he could refer people
to it.
Then the subject stopped coming up, and it was forgotten FOR A DECADE
till YOU, Edward Nilges, decided that it was perfect hopeless cause
for you to flamewar with (whatever your stated motives, none of which
make any sense).
As part of this you deleted any disparaging reference to Schildt you
found in Wikipedia, and added tirades accusing anyone who disagreed of
all kinds of vile motives.
You were reverted, (and eventually banned for being a dick, generally)
but stimulated others to beef up the wiki page on Schildt, adding
citations, including Seebach, Feather and Summit.
Note that again: Seebach et. al. all DID NOT put themselves in the
wiki article, YOU DEMANDED CITATIONS and you got them.
You insist Seebach engineered all this, waiting 14 years to strike....
again only an "insane moron" could think this.
As for "stalking", YOU have attempted to get Seebach's publisher to
repudiate him, though this has absolutely nothing to do with them or
any book they have published.
THAT is quite easily defined as stalking, and again labels you as an
insane moron.
Seebs
> On Sun, 11 Apr 2010 17:38:07 -0700 (PDT), spinoza1111
><spino...@yahoo.com> wrote:
>> I find that Seebach is stalking Schildt based on
>>trivia. I have shown this.
> In recorded fact, Seebach wrote a one page critique of a book 14 years
> ago. Occasionally the subject of Schildt's books came up, so for
> convenience he put the CTCN page on his site so he could refer people
> to it.
Yes. I made one attempt to get the publisher to address the technical
errors, they were unwilling to pay an amount I thought reasonable at the
time for the service, I wrote up a page documenting it and forgot about
it.
Seriously, until Nilges started this stuff up again, I didn't even *know*
that there'd ever been a fourth edition of that stupid book. I had no
interest in the topic. As time passed and people stopped recommending
Schildt's books, and thus readers of those books stopped showing up
confused in comp.lang.c, it dropped completely off my radar.
> Note that again: Seebach et. al. all DID NOT put themselves in the
> wiki article, YOU DEMANDED CITATIONS and you got them.
And again, to amplify: I had no clue that anyone was linking to the
page. In fact, if you'd asked me if I had a page on the topic, I woulda
guessed that I used to but that it had been lost during site organization
at some point. I had no idea it was still there, let alone still in
any way relevant to any of this.
As to whether it's "trivia", I don't think a consistent, in-every-example,
failure to use getc() or getchar() correctly, as well as a precisely
false explanation of EOF, is "trivial" for a newbie C programmer. Neither
is failing to mention struct padding.
Are we done here yet? Nilges has been being unpersuadable on Usenet for
a *long* time. Nothing suggests that this is going to be the time he
finally seeks treatment for whatever he did to ruin his life. Arguing
with him does nothing. So far as I can tell, if people would just ignore
him and let him be, this would be an extremely good solution for
everything -- Nilges would be devoting his considerable time and effort
trying to defame me, and no one else would have to deal with it. Since
none of the people in the corporate hierarchy above me are dumb enough
to fall for his crap, this is pretty much the ideal output. Let Nilges
lie about me all he wants; it's not hurting anyone.
Please put [NILGES] in subject lines when responding to him or threads
about him so people can killfile them more easily, and let's get back
to talking about C. This has been about as amusing as it's going to
get unless he actually sues, and since that won't happen, we're done
here; this is now a sitcom in reruns, and there is No Point.
-s
--
spinoza1111
Wow, the issue of importance < every other issue. The infinitesimal in
the flesh. Oh well.
Actually, you MIGHT be wrong, here, meneer. I do know that after WWII
Germanic languages (including Dutch) changed radically and seem to me
(as a layperson in these matters) to have become more "democratic".
I've certainly seen "Mijn Heer" in old books capitalized. It would
seem to me that "meneer" is a demotic simplification because after
WWII Dutch people wanted to escape the social distinctions of Germanic
languages as a source of Fascism, and to break connections with High
German.
Certainly, it remains the case in German (which is not Dutch) that
nouns are capitalized as many (but not all) cases in seventeenth-
century English.
I'm afraid, meneer, gnädiger Herr, that this is just one more case of
being a time traveler, in the sense that I read things call books, and
draw perhaps unwarranted conclusions from them. I then meet *ne
kulterni* people from foreign lands and they correct me usefully
enough on the (sometimes disastrous) impact an international (and
English-based, hein?) thug Kultur has had on their language and the
Geist undt Lebens-Welt of their people.
I dunno, by "meneer" looks like a surly and passive-aggressive mumble
of the old and more respectful usage, a false reconciliation of
Kamerad/Tovarish with the old ways forced upon Western Europe by
American anti-Communism.
Meneer is a sneer which partaketh in that which it abandons.
In fine, dear boy, "don't compete with me", as meneer Dijsktra said,
especially in making a mountain out of a molehill.
>
> HTH,
> AvK
spinoza1111
> > On Apr 11, 9:03 pm, Willem <wil...@turtle.stack.nl> wrote:
> >> spinoza1111 wrote:
>
> >> ) This is my reply (part 1) to Peter Seebach's new edition of "C: the )
> >> Complete Nonsense" athttp://www.seebs.net/c/c_tcn4e.html. Further )
> >> parts of my complete reply will be forthcoming.
>
> <snip bad acid trip>
>
> You can't use "void main()"
> ; main returns float.
>
> > So, mijn Heer, you take good care,
>
> Heer should not be capitalised. Capitalised "Heer" refers to God,
Interesting! Was that the case in older books? I'm pretty sure that
there the intent was to enforce a social distinction, but I can
understand that Dutch is not German, and that the good Dutch didn't
want upper class twittery to control.
Is my theory correct, that this is postwar Dutch. I would be genuinely
interested to know, gnädiger Herr.
> which is probably not your intention when you address Willem.
No, it wasn't.
Colonel Harlan Sanders
>
>Are we done here yet? Nilges has been being unpersuadable on Usenet for
>a *long* time. Nothing suggests that this is going to be the time he
>finally seeks treatment for whatever he did to ruin his life. Arguing
>with him does nothing. So far as I can tell, if people would just ignore
>him and let him be, this would be an extremely good solution for
>everything
Sure.
spinoza1111
> On 2010-04-12, Colonel Harlan Sanders <Har...@kfc.com> wrote:
>
> > On Sun, 11 Apr 2010 17:38:07 -0700 (PDT), spinoza1111
> ><spinoza1...@yahoo.com> wrote:
> >> I find that Seebach is stalking Schildt based on
> >>trivia. I have shown this.
> > In recorded fact, Seebach wrote a one page critique of a book 14 years
> > ago. Occasionally the subject of Schildt's books came up, so for
> > convenience he put the CTCN page on his site so he could refer people
> > to it.
>
> Yes. I made one attempt to get the publisher to address the technical
> errors, they were unwilling to pay an amount I thought reasonable at the
> time for the service, I wrote up a page documenting it and forgot about
> it.
This was malfeasance. If you post something that's cited, it's your
responsibility to keep it up to date.
It was also greed, and an exaggerated opinion of your worth.
>
> Seriously, until Nilges started this stuff up again, I didn't even *know*
> that there'd ever been a fourth edition of that stupid book. I had no
> interest in the topic. As time passed and people stopped recommending
> Schildt's books, and thus readers of those books stopped showing up
> confused in comp.lang.c, it dropped completely off my radar.
>
> > Note that again: Seebach et. al. all DID NOT put themselves in the
> > wiki article, YOU DEMANDED CITATIONS and you got them.
>
> And again, to amplify: I had no clue that anyone was linking to the
> page. In fact, if you'd asked me if I had a page on the topic, I woulda
> guessed that I used to but that it had been lost during site organization
> at some point. I had no idea it was still there, let alone still in
> any way relevant to any of this.
>
Plausible deniability...sleazy. Actually, I don't believe you. I
believe instead you were gratified to be cited as an authority when
the wikipedia page appeared in 2006.
> As to whether it's "trivia", I don't think a consistent, in-every-example,
> failure to use getc() or getchar() correctly, as well as a precisely
> false explanation of EOF, is "trivial" for a newbie C programmer. Neither
> is failing to mention struct padding.
As Dr McClean has pointed out but in my own words, you're criticising
an example or illustration. You rarely discuss the surrounding text,
and your main() point, your "main point", confuses the needs of the OS
with the programming language. Those two concerns need to be
separated.
It is true that a program with a void main needs to be trivially
changed if ported to a hosted environment; but because Windows doesn't
use the return outside of a command in a Windows shell, this means
that the examples in the old editions weren't intended for hosted use,
period.
>
> Are we done here yet? Nilges has been being unpersuadable on Usenet for
> a *long* time. Nothing suggests that this is going to be the time he
Perhaps, but I've learned and relearned more than thee.
> finally seeks treatment for whatever he did to ruin his life. Arguing
> with him does nothing. So far as I can tell, if people would just ignore
"Please ignore him"...hmm
How ill this Taper burnes. Ha! Who comes heere?
I thinke it is the weakenesse of mine eyes
That shapes this monstrous Apparition.
It comes vpon me: Art thou any thing?
Art thou some God, some Angell, or some Diuell,
That mak'st my blood cold, and my haire to stare?
Speake to me, what thou art.
Ghost.
Thy euill Spirit Brutus?
Why does Shakespeare make a victim into an evil spirit?
> him and let him be, this would be an extremely good solution for
> everything -- Nilges would be devoting his considerable time and effort
> trying to defame me, and no one else would have to deal with it. Since
Hmm...yes, I should perhaps learn the art of automated defamation.
Peter, you defamed Herb Schildt through inaction for several years,
since once you were cited, you needed to realize that you were cited
in wikipedia as a responsible NPOV source.
> none of the people in the corporate hierarchy above me are dumb enough
To the people in the corporate hierarchy, you're a dime a dozen.
> to fall for his crap, this is pretty much the ideal output. Let Nilges
> lie about me all he wants; it's not hurting anyone.
>
> Please put [NILGES] in subject lines when responding to him or threads
> about him so people can killfile them more easily, and let's get back
> to talking about C. This has been about as amusing as it's going to
> get unless he actually sues, and since that won't happen, we're done
> here; this is now a sitcom in reruns, and there is No Point.
A lawsuit is one option. A published paper citing your malfeasance is
another. And so is a wikipedia Biographies of Living Persons notice
which will demonstrate a serious misuse of wikipedia in which you
actively or passively took part, which might make you unable to post
at wikipedia.
However, my goal isn't to harm you. It's merely to get you to admit
wrongdoing in re "The Matter of Herbert Schildt", and to stop using
the Internet for drive-by shootings.
>
> -s
> --
Peter Nilsson
> ... So far as I can tell, if people would just ignore
> him and let him be, ...
Well there's a stone from the glass house.
--
Peter
spinoza1111
Not correct, with all due respect:
Malcolm, in your case what is due is high
And so I
Shall be circumspect.
Cf Introduction to Logic (Nicholas Rescher 1964 St Martins.)
"In an argumentum ad hominem the premises address themselves 'to the
man' instead of to the issue. This fallacy has three principal forms:
abusive, circumstantial and *tu quoque*"
"Sometimes, in the heat of debate, or simply as an unscrupulous way of
compensating for lack of proper evidence for his case, a man will make
a personal attack on his opponent instead of trying to disprove what
he says. An instance of this 'abusive argumentum ad hominem' is
'Nietzsche's view that all moral valuations are of aristocratic origin
is incorrect, for it is a well-known fact that Nietzsche was an
unhappy, bitter and neurotic man, who ultimately became insane'".
"An argument of this sort is of course highly improper and thoroughly
fallacious: the personal or moral character of a man has nothing
whatever to do [ceteris paribus] with the correctness or incorrectness
[validity or invalidity] of the arguments he advances. The virtuous
can make mistakes, for no man is exempt from error, and, on the other
hand, even the most wicked or wrong-headed individual can utter a
truth."
"'Circumstantial argumentum ad hominem' does not directly abuse the
opponent but undercuts his position by suggesting that he is serving a
personal interest in advancing his views and does not adhere to them
for properly evidential reasons. For example, the argument:
'gentlemen, this rent control bill is unworkable and unust, for Mr.
Apartment and the other men who have joined him in sponsoring it are
all tenants and rentors: there isn't a single landlord in the group'
fixes on the fact that members of the opposition are personally
involved in the matter under discussion, though this is actually
immaterial to the question of whether their recommendations are
'unworkable and unjust'".
"The 'tu quoque form of argumentum ad hominem' contends that the
opponent has also on another occasion held the view he now opposes, or
adopts the practice he now condemns (the Latin phrase *tu quoque*
means 'you also')."
Now, Rescher's discussion has some flaws as we'll see, but it's a lot
better than the Internet usage applied by Willem, which is "a strong
and strange argument showing scholarship against a popular guy
advanced by someone who writes like a fag and whose shit's all fucked
up".
First, my comments on Rescher in light of Copi, whose Introduction to
Logic superseded Rescher and which I used in teaching Phil 210.
I inserted "ceteris paribus" in square brackets in Rescher's because
"The personal or moral character of a man has nothing whatever to do
with the correctness or incorrectness of the arguments he advances" is
true "all other things being equal" (the meaning of "ceteris
paribus").
Rescher, unlike Copi, misses the fact that a bad man testifying in his
own defense will often lie. But in the abstract "ceteris paribus"
sense Rescher is right. Watson and Crick were bastards, but right on
DNA. Einstein was a good guy, right on the Special Theory, wrong
(perhaps) on the Copenhagen interpretation. Seebach is a buffoon but
correct in saying that the Linux C programmer shouldn't void main.
In refuting the "conspiracy theory" of JFK's assassination in his book
"Reclaiming History", former LA district attorney Vincent Bugliosi
does mention that many of the sources of alternate claims were louche
characters from the wild side of Dallas and New Orleans. But he uses
this only to show where they might lie to cover up their own bad
behavior. He also draws the conclusion that the major conspiracy
theorists were bad men because they concealed evidence which he has.
Oliver Stone's movie validly points out that it would be ad hominem to
globally mistrust hustlers, and Bugliosi knows this. Therefore, he
shows that the hustlers lie, not on their hustling, but about material
facts concerning the assassination. Similarly, Seebach lies about the
standard because it doesn't mandate int main(), it allows a hosted
implementation to expect something in the stack after the termination
of main().
Also, following Copi, I'd replace "correctness or incorrectness" with
"validity or invalidity". This is because the traditional logic of
Rescher is pre-scientific in the sense that it's a taxonomy and not a
theory without an organizing rule (like, sadly, Seebs' inchoate view
of C). Copi organizes his presentation of informal logic using the
modern notion of validity and invalidity based on modern propositional
logic, in which (the problems of material implication in modern logic
aside), any argument can be shown invalid when in fact its premises
are true and its conclusion false.
Now, what type of Rescher-AAH is meneer Willem charging me with?
Clearly the "abusive" form. He's not charging me with having a dog or
financial interest in the fight, and he's not charging me with *tu
quoque*.
But, if we apply a sequence of transformations to Rescher's example
(name, tense, and view), what do we get?
"Nilges' views on are incorrect, for it is a well-known fact that
Nilges is an unhappy, bitter and neurotic man, who is insane"
But that is a summary of the views of Seebach, the Kentucky Colonel,
et aliter, isn't it.
Whereas I don't start with an axiom "Seebach is a stalker". Instead,
that's a conclusion from a great deal of research.
Case closed.
> make, because we can't give equal time to everyone who asserts
> something. We have to weight the more worthy speakers.
But here we cannot. In fact, the appearance of worth is so rare that
when it appears, it talks like a fag and its shit's all fucked up, and
like Hypatia, she is stripped and beaten, and like Stravinsky's Chosen
One, forced to dance herself to death.
Seebs
I have him killfiled; I haven't yet got the tools to autokill any thread
he starts, or anything.
spinoza1111
> On 2010-04-12, Peter Nilsson <ai...@acay.com.au> wrote:
>
> > Seebs <usenet-nos...@seebs.net> wrote:
> >> ... So far as I can tell, if people would just ignore
> >> him and let him be, ...
> > Well there's a stone from the glass house.
>
> I have him killfiled; I haven't yet got the tools to autokill any thread
> he starts, or anything.
...yet you keep replying rudely, only pretending to speak to third
parties, like an offensive drunk at a party in meatspace. You also
fail, ad hominem, to diligently answer my case, like an offensive
drunk at a party in meatspace. You also stalk people like Schildt
obsessively through failure to keep a frequently cited post up to
date, like an offensive if sleepy drunk at a party in meatspace.
>
> -s
> --
Nick Keighley
> [refuting Kennedy assination conspiracy theories (I couldn't parody this stuff)]
> Similarly, Seebach lies about the
> standard because it doesn't mandate int main(),
weeell,
"Hosted Environment
The function called at program startup is named main. [...] It can be
defined with no parameters
int main (void) { /*...*/ }
"
(and then goes on the discuss argv and argc).
There is no hint of void main (or any other return type other than
int). This may be open to interpretation (I don't think so, but other
people do) but that isn't lieing.
> it allows a hosted
> implementation to expect something in the stack after the termination
> of main().
Schildt isn't discussing standalone implementations.
<snip>
--
"The expression isn't unclear *at all* and only an expert could
actually
have doubts about it" - Dan Pop 2001-02-06
blm...@myrealbox.com
spinoza1111 <spino...@yahoo.com> wrote:
> This is my reply (part 1) to Peter Seebach's new edition of "C: the
> Complete Nonsense" at http://www.seebs.net/c/c_tcn4e.html. Further
> parts of my complete reply will be forthcoming.
[ snip ]
> 1. "The printf command does not send a newline, nor is the stream
> flushed. On many systems, doing this to the console would not display
> the prompt until some later point. (See Newlines and Output.)"
> The intent is clear as in understanding and truth. Herb is merely
> expressing his intention to allow, on the many systems where the
> printf works, the user to enter the data on the same line.
> In a profession in which the grave and senior deliver so many bugs,
> for example in which the pompous Keith Thompson of clc gravely
> approved your one-line, off by one strlen, your false perfection and
> useless beauty, a standard which you so signally fail to self-apply,
> creates bugs.
>
> Suppose Herb had been told by a user that the input as typed must
> appear on the same line. You'd assault his professionalism in a
> walkthrough based on the possibility that in some systems, omitting a
> newline in a printf might not "push" the data out. You'd be "right"
> but nothing would get accomplished.
> Of course, there is probably a way of doing this,
fflush(), I believe.
> but the non-
> obviousness is a flaw in C.
>
> It would be a bug in the runtime for it to wait to "print" until eof.
> It is contrary to the entire stream-of-characters io text model of C
> to "wait" until end of line. In other words, you trash a guy because
> of an error in C which you and others failed to fix in C99.
> "For that matter, the file was opened in text mode, not binary mode.
> In text mode, you may have to provide a newline at the end of your
> output; since it is permissible for an implementation to require this,
> you should always do it, especially in sample programs in a book
> purporting to teach C."
>
> In other words, the standard gave a plenary indulgence or get out of
> jail free card to buggy compilers owing to vendor greed. And you fell
> for it. Or did it.
>
> And your advice is wrong. Any number of programs need to print
> characters in a loop using printf in the loop, and delaying the
> newline until the loop is complete. To follow your advice, the
> programmer would have to allocate a buffer,
Not at all. As I understand it, what happens, and when, to the
characters written to an output stream with printf depends on the
program's environment. Output may be buffered *by the environment*
until the next newline is encountered, or until end of file is
reached, or until the environment's buffer is full. Programmers do
need to be aware that output may not actually appear right away,
and also that it may not appear at all unless/until the output
stream is flushed (perhaps by being closed), but what this has
to do with their doing their own buffering -- eh.
> and "buffer" creation is
> usually a sign of incompetence and a source of bugs.
[ snip ]
--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
blm...@myrealbox.com
Seebs <usenet...@seebs.net> wrote:
> On 2010-04-12, Colonel Harlan Sanders <Har...@kfc.com> wrote:
> > On Sun, 11 Apr 2010 17:38:07 -0700 (PDT), spinoza1111
> ><spino...@yahoo.com> wrote:
[ snip ]
> Please put [NILGES] in subject lines when responding to him or threads
> about him so people can killfile them more easily,
As I understand it, Google's posting interface strips tags in square
brackets from subject lines, so your proposed fix here may not be as
effective as you might like. Just sayin'.
> and let's get back
> to talking about C. This has been about as amusing as it's going to
> get unless he actually sues, and since that won't happen, we're done
> here; this is now a sitcom in reruns, and there is No Point.
--
Ian Collins
> On 2010-04-12, Peter Nilsson<ai...@acay.com.au> wrote:
>> Seebs<usenet-nos...@seebs.net> wrote:
>>> ... So far as I can tell, if people would just ignore
>>> him and let him be, ...
>
>> Well there's a stone from the glass house.
>
> I have him killfiled; I haven't yet got the tools to autokill any thread
> he starts, or anything.
Try Thunderbird.
--
Ian Collins
J de Boyne Pollard
> > because it doesn't mandate int main(),
>
> weeell,
>
> "Hosted Environment
> The function called at program startup is named main. [...] It can be
> defined with no parameters
> int main (void) { /*...*/ }
> "
>
> (and then goes on the discuss argv and argc).
>
> There is no hint of void main (or any other return type
> other than int).
Actually, there is. You've stopped reading one third of
the way through a sentence. Read all of the way to the
end of that sentence. Then read for a few more sections
beyond that point, as well.
SG
> Similarly, Seebach lies about the standard
> because it doesn't mandate int main(),
What's your definition of "it mandates" in this context? The standard
says that implementations must accept main functions of type
void(void) and void(int,char*[]) (or equivalent). Further, it allows
implementations to use other signatures. But these other signatures
aren't guaranteed to work on a conforming implementation. Of course,
we all knew that already. Also, we all know what "implementation"
refers to, of course.
I cannot find the lie you are referring to. Seebach acknowledged that
"[void main(void) was] a common extension".
What exactly did I misunderstand?
Cheers,
SG
Richard Heathfield
> On 12 Apr., 15:07, spinoza wrote:
>> Similarly, Seebach lies about the standard
>> because it doesn't mandate int main(),
>
> What's your definition of "it mandates" in this context? The standard
> says that implementations must accept main functions of type
> void(void) and void(int,char*[]) (or equivalent).
No, it most certainly does not say any such thing. What it says is that
*hosted* implementations must accept main functions of type int(void),
int(int, char **), or equivalent (note the return type - int, not void).
Implementations *may* accept main functions of other types, but are not
required so to do.
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
Nick Keighley
wrote:
> > > Similarly, Seebach lies about the standard
> > > because it doesn't mandate int main(),
>
> > weeell,
X3.159-1989 Section 2.1.2.2 page 7
> > "Hosted Environment
"A hosted environment need not be provided, but..."
2.1.2.2.1 Program Startup
> > The function called at program startup is named main.
[The implementaion declares no prototype for this function.]
> > It can be defined with no parameters
> > int main (void) { /*...*/ }
> > "
>
> > (and then goes on the discuss argv and argc).
>
> > There is no hint of void main (or any other return type
> > other than int).
>
> Actually, there is. You've stopped reading one third of
> the way through a sentence.
continuing
"or with two parameters (refered to here as argc and argv [...])"
no I'm sorry I'm not going to type the whole bloody spec in. There is
nothing in the remainder of the sentence that mentions return types.
Now there may be something elsewhere in the spec that does talk about
this but it isn't here. I have to confess I was surprised becasue I'm
sure I've seen people say there was something like "main shall look
like this and may also be defined in some implementaion dependent
manner". but now I look I can't see text like that. Can you give me a
quote?(please include the section header name as I'm working from ANSI
text).
> Read all of the way to the
> end of that sentence.
did that, args all the way down.
> Then read for a few more sections
> beyond that point, as well.
well I got to "Program Execution" (section 2.1.2.3). How far would you
like me to go?
Nick Keighley
the strong cider?
Nick Keighley
> SG wrote:
> > On 12 Apr., 15:07, spinoza wrote:
> >> Similarly, Seebach lies about the standard
> >> because it doesn't mandate int main(),
>
> > What's your definition of "it mandates" in this context? The standard
> > says that implementations must accept main functions of type
> > void(void) and void(int,char*[]) (or equivalent).
>
> No, it most certainly does not say any such thing. What it says is that
> *hosted* implementations must accept main functions of type int(void),
> int(int, char **), or equivalent (note the return type - int, not void).
> Implementations *may* accept main functions of other types, but are not
> required so to do.
does it explicitly say that?
Nick Keighley
> In article <slrnhs4uqc.qlr.usenet-nos...@guild.seebs.net>,
> > Please put [NILGES] in subject lines when responding to him or threads
> > about him so people can killfile them more easily,
>
> As I understand it, Google's posting interface strips tags in square
> brackets from subject lines, so your proposed fix here may not be as
> effective as you might like. Just sayin'.
this is a test.
this is posted from google and the subject line should contain square
brackets
Nick Keighley
John Bode
wrote:
Full quote from n1256:
> 5.1.2.2 Hosted environment
>
> 1 A hosted environment need not be provided, but shall conform to the
> following specifications if present.
>
> 5.1.2.2.1 Program startup
>
> 1 The function called at program startup is named main. The implementation
> declares no prototype for this function. It shall be defined with a return
> type of int and 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[]) { /* ... */ }
>
> or equivalent;9) or in some other implementation-defined manner.
>
> ...
>
> 9) Thus, int can be replaced by a typedef name defined as int, or the type
> of argv can be written as char ** argv, and so on.
Key words here are "some other *implementation-defined* manner": if
the implementation allows return types for main() other than int, then
that must be documented *by the implementation*. Otherwise the
behavior is undefined.
The standard defines exactly two interfaces for main() in a hosted
environment, and both of them must return int. It allows for hosted
implementations to define their own interfaces for main(), but that's
*not* the same thing as saying that the *standard* allows main() to be
typed void (or any other type).
blm...@myrealbox.com
As can I (using news.individual.net). However, Seebs's subject line
was
"Re: [NILGES] Son of Snarky Tirade: a response to Seebach's new CTCN: part 1"
and yours doesn't seem to have the beginning "[NILGES]". That's what
I thought would happen.
So maybe the trick is to put the text in square brackets at the end
rather than the beginning?
(Cue chorus of ungrateful whining about what GG has done for/to/with
Usenet .... )
SG
> SG wrote:
> > On 12 Apr., 15:07, spinoza wrote:
> >> Similarly, Seebach lies about the standard
> >> because it doesn't mandate int main(),
>
> > What's your definition of "it mandates" in this context? The standard
> > says that implementations must accept main functions of type
> > void(void) and void(int,char*[]) (or equivalent).
>
> No, it most certainly does not say any such thing. What it says is that
> *hosted* implementations must accept main functions of type int(void),
> int(int, char **), or equivalent (note the return type - int, not void).
> Implementations *may* accept main functions of other types, but are not
> required so to do.
Sorry, that's actually what I meant to say. The void return type is a
typo.
Cheers,
SG
Eric Sosman
5.1.2.2.1p1.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Keith Thompson
> On 12 Apr, 14:07, J de Boyne Pollard <J.deBoynePoll...@Tesco.NET>
> wrote:
>> > There is no hint of void main (or any other return type
>> > other than int).
>>
>> Actually, there is. You've stopped reading one third of
>> the way through a sentence.
>
> continuing
> "or with two parameters (refered to here as argc and argv [...])"
>
> no I'm sorry I'm not going to type the whole bloody spec in. There is
> nothing in the remainder of the sentence that mentions return types.
Yes, there's an ambiguity there. It says, in outline that main()
shall be defined with a return type of int and with no parameters ...
or with two parameters [argc and argv] or equivalent; or in some other
implementation-defined manner.
The question is, what is the scope of the "or"? It's usually
assumed that it means
with a return type of int
and
with no parameters
or
with two parameters
or
in some other implementation-defined manner
But the wording and punctuation could easily imply:
with a return type of int
and
with no parameters
or
with two parameters
or
in some other implementation-defined manner
which requires any implementation-defined manner to have a return type
of int.
But if you read on to 5.1.2.2.3p1, you'll see:
If the return type is not compatible with int, the termination
status returned to the host environment is unspecified.
Under the second interpretation, that would be as meaningless.
I think that makes it sufficiently clear that the authors of the
standard intended "some other implementation-defined manner" to
permit return types other than int.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Seebs
> Actually, there is. You've stopped reading one third of
> the way through a sentence. Read all of the way to the
> end of that sentence. Then read for a few more sections
> beyond that point, as well.
Have read the whole thing. For hosted environments, the only forms that
a compiler must accept are "int main(void)", "int main (int argc, char
**argv)", and things directly compatible with those. (e.g., you can use
a typedef, or write "char *argv[]").
The standard does allow an implementation freedom to define additional
forms of main() that it will accept, true. But that doesn't mean that it
doesn't mandate a return type of int. That one implementation accepts
something doesn't make it standard C.
If you write "int main(int argc, char **argv)", every hosted C compiler
*must* accept your program. If you write "void main(void)", any hosted C
compiler *may* reject your program.
Compare this with, say:
static int i = getchar();
Obviously, prohibited by the standard, but nothing prevents a compiler
from generating code from it.
-s
--
Seebs
> Try Thunderbird.
Huh, haven't looked at that side of things in years; I'm still living
in the happy land of slrn. (I'd still be using strn, except that the
version I had couldn't handle an upstream that required authentication
to post.)
Seebs
> As I understand it, Google's posting interface strips tags in square
> brackets from subject lines, so your proposed fix here may not be as
> effective as you might like. Just sayin'.
Google: Breaking Usenet in every way they can think of since the 90s.
Seebs
Interesting -- the material at the end survived, but the initial tag got
eaten.
!@*#!#@ing google.
spinoza1111
> On 2010-04-12, J de Boyne Pollard <J.deBoynePoll...@Tesco.NET> wrote:
>
> > Actually, there is. You've stopped reading one third of
> > the way through a sentence. Read all of the way to the
> > end of that sentence. Then read for a few more sections
> > beyond that point, as well.
>
> Have read the whole thing. For hosted environments, the only forms that
> a compiler must accept are "int main(void)", "int main (int argc, char
> **argv)", and things directly compatible with those. (e.g., you can use
> a typedef, or write "char *argv[]").
>
> The standard does allow an implementation freedom to define additional
> forms of main() that it will accept, true. But that doesn't mean that it
> doesn't mandate a return type of int. That one implementation accepts
> something doesn't make it standard C.
But, it does. It makes it what the standard calls standard C for a
"freestanding" environment, in 5.1.2.1. This environment doesn't even
need a main() and can, but doesn't have to, be restricted to a minimal
library.
>
> If you write "int main(int argc, char **argv)", every hosted C compiler
> *must* accept your program. If you write "void main(void)", any hosted C
> compiler *may* reject your program.
And if you write "int main(int argc, char **argv)" any freestanding,
standard C compiler or its environment *may* reject your program.
However, a computer scientist would be more concerned, not with the
subaltern-childish "rejection" of his program but whether his program
is correct.
You seem to have a consistent problem with the road not taken by your
logic, as in the case of your failure to properly assign db_header in
queue.c.
>
> Compare this with, say:
>
> static int i = getchar();
>
> Obviously, prohibited by the standard, but nothing prevents a compiler
> from generating code from it.
>
> -s
> --
Richard Heathfield
See 2.1.2.2, or its C99 equivalent.
Note the introductory words: "A hosted environment need not be provided,
but *shall* conform to the following specifications if present." (My
*asterisks*.)
spinoza1111
wrote:
> On 12 Apr, 06:20, spinoza1111 <spinoza1...@yahoo.com> wrote:
>
> > [refuting Kennedy assination conspiracy theories (I couldn't parody this stuff)]
> > Similarly, Seebach lies about the
> > standard because it doesn't mandate int main(),
>
> weeell,
>
> "Hosted Environment
> The function called at program startup is named main. [...] It can be
> defined with no parameters
> int main (void) { /*...*/ }
> "
>
> (and then goes on the discuss argv and argc).
>
> There is no hint of void main (or any other return type other than
> int). This may be open to interpretation (I don't think so, but other
> people do) but that isn't lieing.
>
> > it allows a hosted
> > implementation to expect something in the stack after the termination
> > of main().
>
> Schildt isn't discussing standalone implementations.
He certainly isn't restricting the discussion to hosted Linux
implementations. He's discussing a variety of implementations where
the goal is not to create the Great American Portable Program, but to
get a job done. These would include many, many environments in Windows
where the C code is called by a GUI and for this reason, no main()
need appear.
To believe that the "typical" C program even has a main() is grandiose
folly, for it means that the "typical" C program is assigned some
important task by a Father (the OS, or an Important command shell).
But few people here seem to have the level of skill as computer
scientists or OS programmers to be other than Walter Mittys, who
fantasize that someday they might turn from ordinary application
programmers to Great OS and Compiler Developers.
No, we use C when we need to call a critical routine from Java which
won't call main() and will define the needs of the host. Hell, it
might need to "return" void.
Expecting portability from C is also grandiose folly, since its
semantics are so ill-defined that it's malpractice, when transferring
a C program to a different computer architecture, to not review every
line preferably in a group setting or in pair programming. If you
don't want to do this, use Java or C Sharp.
To infer from an int main() to portability is folly on steroids...as
most people here know. To gravely pronounce a code snippet here
submitted for serious review by the few grownups here "bad" because
its main() is void is more foolishness.
Like the Troglodytes in Plato's cave of Unknowing, you confuse
Schildt's deliberately dumbed down examples, and your own production,
with the reality...say the reality I faced when I had to write an
actual, 26000 line compiler for most of Quick Basic on my own time and
dime in San Francisco budget hotels, and I toasted my friend's laptop
with a Starbuck's venti.
Harbison and Steele looks better than Schildt, because the issue is
Seebach's uninformed stalking, not the quality of Schildt.
But it doesn't look like a book with truly portable code that works
anywhere. To get that, you have to use Java or C Sharp.
spinoza1111
>
> > [refuting Kennedy assination conspiracy theories (I couldn't parody this stuff)]
No, you couldn't [even] parody it, because you don't read outside your
field, and you move your lips when you read inside it. The fact is
that Bugliosi exposes the same childish thought patterns manifest in
Seebach: the failure to do homework, the deliberate concealment of
evidence, the use of the Internet to lend false authority, and the
dreamlike associativity of thought.
spinoza1111
wrote:
> In article <6be118ea-7c38-487d-b183-b0ad252ce...@12g2000yqi.googlegroups.com>,
The hatred in this discussion, the ignorance, and the fear...you're
discussing how to kill someone metaphorically. You're not even human
enough to be real Nazis. Instead, you're in many ways more evil since
so cowardly wanting a Second Life as powerful beings who can
"kill" (file) people you don't like. You also seem to me to be
simultaneously fascinated by the technology of eliminating the most
intelligent and best-educated discussant, and incompetent even at
that.
Seebach refused McGraw Hill's offer of a tech review job, probably not
mainly because it wasn't enough money, but because that would involve
meeting with Schildt, and Seebach is a coward. That's plain. Early in
this discussion, I sent him email as is customary in an incipient
flame war to avoid a flame war. He refused to answer or read that
email.
What an asshole!
This has gone to a formal wikipedia complaint. The next step will be a
book or an article on Internet bullying by employed "professionals"
and this will be a case study.
J de Boyne Pollard
> > end of that sentence.
>
> continuing
> "or with two parameters (refered to here as argc and argv [...])"
You've still stopped before the end of the sentence. READ ALL
OF THE WAY TO THE END OF THAT SENTENCE.
> I have to confess I was surprised becasue I'm sure I've seen
> people say there was something like like "main shall look
> like this and may also be defined in some implementaion
> dependent manner". but now I look I can't see text like
> that. Can you give me a quote?
It's at the end of the very sentence that you are not
reading all of the way through!
> > Then read for a few more sections
> > beyond that point, as well.
>
> well I got to "Program Execution" (section 2.1.2.3).
> How far would you like me to go?
If you reached that, then you've just read the
relevant section.
Seebs
> You've still stopped before the end of the sentence. READ ALL
> OF THE WAY TO THE END OF THAT SENTENCE.
That sentence does not allow a C program to use another form of main(),
it allows an implementation to allow another form of main.
Think about it like integer ranges. An implementation *may* define a
range of int larger than +/- 32,767 -- but the C standard mandates that
you not assume a larger range for int. Because an implementation doesn't
*have* to define a larger range.
If you want to write a program for a hosted enviornment, and you want it
to work on a hosted environment that some other person might provide, your
only choice for main's return type is int. It really is mandated.
-s
--
spinoza1111
> On 2010-04-12, Colonel Harlan Sanders <Har...@kfc.com> wrote:
>
> > On Sun, 11 Apr 2010 17:38:07 -0700 (PDT), spinoza1111
> ><spinoza1...@yahoo.com> wrote:
> >> I find that Seebach is stalking Schildt based on
> >>trivia. I have shown this.
> > In recorded fact, Seebach wrote a one page critique of a book 14 years
> > ago. Occasionally the subject of Schildt's books came up, so for
> > convenience he put the CTCN page on his site so he could refer people
> > to it.
>
> Yes. I made one attempt to get the publisher to address the technical
> errors, they were unwilling to pay an amount I thought reasonable at the
> time for the service, I wrote up a page documenting it and forgot about
> it.
1. I think you're lying. You didn't want to meet with Schildt because
in fact you were afraid you might be proven wrong.
2. The person you're talking to is a complete "Lanier" troll, since he
has contributed no code nor any insights on C to these threads and
appears to know nothing about computing. He is a loser who seeks out
people being bullied and joins in because that's how he gets his rocks
off.
>
> Seriously, until Nilges started this stuff up again, I didn't even *know*
> that there'd ever been a fourth edition of that stupid book. I had no
> interest in the topic. As time passed and people stopped recommending
> Schildt's books, and thus readers of those books stopped showing up
> confused in comp.lang.c, it dropped completely off my radar.
But this means you are reviewing, and changing wikipedia, in a
Biography of Living Persons, based on a biased review of a book you're
opening at random and that you haven't even read.
>
> > Note that again: Seebach et. al. all DID NOT put themselves in the
> > wiki article, YOU DEMANDED CITATIONS and you got them.
>
> And again, to amplify: I had no clue that anyone was linking to the
> page. In fact, if you'd asked me if I had a page on the topic, I woulda
> guessed that I used to but that it had been lost during site organization
> at some point. I had no idea it was still there, let alone still in
> any way relevant to any of this.
What part of tort negligence don't you understand?
>
> As to whether it's "trivia", I don't think a consistent, in-every-example,
> failure to use getc() or getchar() correctly, as well as a precisely
> false explanation of EOF, is "trivial" for a newbie C programmer. Neither
> is failing to mention struct padding.
>
No competent programmer makes code depend on struct padding. Many
competent C programmers consistently do not interact with character
IO, since C is no longer useful for user interfacing; news flash; the
Teletypewriter model of Linux is out of date.
> Are we done here yet? Nilges has been being unpersuadable on Usenet for
Not by you, certainly.
> a *long* time. Nothing suggests that this is going to be the time he
> finally seeks treatment for whatever he did to ruin his life. Arguing
Fuck you VERY much, since you make excuses for your bad code based on
ADHD and autism. Again, and again until you get it, asshole, how dare
you accuse anyone of mentally disordered posting when you use your
dysfunction as an excuse for your errors?
> with him does nothing. So far as I can tell, if people would just ignore
But you're not. In fact, you are getting quotes from blm and hiding
behind her whilst libeling me.
> him and let him be, this would be an extremely good solution for
> everything -- Nilges would be devoting his considerable time and effort
> trying to defame me, and no one else would have to deal with it. Since
So sue me for defamation, big man. I need the free publicity for a
counter-suit that will be filed that you've committed a criminal act,
electronic stalking of Schildt and myself. Per Blackstone the truth of
what I say is not enough to protect me from civil defamation lawsuits.
Instead, I can establish that
* I am acting according to wikipedia policy in protecting wikipedia
against a charge of libel for carrying the Schildt article for four
years, referencing your crap
* I am trying to end a criminal case of electronic defamation and
stalking on your part in the interests of this community and the
numerous Windows programmers who come here and are defamed for
violating your shibboleths
* Since I'm not a "deep pocket defendant" (are you?) I'm not going to
be worth your attorney's time.
> none of the people in the corporate hierarchy above me are dumb enough
> to fall for his crap, this is pretty much the ideal output. Let Nilges
> lie about me all he wants; it's not hurting anyone.
>
> Please put [NILGES] in subject lines when responding to him or threads
> about him so people can killfile them more easily, and let's get back
> to talking about C. This has been about as amusing as it's going to
> get unless he actually sues, and since that won't happen, we're done
> here; this is now a sitcom in reruns, and there is No Point.
But you keep on replying.
>
> -s
> --
J de Boyne Pollard
> > > type other than int).
> >
> > the way through a sentence. Read all of the way to the
> > end of that sentence. Then read for a few more sections
> > beyond that point, as well.
>
>
> The standard does allow an implementation freedom to
> define additional forms of main() that it will accept,
> true. But that doesn't mean that it doesn't mandate a
Read the standard more carefully. It most definitely
doesn't mandate such a thing. Read what was being
refuted carefully, too. M. Keighley was asserting
that there's "no hint of [...] any other return
type other than int". Clearly, there's not only a
hint, there's explicit wording devoted to that
very thing.
I'm surprised that you're getting this wrong. This
ground has been covered ad nauseam over the years.
I have a Frequently Given Answer on the subject that
lays out how the punctuation breaks up the list and
what sections deal with alternative types for the
return value of main(). I even put together, back
in 2002, exactly what wording changes would be
needed to make the standard actually say what
people so often assert it to say. You want the
standard to "mandate a return type of int"? You
know exactly what to vote in at the next
WG14 meeting. (-:
Seebs
> doesn't mandate such a thing.
Having been involved in the discussions that led to the current
wording, I am convinced that it does.
To state that the standard "mandates" something does not imply that
an implementation does not have the freedom to accept something else;
it only asserts that that is the only thing the implementation *must*
accept.
The only declarations of main() that a hosted implementation *must*
accept are two forms, both of which return int. If you write something
else, you are relying on the implementation choosing to support a
feature not required by the standard.
> I'm surprised that you're getting this wrong. This
> ground has been covered ad nauseam over the years.
> I have a Frequently Given Answer on the subject that
> lays out how the punctuation breaks up the list and
> what sections deal with alternative types for the
> return value of main().
That's nice. It doesn't matter, though. The standard, while
allowing implementations freedom to accept other forms, mandates
a return type of int for programs written in standard C. The
assertion being made has never been that no compiler anywhere
could accept other types; it is that no program which relies on
such a feature is strictly conforming code, or reliably portable
to additional implementations.
Phil Carmody
> On 04/12/10 05:21 PM, Seebs wrote:
>> On 2010-04-12, Peter Nilsson<ai...@acay.com.au> wrote:
>>> Seebs<usenet-nos...@seebs.net> wrote:
>>>> ... So far as I can tell, if people would just ignore
>>>> him and let him be, ...
>>
>>> Well there's a stone from the glass house.
>>
>> I have him killfiled; I haven't yet got the tools to autokill any thread
>> he starts, or anything.
>
> Try Thunderbird.
Do they still make it? If not, I guess there's still cisco
according to http://www.bumwine.com/tbird.html
Phil
--
I find the easiest thing to do is to k/f myself and just troll away
-- David Melville on r.a.s.f1
Phil Carmody
> In article <slrnhs4uqc.qlr...@guild.seebs.net>,
> Seebs <usenet...@seebs.net> wrote:
>> On 2010-04-12, Colonel Harlan Sanders <Har...@kfc.com> wrote:
>> > On Sun, 11 Apr 2010 17:38:07 -0700 (PDT), spinoza1111
>
> [ snip ]
>
>> Please put [NILGES] in subject lines when responding to him or threads
>> about him so people can killfile them more easily,
>
> brackets from subject lines, so your proposed fix here may not be as
> effective as you might like. Just sayin'.
Killfiling anything from googlegroups is always a solution to
that problem.
Tim Rentsch
> On 11 Apr, 15:52, Willem <wil...@turtle.stack.nl> wrote:
>> spinoza1111 wrote:
>>
>> It means "invalid" arguments (arguments in which
>> ) the conclusion doesn't follow from the premises) in which the premise
>> ) is the bad character of the person making the assertion you would like
>> ) to refute in a matter unrelated to his character.
>>
>> And that is exactly what you did.
>> Your 'refutations' were based upon (your perceptions of) Seebach
>> as a person and had nothing to do with the criticisms themselves.
>>
>> Your text is a textbook example of argumentam ad-hominem.
>>
> Ad hominem is a bit more subtle than it might first appear. The ad
> hominem fallacy is to assert that an argument is wrong or invalid
> because of the person who is making it. However we do this all the
> time. No-one's bothered what some schoolkid says about the deficit
> reduction plan. If some central banker says "this is the only policy
> which will reduce the deficit without substantial economic
> dislocation", everyone sits up and takes notice.
This description glosses over an important distinction. Almost
everyone uses ad hominem judgments in forming their own
opinions, in their own private thoughts. That's quite different
from making an ad hominem argument as part of a public
statement. I choose whom I listen to, and sometimes whom not
to, because it's my decision and I have only so much time to
spend. But making such a statement in a public forum is like
saying, "You shouldn't listen to person X, because _I_ don't
think he's worth listening to." Each person has a right to
choose for themselves which people are worth listening to, using
whatever criteria they think are important. Arguments should be
made based on merit; arguments based on personalities are a
waste of bandwidth.
spinoza1111
Agreed. And Seebach made an issue that has nothing to do with
personalities, the inaccuracy of code snippets in computer books, into
an issue named "Schildt", and through tortious negligence caused
Schildt to be stalked by several people, including, in effect, by
Seebach.
Whereas if Seebach had done his homework (something he repeatedly
fails to do, whether in code samples or "in the matter of Herbert
Schildt"), he would have found that Brian Kernighan had raised
precisely this issue in Kernighan's book "The Elements of Programming
Style".
When I spoke with Kernighan about this in 1988, I asked him if anyone
had been offended by his harsh words, and he said that they were
grateful for his input. My guess would be that like Dijsktra, and
unlike Seebach, Kernighan had (1) courage and (2) decency.
Kernighan had courage because in saying "Houston, we have a problem"
as regards software in books, he was speaking truth to power; he was
an individual person criticising a publishing apparatus, a group of
individuals and companies. Such courage is now out of date in American
programming circles simply because the remaining American programmers
whose jobs haven't gone overseas to overall more competent and decent
foreigners depend upon the grace and favor as courtiers, retainers and
eunuchs on corporate feudal lords.
Kernighan had decency because in 1976, computers mattered less than
people including professional standing which is not lightly defamed.
There are plenty of computer books with errors in them. There are,
probably, any number of C books with void main in them. However,
younger "professionals" no longer have courage, decency or a work
ethic and for this reason they preferred linking to CTCN and
essentially mocking real academic "cites". Nobody in the "get Schildt"
crowd has the courage, decency, work ethic, or computer science
background to ask why publishers must all compete to produce computer
books so quickly that errors appear.
It's easier to regress to name-calling, but Seebach should not be
surprised to eat his own dog food, and be subject to the same
treatment.
Attorney: Mr. Seebach, for the record, would you please provide the
court with your formal qualifications in software?
Seebach: I am self-taught.
Attorney: Have you taken any classes in computer science?
Seebach (rattling his worry balls obsessively) N..nnn...no...
Attorney: Thank you Mr Seebach. You may step down.
...
Attorney (for Seebach): Mr. Nilges, for the record, would you please
provide the court with your formal qualifications in software?
Nilges: Certainly. I completed the first class ever offered at my
university in 1970 in computer science with the grade of B. I
completed 8 classes towards the MSCS in computer science with 7 As and
one B+. Based on this, I was an adjunct professor of computer science
from 1998 to 2000.
Attorney: And why did you fail in 1970 to get an A?
Nilges: This was because I joined the nationwide student strike
against Nixon's invasion of Cambodia and did not attend classes.
Attorney: Certainly not a very impressive record, Mr. Nilges, indeed
rather troubling. Would you say that this less than stellar record of
low achievement and stirring up trouble qualifies you to be so
critical of a member of the C99 working group?
Nilges: I am no spring chicken. At the time I started out, theory and
practice were ill-formed; for example, Andrew Tanenbaum, the author of
our textbook on computer architecture, felt that a layered approach to
computer architecture was best for in 1974, memory was cheap but CPU
power relatively expensive; Tanenbaum seems not to have foreseen that,
quite independent of Moore's law, the ratio of memory to CPU costs
would change in such a manner that by 1987, when I attended ACM's
ASPLOS conference on new developments in architecture for my
professional development, highly pipelined, single-level and C
optimized processors were in fashion. Therefore education requirements
were often waived for my "baby boom" generation in a way that in my
personal view, should not longer apply.
Attorney for Seebach (whose supervising attorney has been frantically
signalling her to shut Nilges up by making sawing motions with his
hand): ...v-very well, Mr. Nilges, you may step down.
...
Attorney for either side: Mr Schildt, will you please describe your
educational qualifications?
Schildt: I have the MSCS in computer science.
Attorney: Thank you, Mr Schildt
To avoid these scenes all Peter needs to do is apologize for his
conduct and remove the wikipedia biography.
Nick Keighley
I've got the ANSI standard. Is that "Program Startup"? (ie. the bit I
already quoted?)
Nick Keighley
> Nick Keighley wrote:
> > On 12 Apr, 14:58, Richard Heathfield <r...@see.sig.invalid> wrote:
> >> SG wrote:
> >>> On 12 Apr., 15:07, spinoza wrote:
> >>>> Similarly, Seebach lies about the standard
> >>>> because it doesn't mandate int main(),
> >>> What's your definition of "it mandates" in this context? The standard
> >>> says that implementations must accept main functions of type
> >>> void(void) and void(int,char*[]) (or equivalent).
> >> No, it most certainly does not say any such thing. What it says is that
> >> *hosted* implementations must accept main functions of type int(void),
> >> int(int, char **), or equivalent (note the return type - int, not void).
> >> Implementations *may* accept main functions of other types, but are not
> >> required so to do.
>
> > does it explicitly say that?
>
> See 2.1.2.2, or its C99 equivalent.
>
> Note the introductory words: "A hosted environment need not be provided,
> but *shall* conform to the following specifications if present." (My
> *asterisks*.)
so a hosted implememntation must use one of the forms specified?
Nick Keighley
> Nick Keighley <nick_keighley_nos...@hotmail.com> writes:
> > On 12 Apr, 14:07, J de Boyne Pollard <J.deBoynePoll...@Tesco.NET>
> >> > There is no hint of void main (or any other return type
> >> > other than int).
>
> >> Actually, there is. You've stopped reading one third of
> >> the way through a sentence.
>
> > continuing
> > "or with two parameters (refered to here as argc and argv [...])"
>
> > no I'm sorry I'm not going to type the whole bloody spec in. There is
> > nothing in the remainder of the sentence that mentions return types.
>
> Yes, there's an ambiguity there.
where? Look I'm not trying to be awkward but I really can't see the
text that everyone else can see!!
> It says, in outline that main()
> shall be defined with a return type of int and with no parameters ...
> or with two parameters [argc and argv] or equivalent; or in some other
> implementation-defined manner.
My text doesn't have that last bit.
> The question is, what is the scope of the "or"? It's usually
> assumed that it means
>
> with a return type of int
> and
> with no parameters
> or
> with two parameters
> or
> in some other implementation-defined manner
>
> But the wording and punctuation could easily imply:
>
> with a return type of int
> and
> with no parameters
> or
> with two parameters
> or
> in some other implementation-defined manner
>
> which requires any implementation-defined manner to have a return type
> of int.
>
> But if you read on to 5.1.2.2.3p1, you'll see:
>
> If the return type is not compatible with int, the termination
> status returned to the host environment is unspecified.
I don't have that text either. Is this a C99 change? If so it was a
retrograde one!
Nick Keighley
wrote:
> > > Actually, there is. You've stopped reading one third of
> > > the way through a sentence. Read all of the way to the
> > > end of that sentence.
>
> > continuing
> > "or with two parameters (refered to here as argc and argv [...])"
>
> You've still stopped before the end of the sentence. READ ALL
> OF THE WAY TO THE END OF THAT SENTENCE.
quote it. What terminates the sentence? (It's a long way to the next
full stop). I'm beginning to think we aren't reading the same text.
Richard Heathfield
<nonsense snipped>
> Attorney for either side: Mr Schildt, will you please describe your
> educational qualifications?
>
> Schildt: I have the MSCS in computer science.
>
> Attorney: Thank you, Mr Schildt
You're resting your hopes on the inability of non-experts to distinguish
between pseudo-experts and genuine experts. Schildt's Master's degree
does not make him an expert in the field. It makes him the more
culpable, since he uses it to fool people into believing that he knows
what he's talking about... although, to be fair, perhaps he himself
thinks he does.
Richard Heathfield
In C90, a hosted implementation *must* accept each of the two specified
forms, and *may* accept other forms.
In C99, the wording changed, but the practical upshot is no different.
Nick Keighley
> On Apr 12, 8:07 am, J de Boyne Pollard <J.deBoynePoll...@Tesco.NET>
> wrote:
>
>
>
>
>
> > > > Similarly, Seebach lies about the standard
> > > > because it doesn't mandate int main(),
>
>
> > > "Hosted Environment
> > > The function called at program startup is named main. [...] It can be
> > > defined with no parameters
> > > int main (void) { /*...*/ }
> > > "
>
> > > (and then goes on the discuss argv and argc).
>
> > > other than int).
>
> > the way through a sentence. Read all of the way to the
> > beyond that point, as well.
>
>
>
>
>
>
> > 5.1.2.2 Hosted environment
>
> > 1 A hosted environment need not be provided, but shall conform to the
> > following specifications if present.
>
> > 5.1.2.2.1 Program startup
>
> > 1 The function called at program startup is named main. The implementation
> > declares no prototype for this function. It shall be defined with a return
> > type of int and 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[]) { /* ... */ }
>
> > or equivalent;9) or in some other implementation-defined manner.
that last line isn't present in X3.159-1989
I don't understand why it was added.
So Schildt's book is working to the the 1999 standard. Now we know
that does it increas or decrease the number of errors?
> > ...
>
> > 9) Thus, int can be replaced by a typedef name defined as int, or the type
> > of argv can be written as char ** argv, and so on.
>
> Key words here are "some other *implementation-defined* manner": if
> the implementation allows return types for main() other than int, then
> that must be documented *by the implementation*. Otherwise the
> behavior is undefined.
>
> The standard defines exactly two interfaces for main() in a hosted
> environment, and both of them must return int. It allows for hosted
> implementations to define their own interfaces for main(), but that's
> *not* the same thing as saying that the *standard* allows main() to be
> typed void (or any other type).
Richard Heathfield
> On 12 Apr, 16:56, Keith Thompson <ks...@mib.org> wrote:
>> Nick Keighley <nick_keighley_nos...@hotmail.com> writes:
>>> On 12 Apr, 14:07, J de Boyne Pollard <J.deBoynePoll...@Tesco.NET>
>
>
>>>>> There is no hint of void main (or any other return type
>>>>> other than int).
>>>> Actually, there is. You've stopped reading one third of
>>>> the way through a sentence.
>>> continuing
>>> "or with two parameters (refered to here as argc and argv [...])"
>>> no I'm sorry I'm not going to type the whole bloody spec in. There is
>>> nothing in the remainder of the sentence that mentions return types.
>> Yes, there's an ambiguity there.
>
> where? Look I'm not trying to be awkward but I really can't see the
> text that everyone else can see!!
>
>
>> It says, in outline that main()
>> shall be defined with a return type of int and with no parameters ...
>> or with two parameters [argc and argv] or equivalent; or in some other
>> implementation-defined manner.
>
> My text doesn't have that last bit.
It doesn't matter. Under C90, if a hosted implementation supports some
other form of main as well as those specified, then a program using such
a form has undefined behaviour (violation of a "shall" that is outside a
constraint), but can (presumably) rely on the support of the
implementation the programmer is using, which means it is reasonable to
say that it will work under that implementation but not under others.
Under C99, if a hosted implementation supports some other form of main
as well as those specified, then a program using such a form has
implementation-defined behaviour, and can (presumably) rely on the
support of the implementation the programmer is using, which means it is
reasonable to say that it will work under that implementation but not
under others.
Slightly different paths, but exactly the same outcome.
<snip>
Seebs
> You're resting your hopes on the inability of non-experts to distinguish
> between pseudo-experts and genuine experts.
Right. Think about it this way:
Of people who have been on the ISO C committee, what percentage would
you expect to claim that Schildt is a more reliable source of information
about C than I am?
(Hint: I would not expect the total number to exceed one, and that one
never attended a meeting that I know of.)
Expertise does not begin and end with formal education. One way people
tend to evaluate claims of expertise is to test a person's claims about
the subject matter against the claims of other people.
What percentage of books about C do you think get EOF wrong? I haven't
seen many that get that one wrong; it's basic, it's easily explained,
it's clearly documented...
Richard Heathfield
<snip>
> What percentage of books about C do you think get EOF wrong?
I would guess it's about 50-50. If you think Schildt is the only one who
writes useless C books, you're mistaken.
<snip>
Seebs
> So Schildt's book is working to the the 1999 standard. Now we know
> that does it increas or decrease the number of errors?
3rd edition, which came out in 1995, obviously was not working to the
1999 standard. Amusingly, the 4th edition, which was working to the
1999 standard, removed the spurious claim that you could use "void main".
There is really no difference between the two specs, except for the
clarification that implementations are obliged to define any other
signatures... But note that there's really no teeth to that.
Consider.
What if an implementation does *not* define any other form of main(),
but then cheerfully accepts:
double main(double x)
?
The program isn't particularly strictly conforming, and I don't think
it violates a constraint (?), so I don't think anything the implementation
does, including accepting the program and producing code which meets
the user's expectations, violates anything.
All C99 did was strongly hint that, if you were accepting other
forms of main(), you ought to document them.
Seebs
>> What percentage of books about C do you think get EOF wrong?
> I would guess it's about 50-50. If you think Schildt is the only one who
> writes useless C books, you're mistaken.
I've seen a lot of other books get subtle things wrong, but I don't
think I've yet seen anyone else make that particular EOF error. It's a
common newbie mistake, yes, but I've never seen (that I remember)
a newbie who made that mistake ascribe it to a C book not written
by Herbert Schildt.
Stuff like the 2's complement thing, what happens when you right
shift negative signed values, void main, all of those I've probably
seen elsewhere. The EOF thing, though, I don't think I have.
Now you've got me curious. Someone remind me to check next time I'm
in a large bookstore.
Nick Keighley
> In article <6be118ea-7c38-487d-b183-b0ad252ce...@12g2000yqi.googlegroups.com>,
> Nick Keighley <nick_keighley_nos...@hotmail.com> wrote:
>
>
>
>
>
> > On 12 Apr, 15:07, Nick Keighley <nick_keighley_nos...@hotmail.com>
> > wrote:
> > > On 12 Apr, 10:03, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
>
> > > > In article <slrnhs4uqc.qlr.usenet-nos...@guild.seebs.net>,
> > > > > about him so people can killfile them more easily,
>
> > > > As I understand it, Google's posting interface strips tags in square
> > > > brackets from subject lines, so your proposed fix here may not be as
>
> > > this is a test.
> > > this is posted from google and the subject line should contain square
> > > brackets
>
> > well I can see em
>
> As can I (using news.individual.net). However, Seebs's subject line
> was
>
> "Re: [NILGES] Son of Snarky Tirade: a response to Seebach's new CTCN: part 1"
>
> and yours doesn't seem to have the beginning "[NILGES]". That's what
> I thought would happen.
>
> So maybe the trick is to put the text in square brackets at the end
> rather than the beginning?
the subject of this post is
"[PREFIX ENCLOSED IN SQUARE BRACKETS] google test [POSTFIX ENCLOSED
IN SQUARE BRACKETS]"
> (Cue chorus of ungrateful whining about what GG has done for/to/with
> Usenet .... )
--
All right, but apart from the sanitation, the medicine,
education,
wine, public order, irrigation, roads, a fresh water system, and
public health, what have the Romans ever done for us?
Nick Keighley
wrote:
> On 12 Apr, 15:24, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> > In article <6be118ea-7c38-487d-b183-b0ad252ce...@12g2000yqi.googlegroups.com>,
> > Nick Keighley <nick_keighley_nos...@hotmail.com> wrote:
> > > On 12 Apr, 15:07, Nick Keighley <nick_keighley_nos...@hotmail.com>
<snip>
> > > > > As I understand it, Google's posting interface strips tags in square
> > > > > brackets from subject lines, so your proposed fix here may not be as
> > > > > effective as you might like. Just sayin'.
>
> > > > this is a test.
> > > > this is posted from google and the subject line should contain square
> > > > brackets
>
> > > well I can see em
>
> > As can I (using news.individual.net). However, Seebs's subject line
> > was
>
> > "Re: [NILGES] Son of Snarky Tirade: a response to Seebach's new CTCN: part 1"
>
> > and yours doesn't seem to have the beginning "[NILGES]". That's what
> > I thought would happen.
>
> > So maybe the trick is to put the text in square brackets at the end
> > rather than the beginning?
>
> the subject of this post is
> "[PREFIX ENCLOSED IN SQUARE BRACKETS] google test [POSTFIX ENCLOSED
> IN SQUARE BRACKETS]"
again it appears to survive...
Keith Thompson
> On 12 Apr, 16:56, Keith Thompson <ks...@mib.org> wrote:
>> Nick Keighley <nick_keighley_nos...@hotmail.com> writes:
>> > On 12 Apr, 14:07, J de Boyne Pollard <J.deBoynePoll...@Tesco.NET>
>
>
>> >> > There is no hint of void main (or any other return type
>> >> > other than int).
>>
>> >> Actually, there is. You've stopped reading one third of
>> >> the way through a sentence.
>>
>> > continuing
>> > "or with two parameters (refered to here as argc and argv [...])"
>>
>> > no I'm sorry I'm not going to type the whole bloody spec in. There is
>> > nothing in the remainder of the sentence that mentions return types.
>>
>> Yes, there's an ambiguity there.
>
> where? Look I'm not trying to be awkward but I really can't see the
> text that everyone else can see!!
>
>
>> It says, in outline that main()
>> shall be defined with a return type of int and with no parameters ...
>> or with two parameters [argc and argv] or equivalent; or in some other
>> implementation-defined manner.
>
> My text doesn't have that last bit.
You must be looking at the C89 or C90 standard. The "or in some other
implementation-defined manner" was a C99 addition. Without it, the
ambiguity isn't there.
Don't you have a copy of n1256.pdf?
[...]
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Nick Keighley
On 12 Apr, 20:09, spinoza1111 <spinoza1...@yahoo.com> wrote:
> On Apr 12, 9:41 am, Seebs <usenet-nos...@seebs.net> wrote:
<snip>
> > As to whether it's "trivia", I don't think a consistent, in-every-example,
> > failure to use getc() or getchar() correctly, as well as a precisely
> > false explanation of EOF, is "trivial" for a newbie C programmer. Neither
> > is failing to mention struct padding.
>
> No competent programmer makes code depend on struct padding.
that's because they know about it. A newbie (and I think this was a
book aimed a newbies despite the title) might think he can copy, say,
a message from a socket straight into a structure and not have
problems. That "Why is this structure bigger than the sum of its
parts" is a clc FAQ only illustrates my point.
On the other hand criticism for sins of ommission is a bit subjective.
Who decides what *ought* to be in a book?
> Many
> competent C programmers consistently do not interact with character
> IO, since C is no longer useful for user interfacing;
so why did schildt use it so often?
> news flash; the
> Teletypewriter model of Linux is out of date.
I still use unix filter programs on a regular basis. Hell, I still
write 'em.
[now I'm nicely set up for a tirade...]
<snip>
--
There is no worse tyranny than to force a man to pay for what he
doesn't
want merely because you think it would be good for him.--Robert
Heinlein
Keith Thompson
[...]
> Consider.
>
> What if an implementation does *not* define any other form of main(),
> but then cheerfully accepts:
> double main(double x)
> ?
>
> The program isn't particularly strictly conforming, and I don't think
> it violates a constraint (?), so I don't think anything the implementation
> does, including accepting the program and producing code which meets
> the user's expectations, violates anything.
As I've mentioned before, strict conformance isn't particularly
relevant. A program that prints the value of INT_MAX isn't strictly
conforming.
"double main(double x)" isn't a constraint violation. The behavior of
any program that uses it is undefined (unless the implementation
defines the behavior).
> All C99 did was strongly hint that, if you were accepting other
> forms of main(), you ought to document them.
Right. An implementation that accepts double main(double x)
can justify it under 5.2.whatever, or under section 4's general
permission to provide extensions, or just by not blowing up when
it sees it.
James Harris
...
> Attorney for Seebach (whose supervising attorney has been frantically
> signalling her to shut Nilges up by making sawing motions with his
> hand): ...v-very well, Mr. Nilges, you may step down.
Hahahaaa! I think the attorney for Mr Nilges would be frantically
signalling for Mr Nilges to stop talking!
...
> Attorney for either side: Mr Schildt, will you please describe your
> educational qualifications?
>
> Schildt: I have the MSCS in computer science.
With all this talk of qualifications does this give an insight into
where these issues come from? Could it be that:
1. Nilges doen't know enough about C to say whether Seebs' comments
are right or not so he doesn't comment at all on the issues (instead
he asks Malcolm McLean to review it).
- and -
2. Nilges assumes that someone with a bigger qualification must know
more about C than someone without.
- or -
3. Nilges suffers from what some might call a personality disorder
where he must at all times have a cause to fight for, a compulsion, a
fixation, an idee fixe etc. There's probably a proper name for it.
James
J de Boyne Pollard
> > doesn't mandate such a thing.
>
> Having been involved in the discussions that led to
> the current wording, I am convinced that it does.
Then you are committing the canonical error, committed by many,
of substituting what you think or want the standard to say
for what the standard actually says. It's the error committed
by some FAQs and by some well-intentioned but misinformed
people. Go and read what the standard *actually says*.
> > I'm surprised that you're getting this wrong. This
> > ground has been covered ad nauseam over the years.
> > I have a Frequently Given Answer on the subject that
> > lays out how the punctuation breaks up the list and
> > what sections deal with alternative types for the
> > return value of main().
>
> That's nice. It doesn't matter, though. The standard,
> while allowing implementations freedom to accept other
> forms, mandates a return type of int for programs
> written in standard C.
Wrong. Go and read what the document actually says. If
you want your statements to be true, you really do have
to stand up in a WG14 meeting and vote a wording change
in, because the current wording does not state what you
are repeatedly, and erroneously, stating, and indeed has
explicit wording dealing with the very opposite of what
you claim it to mandate. Ignore the FAQs. Ignore your
garbled memories of discussions in meetings. Ignore
the folk wisdom passed along in newsgroups. Read the
text of the standard as it is actually written, and has
been for the past decade and more. It's not what you
think it to be. The mandate that you claim to exist
does not exist in the actual text of the document. If
you want the document to be as you think it to be,
you really do have to change it.
After such a change, it would become compatible with
the C++ standard in this area. Unlike the C standard,
ISO/IEC 14882:1998 *really does* mandate int as the
return type of main(), with an explicit "shall"
constraint upon well-formed programs. Its wording is
different to the C standard's, *including* such a
constraint and *excluding* any such thing as the C
standard's discussions of return types for main()
that are not int. To be the same, the C standard
would have to change, because that's not how the
C standard is now.
Nick Keighley
According to google I've tagged someone elses post
On 13 Apr, 08:44, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> I tried to tag this post [NILGES] please inform me if I failed.
> On 12 Apr, 20:09, spinoza1111 <spinoza1...@yahoo.com> wrote:
> > On Apr 12, 9:41 am, Seebs <usenet-nos...@seebs.net> wrote:
> > > As to whether it's "trivia", I don't think a consistent, in-every-example,
> > > failure to use getc() or getchar() correctly, as well as a precisely
> > > false explanation of EOF, is "trivial" for a newbie C programmer. Neither
> > > is failing to mention struct padding.
<snip>
> > Many
> > competent C programmers consistently do not interact with character
> > IO,
[I missed this first time through]
they don't read text files?!
> since C is no longer useful for user interfacing;
>
> so why did schildt use it so often?
>
> > news flash; the
> > Teletypewriter model of Linux is out of date.
#800000
<snip>
J de Boyne Pollard
> > > > the way through a sentence. Read all of the way to the
> > > > end of that sentence.
>
> > > continuing
> > > "or with two parameters (refered to here as argc and argv [...])"
>
> > You've still stopped before the end of the sentence. READ ALL
> > OF THE WAY TO THE END OF THAT SENTENCE.
>
> quote it.
I've got a Frequently Given Answer that lays out the
whole sentence with the invervening examples removed,
showing how it parses. I'll send the hyperlink to you.
> What terminates the sentence? (It's a long way to the next
> full stop).
The question indicates that you already know the answer. (-:
> I'm beginning to think we aren't reading the same text.
It's possible. I'm reading the ISO/IEC 9899:1999 FDIS text.
It has the wording that has been the C standard wording on
this matter for the past decade. It is unchanged through
TC2.
Richard Heathfield
<snip>
> Now you've got me curious. Someone remind me to check next time I'm
> in a large bookstore.
Check next time you're in a large bookstore.
J de Boyne Pollard
I'm not sure that that's really true. As I said before,
Schildt wasn't writing about C, but about DOS implementations
of C. As Jonathan Leffler said, "Once you have one of his
books, you also have a majority of the material in all his
other books.". And we all know that "Turbo C: The complete
reference" exists. (-:
Schildt was really documenting the language as DOS
programmers see it, and working to that. I suspect
that his primary references were the programmers' guides
and library references for DOS implementations, not the
C standard. After all, there wasn't a published C
standard in 1988. But there was a Turbo C manual. (-:
J de Boyne Pollard
> writes useless C books, you're mistaken.
Yechiel M. Kimchi lists quite a few books on
xyr "C Books and C++ Books You Don't Want !"
WWW site.
Richard Heathfield
<snip>
> "double main(double x)" isn't a constraint violation. The behavior of
> any program that uses it is undefined (unless the implementation
> defines the behavior).
I once tried this under NT4. I don't remember what parameter list I
chose, but I used double for main's return type. The crash was extremely
colourful - a DOS screen filled with random characters having random
attributes - and the machine refused to respond until a reboot.
Return types matter.
<snip>
Richard Heathfield
All the original text I post to Usenet is protected by copyright law. If
you quote me, kindly have the courtesy to attribute the quotation correctly.
Walter Banks
spinoza1111 wrote:
Mr Nilges on what basis do you have standing here. So far
a 40 year old degree and a few grad classes. Refereed paper list
Well sir I used to program in C.
Have you written a C compiler? No sir I wrote a compiler.
A C compiler ?
No Sir that would be a compiler for a real language
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
blm...@myrealbox.com
Nick Keighley <nick_keigh...@hotmail.com> wrote:
> On 12 Apr, 15:24, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> > In article <6be118ea-7c38-487d-b183-b0ad252ce...@12g2000yqi.googlegroups.com>,
> > Nick Keighley <nick_keighley_nos...@hotmail.com> wrote:
[ snip ]
> > As can I (using news.individual.net). However, Seebs's subject line
> > was
> >
> > "Re: [NILGES] Son of Snarky Tirade: a response to Seebach's new CTCN: part 1"
> >
> > and yours doesn't seem to have the beginning "[NILGES]". That's what
> > I thought would happen.
> >
> > So maybe the trick is to put the text in square brackets at the end
> > rather than the beginning?
>
> the subject of this post is
> "[PREFIX ENCLOSED IN SQUARE BRACKETS] google test [POSTFIX ENCLOSED
> IN SQUARE BRACKETS]"
And I also get
"[PREFIX ENCLOSED IN SQUARE BRACKETS] google test [POSTFIX ENCLOSED
IN SQUARE BRACKETS]"
> > (Cue chorus of ungrateful whining about what GG has done for/to/with
> > Usenet .... )
>
> --
>
> All right, but apart from the sanitation, the medicine,
> education,
> wine, public order, irrigation, roads, a fresh water system, and
> public health, what have the Romans ever done for us?
There's a reason I said "ungrateful" and "for/to/with" rather
than just "to/with" .... I was very pleased and relieved when
Google rescued DejaNews's archives and made them available again,
and there's something to be said too for their providing a posting
interface. But the archive-searching functionality seems to often
break in mysterious ways, and that business of altering/hiding
anything that looks like an e-mail address is quite annoying, and in
general sometimes it seems like the people assigned to the GG project
aren't as familiar with Usenet customs as one might like. <shrug>
--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
blm...@myrealbox.com
Nick Keighley <nick_keigh...@hotmail.com> wrote:
> On 13 Apr, 08:28, Nick Keighley <nick_keighley_nos...@hotmail.com>
> wrote:
> > On 12 Apr, 15:24, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> > > In article <6be118ea-7c38-487d-b183-b0ad252ce...@12g2000yqi.googlegroups.com>,
> > > Nick Keighley <nick_keighley_nos...@hotmail.com> wrote:
> > > > On 12 Apr, 15:07, Nick Keighley <nick_keighley_nos...@hotmail.com>
> > > > > On 12 Apr, 10:03, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
[ snip ]
> > the subject of this post is
> > "[PREFIX ENCLOSED IN SQUARE BRACKETS] google test [POSTFIX ENCLOSED
> > IN SQUARE BRACKETS]"
>
> again it appears to survive...
>
Not for me -- for this one I get
"Re: google test [POSTFIX ENCLOSED IN SQUARE BRACKETS]"
Huh.
(Probably clc is not the best place to be doing this testing,
but then again I think you need a non-GG helper .... )
Eric Sosman
> On 12 Apr, 16:20, Eric Sosman<esos...@ieee-dot-org.invalid> wrote:
>> On 4/12/2010 10:04 AM, Nick Keighley wrote:
>>> On 12 Apr, 14:58, Richard Heathfield<r...@see.sig.invalid> wrote:
>>>> Implementations *may* accept main functions of other types, but are not
>>>> required so to do.
>>
>>> does it explicitly say that?
>>
>
> I've got the ANSI standard. Is that "Program Startup"? (ie. the bit I
> already quoted?)
You won't find 5.1.2.2.1p1 in the ANSI standard, whose section
numbers only go up to 4.13.8 (plus appendices). My reference was
to ISO/IEC 9899:1999, the language definition now in force (leaving
aside TC's and such interim amendments). The cited paragraph has
three count them three sentences. I draw your attention to the final
clause of the third sentence -- the bit after the semicolon, near
the footnote reference, just past the gas station, you can't miss it.
As for the ANSI standard, there's similar but not identical
text in 2.1.2.2. The ANSI text does *not* explicitly mention the
implementation's freedom to accept other forms of main() -- but
the freedom is there anyhow, under the provisions of 1.7, similar
(but again not identical) to ISO 4p6.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Nick Keighley
but its now gone away...
Ersek, Laszlo
> J de Boyne Pollard wrote:
>>> If you think Schildt is the only one who writes useless C books,
>>> you're mistaken.
>>
>> Yechiel M. Kimchi lists quite a few books on xyr "C Books and C++ Books
>> You Don't Want !" WWW site.
>
> All the original text I post to Usenet is protected by copyright law. If
> you quote me, kindly have the courtesy to attribute the quotation
> correctly.
(I always try very hard to keep attributions intact, so my question is
purely academic. (If not for other reasons, giving credit is about the
only practical currency one subscriber can pay with for the other's
effort.))
May Jonathan's (and anybody else's) consistent attribution-snipping be due
to him considering authorship not only incidental, but downright
distracting? Perhaps he wishes to concentrate exclusively on what is said,
not on who said it.
(I never thought of it in terms of copyright, but there seems to be no
single jurisdiction governing or enforcing copyright on usenet postings.
Perhaps the WIPO could be dragged here kicking and screaming, or you could
attach a terms of use notice to each of your posts, because the default
set of rights may not be identical internationally.)
As said before, this is purely theoretical navel-gazing on my part; I
always watch out for mis-snipping origins.
lacos
Charlton Wilbur
S> On 2010-04-11, Malcolm McLean <malcolm...@btinternet.com> wrote:
>> Ad hominem is a bit more subtle than it might first appear. The
>> ad hominem fallacy is to assert that an argument is wrong or
>> invalid because of the person who is making it. However we do
>> this all the time. No-one's bothered what some schoolkid says
>> about the deficit reduction plan. If some central banker says
>> "this is the only policy which will reduce the deficit without
>> substantial economic dislocation", everyone sits up and takes
>> notice.
S> Yes. However, *formally*, this is the ad hominem fallacy.
"The argument is wrong because it is made by someone with no formal
qualifications in the field" is an ad hominem fallacy because it is
entirely possible for someone with no qualifications in the field to
make a correct argument.
Amusingly enough, Mr McLean then substitues the argument from authority
fallacy: that because someone is acknowledged to be an expert, he is
likely to be correct.
>> "Seebs has no computer science qualifications" is a classic case
>> of the ad hominem fallacy that everyone makes, and in fact we
>> have to make, because we can't give equal time to everyone who
>> asserts something. We have to weight the more worthy speakers.
S> It would be if this were an issue where it were in any way
S> difficult for an ordinary practitioner in the field to evaluate
S> the claims made. Since it's not, and since every practitioner
S> who has looked at the claims confirms them, the presenter becomes
S> irrelevant.
Actually, no, it's completely irrelevant. The truth value of a
statement like "Schildt's book does not accurately describe C" is
completely independent of the identity or credentials of the person
making the claim. Especially when it can be exhaustively backed up.
The fact that people who are qualified and experienced in the field
agree is nice for the sake of moral support, but also has no bearing on
the truth value of the statement.
Charlton
--
Charlton Wilbur
cwi...@chromatico.net
Keith Thompson
[...]
> (I always try very hard to keep attributions intact, so my question is
> purely academic. (If not for other reasons, giving credit is about the
> only practical currency one subscriber can pay with for the other's
> effort.))
>
> May Jonathan's (and anybody else's) consistent attribution-snipping be
> due to him considering authorship not only incidental, but downright
> distracting? Perhaps he wishes to concentrate exclusively on what is
> said, not on who said it.
Perhaps. But people who deliberately delete attribution lines are
being extremely rude. It doesn't much matter how they justify it.
At least one other person who does this has attempted to explain it;
J de Boyne Pollard has not, as far as I know. (Perhaps we could find
the answer by searching for one of his "Frequently Given Answers".)
Seebs
><snip>
>> "double main(double x)" isn't a constraint violation. The behavior of
>> any program that uses it is undefined (unless the implementation
>> defines the behavior).
> I once tried this under NT4. I don't remember what parameter list I
> chose, but I used double for main's return type. The crash was extremely
> colourful - a DOS screen filled with random characters having random
> attributes - and the machine refused to respond until a reboot.
> Return types matter.
Frequently. I guess my point was just that, if they DID want to make that
work, they didn't need C99's new language to do so -- and even C99's language
doesn't mean that the standard didn't mandate a return type of int.
Seebs
> Then you are committing the canonical error, committed by many,
> of substituting what you think or want the standard to say
> for what the standard actually says. It's the error committed
> by some FAQs and by some well-intentioned but misinformed
> people. Go and read what the standard *actually says*.
I have.
I understand it just fine.
I think our issue has nothing at all to do with the words in the
standard here, but with the question of what it means for the standard
to "mandate" something.
> Wrong. Go and read what the document actually says.
If you want to make a case, you actually have to present some
kind of argument, not just assert that you're right.
Argument. You know. Explanation of how the data you cite allegedly
support your position.
You have provided NONE. That's because there isn't one. It's also because,
before you could do that, you'd have to offer a clear explanation of what
you think it means to say that the standard "mandates" something.
Hint: The general permission to offer extensions means that you can always
accept new kinds of programs that contradict what the standard mandates.
That an implementation is permitted, implicitly or implicitly, to accept a
program, does not mean that the standard did not mandate something contrary
to that program's structure or contents.
When we say the standard "mandates" a return type of int, we mean that, if
you use any other return type for main(), the standard provides you with
no guarantees. It is quite possible that an individual implementation will
choose to offer you guarantees. It was just as possible in 1989. It doesn't
change what the standard requires.
If you want to write code which conforms to the C standard, for a hosted
implementation, your main() must return int. That compilers *could* accept
other forms doesn't change that. Similarly, you can't rely on the value
of a right-shifted signed negative number. That an implementation COULD
define that to give you useful results doesn't mean that you can rely on it
and claim to be conforming with the standard.
Seebs
STOP QUOTING PEOPLE WITHOUT ATTRIBUTIONS.
> Someone that Pollard was TOO RUDE TO IDENTIFY said:
>> So Schildt's book is working to the the 1999 standard.
> I'm not sure that that's really true. As I said before,
> Schildt wasn't writing about C, but about DOS implementations
> of C.
This is really not true. He was certainly primarily informed by DOS
implementations, but his *topic* was the C language. That he sucked
at it is not the same thing as saying that he was talking about
something else.
But on second thought, nevermind. Between "I've sent you a hyperlink"
and the refusal to attribute quotes, you are simply too annoying to
deal with.
You don't seem to comprehend that Usenet is a public discussion medium.
You're writing like you're responding to email; you send an individual
person a relevant link, but you don't display it for the thousands of
other readers. You quote things without attribution as though only the
person you were quoting has any interest in reading the post.
That, and you've gone around five or six rounds insisting on a novel
interpretation of the C standard that suggests that you don't understand
the relationship between the standard's requirements on implementations
and the standard's requiremens on programmers, but you have not yet
bothered to actually MAKE YOUR ARGUMENT.
Nevermind. *plonk*
Seebs
> 3. Nilges suffers from what some might call a personality disorder
> where he must at all times have a cause to fight for, a compulsion, a
> fixation, an idee fixe etc. There's probably a proper name for it.
http://en.wikipedia.org/wiki/Narcissistic_personality_disorder
"The narcissist is described as being excessively preoccupied
with issues of personal adequacy, power, and prestige."
[...]
"fanatic type - including paranoid features. A severely
narcissistically wounded individual, usually with major
paranoid tendencies who holds onto an illusion of omnipotence.
These people are fighting the reality of their insignificance
and lost value and are trying to re-establish their
self-esteem through grandiose fantasies and self-reinforcement.
When unable to gain recognition of support from others,
they take on the role of a heroic or worshipped person with
a grandiose mission."
Fascinating reading.
Seebs
> May Jonathan's (and anybody else's) consistent attribution-snipping be due
> to him considering authorship not only incidental, but downright
> distracting? Perhaps he wishes to concentrate exclusively on what is said,
> not on who said it.
Could be, although coupled with the "I've sent you a hyperlink", I think
it's just failure to think through the implications of a shared discussion
medium.
I have concluded that it's not worth the time to figure out.
Seebs
> I tried to tag this post [NILGES] please inform me if I failed.
>
> On 12 Apr, 20:09, spinoza1111 <spinoza1...@yahoo.com> wrote:
>> On Apr 12, 9:41 am, Seebs <usenet-nos...@seebs.net> wrote:
><snip>
>> > As to whether it's "trivia", I don't think a consistent, in-every-example,
>> > failure to use getc() or getchar() correctly, as well as a precisely
>> > false explanation of EOF, is "trivial" for a newbie C programmer. Neither
>> > is failing to mention struct padding.
>> No competent programmer makes code depend on struct padding.
> that's because they know about it. A newbie (and I think this was a
> book aimed a newbies despite the title) might think he can copy, say,
> a message from a socket straight into a structure and not have
> problems. That "Why is this structure bigger than the sum of its
> parts" is a clc FAQ only illustrates my point.
Exactly. If you know about struct padding, it's easy to avoid making code
which depends on it. If you don't, it's not quite so easy.
>> Many
>> competent C programmers consistently do not interact with character
>> IO, since C is no longer useful for user interfacing;
> so why did schildt use it so often?
Exactly; even if we were to grant the delusional rant, it'd just make
the book worse.
I do agree that there's some room for ambiguity about what things-not-covered
should be discussed when talking about a book's quality, but the more I look
at Schildt's work, the more I think it's just plain not even complete enough
to justify what little credibility it had. There's too much fundamental
and significant stuff missing. Moreso when he removed things (say, the
real discussion on order-of-evaluation problems) rather than fix errors in
them.
I'm gonna sorta break ranks with the conventional wisdom of the C community
and say that the existence of order-of-evaluation bugs is arguably a wart
in the language design. I think that, on the whole, it's a wart which is
justifiable in context (both when the language was designed, and what it is
now mostly used for). However, it's certainly a wart... Which is why a
book which doesn't have any real coverage of the feature's implications
is worthless to the student.
Seebs
><snip>
>> Now you've got me curious. Someone remind me to check next time I'm
>> in a large bookstore.
> Check next time you're in a large bookstore.
I'd complain that this was useless, except I've done it pretty much every
time in the last decade that someone asked me to remind them of something.
Okay, clarification.
The next time I'm in a large bookstore, someone please remind me to check.
:P
Keith Thompson
> On 2010-04-13, Richard Heathfield <r...@see.sig.invalid> wrote:
>> Seebs wrote:
>><snip>
>>> Now you've got me curious. Someone remind me to check next time I'm
>>> in a large bookstore.
>
>> Check next time you're in a large bookstore.
>
> I'd complain that this was useless, except I've done it pretty much every
> time in the last decade that someone asked me to remind them of something.
>
> Okay, clarification.
>
> The next time I'm in a large bookstore, someone please remind me to check.
> :P
No problem. Next time you're in a large bookstore, post here so we
can remind you. Be sure you don't leave the store until you've read
all the responses.
It wouldn't hurt to remind us (while you'e in the bookstore, not now)
what we're supposed you remind you of.
Nick Keighley
> On 2010-04-13, Nick Keighley <nick_keighley_nos...@hotmail.com> wrote:
> > On 12 Apr, 20:09, spinoza1111 <spinoza1...@yahoo.com> wrote:
> >> On Apr 12, 9:41 am, Seebs <usenet-nos...@seebs.net> wrote:
> [...] the existence of order-of-evaluation bugs is arguably a wart
> in the language design. I think that, on the whole, it's a wart which is
> justifiable in context (both when the language was designed, and what it is
> now mostly used for). However, it's certainly a wart... Which is why a
> book which doesn't have any real coverage of the feature's implications
> is worthless to the student.
it's a pretty common wart
though I believe more modern (well newer) languages like Java avoid it
I once wrote
some_func (i, i++, i++);
Which is not so much staring into the abyss as throwing rocks and
shouting taunts at it