220 36664 article Path: news.gmane.org!.POSTED!not-for-mail From: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Static analysis and the future of C++ Date: Tue, 16 Jan 2018 11:19:40 -0500 Lines: 79 Approved: news@gmane.org Message-ID: References: <0087c1a4-0b36-40ca-8d43-5bfaf0af62ca@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113c81dc14d7c90562e71930" X-Trace: blaine.gmane.org 1516119464 17352 195.159.176.226 (16 Jan 2018 16:17:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 16 Jan 2018 16:17:44 +0000 (UTC) To: "ISO C++ Standard - Future Proposals" Original-X-From: std-proposals+bncBCGNLO5F34OBBHWM7DJAKGQE56XLI3A@isocpp.org Tue Jan 16 17:17:40 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f197.google.com ([209.85.223.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ebTvf-0004AU-Fa for gclcip-std-proposals@m.gmane.org; Tue, 16 Jan 2018 17:17:39 +0100 Original-Received: by mail-io0-f197.google.com with SMTP id r74sf5283826iod.15 for ; Tue, 16 Jan 2018 08:19:43 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1516119583; cv=pass; d=google.com; s=arc-20160816; b=jg34ngA7xR/+Rs0WGt8rfXz/witIfdwCJAsDtrg+kFnQwl+rCATLD6qfkT4SigTLDK OKGKs0t5zG953cjujA2x5Lxe5TDVf1o3v3Z7wMePxKoP3O2bN/me0STnfovviFIGI3vr pUorsqCzCya+P/hwwDrPE5IGJw1wyLl4rvqxcrEbqs70UnxiLo2jpb9Gg5LPLdmPU5pd YvWt7//43gZGnIKuQ3m+gH8/meUS7mAQ3DcM+7c+X5C6TAyfkSOE0x/7FfdqTob1mZJ6 LryUJKDZHYfHb0+kn26z0JlZMPWTrWK2rtorJOpCORB7OZqJmpICh1iRTC1m1CQlBvkY QrSg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:references:in-reply-to:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=q91tQBQu1uYi6uUz3Kmuij+s1/ERABySt+a4fo3Ep70=; b=MtruhQqimjWG11LrS2QmP3EuNThD+MlYf9EUTLfxHiVzi1YOCmoa5mBh4OgmupU/oU r2FgfMZ5NCkFnIaD7ZoYFdKZnv3uDCKUDbE3I2B9V9fHllwGxv+tmZvI/oOw8uzi/Hik QXlVOihZqz0KG5bmO5BmBvudNO0my2J1ZMLY+q2geU7wU2i/Er1do/TCf8wT2vF9mFok DzQRK/Bf3Xq4p4JRU5clOXjNuCnsE1pDMY/MT8ZhiY087dO3baKlTfD99p/MBzedUV4+ HjM9LsZYuEP+FLdS/aVpPdWBxfW91E/IEIFRA+BJWWVEFlEPzD2H5ueJ1lt17qa9jHhh QcuQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=BObCWxwT; spf=pass (google.com: domain of calabrese@google.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=calabrese@google.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com 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:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=q91tQBQu1uYi6uUz3Kmuij+s1/ERABySt+a4fo3Ep70=; b=TQuirevv4TDJyuJk2pkVe8DUP4zwooXUrfABMc45q7gBmDB6genH+3zzHSKfdacHwo A4rpjJFA2OgFsocZuiXYAYCxohDZGSZd1KPUDuUbpMCfBfNYfupI4pRJRmhi9lhFaYAY XnmSgr0TpJ+T4/2Qn8ZN6yvAR9J3q/r2G3K+AgELQPMwWtnXGKK+XbetjHk1dhnxkFAe PHO8b2BIVZlpb+aAictg3fTP6ViS4w5ZJKC15EnGI0VRKv0RlsnSqphn/KFJpPgFVFYa TIYXr/DVe/vXnPR4SHshw9xaB/PrJe8nUAwRAyts4R4AoEMwGU5bb5nvPevPMiNvqJiR 0g0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject: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=q91tQBQu1uYi6uUz3Kmuij+s1/ERABySt+a4fo3Ep70=; b=DtVz6AedliJmz9jLJU0Rc3O+kdkuTBPRmVWT1Zzvtf4KW19F4qVcZzjl9IRIliFSKR lgqnsiUKICAw34blwZAXucDqV+5fnO6EY4FehRMQXBXa83AS1jJJeL46xgtjNYuoLmDX 7BNoCIMygzYuLX6LLxHrTEOr5hAL2NGp73+J9XzSMs/XfhbOQ35KOlGHZ1X5I9xoDVJq uAQGjwmdnakk/Dw9bZc6E2M5HtsPPv3my4vbSY3Ln/UKpbLok2o9oTnctjl8a239iyY4 Lf/xPLUtAZy9/dX0f2CO01Wj7+RtrP1IfiwcZOGZOP/rMVvgwtjGvCBC+fU1DCjdlKpL zGrg== X-Gm-Message-State: AKGB3mI7TYVXjXtKkU7WutifgNBi2hNgdedfBpAFxdMTif6FMHuwi5Zc hvWpFmB0TXGaDFJLjJHNMfk= X-Google-Smtp-Source: ACJfBotq1Z2o0RXsHKtoSt2sEVBAjLy0yD8gnEEfbjwc68OqsmrGgFXyTun/fJu3ZKkrluuklp7krg== X-Received: by 10.107.111.6 with SMTP id k6mr27020907ioc.94.1516119583340; Tue, 16 Jan 2018 08:19:43 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.47.194 with SMTP id v63ls848296iov.6.gmail; Tue, 16 Jan 2018 08:19:42 -0800 (PST) X-Received: by 10.107.160.196 with SMTP id j187mr40789927ioe.186.1516119582082; Tue, 16 Jan 2018 08:19:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516119582; cv=none; d=google.com; s=arc-20160816; b=tFUDrqRjuMVEPTGQNgxTobRDGh0H39Cs9dB2naJnXux3YZCJ2DBWRO9azSl30ts6jb gfuJjKszMUKXsd4l5+HUkIqkvEJzFyTGtnu38KAC967J1pmQcJg4btdMjxcvot2qOBw+ TQ6obl5HhTbRPLnxAq0C8K0if2KrxxDFfDMB06F7WNE+21b1gkZ048qvwO0NAtQnR0yQ LRckCABIwNwkmEJO+YX3dM9LCbBJp3QNNCCi8nnWy+36T1dKUN3iNcVX0P3f6wljc6Lf VZ+K337UCCjqZpAo/pFlyVd7vHReENi0UWGsIapid64g0JkUJcqhlA45Kvv5Se5H5iq1 daUQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=UxPKAeNiNivgn5DemB8Viq9xePOMiifMDslcigZHX/c=; b=zZ2GSRUEBGm2/pkhQK1TVLT1ZeFr7ELHlnhazkm8z81YF8fsVUlodqjIIT/QrPunG+ p5JIKDguaV1ze6IGKyJnctxe7bw10ArvlqWxTZKHXg7o9usie9V9oW4Ns0UD8zzYRbtK fI79U5/B1gvN7pgxSA5viYnF+sd/WG6ipnB26uYeQ8GcEHnisga5+ZKIOv2w/oMTccjE PaJvdUPnsHUbA7H0ReaV+OfvC9w91lniGHq31P3I92z0sDiI4tte7SCaX78AET/qg6df l//05QLbN3HpX49ljjNuhWJM+lmn5+3HtubcPyUllL9YOM6LvkPypkXVH1cP6bEkDjMx sNzg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=BObCWxwT; spf=pass (google.com: domain of calabrese@google.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=calabrese@google.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id s66sor1295462ioi.272.2018.01.16.08.19.41 for (Google Transport Security); Tue, 16 Jan 2018 08:19:41 -0800 (PST) Received-SPF: pass (google.com: domain of calabrese@google.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 10.107.128.159 with SMTP id k31mr15695421ioi.168.1516119581270; Tue, 16 Jan 2018 08:19:41 -0800 (PST) Original-Received: by 10.107.189.193 with HTTP; Tue, 16 Jan 2018 08:19:40 -0800 (PST) In-Reply-To: X-Original-Sender: calabrese@google.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=BObCWxwT; spf=pass (google.com: domain of calabrese@google.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=calabrese@google.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com X-Original-From: Matt Calabrese 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:36664 Archived-At: --001a113c81dc14d7c90562e71930 Content-Type: text/plain; charset="UTF-8" On Sun, Jan 14, 2018 at 10:39 AM, j c wrote: > This discussion will be pointless until C++ decides what it should do when > built-in static analysers discover undefined behaviour. > Right now they use it as an excuse to generate heavily optimised, but > ultimately incorrect, programs instead of just bailing out of the compile. > 1) Any program with UB is broken. Optimizations are not what make them broken. 2) Plenty of compilers do diagnose forms of UB at compile-time in places where it is feasible to deduce or to reasonably assume that the code is intended to be reachable when in a problematic state (simple example that is often diagnosed in warnings is the lack of return statement for functions, though even that is necessarily noisy). Sure, implementations can always do more, but it's not as though developers are saying "here's UB that we can detect at compile-time and that we will intentionally avoid warning about, you know, just to annoy our users". That's a horrible misconception that people need to stop perpetuating. 3) Just because an optimization seemingly takes advantage of UB does not imply that potential execution leading to UB was detected or is even feasibly detectable at compile-time with the language as-is (assumptions that there are no data races, etc.). -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DE%3D5-n7RiK2mjbze%3DcoCHXcT50Fj_bQWe7tA1fFt7gx1Mw%40mail.gmail.com. --001a113c81dc14d7c90562e71930 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= un, Jan 14, 2018 at 10:39 AM, j c <james.a.cooper@gmail.com>= wrote:
This discussion will be po= intless until C++ decides what it should do when built-in static analysers = discover undefined behaviour.
Right now they use it as an excuse to gen= erate heavily optimised, but ultimately incorrect, programs instead of just= bailing out of the compile.

1) Any p= rogram with UB is broken. Optimizations are not what make them broken.
2) Plenty of compilers do diagnose forms of UB at compile-time in pla= ces where it is feasible to deduce or to reasonably assume that the code is= intended to be reachable when in a problematic state (simple example that = is often diagnosed in warnings is the lack of return statement for function= s, though even that is necessarily noisy). Sure, implementations can always= do more, but it's not as though developers are saying "here's= UB that we can detect at compile-time and that we will intentionally avoid= warning about, you know, just to annoy our users". That's a horri= ble misconception that people need to stop perpetuating.
3) Just = because an optimization seemingly takes advantage of UB does not imply that= potential execution leading to UB was detected or is even feasibly detecta= ble at compile-time with the language as-is (assumptions that there are no = data races, etc.).

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DE%3D5-n= 7RiK2mjbze%3DcoCHXcT50Fj_bQWe7tA1fFt7gx1Mw%40mail.gmail.com.
--001a113c81dc14d7c90562e71930-- .