220 24178 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 01:30:51 +0300 Lines: 55 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 1454538654 14239 80.91.229.3 (3 Feb 2016 22:30:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Feb 2016 22:30:54 +0000 (UTC) To: "ISO C++ Standard - Future Proposals" Original-X-From: std-proposals+bncBCXY5TXHWYJRBHH7ZG2QKGQEZM26TJI@isocpp.org Wed Feb 03 23:30:54 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 1aR5ws-0002eC-24 for gclcip-std-proposals@m.gmane.org; Wed, 03 Feb 2016 23:30:54 +0100 Original-Received: by mail-pf0-f197.google.com with SMTP id r82sf80256359pfi.2 for ; Wed, 03 Feb 2016 14:30:53 -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=QUpMOGTepEnW+vICJ6R9l1/lJ63SUdeUgQY2JPGSTsA=; b=fDNpItLNIpSDyYTNzj4n4hkViMntC8BfdU3ioHmiKvVIVYDxSrxKj2yP6Dn2H+eG4d eQOjXzMNNXIgxm+c3OvFAvJ9fVGmLlsneBlNtDzBQpCmTv3o2HcB61NvNjbjZ6xyRBJS fJI/wpSLmg5ENjpy9ws5ayUDInBDIsPsdkRNDILYlSm/mN6llxQA6iX54FBrnMC/ubOB y6kHiUFIwy05S6QbCewzPL7RlUf4GwiILBYff4cDbJRXzlvobdi9TksQzOEE5o5pODlC zDb0GYXGnEyGyJuvmkdlTx39RZ+tQXbbTB3pKK1k4pBxIilXcdsJjJ4KpHjx49TBQlep KINA== 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=QUpMOGTepEnW+vICJ6R9l1/lJ63SUdeUgQY2JPGSTsA=; b=JHvK2BDKO/OX5nMLGVMhRj7xhX7C0XvL38qeUnpf4JSGY6vh/pWxUTbF2l5JVFqln8 7eFIa6nGcrrQp8kMsgbChtzxet3CtLXSQ0Z+BndCyh0hT4cL6JM/BIc5AT8en/2C0JL3 wnveEELsEUAw6VQTFdyZ18jICbhAgmHcvVJiJkM1qSdMJxvpd3mMJIl0GfTfVj5NaKx2 ECR+euKeAhTkUugDR8cyX4mPJg4QjuQEifDOOGIXITMERdMXNko/r8RXPZ1GHJ2XQHcH t44MHGKFBwxumqyUYYSS6uDCYIlCm9rAtYCy3akFNv9lN910mEf6fYha9earpg1nQfPE MUfg== X-Gm-Message-State: AG10YOS/jwheNtgjQlDBQ3XVlluvkyjcaQTFsOPG1yOegkeOEF/bWSl1iRlHcBlopDX65A== X-Received: by 10.66.242.141 with SMTP id wq13mr3824239pac.8.1454538652796; Wed, 03 Feb 2016 14:30:52 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.43.129 with SMTP id w1ls2052495igl.22.canary; Wed, 03 Feb 2016 14:30:51 -0800 (PST) X-Received: by 10.50.13.102 with SMTP id g6mr6354525igc.77.1454538651871; Wed, 03 Feb 2016 14:30:51 -0800 (PST) Original-Received: from mail-io0-x233.google.com (mail-io0-x233.google.com. [2607:f8b0:4001:c06::233]) by mx.google.com with ESMTPS id c19si15335332igr.39.2016.02.03.14.30.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Feb 2016 14:30:51 -0800 (PST) Received-SPF: pass (google.com: domain of andrey.semashev@gmail.com designates 2607:f8b0:4001:c06::233 as permitted sender) client-ip=2607:f8b0:4001:c06::233; Original-Received: by mail-io0-x233.google.com with SMTP id f81so72817296iof.0 for ; Wed, 03 Feb 2016 14:30:51 -0800 (PST) X-Received: by 10.107.6.82 with SMTP id 79mr5659467iog.72.1454538651757; Wed, 03 Feb 2016 14:30:51 -0800 (PST) Original-Received: by 10.79.37.8 with HTTP; Wed, 3 Feb 2016 14:30:51 -0800 (PST) In-Reply-To: <5115b78c-8fb4-4c72-a278-f74c636f5217@isocpp.org> 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::233 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:24178 Archived-At: 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. > The main arguments that I anticipate against this proposal are > 1) Potentially emitting 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` call is optimized out. For > large functions, an extra call at the end > represents only a marginal increase. However I don't have any data. Given that _every_ returning function has the potential to be augmented this way, I believe the overhead will be significant. Also, addition of a function call may affect inlineability of an otherwise small and simple function. -- --- 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/. .