help w/ c/c++ problem

[Mark McIntyre]

Keith Thompson said:

The bottom line on void main, as far as I'm concerned, is this: if J
Random Newbie posts code here which uses void main, my implementation
will reject it, as is its right.

I'm with RJH here.

Perhaps because he realises how utterly weaselish and useless it is.

and here...

And *in practice*, few C compilers document void main. In fact, I can't
recall any that do. I know that Microsoft document it in their C++
docs,

The C documentation that I have for Microsoft (in the section of the
MSDN titled "C Language Reference") documents a return type of int,
giving the signature as

main( int argc, char *argv[ ], char *envp[ ] )

and specifically noting that envp is an implementation specific
extension.

Later on, a section entitled "implementation defined behaviour"
includes a section that gives three prototypes, all of which return
int. There is no mention of returning void anywhere.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Army1987]

Possible, but I suspect he's just young and naive. The assumption that

I'd expect a young and naive but non-stupid person to be more
likely not to believe their teacher when he's right than viceversa.
(It also depends on the teacher. If he is *really* expert in
programming C on implementations where void main() is allowed and
just happened not to care about standard C, all right, as long as
he claims to teach "FooWare C 7.4", rather than just "C". On the
other hand, an instructor like mine, who compared strings with ==,
never once checked the result of malloc() or of scanf(), used
printf("%d", sizeof(MyStruct)) and showed us how unsurprisingly the
size was the sum of the sizes of the fields of the structure etc.
couldn't be taken seriously, no matter how hard I tried.)

 

[Mark McIntyre]

"void main(void)" is ugly and its mother dresses it funny, and I've
never claimed otherwise. I simply take issue with Mark's statement
upthread:

| Then I'm afraid that both your book and your teacher are wrong. The C
| Standard REQUIRES main to return an int.

That statement is just incorrect. I don't particularly expect Mark
ever to admit this, so I'll gladly drop this now.

I'll admit to it when the persons who spent several hundred posts
convincing *me* of it four years ago in this very forum, admits they
were wrong. Dan, where are you now?

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Mark McIntyre]

Fine by me. Arguing with Mr McIntyre seems to be a waste of time[1], and
I have stopped bothering.

When you stoop to stupid insults ike this, you merely demonstrate why
people increasingly argue with you. FWIW I frequently do agree with
you, but naturally only when you're right....


--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Mark McIntyre]

On Tue, 03 Jul 2007 02:17:32 +0200, in comp.lang.c , Harald van D?k

(snip)

Change 5.1.2.2.3p1 to:

If the return type of the /main/ function is a type compatible with
/int/, then a return from the initial call to the /main/ function is
equivalent to calling the /exit/ function with the value returned by =20
the /main/ function as its argument.[10] If the } that terminates the
/main/ function is reached,

(spaced for emphasis)

or the return type of the /main/ function is
not a type compatible with /int/, the termination status returned =20
to the host environment is unspecified.

Excellent - thats interesting and thanks for pointing it out to me. I
quite agree it clarifies that a hosted env to provide an
implementation defined non-int return type. This is evidently a change
from C89, and as such is a welcome clarification.

So I agree with you, a hosted implementation can define a non-int
return type for main. However I stress, it is implementation defined,
non standardised and nonportable. As such I stand by my original
comment.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[osmium]

:

... just happened not to care about standard C, all right, as long as
he claims to teach "FooWare C 7.4", rather than just "C".

The problem is that the student was told this in the first session of the
class buried in a blur of boilerplate information, "My name is, my office is
at, my office hours are, my telephone extension is, the subject is... " IOW,
it is buried in noise.

If the student reads the preface of his text book _carefully_ he may get a
heads up there. The bottom line: I would guess that most students don't
even _know_ what they are learning. And my guess is that damned few
instructors have anywhere near the passion that most of the regulars on this
newsgroup has for standards. Remarkably, many regulars actually seem to
_enjoy_ it. A three gotcha day is a highlight and a day to be remembered.

 

[CBFalconer]

Fine by me. Arguing with Mr McIntyre seems to be a waste of
time[1], and I have stopped bothering.

When you stoop to stupid insults ike this, you merely demonstrate
why people increasingly argue with you. FWIW I frequently do agree
with you, but naturally only when you're right....

