220 22584 article Path: news.gmane.org!not-for-mail From: Jonas Persson Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Unreachable attribute. Date: Fri, 13 Nov 2015 08:24:52 +0100 Lines: 193 Approved: news@gmane.org Message-ID: References: <2573561.klGZ6ZHjC3@lastique-n550jv> <4611855.M52eYPluZF@lastique-n550jv> <3705e2b3-76ac-4a55-b4d3-9252c6462c50@isocpp.org> <305866a5-c79d-49f7-ad82-0e359039a5b4@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1144334696786a052466f431 X-Trace: ger.gmane.org 1447399497 18090 80.91.229.3 (13 Nov 2015 07:24:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Nov 2015 07:24:57 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDLJBMEUU4NBBRNAS2ZAKGQE7J4T24A@isocpp.org Fri Nov 13 08:24:57 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f71.google.com ([209.85.215.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zx8j9-0003Ae-4U for gclcip-std-proposals@m.gmane.org; Fri, 13 Nov 2015 08:24:55 +0100 Original-Received: by lfdo63 with SMTP id o63sf31569739lfd.2 for ; Thu, 12 Nov 2015 23:24:54 -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=rBx/dinVb47i7aGYq/SDCeZsLNrKxhIlELWhWg+PatA=; b=RUp4F84/GTyNkAEYM3Gu4N4v4FwZObkfJZ0Mq2hVIewp3vfxcecLWeePi9QHkymWrS irnKqa8EtBcKLM2iloxJVSHJodPpkrQ6Z6gENVJCnO9g8zQLA8BnWDDtSbnxdUFpVh3u l9+i9rVN+3VRKw57hMvbtyjViXYU2hY2JX2H0cb74KQ8p5+HmEYX6OlRUkAtdotpcdvi dGOenJ61jdjLmmqR9bGGJt9AMtiA2FKrrFyfaDk1m6Qfh0M5+q5ixV2oQXpv0nFAbmzF 7G+rzDKQBjXA4GF9ELkDVTgK9KDHLORnGJWIo4FWXMXYHqpBgpaoOQoYo04RMQJyFJKW bNAA== 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=rBx/dinVb47i7aGYq/SDCeZsLNrKxhIlELWhWg+PatA=; b=EMrYPQ8N5K0CrA5ubbfYDFujA7d2DdfGoYBbm3oCMFqKc2LFIVJCs996t2bSbGMTfs eCZblmijjt7GKtFz5nwoB3hQe/SRP6C60ALPXBdcbwR5iW1+0mY4dWIt+KfYyjL+cJg9 HE/OqrHfdV7MyuWytqaGXOK4hU2Nksh/MjWjhyGfmcmrGImCWbFy1hf0r+6gNu+ZDImx muyby5Q1RvR3u1gF70GI3DhGkO87oRZY3atLSgAYcos1RfGmjQbtWuACYkpFDo0Ztzls CvPdrNXBLCheZ5u2JZsYyZyNUCr6qpTbzKDanuXErRoweLJenUA11/1Fy3cdcBxip5yb wvyA== X-Gm-Message-State: ALoCoQlrLylQLHHLORENHQHDBqX5cN3vQWfDytSR1bG2bLPZkklJOXi21LNo1oiUPDM8WkTfzWZP X-Received: by 10.112.181.194 with SMTP id dy2mr2937899lbc.11.1447399494631; Thu, 12 Nov 2015 23:24:54 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.18.198 with SMTP id 189ls89088wms.11.gmail; Thu, 12 Nov 2015 23:24:52 -0800 (PST) X-Received: by 10.28.9.204 with SMTP id 195mr2041065wmj.88.1447399492943; Thu, 12 Nov 2015 23:24:52 -0800 (PST) Original-Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com. [2a00:1450:400c:c09::230]) by mx.google.com with ESMTPS id m79si3742120wmg.42.2015.11.12.23.24.52 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Nov 2015 23:24:52 -0800 (PST) Received-SPF: pass (google.com: domain of l.j.persson@gmail.com designates 2a00:1450:400c:c09::230 as permitted sender) client-ip=2a00:1450:400c:c09::230; Original-Received: by wmec201 with SMTP id c201so18062472wme.1 for ; Thu, 12 Nov 2015 23:24:52 -0800 (PST) X-Received: by 10.28.170.65 with SMTP id t62mr2078438wme.1.1447399492316; Thu, 12 Nov 2015 23:24:52 -0800 (PST) Original-Received: by 10.28.157.148 with HTTP; Thu, 12 Nov 2015 23:24:52 -0800 (PST) In-Reply-To: X-Original-Sender: l.j.persson@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of l.j.persson@gmail.com designates 2a00:1450:400c:c09::230 as permitted sender) smtp.mailfrom=l.j.persson@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:22584 Archived-At: --001a1144334696786a052466f431 Content-Type: text/plain; charset=UTF-8 On Fri, Nov 13, 2015 at 12:45 AM, 'Edward Catmur' via ISO C++ Standard - Future Proposals wrote: > On Thu, Nov 12, 2015 at 11:20 PM, Jonas Persson > wrote: > >> >> >> On Thu, Nov 12, 2015 at 11:52 PM, 'Edward Catmur' via ISO C++ Standard - >> Future Proposals wrote: >> >>> >>> On 12 Nov 2015 22:42, "Jonas Persson" wrote: >>> > >>> > >>> > In this case UB will not give you any better performance. If you get >>> UB on the caller side of a precondition, it is becase the code is >>> incorrect. If that causes the compiler to fail, you can remove the failing >>> code, giving you the same as UB code pruning would. But with fewer subtle >>> bugs. >>> >>> True, for hand-written code. But invalid or unreachable code paths can >>> easily crop up in template code, macro expansions, platform-, library- or >>> configuration-dependent code, generated code, and in edge cases such as >>> loop or recursion terminating conditions. Why should we have to contort our >>> code to remove the failing code when the compiler can easily do it for us? >>> >> Note that I'm not talking about disallowing UB in general here, only for >> precondition callers. >> The reason to make the ill-formed is that >> 1) the primary reason to use contracts is to catch misuse. Here we are >> detecting misuse, but we are not telling. >> 2) it is not evident from reading the code that it will fail or be >> pruned. Only the compiler knows. >> 3) We cannot be sure to catch this error by rebuilding in debug mode or >> with sanitisers, becase any change to the compile process might cause >> changes in inlining or other things so that the >> compiler fails to figure out the failed precondition at compile time. >> > > Making precondition failure ill-formed excludes far too much otherwise > well-formed code: > > void print_column(string s, int width) { > for (int i = 0; i != width; ++i) > cout << ((i < s.size()) ? s[i] : ' '); // X > } > print_column("hello", 10); > > The compiler can prove that the program reaches line *X* with *i = 5*. > But s[5] is a precondition violation! Do you really want this code to be > ill-formed? > How is that precondition violation? If operator[] has a precodition it should be i < size(), which is what you are checking. On the other hand: void print_column(string s, int width) { for (int i = 0; i != width; ++i) cout << s[i]; // X } print_column("hello", 10); would be a violation and I would rather have the compile fail than an access violation or no output at runtime. Properly fixing that with void print_column(string s, int width) [expects:width

On Fri, Nov 13, 2015 at 12:45 AM, 'Edward Catmur' via ISO C++ S= tandard - Future Proposals <std-proposals@isocpp.org>= wrote:
On Thu, Nov 1= 2, 2015 at 11:20 PM, Jonas Persson <l.j.persson@gmail.com> wrote:
<= span class=3D"">


On Thu, Nov 12, 2015 at 11:52 PM, '= ;Edward Catmur' via ISO C++ Standard - Future Proposals <std-pr= oposals@isocpp.org> wrote:


On 12 Nov 2015 22:42, "Jonas Persson" <l.j.persson@gmail.com> wrote: >
>
> In this case UB will not give you any better performance. If you get U= B on the caller side of a precondition, it is becase the code is incorrect.= If that causes the compiler to fail, you can remove the failing code, givi= ng you the same as UB code pruning would. But with fewer subtle bugs.=C2=A0=

True, for hand-written code. But invalid or unreachab= le code paths can easily crop up in template code, macro expansions, platfo= rm-, library- or configuration-dependent code, generated code, and in edge = cases such as loop or recursion terminating conditions. Why should we have = to contort our code to remove the failing code when the compiler can easily= do it for us?

Note that I'm not talking about dis= allowing UB in general here, only for precondition callers.=C2=A0
The reason to make the ill-formed is that=C2=A0
1) the primary r= eason to use contracts is to catch misuse. Here we are detecting misuse, bu= t we are not telling.=C2=A0
2) it is not evident from reading the= code that it will fail or be pruned. Only the compiler knows.=C2=A0
<= div>3) We cannot be sure to catch this error by rebuilding in debug mode or= with sanitisers, becase any change to the compile process might cause chan= ges in inlining or other things so that the
compiler fails to fig= ure out the failed precondition at compile time.

