From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11031 invoked by alias); 25 Apr 2018 16:22:42 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 11021 invoked by uid 89); 25 Apr 2018 16:22:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=offer X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 25 Apr 2018 16:22:41 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 93C3B30BEBCB for ; Wed, 25 Apr 2018 16:22:39 +0000 (UTC) Received: from ovpn-116-250.phx2.redhat.com (ovpn-116-250.phx2.redhat.com [10.3.116.250]) by smtp.corp.redhat.com (Postfix) with ESMTP id 247A660A97; Wed, 25 Apr 2018 16:22:38 +0000 (UTC) Message-ID: <1524673358.2961.4.camel@redhat.com> Subject: Re: [RFC] Deprecate "implicit int" for main() in C++ From: David Malcolm To: Jonathan Wakely , Andrew Haley Cc: gcc@gcc.gnu.org Date: Wed, 25 Apr 2018 16:45:00 -0000 In-Reply-To: <20180425155420.GA12873@redhat.com> References: <20180425122305.GS20930@redhat.com> <7039f928-e50b-1f75-4f71-70fda5873ab0@redhat.com> <53171c2e-1d8d-91f7-c6f7-16273e8840a6@redhat.com> <20180425140452.GT20930@redhat.com> <736ee54e-fc2a-17f0-574a-6d889fdc2336@redhat.com> <20180425155420.GA12873@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-04/txt/msg00170.txt.bz2 On Wed, 2018-04-25 at 16:54 +0100, Jonathan Wakely wrote: > On 25/04/18 16:30 +0100, Andrew Haley wrote: > > On 04/25/2018 03:04 PM, Jonathan Wakely wrote: > > > On 25/04/18 14:59 +0100, Andrew Haley wrote: > > > > On 04/25/2018 02:56 PM, Jason Merrill wrote: > > > > > The warning by default seems sufficient to me. > > > > > > > > Yes. We've been bitten by this a few times, with mysterious > > > > crashes. > > > > I'm not sure it even makes sense only to be a warning, but I > > > > guess > > > > that's up to the C++ TC. > > > > > > It's not always possible for the compiler to prove that flowing > > > off > > > the end never happens, even if the program state ensures that it > > > can't > > > (e.g. by all callers enforcing the function's preconditions > > > correctly). So making it ill-formed is deemed too draconian > > > whenever > > > this gets discussed. > > > > Sure. Having said that, the cases that bit me were those where > > control > > always flowed off the end, i.e. the function contained no return > > statement. > > I forget the "return *this;" in assignment operators embarrassingly > often. So often I've even contemplated a proposal to define flowing > off the end of an assignment operator equivalent to "return *this;" Could/should we offer a fix-it hint for such cases?