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

[spinoza1111]

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.

 

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

 

[blmblm]

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 ]

 

[blmblm]

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

 

[Ian Collins]

I have him killfiled; I haven't yet got the tools to autokill any thread
he starts, or anything.

Try Thunderbird.

 

[J de Boyne Pollard]

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

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

 

[Nick Keighley]

X3.159-1989 Section 2.1.2.2 page 7

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

Try Thunderbird.

the strong cider?

 

[Nick Keighley]

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]

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]

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

 

[John Bode]

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

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.

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

 

[blmblm]

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?

(Cue chorus of ungrateful whining about what GG has done for/to/with
Usenet .... )

 

[SG]

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]

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?

5.1.2.2.1p1.

 

[Keith Thompson]

On 12 Apr, 14:07, J de Boyne Pollard <[email protected]>
wrote: [...]

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.

[snip]

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.

 

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

-s

 

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

-s