220 24181 article Path: news.gmane.org!not-for-mail From: Andrey Semashev Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Proposal: Change the specified behavior when control flow reaches the end of non-void functions Date: Thu, 4 Feb 2016 02:19:25 +0300 Lines: 92 Approved: news@gmane.org Message-ID: References: <5115b78c-8fb4-4c72-a278-f74c636f5217@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1454541583 28169 80.91.229.3 (3 Feb 2016 23:19:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Feb 2016 23:19:43 +0000 (UTC) To: "ISO C++ Standard - Future Proposals" Original-X-From: std-proposals+bncBCXY5TXHWYJRB7MVZK2QKGQERPEI2KI@isocpp.org Thu Feb 04 00:19:28 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f71.google.com ([209.85.213.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aR6hr-0002D8-H0 for gclcip-std-proposals@m.gmane.org; Thu, 04 Feb 2016 00:19:27 +0100 Original-Received: by mail-vk0-f71.google.com with SMTP id n1sf57330066vkb.1 for ; Wed, 03 Feb 2016 15:19:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-original-sender:x-original-authentication-results :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=HeLiIy3mv9MLTNv6pA4Pwy2RVuNLBej6IWivvCy3Vfw=; b=C3TEgpXxOHI36u4eyrnm4DcrBnI+XKzt0wS7Qfuybol8DDxmyTS4PT2wWqZ/ViJqjg nRrjC2cD216SQqWf79hDHxZ+ypTt2MoQeVO/7gobYUXOQ0hncfJubgohgGBF4umN/O0A giFkQenknE4p5NU+biKppu0/HYiXYMjidXXSiboE19Vr0JqYU7DjMNvNhVmYEdH+6N+/ 2C0XEQXj8PVwUClWC1DJlat1RODReS+FzlqVtsQg8tPFZpXRnRCMliW6K4YAiPiD9W/B OQ6V8y2mG4trAd8i8quVgijBDz2S7gK188N1G4I0RBn3+lM1FjWg/zSPND3ptjbhqIEq VF9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=HeLiIy3mv9MLTNv6pA4Pwy2RVuNLBej6IWivvCy3Vfw=; b=SqkM+zV7Rn90x/bHiWFXbfItNtVyi/vVSkIU6YuAfQL99QLEkQ4G27/Hd7bD2dJoDC aA+/BWD8psa1LDGhgXpU8t2sFTnuK7D823dviIF++B4ZNo0iTBvFAvnVxuqOZsGwKr9a twsvbyY+lnplER7nKvy1RCtQV6Q3RHx/SeWGbYxbTS223jn6B8HvN2ItKTgmBF0u8jHI 3e3KLO9OhAHGqdJFuJtm9syQsVDRjIue4xIr4GX9NBsMlW7fL3CwZ+D9XxCHryqkFtjv Phq7sC/WZ2FQ0kpso5Xb2S0e785kwxDmkHGwtzxI3++sOzRrI/AVwHNcp99xMV85yehb 3USA== X-Gm-Message-State: AG10YOTtG6cD0brvhEEa6t1s/szufU63XUDgeqC6giF8y6SE1t2hCuH3F/0175z/lVhcJQ== X-Received: by 10.13.248.4 with SMTP id i4mr4135275ywf.20.1454541566448; Wed, 03 Feb 2016 15:19:26 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.61.210 with SMTP id s18ls1989704igr.32.canary; Wed, 03 Feb 2016 15:19:25 -0800 (PST) X-Received: by 10.50.8.42 with SMTP id o10mr6053801iga.59.1454541565258; Wed, 03 Feb 2016 15:19:25 -0800 (PST) Original-Received: from mail-io0-x241.google.com (mail-io0-x241.google.com. [2607:f8b0:4001:c06::241]) by mx.google.com with ESMTPS id j33si15631056ioo.30.2016.02.03.15.19.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Feb 2016 15:19:25 -0800 (PST) Received-SPF: pass (google.com: domain of andrey.semashev@gmail.com designates 2607:f8b0:4001:c06::241 as permitted sender) client-ip=2607:f8b0:4001:c06::241; Original-Received: by mail-io0-x241.google.com with SMTP id h8so3333766ioe.3 for ; Wed, 03 Feb 2016 15:19:25 -0800 (PST) X-Received: by 10.107.14.73 with SMTP id 70mr5945844ioo.31.1454541565163; Wed, 03 Feb 2016 15:19:25 -0800 (PST) Original-Received: by 10.79.37.8 with HTTP; Wed, 3 Feb 2016 15:19:25 -0800 (PST) In-Reply-To: X-Original-Sender: andrey.semashev@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of andrey.semashev@gmail.com designates 2607:f8b0:4001:c06::241 as permitted sender) smtp.mailfrom=andrey.semashev@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:24181 Archived-At: On Thu, Feb 4, 2016 at 2:01 AM, Nicol Bolas wrote: > On Wednesday, February 3, 2016 at 5:30:53 PM UTC-5, Andrey Semashev wrote: >> >> On Wed, Feb 3, 2016 at 3:15 AM, chris beck wrote: >> > In the C++14 standard, the behavior when control flow reaches the end of >> > a >> > non-void function is described as follows: >> > >> > [stmt.return][6.6.3 The `return` statement] >> > ... Flowing off the end of a function is equivalent to a return with >> > no >> > value; this results in undefined >> > behavior in a value-returning function. >> > >> > I propose that the standard should be amended as follows: >> > >> > ... Flowing off the end of a function is equivalent to a return with >> > no >> > value; if this occurs in a function whose >> > return type is not `void`, `std::terminate` is called. >> >> This would incur unnecessary overhead for functions that do not return >> normally when the compiler is unable to see that. For example: >> >> void throw_an_exception(const char* descr); >> >> int make_int(bool f) >> { >> if (f) >> return 42; >> throw_an_exception("f must be true"); >> } >> >> throw_an_exception here does not return normally but the compiler >> doesn't know that unless it has access to its body. This is a quite >> common scenario when the code is written to reduce binary size. > > Actually, we have an annotation for that: `[[noreturn]]`. Any function so > marked is expressly stated to not return control to the caller. So any code > written after such a call should never be executed, and the compiler will > know that. That means that the previously fine code is now not optimal unless modified (i.e. marked with the attribute or somehow rearranged). I wouldn't like that. >> Given that _every_ returning function has the potential to be >> augmented this way, I believe the overhead will be significant. > > That's not even remotely true. Even looking at functions that return values, > the plurality of such functions end in a return statement. And therefore, > even for the dumbest of compilers, they would need no such terminus. > > Similarly, a function that statically returns a value from all control paths > will likewise not need such a terminal statement. And compilers do that kind > of checking anyway, since they often warn about all control paths not > returning values. > > So the only cases where this would even appear would be functions where not > all static control paths return a value. Yes, and I see such functions more often than I'd like. >> Also, >> addition of a function call may affect inlineability of an otherwise >> small and simple function. > > Now that's actually a good point. Kinda. > > I highly doubt it will make a function un-inlinable which otherwise could be > inlined. The concern is more that it will make the code generated by the > inliner more complex, having to always jump around this `std::terminate` > call, rather than just flowing naturally. Even if the augmented function gets inlined, the negative effect is still there. It is merely transferred to all inline targets - the caller functions themselves become heavier and less likely to be inlined. The effect is multiplied with every augmented function that is inlined. > It could have a negative effect in tight loops. Right. -- --- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/. .