220 24159 <20160203120250.4907089.26832.4263@gmail.com> article Path: news.gmane.org!not-for-mail From: Tony V E 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: Wed, 03 Feb 2016 07:02:50 -0500 Lines: 138 Approved: news@gmane.org Message-ID: <20160203120250.4907089.26832.4263@gmail.com> 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/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1454500984 19145 80.91.229.3 (3 Feb 2016 12:03:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Feb 2016 12:03:04 +0000 (UTC) To: chris beck , ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCUZ5QWKNQIO3WGHWUCRUBAW5D7HE@isocpp.org Wed Feb 03 13:02:57 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pf0-f197.google.com ([209.85.192.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aQw99-0004kZ-Fh for gclcip-std-proposals@m.gmane.org; Wed, 03 Feb 2016 13:02:55 +0100 Original-Received: by mail-pf0-f197.google.com with SMTP id x8sf44103213pfa.1 for ; Wed, 03 Feb 2016 04:02:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:content-transfer-encoding:message-id:date :subject:from:in-reply-to:references:to: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=TcgXwL1CO3hyeLAUejrXy2TGCnCNWJHsdYITwwqzeIo=; b=HdSG8gKKo1bK2WS/2yB6SPajeLcC3/RdJ6mT0pKFzTR7/JawIcjdU5MNugOSLNMfpx DcFUjkmaJhWcZbhxYGxq7lMW/taEp0qsJrzpguNtkyidYXaJ/TQrpQ0qGTtOwguJg/Dt F8oJt61xZYHtPVZWuYAkVLNSsVvVYP3VOTDnkFgyWT6BGbwXopxZw7KuFR3rJWjIgZsV hCHV5OFfZMNmIpexshu7rHTcxfc3Y4N38yKkNEfE6cA3Pyp4jjSZ9m36HVnbsJCzWV/b 99ZWjtkqHsS+Wl7iSLRewpksNn0TCbmeoz+uYH2f53scy7VR3RaDn7qJcxiOmDVvmbSZ X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version :content-transfer-encoding:message-id:date:subject:from:in-reply-to :references:to: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=TcgXwL1CO3hyeLAUejrXy2TGCnCNWJHsdYITwwqzeIo=; b=FBYVDbW5RJM43j7d0gh3VzSbHzP/OVbdI6eQ7D8g9fZZs+Zj+hog2+SsUW+gOdIGT/ AoS1XXzlEzjd9MgLRrPDTwuPMvBq90C5VW/k7yq0BxtdnEyaT3LrnPAXrgQBXlJyq1O7 3/ZDckm7+smwG5ufGi8KmfDJSCYMMNeS0gEWBsL4rQ6qz81i//Ee5VApe44tzirAzsaj bxHE/MDYa/bM86Rxt3V0h54/cU1lM3DwnbpVk7peAYF3HkonZZEt/V1qEu0/62VENcTQ YCkCtnOM/JZs5ZLHyaMqw5PP2hZ0Y0pKdLkyb+iMA43rkIrMJyhexkd6qWoNBH9hJYMd X-Gm-Message-State: AG10YOTWbHihmDko8tmW7kVENiWj2jQ6GJgENrDa8xczh0d9OLDDAXNYpNMHdt0aj43g3w== X-Received: by 10.66.162.138 with SMTP id ya10mr946788pab.21.1454500974459; Wed, 03 Feb 2016 04:02:54 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.30.8 with SMTP id o8ls537617igh.44.gmail; Wed, 03 Feb 2016 04:02:53 -0800 (PST) X-Received: by 10.107.12.19 with SMTP id w19mr3518667ioi.114.1454500973232; Wed, 03 Feb 2016 04:02:53 -0800 (PST) Original-Received: from mail-io0-x230.google.com (mail-io0-x230.google.com. [2607:f8b0:4001:c06::230]) by mx.google.com with ESMTPS id p18si11899988igs.50.2016.02.03.04.02.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Feb 2016 04:02:53 -0800 (PST) Received-SPF: pass (google.com: domain of tvaneerd@gmail.com designates 2607:f8b0:4001:c06::230 as permitted sender) client-ip=2607:f8b0:4001:c06::230; Original-Received: by mail-io0-x230.google.com with SMTP id g73so52509325ioe.3 for ; Wed, 03 Feb 2016 04:02:53 -0800 (PST) X-Received: by 10.107.130.221 with SMTP id m90mr2879059ioi.69.1454500973065; Wed, 03 Feb 2016 04:02:53 -0800 (PST) Original-Received: from [127.0.0.1] (GLPHON2233W-LP130-01-1177896072.dsl.bell.ca. [70.53.68.136]) by smtp.gmail.com with ESMTPSA id z138sm2857117iod.37.2016.02.03.04.02.50 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 03 Feb 2016 04:02:50 -0800 (PST) X-Mailer: BlackBerry Email (10.3.2.2876) In-Reply-To: <5115b78c-8fb4-4c72-a278-f74c636f5217@isocpp.org> X-Original-Sender: tvaneerd@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of tvaneerd@gmail.com designates 2607:f8b0:4001:c06::230 as permitted sender) smtp.mailfrom=tvaneerd@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:24159 Archived-At: =
Since it is currently undefined behaviour, you could ask your c= ompiler vendor to offer it as a compiler option, and then we could get some= experience as to how valuable it is.
= =

= = <= div style=3D"font-size: initial; font-family: Calibri, 'Slate Pro', sans-se= rif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-c= olor: rgb(255, 255, 255);">Sent from my BlackBerry port= able Babbage Device = = =
From: chris beck
= Sent: Tuesday, February 2, 2016 7:15 PM
To: ISO C++ St= andard - Future Proposals
Reply To: std-proposals@isocpp.o= rg
Subject: [std-proposals] Proposal: Change the specified= behavior when control flow reaches the end of non-void functions

<= div id=3D"_originalContent" style=3D"">
In the C++14 standa= rd, the behavior when control flow reaches the end of a non-void function i= s described as follows:

[stmt.return][6.6.3 The `return` statement]<= br>    ... Flowing off the end of a function is equivalent t= o 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 i= s equivalent to a return with no value; if this occurs in a function whose<= br>return type is not `void`, `std::terminate` is called.

The reason= for this is to make it easier to catch this undefined behavior by requirin= g the program to fail fast.
In practice, it *seems* that gcc and clang g= enerally do something like return an indeterminate value when they fall off=
the end of a non-void function, and tracking down such bugs can be very= difficult and time-consuming.
In C++ code written in a modern style, th= is seems to be one of the easiest ways that an uninitialized value can occu= r in
real code.

Most programmers deal with the situation by dilig= ently paying attention to compiler warnings -- gcc will issue a warning
= when it can see that control flow can reach the end of a non-void function.= However, this is not an excellent solution.
It only works when gcc can = actually prove that the end of the function is reachable, and this depends = on the
optimization level used, and on the optimizations that succeed. I= f the function is sufficiently complicated that gcc
can't be sure the en= d is reachable, gcc won't issue a warning even if the end can be reached, t= o avoid giving a
"false-positive" warning, which would limit the utility= of the warning. Determining for sure if the end is reachable is
equival= ent to the halting problem, so this approach is inherently limited.

= By simply requiring the compiler to emit a call to `std::terminate` (instea= d of potentially returning an undefined
value when this happens), we can= catch the problem at run-time 100% of the time without having to solve the= halting
problem. Moreover, in many real cases the compiler can prove th= at the "end" is not reachable and that the function does
properly return= , and then it may eliminate the `std::terminate` call.

The main argu= ments that I anticipate against this proposal are
1) Potentially emittin= g extra calls to `std::terminate` may bloat code, which without this change= wouldn't need it, and
would work fine.

  My belief is that = the overhead would be low -- I would anticipate that "small" functions can = usually be proved to
return correctly, and then the `std::terminate` cal= l is optimized out. For large functions, an extra call at the end
repres= ents only a marginal increase. However I don't have any data.

2) The= C standard specifies this as undefined behavior -- C++ should do so also f= or compatibility. Potentially, there
may be programs which technically h= ave undefined behavior by way of returning an indeterminate value in this w= ay, but in
fact the indeterminate value is then ignored in the caller an= d so it doesn't cause problems and runs fine. Such programs
would now be= terminated instead, breaking previously "working" code.

  My h= ope would be that more programs will be fixed by catching the indeterminate= values before they cause havoc, than
would be broken in this manner -- = likely, even the programs which break due to this change would benefit from= being
refactored to avoid this problem. Anyways, it seems that the stan= dard committee recently has been willing to make
breaking changes that i= mprove maintainability in the long term, for instance, with the changes reg= arding throwing
exceptions from destructors which became standard in C++= 11.
So perhaps the standards committee has an appetite for this also.
3.) The impact of this change may vary widely from compiler to compile= r. Some compilers with very mature dead-code
elimination may be able to = tolerate a change like this with few spurious `std::terminate` calls result= ing in their code,
but others whose optimization tech is engineered diff= erently may struggle to eliminate those calls -- requiring much
work fro= m developers of those compilers to avoid this overhead.

  It's = difficult for one individual to survey the entire body of C++ compilers and= the optimization techniques they use,
I am only actually familiar with = a few compilers. My impression is that dead-code elimination is one of the = most
important optimizations and that all modern compilers do this very = aggressively, but if you know a popular compiler that
you think might st= ruggle with eliminating function calls injected at the end of functions lik= e I proposed in a large
program, I would be interested to investigate an= d perhaps run some tests.



I would very much appreciate any t= houghts or feedback regarding this idea. If there have been previous propos= als of
this which have been rejected, I would appreciate a reference, I = was not able to find such.

Best Regards,
Chris Beck

--

---
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 e= mail to std-proposa= ls+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= /.

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+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= /.
.