However, you seem to fail to apply that criterion when you are
wrong.

 

[Mark McIntyre]

Fine by me. Arguing with Mr McIntyre seems to be a waste of
time[1], and I have stopped bothering.

When you stoop to stupid insults ike this, you merely demonstrate
why people increasingly argue with you. FWIW I frequently do agree
with you, but naturally only when you're right....

However, you seem to fail to apply that criterion when you are
wrong.

I can read this one of two ways:

0) I don't agree with someone when I'm wrong. This is false - unless
I'm not convinced by the other guy's arguments. If the argument is
convincing I'll happily concede (see elsethread for an example).

1) I don't agree with someone when /he's/ wrong. This is true as often
as I can make it so...

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Keith Thompson]

I'll admit to it when the persons who spent several hundred posts
convincing *me* of it four years ago in this very forum, admits they
were wrong. Dan, where are you now?

This has nothing to do with whether anyone else was right or wrong, or
with what anybody admits. It's a simple technical point. The
standard explicitly allows (but of course does not require)
implementations to support other forms of main, including
'void main(void)'. If an implementation documents and supports
'void main(void)', then a program that uses 'void main(void)' is valid
*for that implementation*. (Assuming a hosted implementation, there
are no good reasons to take advantage of such a feature, and plenty of
reasons not to, but that's not the point.)

Thus your statement that
The C Standard REQUIRES main to return an int.
is incorrect. A conforming implementation may allow 'void main(void)'
-- or 'long double main(unsigned long long foobar)'.

What's so difficult about that?

 

[Mark McIntyre]

This has nothing to do with whether anyone else was right or wrong, or
with what anybody admits. It's a simple technical point.

I don't propose to discuss this any further after this, but I need to
clarify the above, since you've seen fit to complain about it.

About four years ago, I argued strongly FOR precisely the
interpretation that is currently put on the words "or in some other
implementation defined manner". I was however shouted down by several
experts, who made strong arguments against my PoV. I accepted their
apparently greater wisdom.

So you will understand that I'm amused yet annoyed to see at least
some of the same experts now arguing the other side of the coin, and
even more entertained to see them vigorously attacking my posts.

Thus your statement that
The C Standard REQUIRES main to return an int.
is incorrect. A conforming implementation may allow 'void main(void)'
-- or 'long double main(unsigned long long foobar)'.

<uberpedant>
you too are incorrect since you need to add the words "provided it
documents the alternate form".
</>
If I had inserted the word "portable" somewhere there, would that have
satisfied by the way?

What's so difficult about that?

See my response elsethread, which you've either ignored, or missed.

I also want to point out that the uber-pedantry with which this point
has been debated has almost certainly given some newbies the mistaken
impression that void main() is generally ok. I trust those of you who
leapt upon this particular hobbyhorse feel happy with that.

EOT.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[CBFalconer]

.... snip ...


<uberpedant>
you too are incorrect since you need to add the words "provided it
documents the alternate form".
</>

Altogether too much time is spent on this relatively minor and
easily fixed (apart from recursive calls to main) triviality. I
assume the FAQ has a suitable section. It is one thing to mention
it, entirely another to argue about it.

 

[Keith Thompson]

I don't propose to discuss this any further after this, but I need to
clarify the above, since you've seen fit to complain about it.

About four years ago, I argued strongly FOR precisely the
interpretation that is currently put on the words "or in some other
implementation defined manner". I was however shouted down by several
experts, who made strong arguments against my PoV. I accepted their
apparently greater wisdom.

Hmm. I don't remember that discussion, so I can't comment on it.
I can only base my arguments on what the standard actually says.

So you will understand that I'm amused yet annoyed to see at least
some of the same experts now arguing the other side of the coin, and
even more entertained to see them vigorously attacking my posts.

Assuming your description of the earlier discussion to be accurate,
yes, amusement and annoyance would be appropriate. On the other hand,
I can't exclude the possibility that you've misinterpreted the earlier
discussion. Is there any chance you can provide a pointer to it? A
Google Groups search for "void main" is unlikely to be useful.

<uberpedant>
you too are incorrect since you need to add the words "provided it
documents the alternate form".
</>

My intent was that "allowing" it includes the requirement to document
it, but I was insufficiently clear on that point. In any case, 'void
main(void)', even for an implementation that doesn't explicitly
support it, merely invokes undefined behavior; it's not a constraint
violation, so no diagnostic is required. If the implementation
documents the behavior of 'void main(void)', it's a valid extension
(and it must actually work as the standard and the implementation's
documentation specify). If the implementation doesn't document it, it
can treat it in any random way it likes; that includes behaving in
accordance with the documentation that would have been provided if
that page hadn't fallen out of the manual.

If I had inserted the word "portable" somewhere there, would that have
satisfied by the way?

It would depend on where and how you insert it, but yes, it probably
would.

See my response elsethread, which you've either ignored, or missed.

I've read the entire thread. Google Groups says you've posted nine
responses in this thread; I don't know which one you're referring to.

I also want to point out that the uber-pedantry with which this point
has been debated has almost certainly given some newbies the mistaken
impression that void main() is generally ok. I trust those of you who
leapt upon this particular hobbyhorse feel happy with that.

I believe I've made it clear, in most of the responses I've posted on
this thread, that 'void main(void)' is non-portable and that there's
no reason to use it in a hosted environment.

Kids, don't use 'void main(void)'! main() returns int!

(In a freestanding environment, 'void main(void)' could be the *only*
supported form, but newbies are unlikely to encounter freestanding
environments.)

For the record, I'd be happier if the "or in some other
implementation-defined manner" wording had never been added to the
standard. I think it was intended primarily to allow the fairly
common extension of a 'char **envp' parameter, but it would be better
to allow that only in a non-conforming mode. I would also prefer
forms of main() other than the allowed ones to be constraint
violations rather than undefined behavior, so programming errors could
be caught earlier. In other words, I *wish* your statement were
correct.

For that matter, the "or in some other implementation-defined manner"
wording is redundant, since extensions are explicitly allowed anyway
(C99 4p6).

But as I wrote above, I can only base my arguments on what the
standard actually says.

 

[Richard Bos]

This has nothing to do with whether anyone else was right or wrong, or
with what anybody admits. It's a simple technical point. The
standard explicitly allows (but of course does not require)
implementations to support other forms of main, including
'void main(void)'. If an implementation documents and supports
'void main(void)', then a program that uses 'void main(void)' is valid
*for that implementation*. (Assuming a hosted implementation, there
are no good reasons to take advantage of such a feature, and plenty of
reasons not to, but that's not the point.)

The same thing, though, is true for every possible perversion of C, for
precisely the reason you mention upthread: any implementation may
already allow any extension. Therefore, this special mention of other
forms of main() in the Standard is superfluous and confuscatory, and
should never have been allowed in; and also therefore, void main(void)
is neither more nor less allowed by the Standard than (int)*ptr=4.

Thus your statement that
The C Standard REQUIRES main to return an int.
is incorrect. A conforming implementation may allow 'void main(void)'
-- or 'long double main(unsigned long long foobar)'.

What's so difficult about that?

The difficult bit is that, by exactly the same reasoning, any statement
that
The C Standard requires <restraint on C code>
is incorrect, for _any_ restraint. IOW, by that measure, not only is
void main(void) allowed in C code by the Standard, but so is program
main(input, output) begin end.

Richard

 

[Army1987]

If the student reads the preface of his text book _carefully_ he may get a
heads up there.

[snip]
The preface of my textboox says that they had to choose between a
language which is easy to teach such as Pascal, and a language
which is in common use in real application such as C, and they
compromised on using C but using a teaching style such as the one
commonly used to teach C. *ugh* They do not say explicitly they
use standard C, but they included appendices with the BNF syntax
of ANSI C (i.e. C89, that book predates C99), a list of the
identifiers declared in standard headers (at least they tried,
since I don't think SIG_ATOMIC_T or sseek_cur were spelt this way
in C89...), and the description of some functions (e.g. remove())
is a quite faithful translation of the Standard.

(But they even claim that main() is essentially shortand for
void main(void)...)

 

[Keith Thompson]

The same thing, though, is true for every possible perversion of C, for
precisely the reason you mention upthread: any implementation may
already allow any extension. Therefore, this special mention of other
forms of main() in the Standard is superfluous and confuscatory, and
should never have been allowed in;

Agreed, but it is there. I prefer to discuss the language as it is,
not as I wish it were.

and also therefore, void main(void)
is neither more nor less allowed by the Standard than (int)*ptr=4.

There's a big difference. '(int)*ptr=4' is a constraint violation.
'void main(void)' is undefined behavior if the implementation doesn't
document it, perfectly legal if it does.

The difficult bit is that, by exactly the same reasoning, any statement
that
The C Standard requires <restraint on C code>
is incorrect, for _any_ restraint. IOW, by that measure, not only is
void main(void) allowed in C code by the Standard, but so is program
main(input, output) begin end.

The difference is that the standard explicitly allows variant
declarations for main. That permission is strictly redundant, but I
have to assume it's there for a reason.

And here's what the C99 Rationale has to say about it:

main is the only function that may portably be declared either
with zero or two arguments. (The number of other functions?
arguments must match exactly between invocation and definition.)
This special case simply recognizes the widespread practice of
leaving off the arguments to main when the program does not access
the program argument strings. While many implementations support
more than two arguments to main, such practice is neither blessed
nor forbidden by the Standard; a program that defines main with
three arguments is not _strictly conforming_ (see J.5.1.).

So the weasel words apparently are primarily intended to allow for a
third parameter, typically envp, but the wording is vague enough to
give silly things like 'void main(void)' equal status with
'int main(int argc, char **argv, char **envp)'.

It's interesting that we don't get nearly as many newbies thinking the
envp parameter is standard as we get thinking 'void main(void)' is
standard.

 

[Keith Thompson]

If the student reads the preface of his text book _carefully_ he may get a
heads up there.

[snip]
The preface of my textboox says that they had to choose between a
language which is easy to teach such as Pascal, and a language
which is in common use in real application such as C, and they
compromised on using C but using a teaching style such as the one
commonly used to teach C. *ugh*

Did you mean "commonly used to teach Pascal"?

What is your textbook?

They do not say explicitly they
use standard C, but they included appendices with the BNF syntax
of ANSI C (i.e. C89, that book predates C99), a list of the
identifiers declared in standard headers (at least they tried,
since I don't think SIG_ATOMIC_T or sseek_cur were spelt this way
in C89...), and the description of some functions (e.g. remove())
is a quite faithful translation of the Standard.

(But they even claim that main() is essentially shortand for
void main(void)...)

Well, pre-ANSI C had no 'void' keyword. For a function not intended
to return a result, it was common to declare it with no explicit
return type; the return type would default to int, but it could be
used as if it didn't return anything. Typical pre-ANSI code might
look like this:

do_something(n)
double n;
{
/* ... */
/* no return statement */
}

...

do_something(42.0);

The function would implicitly return an unspecified int result, which
would be ignored by the caller.

The modern version might look like this:

void do_something(double n)
{
/* ... */
}

...

do_something(42.0);

 

[Army1987]

If the student reads the preface of his text book _carefully_ he may get a
heads up there.

[snip]
The preface of my textboox says that they had to choose between a
language which is easy to teach such as Pascal, and a language
which is in common use in real application such as C, and they
compromised on using C but using a teaching style such as the one
commonly used to teach C. *ugh*

Did you mean "commonly used to teach Pascal"? Yes...
What is your textbook?

"Informatica: arte e mestiere" by Stefano Ceri, Dino Mandrioli,
Licia Sbattella. A book in English by the same authors is titled
"The art and craft of computing", I guess it is essentially a
translation since the titles are almost the same (but I don't have
it). But I think that firepaper can be also obtained at a cheaper
price than that...

Well, pre-ANSI C had no 'void' keyword. For a function not intended to
return a result, it was common to declare it with no explicit return

But I think in C89 a main() with no return caused UB...

 

[J. J. Farrell]

It's interesting that we don't get nearly as many newbies thinking the
envp parameter is standard as we get thinking 'void main(void)' is
standard.

Not really; isn't that simply down to the number of C textbooks which
explicitly say that defining main as void is fine? I don't think many
of them mention the environment extension.

 

[Keith Thompson]

Not really; isn't that simply down to the number of C textbooks which
explicitly say that defining main as void is fine? I don't think many
of them mention the environment extension.

Yes, but that doesn't make it uninteresting. }

 

[Keith Thompson]

But I think in C89 a main() with no return caused UB...

Not quite; it merely returns an undefined termination status to the
host environment.