C the complete nonsense

[Seebs]

Yes, really. And it's what the *header file* is called. That's
exactly the
spelling that a FAT filesystem will use for the header file's 8.3
name.

The term "header file", itself, is incorrect. "headers" are not necesarily
files. There is not necessarily an actual "file" called stdio.h, or STDIO.H,
or StDiO.H, or anything like that. There is a *header* called <stdio.h>.

It doesn't matter what the filesystem might look like; you have your choice
of whether to display FAT names in uppercase or lowercase. What matters is
that if you include <stdio.h> it is guaranteed to work, and if you include
<STDIO.H> it is not guaranteed to work.

Schildt did not advertise a book on "how specific compilers have been
implemented on a FAT filesystem."

They're often
conflated
with the POSIX API C language bindings, but they are in fact a wholly
different API, that just happens to resemble the POSIX API on a dark
night
if one squints heavily. The most widely-known difference is mkdir().
In
the C language bindings to the DOS system API, which really did spell
it
without a leading underscore in DOS-targetting compilers, it takes
one
argument. In the C language bindings to the POSIX API it takes two.

Oh, fun.

Thanks for the clarification. In any event, the issue is largely moot;
the 4th edition of C:TCR fixes the header names.

-s

 

[spinoza1111]

spinoza1111wrote:



Some of the specific errata have been fixed in a later edition
but the same errors elsewhere  not directly referenced in Seeb's
were left unchanged. A solid technical editing pass should have
been made between revisions and the examples should have
been validated against the written description and run in the
context that the fragments were intended.


It is Schildt's work Seeb's email address is readily available he
could have easily contacted Seeb  (maybe he did). Seebs has
no obligation to work with Schildt. The current review started
directly with your call to treat Schildt honestly. Classify the errors
in some rigorous way starting with mundane to serious and
let the results stand for themselves.

Knuth paid for bug reports. Haberson and Steele author

I don't think Schildt should have to waste his time on thousands of
bug reports, especially "bug reports" such as "the 'heap' is a DOS
term": yet in the document, Seebach calls for his readers to create
bug reports. He sought to flood the internet with thousands of phony
bug reports and expect Herb to handle this.

This is stalking.

 

[Seebs]

Hey! M. Seebach! Apparently you have the power to magically
control whether any other people can hyperlink to your WWW pages
from elsewhere. Did you know that you could probably make a
fortune from the WWW advertising industry with that ability?

*snerk*

To be fair, I suppose in theory I could have removed the page that was
linked to, although I assume they'd just have linked to an archived
copy.

But why should I have? It was correct as to what it actually said,
about the version of the book which existed when it was written.
Until Nilges came along, no one cared or remembered it, so far as I
can tell.

Anyone care to hazard a guess, out of the various architectures
that the C language has been implemented on, which one
has a representation for integers where 2010-2006 is 15? It's
not twos-complement, certainly.

The "15" number is my fault, I referred to the document as
15 years old, when in fact it is only around 14 years old... Not that
this explains why the age of the document is relevant to a discussion
of Wikipedia's link to it.

That said, well, the only real issue ever raised about the previous
document was that it was poorly structured (granted) and addressed a
previous version. The substance of the complaints was sound, and as
I've now shown, they really were representative of the quality of
the book.

The only real way Nilges has affected me negatively is that he's forever
shattered my dreams of being Usenet Kook of the Month. I used to think
I could maybe compete, now I know I'm outclassed.

-s

 

[Colonel Harlan Sanders]

I don't think Schildt should have to waste his time on thousands of
bug reports, especially "bug reports" such as "the 'heap' is a DOS
term": yet in the document, Seebach calls for his readers to create
bug reports. He sought to flood the internet with thousands of phony
bug reports and expect Herb to handle this.

The Nilgewater is rising!
Head for high ground!

This is stalking.

Clearly.

 

[J de Boyne Pollard]

He once sent, via his publisher, a document arguing that

the C89 standard really did allow "void main()" portably.

