From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7455 invoked by alias); 23 Apr 2002 08:54:03 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 7406 invoked by uid 61); 23 Apr 2002 08:54:00 -0000 Date: Tue, 23 Apr 2002 01:54:00 -0000 Message-ID: <20020423085359.7405.qmail@sources.redhat.com> To: ac131313@redhat.com, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org From: rth@gcc.gnu.org Reply-To: rth@gcc.gnu.org, ac131313@redhat.com, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org Subject: Re: c/5678: Returning a void in a void func doesn't get a warning X-SW-Source: 2002-04/txt/msg01170.txt.bz2 List-Id: 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