main without a return statement

[axr0284]

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

 

[Eric Sosman]

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

 

[axr0284]

axr0284 wrote On 11/07/07 10:27,:




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

 

[Martin Ambuhl]

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.

 

[jameskuyper]

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.

 

[Philip Potter]

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.

 

[Barry Schwarz]

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

 

[Charlie Gordon]

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 (; { ... }

 

[Keith Thompson]

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

 

[Richard Heathfield]

Keith Thompson said:

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

 

[Charlie Gordon]

Keith Thompson said:

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 ?

 

[Philip Potter]

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

 

[Richard Heathfield]

Charlie Gordon said:

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.


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.

 

[Charlie Gordon]

Charlie Gordon said:



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


You're welcome.


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 (; { ... }''.

 

[Charlie Gordon]

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

 

[Philip Potter]

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

 

[Charlie Gordon]

"Satiring" may be closer to the mark

Of course, so was I.

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

 

[CBFalconer]

Charlie Gordon said:



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.

 

[jameskuyper]

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.

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.

 

[Charlie Gordon]

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