What will happen if main called in side main function?

[Ravi]

void main()
{
main();
}

int main()
{
main();
}

 

[Eric Sosman]

Ravi wrote On 03/31/06 12:03,:

void main()
{
main();
}

This example is incorrect because main() returns an
`int'; it is not a `void' function. The C language does
not define what will happen when you mis-define main()
this way; however, on many implementations the effect
will be similar to the second example.

int main()
{
main();
}

This example will execute forever, provided the machine
running it has infinite resources. Less powerful machines
may be unable to run this program to completion ...

 

[Ravi]

But i have read that C can have only one main function, so is this
valid?

 

[Jordan Abel]

But i have read that C can have only one main function, so is this
valid?

But a function can call itself.

 

[Fred Kleinschmidt]

But i have read that C can have only one main function, so is this
valid?

Please always include the context of your message.

int main() {
main();
return 0;
}

There is only one instance of main() defined. It just happens to recursively
call itself.
Forever.

This, on the other hand, will eventually stop:

int num = 10;
int main() {
if ( --num > 0 ) {
main();
}
return 0;
}

 

[Flash Gordon]

Ravi wrote On 03/31/06 12:03,:


This example will execute forever, provided the machine
running it has infinite resources. Less powerful machines
may be unable to run this program to completion ...

A slightly better implementation without infinite resources might use
tail recursion optimisation and convert it in to a simple loop that only
terminates when the machine itself is terminated.

 

[Jack Klein]

void main()
{
main();
}

int main()
{
main();
}

It seems apparent from a later message you posted in the thread, you
are asking if the above is a valid program. No, it is not, you cannot
have two functions with external linkage and the same name in a
program. And you cannot have two functions with the same name in a
single translation unit, regardless of linkage.

And main() must be defined with a return type of int.

 

[swengineer001]

This example will execute forever, provided the machine
running it has infinite resources. Less powerful machines
may be unable to run this program to completion ...

I don't beleive any machine can run this to completion since the
program operates recursively forever. Also this should cause a compiler
warning about no return statement in a non void function, at least on
any compiler I have ever used.

 

[Skarmander]

I don't beleive any machine can run this to completion since the
program operates recursively forever.

I do believe the person you failed to attribute was trying to make a joke.
The standard form would be "the new X is so fast, it can execute an infinite
loop in under Y seconds".

Also this should cause a compiler warning about no return statement in a
non void function, at least on any compiler I have ever used.

GCC with -std=c99 will not issue a warning, because in C99 it's legal to
omit the return statement from main() (and *only* main()), in which case a
return value of 0 is implied.

I don't think I've yet read why this was considered a good idea; maybe to
retroactively fix all the broken code that invoked undefined behavior.

S.

 

[Keith Thompson]

GCC with -std=c99 will not issue a warning, because in C99 it's legal
to omit the return statement from main() (and *only* main()), in which
case a return value of 0 is implied.

I don't think I've yet read why this was considered a good idea; maybe
to retroactively fix all the broken code that invoked undefined
behavior.

Omitting the return statement in main() never invoked undefined
behavior (unless a recursive call to main() attempts to use the
result). At worst, it merely returns an unspecified status to the
calling environment, and the behavior of the calling environment is
outside the scope of the C standard.

I think part of the motivation for the change is that made some of the
examples in K&R retroactively valid.

The Rationale (C99RationaleV5.10.pdf) doesn't mention this change as
far as I can tell.

 

[Skarmander]

Omitting the return statement in main() never invoked undefined
behavior (unless a recursive call to main() attempts to use the
result). At worst, it merely returns an unspecified status to the
calling environment, and the behavior of the calling environment is
outside the scope of the C standard.

Yes, true. Although some calling environments will get quite upset if you
don't return a decent value from main(), the hissy fit they throw is not
undefined behavior.

I'm confusing this with declaring main as returning void, which is a lot worse.

I think part of the motivation for the change is that made some of the
examples in K&R retroactively valid.

That's... interesting. I suppose it really doesn't matter much, as it's a
minor thing. But still, a peculiar addition.

S.

 

[Richard Tobin]

[/QUOTE]

Also this should cause a compiler
warning about no return statement in a non void function, at least on
any compiler I have ever used.

Since the recursive call to main() never returns, the end of the
function cannot be reached, so a return statement would be
superfluous. Indeed, a sufficiently good compiler would warn if
you did have one!

-- Richard

 

[Keith Thompson]

Also this should cause a compiler
warning about no return statement in a non void function, at least on
any compiler I have ever used.

Since the recursive call to main() never returns, the end of the
function cannot be reached, so a return statement would be
superfluous. Indeed, a sufficiently good compiler would warn if
you did have one![/QUOTE]

A sufficiently good compiler would translate the program to a single
instruction that does the equivalent of a stack overflow.

 

[Skarmander]

A sufficiently good compiler would translate the program to a single
instruction that does the equivalent of a stack overflow.

Actually, I would be impressed if the compiler turned it into a self-jump
instead. Optimizing tail recursion is not very hard, but it generally
doesn't pay off in imperative languages, so you don't see many C compilers
doing it.

Of course, an even more efficient compiler would use the equivalent of HLT,
to save processor cycles.

S.

 

[Jordan Abel]

Actually, I would be impressed if the compiler turned it into a self-jump
instead. Optimizing tail recursion is not very hard, but it generally
doesn't pay off in imperative languages, so you don't see many C compilers
doing it.

Of course, an even more efficient compiler would use the equivalent of
HLT, to save processor cycles.

Or just have it exit after a set time. Would be really impressive on
benchmarks.

 

[swengineer001]

Also this should cause a compiler
warning about no return statement in a non void function, at least on
any compiler I have ever used.

Since the recursive call to main() never returns, the end of the
function cannot be reached, so a return statement would be
superfluous. Indeed, a sufficiently good compiler would warn if
you did have one!

-- Richard[/QUOTE]

I can't get a warning out of my compilers for the following:

int main()
{
main();
return 0;
}

However I do get warning for the original one with no return statement.
I would think that in general irt would be very hard for the compiler
to recognize that recursion is going to continue forever.

 

[Skarmander]

I can't get a warning out of my compilers for the following:

int main()
{
main();
return 0;
}

However I do get warning for the original one with no return statement.
I would think that in general irt would be very hard for the compiler
to recognize that recursion is going to continue forever.

Actually, this isn't just very hard, it's impossible in general.
http://en.wikipedia.org/wiki/Halting_problem

S.

 

[Kenneth Brody]

But i have read that C can have only one main function, so is this
valid?

Please see the other posts about how to properly reply using Google's
interface.

Here is the code from your original post:

void main()
{
main();
}

int main()
{
main();
}

If you mean to have both of these functions in one file, then this is
not valid. However, this would be true regardless of the name of the
function.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:[email protected]>