main() called inside main()

[rahulsinner]

hi,

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

wat does the standard says about the above code snippet?

[Prasad]

Nothing,
This will result in infinite loop. Eating a lot of processor time, and
you may see your PC hang.

Thanks.

[Keith Thompson]

ra*********@gmail.com writes:

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

wat does the standard says about the above code snippet?

It's a recursive call to main, which is perfectly legal.

Like any infinite recursive call, it will either exceed some system
resource limit, or it will run indefinitely (if the compiler optimizes
tail recursion).

The "return 0;" will never be reached.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Flash Gordon]

Prasad wrote:

Nothing,
Wrong, the standard says what will happen if you call main recursively.
This will result in infinite loop. Eating a lot of processor time, and
you may see your PC hang.
Or the compiler could fail to optimise it in which case the loop will
not be infinite since you will run out of stack space. Or process limits
might prevent it from eating a log of CPU time. Or the compiler might
optimise it to some form of sleep forever instruction.
Thanks.

Please provide context when replying, Google is *not* Usenet. See the
Google section at http://clc-wiki.net/wiki/Intro_to_clc and the sites it
links to.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php

[Jordan Abel]

On 2006-05-04, ra*********@gmail.com <ra*********@gmail.com> wrote:

hi,

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

wat does the standard says about the above code snippet?

It may run forever, or crash. I don't know if a stack overflow (i.e.
running out of memory in a way that cannot be recovered from) is
considered undefined behavior.

[Default User]

Prasad wrote:

Nothing,
This will result in infinite loop. Eating a lot of processor time, and
you may see your PC hang.

See below.
Brian
--
Please quote enough of the previous message for context. To do so from
Google, click "show options" and use the Reply shown in the expanded
header.

[Keith Thompson]

Jordan Abel <ra*******@gmail.com> writes:

On 2006-05-04, ra*********@gmail.com <ra*********@gmail.com> wrote:

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

wat does the standard says about the above code snippet?

It may run forever, or crash. I don't know if a stack overflow (i.e.
running out of memory in a way that cannot be recovered from) is
considered undefined behavior.

I'm fairly sure it is, since the standard doesn't define what the
behavior is.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Jordan Abel]

On 2006-05-04, Keith Thompson <ks***@mib.org> wrote:

Jordan Abel <ra*******@gmail.com> writes:

On 2006-05-04, ra*********@gmail.com <ra*********@gmail.com> wrote:

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

wat does the standard says about the above code snippet?

It may run forever, or crash. I don't know if a stack overflow (i.e.
running out of memory in a way that cannot be recovered from) is
considered undefined behavior.

I'm fairly sure it is, since the standard doesn't define what the
behavior is.

I guess i'm used to thinking of UB as something that can at least in
principle be identified by careful examination of the source. that is,
for any given set of inputs ["inputs" including returns from library
functions whose outputs are not fully determined by their inputs - e.g.
malloc returning null or not], a program either does cause UB or
doesn't. stack overflows are a big hole in this, and i think they're
unique.

[Ian Collins]

Jordan Abel wrote:

On 2006-05-04, Keith Thompson <ks***@mib.org> wrote:

Jordan Abel <ra*******@gmail.com> writes:

On 2006-05-04, ra*********@gmail.com <ra*********@gmail.com> wrote:

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

wat does the standard says about the above code snippet?

It may run forever, or crash. I don't know if a stack overflow (i.e.
running out of memory in a way that cannot be recovered from) is
considered undefined behavior.

I'm fairly sure it is, since the standard doesn't define what the
behavior is.

I guess i'm used to thinking of UB as something that can at least in
principle be identified by careful examination of the source. that is,
for any given set of inputs ["inputs" including returns from library
functions whose outputs are not fully determined by their inputs - e.g.
malloc returning null or not], a program either does cause UB or
doesn't. stack overflows are a big hole in this, and i think they're
unique.

Are they UB and are they unique?

I'd categorise them as an environment constraint violation, another
example would be opening more files then the operating environment permits.

Stack size is environment specific, so a well formed program that
operates correctly in one environment might violate the constraints of
another.

--
Ian Collins.

[Jordan Abel]

On 2006-05-04, Ian Collins <ia******@hotmail.com> wrote:

Jordan Abel wrote:

On 2006-05-04, Keith Thompson <ks***@mib.org> wrote:

