RE: Control reaches end of non-void function: why only a warning?

RE: Control reaches end of non-void function: why only a warning?

[Ryan Mansfield]

> I see.  Can you cite some document that confirms that this indeed
> complies with the standard?  I'm trying to read more about this.

"A function may have any number of return statements." section 6.8.6.4
paragraph 2

Regards,

Ryan Mansfield

RE: Control reaches end of non-void function: why only a warning?

[Ryan Mansfield]

> Not a bad idea, but in many situations, I am compiling a large
> project whose code generates many warnings, and turning them all
> into errors would be unworkable.

Use -Werror with only the specific warning option (-Wreturn-type) turned on.
Fix the warnings, remove -Werror and add back in the other warning options.

> I have patched my copy of the gcc sources to turn this warning
> into an error, but I'm still curious to see an example of when it
> is useful to knowingly allow the control flow to leave a function
> with an undefined return value.

There could be a function with a control flow that returns something useful
in one path and something meaningless in another. Or a function calls
another function that never returns (exit example).  It is more important
for a compiler to follow the language standard and accept valid source than
it is to have a compiler that tries to enforce good programming practises
and design. There are plenty of static analysis tools for checking c
programs available (lint/splint/etc).

Regards,

Ryan Mansfield

Re: Control reaches end of non-void function: why only a warning?

[Pierre Sarrazin]

Dixit Ryan Mansfield (2005-11-15 20:05):
> There could be a function with a control flow that returns something useful
> in one path and something meaningless in another. Or a function calls
> another function that never returns (exit example).  It is more important
> for a compiler to follow the language standard and accept valid source than
> it is to have a compiler that tries to enforce good programming practises
> and design.

I see.  Can you cite some document that confirms that this indeed
complies with the standard?  I'm trying to read more about this.

-- 
Pierre Sarrazin <sarrazip at sympatico dot ca>

RE: Control reaches end of non-void function: why only a warning?

[Ryan Mansfield]

If you want to be forced then turn the warning into an error with -Werror

Regards,
 
Ryan Mansfield

-----Original Message-----
From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] On
Behalf Of Pierre Sarrazin
Sent: Tuesday, November 15, 2005 1:03 PM
To: gcc-help@gcc.gnu.org
Subject: Re: Control reaches end of non-void function: why only a warning?

Dixit Oliver Kullmann (2005-11-15 16:30):
> On Tue, Nov 15, 2005 at 11:23:15AM -0500, Pierre Sarrazin wrote:
> > The following code generates the warning "control reaches end of
> > non-void function" under g++ 3.4.2:
> > 
> > int g()
> > {
> > }
> > 
> > Why is this only a warning and not an error?
> 
> Simply because this is legal code.

Interesting.  Do you happen to have a source I could go read myself?
It seems like I need a refresher course...

I asked someone to compile this code under Visual Studio .Net and
that compiler gives an error (C4716: "must return a value").

I understand that we sometimes want to code functions like this one:

int f()
{
    exit(1);
}

But that seems relatively rare, and I for one would not mind being
forced to add a dummy return statement after the call to exit().
The benefit of having a more rigorous compiler would outweigh this
slight inconvenience.

-- 
Pierre Sarrazin <sarrazip at sympatico dot ca>

Re: Control reaches end of non-void function: why only a warning?

[Pierre Sarrazin]

Dixit Ryan Mansfield (2005-11-15 13:15):
> > But that seems relatively rare, and I for one would not mind being
> > forced to add a dummy return statement after the call to exit().
> > The benefit of having a more rigorous compiler would outweigh this
> > slight inconvenience.
> 
> If you want to be forced then turn the warning into an error
> with -Werror

Not a bad idea, but in many situations, I am compiling a large
project whose code generates many warnings, and turning them all
into errors would be unworkable.

I have patched my copy of the gcc sources to turn this warning
into an error, but I'm still curious to see an example of when it
is useful to knowingly allow the control flow to leave a function
with an undefined return value.

-- 
Pierre Sarrazin <sarrazip at sympatico dot ca>

Control reaches end of non-void function: why only a warning?

[Pierre Sarrazin]

The following code generates the warning "control reaches end of
non-void function" under g++ 3.4.2:

int g()
{
}

Why is this only a warning and not an error?

-- 
Pierre Sarrazin <sarrazip at sympatico dot ca>

Re: Control reaches end of non-void function: why only a warning?

[Oliver Kullmann]

On Tue, Nov 15, 2005 at 11:23:15AM -0500, Pierre Sarrazin wrote:
> The following code generates the warning "control reaches end of
> non-void function" under g++ 3.4.2:
> 
> int g()
> {
> }
> 
> Why is this only a warning and not an error?
>

Simply because this is legal code.

Re: Control reaches end of non-void function: why only a warning?

[Pierre Sarrazin]

Dixit Oliver Kullmann (2005-11-15 16:30):
> On Tue, Nov 15, 2005 at 11:23:15AM -0500, Pierre Sarrazin wrote:
> > The following code generates the warning "control reaches end of
> > non-void function" under g++ 3.4.2:
> > 
> > int g()
> > {
> > }
> > 
> > Why is this only a warning and not an error?
> 
> Simply because this is legal code.

Interesting.  Do you happen to have a source I could go read myself?
It seems like I need a refresher course...

I asked someone to compile this code under Visual Studio .Net and
that compiler gives an error (C4716: "must return a value").

I understand that we sometimes want to code functions like this one:

int f()
{
    exit(1);
}

But that seems relatively rare, and I for one would not mind being
forced to add a dummy return statement after the call to exit().
The benefit of having a more rigorous compiler would outweigh this
slight inconvenience.

-- 
Pierre Sarrazin <sarrazip at sympatico dot ca>