main() called inside main()

Discussion in 'C Programming' started by rahulsinner@gmail.com, May 4, 2006.

  1. Guest

    hi,

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

    wat does the standard says about the above code snippet?
     
    , May 4, 2006
    #1
    1. Advertising

  2. Prasad Guest

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

    Thanks.
     
    Prasad, May 4, 2006
    #2
    1. Advertising

  3. 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) <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.
     
    Keith Thompson, May 4, 2006
    #3
  4. Flash Gordon Guest

    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
     
    Flash Gordon, May 4, 2006
    #4
  5. Jordan Abel Guest

    On 2006-05-04, <> 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.
     
    Jordan Abel, May 4, 2006
    #5
  6. Default User Guest

    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.
     
    Default User, May 4, 2006
    #6
  7. Jordan Abel <> writes:
    > On 2006-05-04, <> 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) <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.
     
    Keith Thompson, May 4, 2006
    #7
  8. Jordan Abel Guest

    On 2006-05-04, Keith Thompson <> wrote:
    > Jordan Abel <> writes:
    >> On 2006-05-04, <> 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.
     
    Jordan Abel, May 4, 2006
    #8
  9. Ian Collins Guest

    Jordan Abel wrote:
    > On 2006-05-04, Keith Thompson <> wrote:
    >
    >>Jordan Abel <> writes:
    >>
    >>>On 2006-05-04, <> 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.
     
    Ian Collins, May 4, 2006
    #9
  10. Jordan Abel Guest

    On 2006-05-04, Ian Collins <> wrote:
    > Jordan Abel wrote:
    >> On 2006-05-04, Keith Thompson <> wrote:
    >>
    >>>Jordan Abel <> writes:
    >>>
    >>>>On 2006-05-04, <> 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.
     
    Jordan Abel, May 4, 2006
    #10
  11. Ian Collins Guest

    Jordan Abel wrote:
    > On 2006-05-04, Ian Collins <> wrote:
    >
    >>Jordan Abel wrote:
    >>
    >>>On 2006-05-04, Keith Thompson <> 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.
     
    Ian Collins, May 4, 2006
    #11
  12. Jordan Abel Guest

    On 2006-05-04, Ian Collins <> wrote:
    > Jordan Abel wrote:
    >> On 2006-05-04, Ian Collins <> wrote:
    >>
    >>>Jordan Abel wrote:
    >>>
    >>>>On 2006-05-04, Keith Thompson <> 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.
     
    Jordan Abel, May 5, 2006
    #12
  13. Robert Smith Guest

    <> wrote in message
    news:...
    > 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
     
    Robert Smith, May 5, 2006
    #13
  14. CBFalconer Guest

    Robert Smith wrote:
    > <> 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/>
     
    CBFalconer, May 5, 2006
    #14
  15. 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)
     
    Richard Heathfield, May 7, 2006
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Apricot
    Replies:
    4
    Views:
    532
    velthuijsen
    Apr 16, 2004
  2. Ravi
    Replies:
    17
    Views:
    929
    Kenneth Brody
    Apr 1, 2006
  3. Weng Tianxiang
    Replies:
    6
    Views:
    593
    glen herrmannsfeldt
    Sep 12, 2007
  4. S_K
    Replies:
    6
    Views:
    1,188
    Robert Dunlop
    Nov 8, 2007
  5. Jimmy Hartzell
    Replies:
    0
    Views:
    421
    Jimmy Hartzell
    May 19, 2008
Loading...

Share This Page