Jordan Abel <ra*******@gmail.com> writes:

On 2006-05-04, ra*********@gmail.com <ra*********@gmail.com> wrote:

>int main(void)
>{
> main();
> return 0;
>}
>
>wat does the standard says about the above code snippet?

It may run forever, or crash. I don't know if a stack overflow (i.e.
running out of memory in a way that cannot be recovered from) is
considered undefined behavior.

I'm fairly sure it is, since the standard doesn't define what the
behavior is.

I guess i'm used to thinking of UB as something that can at least in
principle be identified by careful examination of the source. that is,
for any given set of inputs ["inputs" including returns from library
functions whose outputs are not fully determined by their inputs - e.g.
malloc returning null or not], a program either does cause UB or
doesn't. stack overflows are a big hole in this, and i think they're
unique.

Are they UB and are they unique?

I'd categorise them as an environment constraint violation, another
example would be opening more files then the operating environment permits.

That doesn't cause UB. It causes fopen to return a null pointer.
Stack size is environment specific, so a well formed program that
operates correctly in one environment might violate the constraints of
another.

Which is unique among ALL things which cause UB.

[Ian Collins]

Jordan Abel wrote:

On 2006-05-04, Ian Collins <ia******@hotmail.com> wrote:

Jordan Abel wrote:

On 2006-05-04, Keith Thompson <ks***@mib.org> wrote:

I'm fairly sure it is, since the standard doesn't define what the
behavior is.
I guess i'm used to thinking of UB as something that can at least in
principle be identified by careful examination of the source. that is,
for any given set of inputs ["inputs" including returns from library
functions whose outputs are not fully determined by their inputs - e.g.
malloc returning null or not], a program either does cause UB or
doesn't. stack overflows are a big hole in this, and i think they're
unique.
Are they UB and are they unique?

I'd categorise them as an environment constraint violation, another
example would be opening more files then the operating environment permits.

That doesn't cause UB. It causes fopen to return a null pointer.

OK.

Stack size is environment specific, so a well formed program that
operates correctly in one environment might violate the constraints of
another.

Which is unique among ALL things which cause UB.

How about dereferencing an odd address on a target the doesn't support this?

--
Ian Collins.

[Jordan Abel]

On 2006-05-04, Ian Collins <ia******@hotmail.com> wrote:

Jordan Abel wrote:

On 2006-05-04, Ian Collins <ia******@hotmail.com> wrote:

Jordan Abel wrote:

On 2006-05-04, Keith Thompson <ks***@mib.org> wrote:
>
>I'm fairly sure it is, since the standard doesn't define what the
>behavior is.
I guess i'm used to thinking of UB as something that can at least in
principle be identified by careful examination of the source. that is,
for any given set of inputs ["inputs" including returns from library
functions whose outputs are not fully determined by their inputs - e.g.
malloc returning null or not], a program either does cause UB or
doesn't. stack overflows are a big hole in this, and i think they're
unique.

Are they UB and are they unique?

I'd categorise them as an environment constraint violation, another
example would be opening more files then the operating environment permits.

That doesn't cause UB. It causes fopen to return a null pointer.

OK.

Stack size is environment specific, so a well formed program that
operates correctly in one environment might violate the constraints of
another.

Which is unique among ALL things which cause UB.

How about dereferencing an odd address on a target the doesn't support
this?

Things that would cause this to happen ALWAYS cause UB. UB doesn't
always mean something bad happens.

[Robert Smith]

<ra*********@gmail.com> wrote in message
news:11**********************@v46g2000cwv.googlegr oups.com...

hi,

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

wat does the standard says about the above code snippet?

This is allowed in C and performs the obvious useless recursive call. It is
forbidden however in the C++ standard

[CBFalconer]

Robert Smith wrote:

<ra*********@gmail.com> wrote in message

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

wat does the standard says about the above code snippet?

This is allowed in C and performs the obvious useless recursive
call. It is forbidden however in the C++ standard

In C it is of primary use in writing obfuscated code. C++ needs no
assistance in this respect, and thus can dispense with the
capability.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

[Richard Heathfield]

ra*********@gmail.com said:

hi,

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

wat does the standard says about the above code snippet?

Not a lot.

It's legal C, but eventually you'll run out of something or other, depending
on what system you are using.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)