help w/ c/c++ problem

[Flash Gordon]

Harald van Dijk wrote, On 01/07/07 17:52:

This is incorrect. The C standard requires implementations to accept main
returning int, but does not prohibit other return types either from being
allowed by implementations or from being used by programs.

It effectively prohibits it on implementations that do not document
other return types and for programs which are meant to be portable.

Personally I've yet to see an argument for using a return type of other
than int that is strong enough to make me ever want to use it or think
that suggesting it is a good idea. Yes, I have seen the arguments about
unreachable code (and warnings there of) etc, I just don't think they
are strong enough to warrant even a small loss of portability.

 

[Harald van =?UTF-8?B?RMSzaw==?=]

Harald van D?k said:


True enough, but neither does it define the behaviour of such program.

Provided the type of main is one that is documented by the implementation,
the behaviour is not undefined as far as the standard is concerned. The
standard specifies that /if/ void main(void) is a valid declaration for
main, then

#include <stdio.h>
void main(void) {
puts("Hello, world!");
}

must print "Hello, world!" followed by a newline, and exit to the host
environment (though it need not exit with a successful status). If void
main(void) is /not/ documented by the implementation, though, then the
behaviour is undefined.

 

[J. J. Farrell]

J. J. Farrell wrote, On 01/07/07 07:31:



It is understandable the a student would be more inclined to be believe
his teacher and text book than a random collection of people on the
internet.

True, but I'd expect someone intelligent enough to become a programmer
would also do some research on who he's getting advice from. It takes
only a few seconds to discover that while Richard may not be an
embodiment of the Standard, and is not infallible, he does have a
clue. The OP also ought to be able to see that the group FAQ is pretty
accurate, and since he of course read that before posting here ...

 

[Denis Kasak]

#define SIZEOF( var ) sizeof var
Note that I used sizeof, without parentheses, not sizeof().

While I understand why you implied that parenthesis are unnecessary,
this is incorrect in this case. What would happen if someone wrote
SIZEOF(var)+1 further in the code?

 

[Harald van =?UTF-8?B?RMSzaw==?=]

While I understand why you implied that parenthesis are unnecessary,
this is incorrect in this case. What would happen if someone wrote
SIZEOF(var)+1 further in the code?

That can be avoided by

#define SIZEOF( var ) (sizeof var)

 

[Richard Heathfield]

Harald van D?k said:

Provided the type of main is one that is documented by the
implementation, the behaviour is not undefined as far as the standard
is concerned. The standard specifies that /if/ void main(void) is a
valid declaration for main, then

#include <stdio.h>
void main(void) {
puts("Hello, world!");
}

must print "Hello, world!" followed by a newline, and exit to the host
environment (though it need not exit with a successful status). If
void main(void) is /not/ documented by the implementation, though,
then the behaviour is undefined.

So the program's usefulness is restricted to those environments where
void main is documented. Since hardly any C90 implementations document
void main, and hardly any C99 implementations exist, void main can
reasonably be said to incur undefined behaviour.

 

[Old Wolf]

That can be avoided by

#define SIZEOF( var ) (sizeof var)

Huh? sizeof binds more tightly than addition anyway.
sizeof var + 1 == (sizeof var) + 1. The problem would
occur if someone wrote:
SIZEOF(var+1)
so the macro needs to be:
#define SIZEOF( var ) (sizeof (var))

