c/5678: Returning a void in a void func doesn't get a warning

c/5678: Returning a void in a void func doesn't get a warning

[ac131313]

>Number:         5678
>Category:       c
>Synopsis:       Returning a void in a void func doesn't get a warning
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Feb 12 22:26:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     Andrew Cagney
>Release:        unknown-1.0
>Organization:
>Environment:
N/A
>Description:
[added gcc]


Checked in as obvious.  Wonder why GCC didn't warn about this.  Should
we add some more -Wxxx flags?


I was looking at it and wondering the same thing - I know I've fixed botched return type warnings.  Trying:

static int f1 (void) { return 1; }
static void f2 (void) { return 1; }
static void f3 (void) { return; }
static int f4 (void) { return; }

I get:

-Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith -Wuninitialized -Werror
doublest.c: In function `f2':
doublest.c:741: warning: `return' with a value, in function returning void
doublest.c: In function `f4':
doublest.c:743: warning: `return' with no value, in function returning non-void

so ok so far.  Hmm, I think this tells the story:

static void f5 (int a) { return f3(); }

Returning the result from a function that returns void (f3()) doesn't attract a warning.

Bug or feature?

    Andrew

--

Further discussion concluded it wasn't compliant with ISO C or C99.  It might fall into GCC feature category.  I struggle to see advantages in this.
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:

Re: c/5678: Returning a void in a void func doesn't get a warning

[rth]

Synopsis: Returning a void in a void func doesn't get a warning

State-Changed-From-To: open->closed
State-Changed-By: rth
State-Changed-When: Tue Apr 23 01:53:57 2002
State-Changed-Why:
    It does fall into gcc feature category.  Using -ansi -pedantic
    does indeed give the warning you wanted.
    
    As for the advantages... well, there aren't many any more.  Once upon a time we only did tail recursion elimination on
    return statements.  One can also make up post-hoc arguments 
    concerning compatibility with c++, which explicitly allows 
    this stuff to make template use easier.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5678