Son of Snarky Tirade: a response to Seebach's new CTCN: part 1

[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.

-s

 

[Seebs]

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.

-s

 

[Nick Keighley]

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

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]

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, 14:07, J de Boyne Pollard <[email protected]>

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?

[...]

 

[Nick Keighley]

I tried to tag this post [NILGES] please inform me if I failed.

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]

Read the standard more carefully.  It most definitely

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*.

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]

tags really do seem to drive google insane...
According to google I've tagged someone elses post

I tried to tag this post [NILGES] please inform me if I failed.

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?

#800000

<snip>

 

[J de Boyne Pollard]

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.

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.

 

[J de Boyne Pollard]

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. 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]

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.

 

[blmblm]

[ 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]"

--

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>

 

[blmblm]

[ 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]

[...]
Implementations *may* accept main functions of other types, but are not
required so to do.

does it explicitly say that?

5.1.2.2.1p1.

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.

 

[Nick Keighley]

On 12 Apr, 15:07, Nick Keighley <[email protected]>
On 12 Apr, 10:03, (e-mail address removed) <[email protected]> wrote:

<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...- Hide quoted text -

but its now gone away...

 

[Ersek, Laszlo]

J de Boyne Pollard wrote:

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> 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.

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

 

[Seebs]

Keith Thompson wrote:

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.

-s