This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: What should -Wmissing-noreturn do with "int main(){exit(0);}" ?
- To: rth at cygnus dot com
- Subject: Re: What should -Wmissing-noreturn do with "int main(){exit(0);}" ?
- From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Date: Sat, 14 Aug 1999 19:14:11 -0400 (EDT)
- Cc: egcs-patches at egcs dot cygnus dot com, egcs at egcs dot cygnus dot com
> From: Richard Henderson <rth@cygnus.com>
>
> On Thu, Aug 12, 1999 at 03:02:02PM -0400, Kaveh R. Ghazi wrote:
> > > int main() { exit(0); }
> >
> > foo.c: In function `main':
> > foo.c:1: warning: function might be possible candidate for
> > attribute `noreturn'
> >
> > The diagnostic is technically correct, but perhaps it should do
> > something different here. I see two alternatives.
>
> Since the diag is correct, is there any need to change it at all?
> I don't see any reason to...
> r~
Well think about what one would need to do to silence the
warning. Is it useful to declare `main' as noreturn?
Attribute noreturn provides two benefits, a slight
optimization, and better analysis for things like unused variables.
But if I understand things correctly, these benefits are for *callers*
of the noreturn function. And the attribute must seen by the callers,
which won't happen for `main'.
So I think -Wmissing-noreturn should either ignore `main', or
if it detects `main' is noreturn it should suggest the user switch
from exitting out of `main' to issuing a return from `main'.
I.e.: "main(){exit(0);}" -> "main(){return 0;}".
I still favor having it ignore main, but either way it didn't seem
logical for the compiler to suggest declaring main as noreturn.
--Kaveh
PS: Here's what I had in mind, what do you think?
1999-08-12 Kaveh R. Ghazi <ghazi@caip.rutgers.edu>
* c-decl.c (finish_function): Ignore "main" when checking for
-Wmissing-noreturn functions.
* invoke.texi: Document it.
diff -rup orig/egcs-CVS19990811/gcc/c-decl.c egcs-CVS19990811/gcc/c-decl.c
--- orig/egcs-CVS19990811/gcc/c-decl.c Mon Aug 9 15:41:49 1999
+++ egcs-CVS19990811/gcc/c-decl.c Thu Aug 12 15:34:34 1999
@@ -6890,7 +6890,8 @@ finish_function (nested)
if (warn_missing_noreturn
&& !TREE_THIS_VOLATILE (fndecl)
&& !current_function_returns_null
- && !current_function_returns_value)
+ && !current_function_returns_value
+ && strcmp (IDENTIFIER_POINTER (DECL_NAME (fndecl)), "main"))
warning ("function might be possible candidate for attribute `noreturn'");
if (TREE_THIS_VOLATILE (fndecl) && current_function_returns_null)
diff -rup orig/egcs-CVS19990811/gcc/invoke.texi egcs-CVS19990811/gcc/invoke.texi
--- orig/egcs-CVS19990811/gcc/invoke.texi Wed Aug 11 07:42:14 1999
+++ egcs-CVS19990811/gcc/invoke.texi Thu Aug 12 15:40:09 1999
@@ -1759,8 +1760,10 @@ header files.
Warn about functions which might be candidates for attribute @code{noreturn}.
Note these are only possible candidates, not absolute ones. Care should
be taken to manually verify functions actually do not ever return before
-adding the @code{noreturn} attribute, otherwise subtle code generation
-bugs could be introduced.
+adding the @code{noreturn} attribute. Otherwise, subtle code generation
+bugs could be introduced. This warning is ignored for function @samp{main}
+because it is common practice to call @samp{exit} from there rather
+than using @code{return} statements.
@item -Wredundant-decls
Warn if anything is declared more than once in the same scope, even in
1999-08-12 Kaveh R. Ghazi <ghazi@caip.rutgers.edu>
* gcc.dg/noreturn-1.c: Test "main" as a special case.
diff -rup orig/egcs-CVS19990811/gcc/testsuite/gcc.dg/noreturn-1.c egcs-CVS19990811/gcc/testsuite/gcc.dg/noreturn-1.c
--- orig/egcs-CVS19990811/gcc/testsuite/gcc.dg/noreturn-1.c Thu May 13 12:15:13 1999
+++ egcs-CVS19990811/gcc/testsuite/gcc.dg/noreturn-1.c Thu Aug 12 15:41:07 1999
@@ -41,3 +41,9 @@ foo6(void)
{
return;
} /* { dg-bogus "warning:" "this function should not get any warnings" } */
+
+int
+main()
+{
+ exit(0);
+} /* { dg-bogus "warning:" "this function should not get any warnings" } */
--
Kaveh R. Ghazi Engagement Manager / Project Services
ghazi@caip.rutgers.edu Qwest Internet Solutions