220 24216 article Path: news.gmane.org!not-for-mail From: "'Edward Catmur' via ISO C++ Standard - Future Proposals" 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: Fri, 5 Feb 2016 11:30:30 +0000 Lines: 151 Approved: news@gmane.org Message-ID: References: <5115b78c-8fb4-4c72-a278-f74c636f5217@isocpp.org> <2390270.BM3DFplE2E@tjmaciei-mobl4> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1140f750b3071e052b042d59 X-Trace: ger.gmane.org 1454671840 28324 80.91.229.3 (5 Feb 2016 11:30:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Feb 2016 11:30:40 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDZLZTXF7UJBBVUP2K2QKGQEP7FQTKA@isocpp.org Fri Feb 05 12:30:39 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f199.google.com ([209.85.213.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aReaz-0007ri-Nw for gclcip-std-proposals@m.gmane.org; Fri, 05 Feb 2016 12:30:37 +0100 Original-Received: by mail-ig0-f199.google.com with SMTP id ik10sf33567020igb.2 for ; Fri, 05 Feb 2016 03:30:37 -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=95E7UTBXyKmUfafEiBz//8w78d/qkkrza+vYJiTEjOk=; b=xUbb+L/55euUemR23zJ/dBlYggYQz5zi930ZysmKxuXhmP8R6ejsdDShMdArZPleQM nUPcFsNckqVF/JKGFkr8TNi3oArnwO9ucnMPX5O/CzRU+wBtFsRX9mrpVYvqq7liG6i0 bui2OEodWjvHBGiJearsWTrceusNiW8g8QNI+jc9x02jL94UzUVXMBHwvZoCI1ktgQt1 aCLzOD2bbWyunFFz2TgRvKiUMLb4tNuRWqrSnqUTwbLn+VfUvEYDFjTUJOIkf8TRY4y1 QfQEuaY6TjADvTZOmx4iW+KlbKyQlhUEgkUV0iF+pC2UFgmkLuG/d3rtKfpwfuDINugG CUjQ== 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=95E7UTBXyKmUfafEiBz//8w78d/qkkrza+vYJiTEjOk=; b=aULF3sjMdNYgY9eIUt1FVt4TDVWGpA6ps6neu5kEzI6up/jtE3bYQDU0c2uRT3T1+m PXKi0PcXmBWNQg8JVJbC5l1IXyhVoo8N/evqj2ov1d2d9J0Bsq9iMnQ0eRCyn4W2RSrj 7dHhz9DrtyyPeMILJHU8QhRir/LLdDNFWG0F2J/mDEa/dNre96Rbi3fPWrIquM4CkPIs yTxbNfAGtCcd/VRd5buSoP0E3t6Q/WF/h1/M5fGPAbV/snj0Ca1SE1fyoRzrWBU2yQ8l 9U7Ll/tnXYTAsXsDkxs+aSY0wzFFDqr2PIQCfItaVxuZffWbNjrXIyzH3clBTh02i9JZ Zj6Q== X-Gm-Message-State: AG10YOSKwHrzzcSS6HAGc8n0NKslGFAyWiVR2L3lwejxBqnljU/HbII2y2Fzgb2oGssINw== X-Received: by 10.107.157.9 with SMTP id g9mr13368602ioe.26.1454671831742; Fri, 05 Feb 2016 03:30:31 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.97.73 with SMTP id dy9ls172865igb.23.canary; Fri, 05 Feb 2016 03:30:30 -0800 (PST) X-Received: by 10.107.133.74 with SMTP id h71mr13259377iod.79.1454671830291; Fri, 05 Feb 2016 03:30:30 -0800 (PST) Original-Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com. [2607:f8b0:4001:c06::22b]) by mx.google.com with ESMTPS id 64si10693193ioc.33.2016.02.05.03.30.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Feb 2016 03:30:30 -0800 (PST) Received-SPF: pass (google.com: domain of ecatmur@googlemail.com designates 2607:f8b0:4001:c06::22b as permitted sender) client-ip=2607:f8b0:4001:c06::22b; Original-Received: by mail-io0-x22b.google.com with SMTP id 9so125782892iom.1 for ; Fri, 05 Feb 2016 03:30:30 -0800 (PST) X-Received: by 10.107.163.137 with SMTP id m131mr15013988ioe.1.1454671830121; Fri, 05 Feb 2016 03:30:30 -0800 (PST) Original-Received: by 10.36.124.76 with HTTP; Fri, 5 Feb 2016 03:30:30 -0800 (PST) In-Reply-To: X-Original-Sender: ecatmur@googlemail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of ecatmur@googlemail.com designates 2607:f8b0:4001:c06::22b as permitted sender) smtp.mailfrom=ecatmur@googlemail.com; dkim=pass header.i=@googlemail.com; dmarc=pass (p=QUARANTINE dis=NONE) header.from=googlemail.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: , X-Original-From: Edward Catmur Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:24216 Archived-At: --001a1140f750b3071e052b042d59 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 5, 2016 at 9:53 AM, Ville Voutilainen < ville.voutilainen@gmail.com> wrote: > On 5 February 2016 at 11:07, 'Edward Catmur' via ISO C++ Standard - > Future Proposals wrote: > > On Fri, Feb 5, 2016 at 1:20 AM, Ville Voutilainen > >> How is that different from any other case of terminating a program? > > When std::terminate is invoked in a manner prescribed by the standard, > there > > is a current exception available to the terminate handler. > > None of what we have described changes any of that. > I'm not suggesting a change; I'm pointing out that terminate is not an appropriate mechanism for terminating the program in cases that do not involve the exception handling mechanism. > >> The proposal in question is that the program be terminated. Nothing in > it > >> says > >> that it needs to be a silent termination. Nor does it require a > >> diagnostic. > > And then you're throwing away information that existing implementations > have > > shown is readily available. > > I fail to see what information we would supposedly throw away. Source location and nature of the error causing termination. > >> What the compiler may want to implement is its own business, so long as > it > >> terminates the program by eventually calling std::terminate. > > I strongly believe that is the wrong mechanism. std::terminate is a > facility > > "... for coping with errors related to the exception handling mechanism > ..." > > [except.special]; falling off the end of a value-returning function has > > absolutely nothing to do with exceptions. If ubsan is to be standardized > > (and I'm broadly in favor of that, given suitable opt-outs) it should > happen > > through an appropriate mechanism, not be shoehorned into the exception > > handling mechanism. > > I fail to see what you're talking about. We have been describing ways to > provide > diagnostics when terminate() is called, and that is not related to the > exception > handling mechanism. But terminate() *is* part of the exception handling mechanism; it is not a general error handling mechanism. -- --- 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/. --001a1140f750b3071e052b042d59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Feb 5, 2016 at 9:53 AM, Ville Voutilainen <ville.voutilainen= @gmail.com> wrote:
On 5 Feb= ruary 2016 at 11:07, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-propos= als@isocpp.org> wrote:
> On Fri, Feb 5, 2016 at 1:20 AM, Ville Voutilainen
= >> How is that different from any other case of terminating a = program?
> When std::terminate is invoked in a manner prescribed by t= he standard, there
> is a current exception available to the terminate handler.

None of what we have described changes any of that.

I'm not suggesting a change; I'= ;m pointing out that terminate is not an appropriate mechanism for terminat= ing the program in cases that do not involve the exception handling mechani= sm.
=C2=A0
>> The proposal in question is that the program be terminated. Nothin= g in it
>> says
>> that it needs to be a silent termination. Nor does it require a >> diagnostic.
> And then you're throwing away information that existing implementa= tions have
> shown is readily available.

I fail to see what information we would supposedly throw away.

Source location and nature of the error causing = termination.=C2=A0
=C2=A0
>> What the compiler may want to implement is its own business, so lo= ng as it
>> terminates the program by eventually calling std::terminate.
> I strongly believe that is the wrong mechanism. std::terminate is a fa= cility
> "... for coping with errors related to the exception handling mec= hanism ..."
> [except.special]; falling off the end of a value-returning function ha= s
> absolutely nothing to do with exceptions. If ubsan is to be standardiz= ed
> (and I'm broadly in favor of that, given suitable opt-outs) it sho= uld happen
> through an appropriate mechanism, not be shoehorned into the exception=
> handling mechanism.

I fail to see what you're talking about. We have been describing= ways to provide
diagnostics when terminate() is called, and that is not related to the exce= ption
handling mechanism.

But terminate() *is* pa= rt of the exception handling mechanism; it is not a general error handling = mechanism.

--

---
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= /.
--001a1140f750b3071e052b042d59-- .