It would be ironic if it were mine, where I've been pointing out that
"a defect in the C standard that needs fixing with a corrigendum [...]
provides the authors of bad C programming books with the very loophole
that they have been needing for the past decade or so". It's quite a
lot of a stretch to say that I make a case for portability (instead of
a case for fixing a defect in the standard). I list several
implementations that don't define a void return type and several that
do, and one that quietly changed when I pointed out the problem. Have
you ever had someone silently fix something when you pointed out a
defect on a WWW page? (-:

If only the C standard were fixed, too ...

 

[Seebs]

The Nilgewater is rising!
Head for high ground!

Yeah, uhm. lolwut?

I have at no point tried to make Schildt handle "thousands of phony bug
reports". I have solicited that people who find technical errors in
C:TCN report them to me.

I have absolutely no interest in contacting Schildt, nor in inducing other
people to contact him. I merely wished to address the complaints that
C:TCN was not particularly detailed or current, or that it was too nitpicky
and did not identify enough substantial errors to justify such
complaints.

-s

 

[Nick Keighley]

Archimedes Plutonium thinks that Wikipedia existed in 1997, too.

isn't it some sort of paradox to use a word like "think" and AP in the
same sentence?

 

[spinoza1111]

No.  But he will brighten an otherwise dull afternoon*.

I'm hoping he's happy now that the Wikipedia article no longer refers to an
out-of-date article that is not adequately researched, fact-checked, and
documented.  

I am tech-reviewing your new article at http://www.seebs.net/c/c_tcn4e.html..
Yes, you changed wikipedia in partial conformance to my request and
you have indeed responded to my concerns in some small measure. I'd
suggest an apology for the name-calling is in order, and that you seek
to further improve your online behavior. However, nothing you've done
meets my standard for dropping this matter.

"Open sourcing" a new "open season" on Schildt, by asking for help in
doing something you don't have the ability to do, is incitement-to-
online harassment and may be a criminal matter. And when people start
asking online how they can make money from this activity, it becomes
extortion.

Furthermore, you have not addressed Dr. McClean's main concern, and
your tone is still too polemic and shows existence of bias
inappropriate in a tech review. Most readers, unfortunately for your
case, will see this as Return of Snarky Tirade instead of what we
need, which is a retraction of your 1995 hit, Snarky Tirade.

It shall amuse me to find order n*n errors in your material. I still
think you need to go to night school in computer science, guy, get
that degree. Pity you're too old to serve your country to get the
money to do so. Couple of years in the military would teach you not to
rat on people and how to get along with your brothers.

I mean, the problem, as described, was that the Wikipedia entry
linked to something essentially obsolete and not very well-organized.  I
have corrected this deficiency.

Bit late for this disclaimer, a stronger form of which needs to be in
the original Snarky Tirade unless it's just blanked. You deliberately
and maliciously allowed what appears at first to be an NPOV tech
review to ruin a reputation for TEN YEARS. The consequences of your
libelous action are not going away; wikipedia's archive contains the
evidence of your deliberate misfeasance and malfeasance. But I'll drop
the matter if you erase the original CTCN, stop work and erase The
Return of Snarky Tirade, and remove the Reception section from the
wikipedia article.

Your deadline for the wikipedia change is 11 April China time.

You say you're concerned with people being misled by "incorrect"
texts. There are hundreds if not thousands of links to the original
Snarky Tirade, as shown by the fact that a search for "C: the Complete
Reference" (the title of the fourth edition) comes up with the Snarky
Tirade first; as I hope you know, links control search ranks.

But as you have admitted, for the past ten years, CTCN is JUST WRONG,
and you knew it was wrong, and you did nothing about it, thereby
misleading hundreds or thousands of people. You are creating a new
malicious libel and calling for assistance as a form of mob action
incitement. And while you do so, you are saying that the lies were
truths "because" you can "open the book at random" and find "errors",
despite the fact that it was directed at an MS-DOS audience with
different needs, despite the fact that you have no academic
qualifications in computer science, and despite the fact that all code
you submit to clc contains beginner errors.

You have assumed that the new book's "errors" will retrospectively
make a ten year lie not a lie. We don't buy this.

As things stand:

* My review of The Return of Snarky Tirade (your new CTCN) will
appear shortly.

* A new BLP complaint will be made on Monday and cc'd to my new best
friend Jimmy Wales [*]

[*] No, not really. But a person who appeared to be he commented
several times on my blog last winter, which means his admin slave may
forward email to that clown.

-s
[*] Yes, it's a reference.

 

[Keith Thompson]

The term "header file", itself, is incorrect. "headers" are not
necesarily files. There is not necessarily an actual "file" called
stdio.h, or STDIO.H, or StDiO.H, or anything like that. There is a
*header* called <stdio.h>.

Yes, the header (as defined by the C standard) is called <stdio.h>.
Well, sort of. The < and > delimiters are not part of the header's
name; rather, the header is uniquely identified by the character
sequence ``stdio.h'' (C99 6.10.2p2).

A given implementation might implement that header as a file (most
do). It's reasonable to refer to that file as a "header file".
And if it's stored on a FAT filesystem, the most precise name for
that file would be "STDIO.H" (As I understand it, FAT filesystems
store file names in upper case; if you perform whatever system call
is used to get the names of the files in the appropriate directory,
it will return "STDIO.H", not "stdio.h", as the name of the file.
I could easily be mistaken on this point.)

So the statement that "The header file ... is called STDIO.H" could
well be perfectly true in that limited context. It's also an absurd
statement to make in a book intended as a C reference. And, as you
mention, it's to Schildt's credit that the statement was changed in
the 4th edition.

It doesn't matter what the filesystem might look like; you have your choice
of whether to display FAT names in uppercase or lowercase. What matters is
that if you include <stdio.h> it is guaranteed to work, and if you include
<STDIO.H> it is not guaranteed to work.

Absolutely.

 

[Nick Keighley]

But!  You, Random Internet Guy, can help.  Pick a number, any number, in
the range 1..700, inclusive.  

if no one else has a number: 619
(and it is "random" as it came out of a prng)

 

[J de Boyne Pollard]

The header file associated with the I/O functions defined by

Yes, really.  And it's what the *header file* is called.  That's
exactly the spelling that a FAT filesystem will use for the header
file's 8.3 name.

The term "header file", itself, is incorrect.  "headers" are not necesarily
files.  [...]

You know that. I know that. But M. Schildt is talking about header
files, quite explicitly, and what xe says about header files is not
wrong. It's pretty clear that the 3rd Edition isn't documenting the
C language, but DOS (and Windows) implementations of the C language.
(After all, you were just pointing out yourself that it documents
several C language bindings to the DOS system API, as well as the C
language bindings to the IBM PC firmware API and a DOS
direct-console-access library. And we all know that "Turbo C/C++:
The Complete Reference" exists.) Whether it's intended to or not
is another matter, but it clearly is. (The Amazon reviewer who
commented how the 3rd Edition is "fully compliant with Microsoft's
Visual C++" has unintentionally hit the nail squarely on the head
with what the book really is.)

MS/PC/DR-DOS implementations use FAT format volumes, with
headers in files, where the 8.3 name of the header file here
very much will be exactly "STDIO.H".

By the way:

you have your choice of whether to display FAT names in
uppercase or lowercase.  

That doesn't change what the names themselves actually are. I
also have the choice of displaying them in Wingdings, and that
doesn't change what the names actually are, either.

 

[Seebs]

if no one else has a number: 619
(and it is "random" as it came out of a prng)

Ahh, I got one already, I did 168-177.

619 looks to be part of the chapter on "AI-Based Problem Solving", and it's
mostly a fragment of a larger program. Nothing obviously wrong, although
it's just generally poorly done. Lots of globals. It looks like a
not-obviously-wrong explanation of depth-first and breadth-first searches.

-s

 

[Seebs]

You know that. I know that. But M. Schildt is talking about header
files, quite explicitly, and what xe says about header files is not
wrong.

I think it is, if only because the book does claim to be a C reference
for all implementations, based on the standard.

It's pretty clear that the 3rd Edition isn't documenting the
C language, but DOS (and Windows) implementations of the C language.
(After all, you were just pointing out yourself that it documents
several C language bindings to the DOS system API, as well as the C
language bindings to the IBM PC firmware API and a DOS
direct-console-access library. And we all know that "Turbo C/C++:
The Complete Reference" exists.)

This is a valid point. However, by 1995, some Windows users were using
a system which had filesystems in which file names were no longer in
uppercase.

More generally, though, it's functionally-wrong; the underlying issue seems
to be that he unconditionally put all file names in block capitals without
thinking about whether they had other forms. (Indeed, the #include statements
in the book nearly always use all-lowercase; the idiom seems to have been,
not an intentional statement about capitalization, but a convention for
showing filenames.)

That said, I don't object to a reference documenting additional features
beyond those required by the standard, and I don't think that makes it
intrinsically no longer a reference for the language in general. It can
be a reference for the language in general, plus some specific extensions.

Whether it's intended to or not
is another matter, but it clearly is. (The Amazon reviewer who
commented how the 3rd Edition is "fully compliant with Microsoft's
Visual C++" has unintentionally hit the nail squarely on the head
with what the book really is.)
Hee.

That doesn't change what the names themselves actually are. I
also have the choice of displaying them in Wingdings, and that
doesn't change what the names actually are, either.

Point. I guess I view case-smashing filesystems as caseless, even though
there may exist an internal representation.

Ah-hah! I've found a way to justify my position.

The question is not "what is the name of the file on the disk". It is "what
is the header file called". Specifically, the file describing the stdio
interface mandated by ANSI. And that is <stdio.h>.

(The sentence is ambiguous as to whether the "specified by ANSI" applies to
the file or to the stdio interface, and since they're sort of
interchangeable...)

But yes. If we declare that the first error is the cover of the book, then
we can make a lot of the other material into non-errors.

-s

 

[Nick Keighley]

Even if this is true, the guy [schildt] has two rights:
1.  Freedom of speech under the US Constitution, the constitutions of
most developed countries, and the UN declaration of human rights.

yes he has freedom of speech. So do the people who criticise his
book(s)

"The most stringent protection of free speech would not protect a man
in falsely shouting fire in a theatre and causing a panic.[/QUOTE]

<snip long legal quote>

well I don't agree that a critique of a book is in this class

[shrug]. He published a book. The book is publicly available and I dodn't
see how it breaches privacy to read it and criticise it. We aren't
going through his bins (trash) or pointing long lenses at his bedroom.

you agree then?

I wouldn't count on this. Lawyers in fact understand computer science
better than ordinary programmers...we have one half of the evidence
for that statement here.

juries don't tend to have many lawyers on them.
Lawyers know computer science? Why did no one tell me? I'd have got my
dad to tutor me!

As you should be grateful.
why?

An intelligent Linux C programmer would simply put CTCR back on the
shelf,

how would a beginner know? There is no indication that the book is
window's biased

while an intelligent Windows C programmer would not, after
either programmer read about void main.

How many intelligent people use the garbage in Amazon reviews to
seriously make a purchase?

well I read 'em

Almost none. Seebach's review is worse than
the crap on Amazon.

<snip nilge rant>

 

[J de Boyne Pollard]

To be fair, I suppose in theory I could have removed the page

that was linked to, although I assume they'd just have linked
to an archived copy.

But why should I have?  [...]

Because you have MAGIC POWERS, that enable you to CONTROL THE
WIKIPEDIA, that make people's MINDS think DANGEROUS THOUGHTS
about whether C programming books are GOOD IDEAS for the
INNOCENT NOVICE. Don't you know this?

The "15" number is my fault, [...]

It is? Not only have you POWER OVER WIKIPEDIA and TOTAL
HYPNOTIC CONTROL OF ALL WWW PAGE AUTHORS, but you have
INVENTED THE NUMBER 15. Is there no end to your
capabilities?

You didn't invent Nilgesmathics, though. You may have
invented 15, but it took Edward G. Nilges to take your
simple number theory and turn it into the advanced
calculus of Nilgesmathics, based upon the Axiom of
Fifteen Totality. So no stealing credit, now.

 

[Seebs]

<snip>

Of course, this turns out not to be true -- the book is full of advice
which is garbage on Windows, too.

Printing a prompt to a test file instead of to the user who's supposed
to respond to it is not particularly useful. A book on C which, so far
as I can tell, *never mentions structure padding at all*, is not doing
its reader any service.

-s

 

[Nick Keighley]

This is not correct. They were referenced in making the Schildt
"biography" on wikipedia in 2006 and over these years, there has
always been a high frequency of references. Furthermore, newbies have
always been directed to the C FAQ which makes a libel a fact.

the FAQ does not mention the book being discussed here. It mentions
the _Annotated ANSI C Standard_. Would you like to open *that* can of
worms? To be honest it is (or was) a cheap way to acquire a copy of
the standard. I own a copy. The annotations are worthless.

 

[Seebs]

the FAQ does not mention the book being discussed here. It mentions
the _Annotated ANSI C Standard_. Would you like to open *that* can of
worms? To be honest it is (or was) a cheap way to acquire a copy of
the standard. I own a copy. The annotations are worthless.

They are indeed exceptionally bad.

I think that's the key bit missing from the Nilges analysis; he's assuming
that negative statements about something are "libel", but that's only the
case *if they are untrue*. But Schildt's writing makes it quite clear that
he has substantial misunderstandings of C (or is an *extremely* bad writer
who is somehow able to consistently say something wrong in several different
ways even though he understands it... but I think this is unlikely).

There is no libel; Schildt has (or at least, had when he wrote this book) a
very poor understanding of C.

-s

 

[Seebs]

To be fair, I suppose in theory I could have removed the page
that was linked to, although I assume they'd just have linked
to an archived copy.
But why should I have?  [...]

Because you have MAGIC POWERS, that enable you to CONTROL THE
WIKIPEDIA, that make people's MINDS think DANGEROUS THOUGHTS
about whether C programming books are GOOD IDEAS for the
INNOCENT NOVICE. Don't you know this?

Oh!

You're right, of course. I had forgotten because I was too busy
thinking about toast.

The "15" number is my fault, [...]

It is? Not only have you POWER OVER WIKIPEDIA and TOTAL
HYPNOTIC CONTROL OF ALL WWW PAGE AUTHORS, but you have
INVENTED THE NUMBER 15. Is there no end to your
capabilities?

Apparently not! On Tuesday, I made a rock so heavy I couldn't
lift it, but then on Wednesday I lifted it anyway. WITHOUT
CONTRADICTION. I am just that awesome.

You didn't invent Nilgesmathics, though. You may have
invented 15, but it took Edward G. Nilges to take your
simple number theory and turn it into the advanced
calculus of Nilgesmathics, based upon the Axiom of
Fifteen Totality. So no stealing credit, now.

You are, of course, right. When it comes to making stuff up, I
will forever be but a pale imitator of Nilges. I am particularly
crippled by a tendency to imagine that the stuff I've just made up
is in some way not real; he has no such limitations.

-s

 

[Phil Carmody]

Not really. On a case-insensitive filesystem, alternative spellings might be
accepted, but that doesn't mean that's what the header is called.

Given that it needn't even necessarily be a file, whether or not
some filesystems may be forgiving of the error is a side issue.

And is it?

The one I saw was. It was for the lowest level non-portable
input/output operations, IIRC. (Unlike the high level conio.h
file, f'rex.)

Phil