main without a return statement

Discussion in 'C Programming' started by axr0284, Nov 7, 2007.

  1. axr0284

    axr0284 Guest

    Hi,
    I have a main function as follows:
    int main(void)
    {
    while(TRUE) { ... }

    return TRUE;
    }

    my question is since the return TRUE is never reached, can I remove
    it. The compiler (VDSP 5.0) is complaining about the non reachability
    in this case. When I remove it, it compiles without warning. Thanks,
    Amish
     
    axr0284, Nov 7, 2007
    #1
    1. Advertising

  2. axr0284

    Eric Sosman Guest

    axr0284 wrote On 11/07/07 10:27,:
    > Hi,
    > I have a main function as follows:
    > int main(void)
    > {
    > while(TRUE) { ... }
    >
    > return TRUE;
    > }
    >
    > my question is since the return TRUE is never reached, can I remove
    > it. The compiler (VDSP 5.0) is complaining about the non reachability
    > in this case. When I remove it, it compiles without warning. Thanks,


    Yes, you can remove it.

    (Incidentally, TRUE looks like a strange value to
    return from main(). The only fully-portable return
    values are EXIT_SUCCESS, EXIT_FAILURE, and zero.)

    --
     
    Eric Sosman, Nov 7, 2007
    #2
    1. Advertising

  3. axr0284

    axr0284 Guest

    On Nov 7, 11:23 am, Eric Sosman <> wrote:
    > axr0284 wrote On 11/07/07 10:27,:
    >
    > > Hi,
    > > I have a main function as follows:
    > > int main(void)
    > > {
    > > while(TRUE) { ... }

    >
    > > return TRUE;
    > > }

    >
    > > my question is since the return TRUE is never reached, can I remove
    > > it. The compiler (VDSP 5.0) is complaining about the non reachability
    > > in this case. When I remove it, it compiles without warning. Thanks,

    >
    > Yes, you can remove it.
    >
    > (Incidentally, TRUE looks like a strange value to
    > return from main(). The only fully-portable return
    > values are EXIT_SUCCESS, EXIT_FAILURE, and zero.)
    >
    > --
    >


    Forgot to added the #define TRUE 1
    Thanks for the answer
     
    axr0284, Nov 7, 2007
    #3
  4. axr0284 wrote:
    > On Nov 7, 11:23 am, Eric Sosman <> wrote:
    >> axr0284 wrote On 11/07/07 10:27,:
    >>
    >>> Hi,
    >>> I have a main function as follows:
    >>> int main(void)
    >>> {
    >>> while(TRUE) { ... }
    >>> return TRUE;
    >>> }
    >>> my question is since the return TRUE is never reached, can I remove
    >>> it. The compiler (VDSP 5.0) is complaining about the non reachability
    >>> in this case. When I remove it, it compiles without warning. Thanks,

    >> Yes, you can remove it.
    >>
    >> (Incidentally, TRUE looks like a strange value to
    >> return from main(). The only fully-portable return
    >> values are EXIT_SUCCESS, EXIT_FAILURE, and zero.)
    >>
    >> --
    >>

    >
    > Forgot to added the #define TRUE 1
    > Thanks for the answer
    >


    1 is not among the standard return values from main. The three with
    mentioned in the standard are, as Eric Sosman wrote, 0, EXIT_SUCCESS,
    and EXIT_FAILURE.
     
    Martin Ambuhl, Nov 7, 2007
    #4
  5. axr0284

    Guest

    axr0284 wrote:
    > On Nov 7, 11:23 am, Eric Sosman <> wrote:

    ....
    > > return from main(). The only fully-portable return
    > > values are EXIT_SUCCESS, EXIT_FAILURE, and zero.)
    > >
    > > --
    > >

    >
    > Forgot to added the #define TRUE 1
    > Thanks for the answer


    Keep in mind that the only fully-portable return values are the ones
    Eric listed above, and none of them are guaranteed to be equal to 1.
     
    , Nov 7, 2007
    #5
  6. axr0284 wrote:
    > On Nov 7, 11:23 am, Eric Sosman <> wrote:
    >> axr0284 wrote On 11/07/07 10:27,:
    >>> int main(void)
    >>> {
    >>> while(TRUE) { ... }
    >>> return TRUE;
    >>> }

    >> (Incidentally, TRUE looks like a strange value to
    >> return from main(). The only fully-portable return
    >> values are EXIT_SUCCESS, EXIT_FAILURE, and zero.)
    >>

    >
    > Forgot to added the #define TRUE 1
    > Thanks for the answer


    Please don't quote signatures.

    Note that on a great many systems, returning 1 will indicate program
    failure. If you have no compelling reason not to, only return
    EXIT_SUCCESS, EXIT_FAILURE, or zero. Zero is equivalent to EXIT_SUCCESS.

    --
    Philip Potter pgp <at> doc.ic.ac.uk
     
    Philip Potter, Nov 7, 2007
    #6
  7. On Wed, 07 Nov 2007 15:27:07 -0000, axr0284 <> wrote:

    >Hi,
    > I have a main function as follows:
    >int main(void)
    >{
    > while(TRUE) { ... }
    >
    >return TRUE;
    >}
    >
    >my question is since the return TRUE is never reached, can I remove
    >it. The compiler (VDSP 5.0) is complaining about the non reachability
    >in this case. When I remove it, it compiles without warning. Thanks,


    Is there no break statement in the while loop? If that return
    statement cannot be reached, how does main ever terminate? Does main
    terminate or is your code for an embedded system?

    TRUE is obviously non-zero and probably 1. It is not a portable value
    to pass back to the operating system. At the point main does
    terminate (if any), what value do you pass back to the operating
    system.


    Remove del for email
     
    Barry Schwarz, Nov 8, 2007
    #7
  8. "axr0284" <> a écrit dans le message de news:
    ...
    > On Nov 7, 11:23 am, Eric Sosman <> wrote:
    >> axr0284 wrote On 11/07/07 10:27,:
    >>
    >> > Hi,
    >> > I have a main function as follows:
    >> > int main(void)
    >> > {
    >> > while(TRUE) { ... }

    >>
    >> > return TRUE;
    >> > }

    >>
    >> > my question is since the return TRUE is never reached, can I remove
    >> > it. The compiler (VDSP 5.0) is complaining about the non reachability
    >> > in this case. When I remove it, it compiles without warning. Thanks,

    >>
    >> Yes, you can remove it.
    >>
    >> (Incidentally, TRUE looks like a strange value to
    >> return from main(). The only fully-portable return
    >> values are EXIT_SUCCESS, EXIT_FAILURE, and zero.)
    >>
    >> --
    >>

    >
    > Forgot to added the #define TRUE 1
    > Thanks for the answer


    TRUE is not really needed, nor welcome, the classic idiom for this kind of
    loop is

    for (;;) { ... }

    --
    Chqrlie.
     
    Charlie Gordon, Nov 8, 2007
    #8
  9. "Charlie Gordon" <> writes:
    [...]
    > TRUE is not really needed, nor welcome, the classic idiom for this kind of
    > loop is
    >
    > for (;;) { ... }


    Or:

    while (1) { ... }

    (Let's not have a lengthy debate about which one is clearer, better,
    and/or more idiomatic, ok?)

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Looking for software development work in the San Diego area.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Nov 9, 2007
    #9
  10. Keith Thompson said:

    > "Charlie Gordon" <> writes:
    > [...]
    >> TRUE is not really needed, nor welcome, the classic idiom for this kind
    >> of loop is
    >>
    >> for (;;) { ... }

    >
    > Or:
    >
    > while (1) { ... }
    >
    > (Let's not have a lengthy debate about which one is clearer, better,
    > and/or more idiomatic, ok?)


    We can make it a very short debate. My vote is "neither".

    (And yes, that test is still going.)

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -http://www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Nov 9, 2007
    #10
  11. "Richard Heathfield" <> a écrit dans le message de news:
    ...
    > Keith Thompson said:
    >
    >> "Charlie Gordon" <> writes:
    >> [...]
    >>> TRUE is not really needed, nor welcome, the classic idiom for this kind
    >>> of loop is
    >>>
    >>> for (;;) { ... }

    >>
    >> Or:
    >>
    >> while (1) { ... }
    >>
    >> (Let's not have a lengthy debate about which one is clearer, better,
    >> and/or more idiomatic, ok?)


    Funny, I did not receive Keith's post. Let's feed the troll:

    ``for (;;) { ... }'' is unmistakably a testless loop (which you might find
    tastless too ;-)

    ``while (1) { ... }'' can be confused with ``while (l) { ... }'', especially
    on Usenet. I would use neither of these.

    > We can make it a very short debate. My vote is "neither".


    Thank you for your constructive criticism, do you mean you use neither of
    them, or both, or one but want to keep you preference to yourself ?

    --
    Chqrlie.
     
    Charlie Gordon, Nov 9, 2007
    #11
  12. Charlie Gordon wrote:
    > "Richard Heathfield" <> a écrit dans le message de news:
    >> Keith Thompson said:
    >>> "Charlie Gordon" <> writes:
    >>>> TRUE is not really needed, nor welcome, the classic idiom for this kind
    >>>> of loop is
    >>>>
    >>>> for (;;) { ... }
    >>> Or:
    >>>
    >>> while (1) { ... }
    >>>
    >>> (Let's not have a lengthy debate about which one is clearer, better,
    >>> and/or more idiomatic, ok?)

    >
    > Funny, I did not receive Keith's post. Let's feed the troll:
    >
    > ``for (;;) { ... }'' is unmistakably a testless loop (which you might find
    > tastless too ;-)
    >
    > ``while (1) { ... }'' can be confused with ``while (l) { ... }'', especially
    > on Usenet. I would use neither of these.


    forever:

    /* ... */

    goto forever;

    is clear, concise, doesn't confuse you with a construct which is
    normally used for finite loops, and is self-documenting. I can't see
    anything at all wrong with it.

    Phil

    --
    Philip Potter pgp <at> doc.ic.ac.uk
     
    Philip Potter, Nov 9, 2007
    #12
  13. Charlie Gordon said:

    <snip>

    > Funny, I did not receive Keith's post. Let's feed the troll:
    >
    > ``for (;;) { ... }'' is unmistakably a testless loop (which you might
    > find tastless too ;-)
    >
    > ``while (1) { ... }'' can be confused with ``while (l) { ... }'',


    That took me a while to spot. Or possibly a for.

    > especially
    > on Usenet. I would use neither of these.
    >
    >> We can make it a very short debate. My vote is "neither".

    >
    > Thank you for your constructive criticism,


    You're welcome.

    > do you mean you use neither of
    > them, or both, or one but want to keep you preference to yourself ?


    YES! :)

    Actually, my preference is well-documented here in comp.lang.c, and it's
    simply stated: if the program ever terminates whilst power is still
    available to keep it running, the "infinite loop" construct is a lie that
    should not be told. If it truly does not terminate, though, then my choice
    would be the for(;;) version, since compilers are less likely to offer a
    warning about a constant condition.

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -http://www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Nov 9, 2007
    #13
  14. "Richard Heathfield" <> a écrit dans le message de news:
    ...
    > Charlie Gordon said:
    >
    > <snip>
    >
    >> Funny, I did not receive Keith's post. Let's feed the troll:
    >>
    >> ``for (;;) { ... }'' is unmistakably a testless loop (which you might
    >> find tasteless too ;-)
    >>
    >> ``while (1) { ... }'' can be confused with ``while (l) { ... }'',

    >
    > That took me a while to spot. Or possibly a for.
    >
    >> especially
    >> on Usenet. I would use neither of these.
    >>
    >>> We can make it a very short debate. My vote is "neither".

    >>
    >> Thank you for your constructive criticism,

    >
    > You're welcome.
    >
    >> do you mean you use neither of
    >> them, or both, or one but want to keep you preference to yourself ?

    >
    > YES! :)
    >
    > Actually, my preference is well-documented here in comp.lang.c, and it's
    > simply stated: if the program ever terminates whilst power is still
    > available to keep it running, the "infinite loop" construct is a lie that
    > should not be told. If it truly does not terminate, though, then my choice
    > would be the for(;;) version, since compilers are less likely to offer a
    > warning about a constant condition.


    Yes!
    I did not call those endless loops, but testless ;-)
    And as such, there should be *no* test. hence ``for (;;) { ... }''.

    --
    Chqrlie.
     
    Charlie Gordon, Nov 9, 2007
    #14
  15. "Philip Potter" <> a écrit dans le message de news:
    fh1kev$416$...
    > Charlie Gordon wrote:
    >> "Richard Heathfield" <> a écrit dans le message de
    >> news:
    >>> Keith Thompson said:
    >>>> "Charlie Gordon" <> writes:
    >>>>> TRUE is not really needed, nor welcome, the classic idiom for this
    >>>>> kind
    >>>>> of loop is
    >>>>>
    >>>>> for (;;) { ... }
    >>>> Or:
    >>>>
    >>>> while (1) { ... }
    >>>>
    >>>> (Let's not have a lengthy debate about which one is clearer, better,
    >>>> and/or more idiomatic, ok?)

    >>
    >> Funny, I did not receive Keith's post. Let's feed the troll:
    >>
    >> ``for (;;) { ... }'' is unmistakably a testless loop (which you might
    >> find tastless too ;-)
    >>
    >> ``while (1) { ... }'' can be confused with ``while (l) { ... }'',
    >> especially on Usenet. I would use neither of these.

    >
    > forever:
    >
    > /* ... */
    >
    > goto forever;
    >
    > is clear, concise, doesn't confuse you with a construct which is normally
    > used for finite loops, and is self-documenting. I can't see anything at
    > all wrong with it.


    Surely you're joking Mr Potter !

    You cannot have more than one of these in a given function, you cannot
    'break' from them or 'continue'...

    --
    Chqrlie.
     
    Charlie Gordon, Nov 9, 2007
    #15
  16. Charlie Gordon wrote:
    > "Philip Potter" <> a écrit dans le message de news:
    >> goto forever;
    >>
    >> is clear, concise, doesn't confuse you with a construct which is normally
    >> used for finite loops, and is self-documenting. I can't see anything at
    >> all wrong with it.

    >
    > Surely you're joking Mr Potter !


    "Satiring" may be closer to the mark :)

    > You cannot have more than one of these in a given function, you cannot
    > 'break' from them or 'continue'...


    Why would you ever need more than one loop forever in a given function?
    If one loops forever, then the other is unreachable.

    "break" merely hides the break condition somewhere else than where you
    expect to find it. If you need a loop to terminate, don't use a loop
    forever construct.

    And "continue" is trivial: 'goto forever;'

    --
    Philip Potter pgp <at> doc.ic.ac.uk
     
    Philip Potter, Nov 9, 2007
    #16
  17. "Philip Potter" <> a écrit dans le message de news:
    fh1qdr$phb$...
    > Charlie Gordon wrote:
    >> "Philip Potter" <> a écrit dans le message de news:
    >>> goto forever;
    >>>
    >>> is clear, concise, doesn't confuse you with a construct which is
    >>> normally used for finite loops, and is self-documenting. I can't see
    >>> anything at all wrong with it.

    >>
    >> Surely you're joking Mr Potter !

    >
    > "Satiring" may be closer to the mark :)


    Of course, so was I.

    >> You cannot have more than one of these in a given function, you cannot
    >> 'break' from them or 'continue'...

    >
    > Why would you ever need more than one loop forever in a given function? If
    > one loops forever, then the other is unreachable.


    some forever loops are merely loops for which the break conditions cannot be
    conveniently moved to the top. Adding extra booleans with silly names such
    as ``done'' or ``working'' is not too elegant.

    > "break" merely hides the break condition somewhere else than where you
    > expect to find it. If you need a loop to terminate, don't use a loop
    > forever construct.


    I disagree with this: you could test for abnormal conditions in different
    parts of your main daemon loop, and break appropriately and conveniently.
    Adding extra logic for this would be cumbersome.

    > And "continue" is trivial: 'goto forever;'


    sounds more like goto fever ;-)

    --
    Chqrlie.
     
    Charlie Gordon, Nov 9, 2007
    #17
  18. axr0284

    CBFalconer Guest

    Richard Heathfield wrote:
    > Charlie Gordon said:
    >
    > <snip>
    >
    >> Funny, I did not receive Keith's post. Let's feed the troll:
    >>
    >> ``for (;;) { ... }'' is unmistakably a testless loop (which you
    >> might find tastless too ;-)
    >>
    >> ``while (1) { ... }'' can be confused with
    >> ``while (l) { ... }'',

    >
    > That took me a while to spot. Or possibly a for.


    Do you mean you have found some difference between the two
    statements? I confess I do not see any such. Unless he is using
    one and ell, which have the same resolution on my screen.

    Aha - I tried it on a hex editor.

    --
    Chuck F (cbfalconer at maineline dot net)
    <http://cbfalconer.home.att.net>
    Try the download section.



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Nov 9, 2007
    #18
  19. axr0284

    Guest

    Charlie Gordon wrote:
    > "Philip Potter" <> a écrit dans le message de news:
    > fh1qdr$phb$...
    > > Charlie Gordon wrote:
    > >> "Philip Potter" <> a écrit dans le message de news:

    ....
    > > Why would you ever need more than one loop forever in a given function? If
    > > one loops forever, then the other is unreachable.

    >
    > some forever loops are merely loops for which the break conditions cannot be
    > conveniently moved to the top. Adding extra booleans with silly names such
    > as ``done'' or ``working'' is not too elegant.


    I agree; there's almost always a more elegant way to put the loop
    condition where it belongs, in the loop construct. One technique that
    often works in otherwise intractable cases is to move some or all of
    the loop into a separate subroutine whose return value is a key
    component of the loop condition. However, even if you are reduced to
    having to use booleans, that still creates code that is easier to
    understand than code which hides the main method of exiting the loop
    inside the loop.

    > > "break" merely hides the break condition somewhere else than where you
    > > expect to find it. If you need a loop to terminate, don't use a loop
    > > forever construct.

    >
    > I disagree with this: you could test for abnormal conditions in different
    > parts of your main daemon loop, and break appropriately and conveniently.
    > Adding extra logic for this would be cumbersome.


    I'm not opposed to breaking out of a loop for unusual cases, but the
    normal way to exit a loop should involve the loop construct itself;
    anything else makes it harder to understand what the loop is actually
    doing.
     
    , Nov 9, 2007
    #19
  20. "CBFalconer" <> a écrit dans le message de news:
    ...
    > Richard Heathfield wrote:
    >> Charlie Gordon said:
    >>
    >> <snip>
    >>
    >>> Funny, I did not receive Keith's post. Let's feed the troll:
    >>>
    >>> ``for (;;) { ... }'' is unmistakably a testless loop (which you
    >>> might find tastless too ;-)
    >>>
    >>> ``while (1) { ... }'' can be confused with
    >>> ``while (l) { ... }'',

    >>
    >> That took me a while to spot. Or possibly a for.

    >
    > Do you mean you have found some difference between the two
    > statements? I confess I do not see any such. Unless he is using
    > one and ell, which have the same resolution on my screen.
    >
    > Aha - I tried it on a hex editor.


    QED

    --
    Chqrlie.
     
    Charlie Gordon, Nov 10, 2007
    #20
    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. wl
    Replies:
    2
    Views:
    587
    Dimitri Maziuk
    Mar 5, 2004
  2. Seong-Kook Shin
    Replies:
    1
    Views:
    495
    Richard Bos
    Jun 18, 2004
  3. lovecreatesbeauty
    Replies:
    8
    Views:
    585
    Kevin D. Quitt
    Mar 15, 2005
  4. Army1987

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

    Army1987, Mar 29, 2007, in forum: C Programming
    Replies:
    37
    Views:
    1,453
    Daniel Rudy
    Apr 3, 2007
  5. Replies:
    5
    Views:
    639
Loading...

Share This Page