(The outer brackets might be superfluous but I'm not
sure, so it doesn't hurt to have them there).

 

[Dave Vandervies]

If it wasn't illegal, nothing strange would happen even on a DS9K,
since the DS9K is a conforming hosted implementation.

It's a constraint violation, which means the DS9k will warn you BEFORE
you try to run it that you probably don't want to.

Last I checked, the DS9k's diagnostics were, if not good, at least
non-fatal.


dave

 

[Harald van =?UTF-8?B?RMSzaw==?=]

Huh? sizeof binds more tightly than addition anyway.

You're right, I missed that. And it doesn't (or shouldn't) really matter
that incorrect code such as SIZEOF(p)->mem is accepted.

 

[Mark McIntyre]

This is incorrect.

I should have added "for a hosted implementation".

The C standard requires implementations to accept main
returning int, but does not prohibit other return types either from being
allowed by implementations or from being used by programs.

This has been done to death. For a hosted implementation, your
statement is incorrect if you want to be compliant to the standard.

There's of course nothing stopping your implementation returning
whatever it likes, including all your post marked "undeliverable".
However it would then not be a C compiler.


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

 

[Harald van =?UTF-8?B?RMSzaw==?=]

I should have added "for a hosted implementation".

Then it is still incorrect.

This has been done to death. For a hosted implementation, your
statement is incorrect if you want to be compliant to the standard.

5.1.2.2.1 Program startup
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.

"Or in some other implementation-defined manner" means if the implementation
documents other types for main, and you use one of these other types, the
behaviour is not undefined. If you believe the behaviour is undefined,
please list any part of the standard that is violated by

void main(void) {}

 

[CBFalconer]

.... snip ...

"Or in some other implementation-defined manner" means if the
implementation documents other types for main, and you use one of
these other types, the behaviour is not undefined. If you believe
the behaviour is undefined, please list any part of the standard
that is violated by

void main(void) {}

You are wasting our time. Once implementation defined the action
is beyond the reach of the standard, and thus off-topic here. The
system is non-portable.

 

[Mark McIntyre]

Then it is still incorrect.

*shrug*. Feel free to posit an opinion, its a free world.

5.1.2.2.1 Program startup

<snip quote>
As I said, we've done this to death. Feel free to search the archives
for the long and tedious threads about it.

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.

"Or in some other implementation-defined manner" means if the implementation
documents other types for main, and you use one of these other types, the
behaviour is not undefined. If you believe the behaviour is undefined,

This is precisely the point thats been debated fondly for years.

please list any part of the standard that is violated by

void main(void) {}

The bit you quoted.

No more questions.
--
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]

On Mon, 02 Jul 2007 20:06:21 +0200, in comp.lang.c , Harald van D?k


The bit you quoted.

No more questions.

One more question. The standard explicitly allows an implementation
to document and support forms, in C99 5.1.2.2.1p1. (This is in
addition to (and IMHO redundant with) the general permission to
provide extensions, C99 4p6.) Why are you ignoring that explicit
statement in the standard?

 

[Harald van =?UTF-8?B?RMSzaw==?=]

*shrug*. Feel free to posit an opinion, its a free world.

I will.

<snip quote>
As I said, we've done this to death. Feel free to search the archives
for the long and tedious threads about it.

I have already read a few threads about it, and they were what convinced me
that 5.1.2.2.1 does not apply to only main's parameters in the first place.
In particular, the fact that 5.1.2.2.3 makes no sense otherwise. I have
looked further now, and also found
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n821.htm>

<<< BEGIN QUOTE>>>
Public Comment Number PC-____
Comment 1.
Category: Inconsistency
Committee Draft subsection: 5.1.2.2.1, 5.1.2.2.3
Title: Alternate forms of main() are not well-enough defined
Detailed description:

5.1.2.2.1 permits main() to have other implementation-defined types.
These types might not include a return type of int.

5.1.2.2.3p1 reads:

A return from the initial call to the /main/ function is equivalent
to calling the /exit/ function with the value returned by the /main/
function as its argument.[10] If the } that terminates the /main/ =20
function is reached, the termination status returned to the host
environment is unspecified.

The first sentence is clearly nonsense if the return type of main() is
not convertable to int.

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, 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.
<<<END QUOTE>>>

So it's not even possible to claim that 5.1.2.2.3 has accidentally been
misworded. It is worded the way it is specifically because main /is/
allowed to return other types than int.

 

[Keith Thompson]

So it's not even possible to claim that 5.1.2.2.3 has accidentally been
misworded. It is worded the way it is specifically because main /is/
allowed to return other types than int.

To be painfully clear, main is allowed to return other types than int
only if the implementation specifically allows it.

 

[Harald van =?UTF-8?B?RMSzaw==?=]

To be painfully clear, main is allowed to return other types than int
only if the implementation specifically allows it.

"It is worded the way it is specifically because the "implementation-defined
manner" of 5.1.2.2.1 does extend to alternate return types."

Do you think that is that clear enough?

 

[Keith Thompson]

"It is worded the way it is specifically because the "implementation-defined
manner" of 5.1.2.2.1 does extend to alternate return types."

Do you think that is that clear enough?

Sure.

My point was that your quoted paragraph, starting with "So it's not
even possible", could be misinterpreted to imply that void main(void)
is allowed in general. I know you didn't mean it that way, I was just
trying to forestall a possible misunderstanding. 5.1.2.2.1p1 grants
flexibility to implementations, not (directly) to programs.

 

[Richard Heathfield]

Keith Thompson said:

One more question. The standard explicitly allows an implementation
to document and support forms, in C99 5.1.2.2.1p1.

True, but it doesn't require them to.

(This is in
addition to (and IMHO redundant with) the general permission to
provide extensions, C99 4p6.)

Also true, but again, extensions are not mandatory.

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. So if J Random Newbie wants his code
to compile on my system so that I can help debug it, he'd better use
the standard entry point semantics. If he relies on my feeling
charitable enough to fix the broken entry point myself, he's running
the risk that I might be having a grumpy day. And I have a *lot* of
grumpy days. So it is in newbies' best interest to use a portable form
of main - and void main ain't portable.

Why are you ignoring that explicit statement in the standard?

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

Imagine if the law required that every hotel room have three-pin
sockets, whilst permitting them to provide two-pin adapters if they
choose. Few hotels can be bothered to provide them, though. Someone
comes along and says "I've got this revolutionary new trouserpress
design for use in hotel rooms, what do you think?" and it has a two pin
plug. So someone says "you might want to stick a three pin plug on that
thing - hotels are required to provide three pin sockets, but none of
them have to provide two pin sockets, and in fact a great many don't."

If the would-be trouserpress entrepreneur baulked at changing the plug
type, we'd think he was being stupidly proud and commercially naive,
*even though* it's legal for hotels to provide two pin adapters.
Because *in practice*, few do.

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, but I'm fairly sure it isn't in their C docs. C++ docs don't
count, obviously.

Given a choice between a construct that is guaranteed to work everywhere
and a construct that is not guaranteed to work anywhere, I remain
astounded that people still seem to think that there really is a
choice.

 

[Keith Thompson]

Keith Thompson said:

True, but it doesn't require them to.

I agree, of course.

Also true, but again, extensions are not mandatory.

I agree, of course.

[...]

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

Nevertheless, it's part of the standard.

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