Making precondition failure ill-formed= excludes far too much otherwise well-formed code:

void print_column(string s, int width)= {
=C2=A0 =C2=A0 for (= int i =3D 0; i !=3D width; ++i)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cout << ((i < s.size()) ? s[= i] : ' '); =C2=A0// X
}
print_column= ("hello", 10);

The compiler can p= rove that the program reaches line X with i =3D 5. But s[5] is a precondition violation! Do y= ou really want this code to be ill-formed?

How is that precondition violation?=C2=A0 If operat= or[] has a precodition it should be i < size(), which is what you are ch= ecking.

On the other hand:
void print_column(string s, int width) {
=C2=A0 =C2=A0 for (int i =3D 0; i= !=3D width; ++i)
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 cout << s[i]; =C2=A0// X
}
print_column("hello", 10);

would be a violation and I would rather have the compile fail t= han an access violation or no output at runtime.
Properly fixing that with

void print_column(string s, int width) [expects:width<s.si= ze()] {
=C2=A0 =C2=A0 = for (int i =3D 0; i !=3D width; ++i)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cout << s[i]; =C2=A0// X
}
print_column("hello", 10);=

would = let the compiler optimize the print_column function and tell you, hopefully= at compile time, that your call to print_column is wrong.=C2=A0

=C2=A0 / Jonas

--

---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
--001a1144334696786a052466f431-- .