220 36622 article Path: news.gmane.org!.POSTED!not-for-mail From: Richard Hodges Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Static analysis and the future of C++ Date: Sun, 14 Jan 2018 17:24:54 +0100 Lines: 300 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="001a113fbfc6187d0c0562bef0f7" X-Trace: blaine.gmane.org 1515946986 14550 195.159.176.226 (14 Jan 2018 16:23:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 14 Jan 2018 16:23:06 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD4PBM7UWAHRBV4I53JAKGQERZQC7TY@isocpp.org Sun Jan 14 17:23:02 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-it0-f72.google.com ([209.85.214.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eal3d-0002jB-8P for gclcip-std-proposals@m.gmane.org; Sun, 14 Jan 2018 17:22:53 +0100 Original-Received: by mail-it0-f72.google.com with SMTP id i67sf11948049ith.1 for ; Sun, 14 Jan 2018 08:24:57 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1515947096; cv=pass; d=google.com; s=arc-20160816; b=sOwfKzvfhvb0Zue4T/KHwqr8t/+04lkgOwGHL7UZZSoikDGDsY4WgOzl2zPQYCRbtR uolur5sEvaKzkcNkRg718jnoj9yEundh0M79b5+fB/za0rPIrbtpa/jYvESW5BQh3s2H ld0KyRN7mGWDF/TawVaQvcmNGUilipGeWxYil4Is1c00XMyG2DErS75SRmuUar+QwRJV 7eOUq1NUzl7svsfvk6bJ934GDkawYK0/4FLOP7cGvkT+pPQLZ1hUVHy+MYU3AhyrW2NI 2nkz3d5gkDnUNeY20vn+hGsgIk8YYvkU42VjMeNXTolasbzjHn8L1IiNtXI4+nF0zoic TeTg== 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=5TtQXMEppOw57nahaeRqkh31o0YqXnyn4YNRJzLHP1w=; b=t4op9RNTxgx8l0gf7pRDT0WyAnsTr59ba8upx3EfjLTb3mS0tdxNguGYVF30ZaXDxn pq2EoSCIZYe0JWeAyOAZDRBVeLkxSOBygAgiJIzA4H63MkOdhPDr7Rsx8VfA3wg9j2d1 vyN3XiyAk1OfBnfPD5H5HRa8wLjzTUoCDOo+tVCOkkpeZF+Bv8iKm6DugokgbaabKiA/ AIPrwmb72FJ5XqPxIPZjql1DBl30Q0d6kW/KGrUMvebceoMAC2P2AOmydWgZkqZ3LPij HkGLnk2HY51AHXmXEOFqqMVXP6duLKDJzQ13sJ6EfQORRIXaefHawfDKCKaPevPlrEha x9Tg== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ZvshVGqJ; spf=pass (google.com: domain of hodges.r@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=hodges.r@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.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=5TtQXMEppOw57nahaeRqkh31o0YqXnyn4YNRJzLHP1w=; b=VmbcVq+ebyszsuYRAm/I6mHNR95Lf+44a/aqskyEkhAf9BNqccqCPq4lamsugk23s7 HV9M6CqxOz/3FXly52BaJr/4WWHeYEEwpqNMcdCthi/uSov7hxT6PgLEIn6K9bU9buNo YeTRZWQ63IReYpnkZ46M4BknE2LZ2nyXcb4jmiWuhlSOeuaxYGH36laMPp1CUYCOZYAr oW6SbrOyiO6ppHH8ecjS0PXDtcYMeVJXJUQMRBTb6A23M6VbQvYG3N4b+6zzynUHVgdg /8IXRbIbNtbcQu7BG5IU9HsaUQHqQ7pm3b57JP2xaGs9PSW0DEqihzgINhPRGoibACTa Y79Q== 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=5TtQXMEppOw57nahaeRqkh31o0YqXnyn4YNRJzLHP1w=; b=B2K/JCJ/5KRFOBe+6466TRaSDCqb0mrSOSJ97I3wjT0wPXptZ0oWFnYSIZ0rGPm28L DaQXpiOHvwnmgdBeFpWUNvWMfqZZrPXWiKnKLcmSLNYKSE5b2lT6KN9v/7VjohDR5u3k a76Yxnht1XsArf9MXd5/H7e+4vXHgJU1MhNWE7Rc1BmBLVwCOQWaLym1Mxjp0xzmtoHO 5sh3Hv4lSnc+YLAugy1+f0AsYDAXNchr5diAJi90+HRrFHpoJBR2kxAb6LycWsTtLJFH aT/xQJWQrYnA9fK58nQlhMMp9qFhZ2n6h+ax9F3ukHwUimz3AorRVfs3gscNXmJBntav YC8Q== X-Gm-Message-State: AKwxytdJsoomE48Bz7huy4cdhCyKugc3wQMQT1F00j7Tg58hRMtAZuVX W5/q0uGGD+cbt4LNktW7aNzkRw== X-Google-Smtp-Source: ACJfBosLzG3zSlXfFjS+jC4kMOg9UIPDemIHcWQZl6sbux4V3pJeZIOLd/xuIAphvClS1fnkm5KGeQ== X-Received: by 10.107.190.70 with SMTP id o67mr10307347iof.59.1515947096883; Sun, 14 Jan 2018 08:24:56 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.148.207 with SMTP id j198ls940450ite.1.canary-gmail; Sun, 14 Jan 2018 08:24:55 -0800 (PST) X-Received: by 10.36.203.131 with SMTP id u125mr12200359itg.78.1515947095548; Sun, 14 Jan 2018 08:24:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1515947095; cv=none; d=google.com; s=arc-20160816; b=Az7bGtsHlVYQ3PvmCZFCI1coZKdO+Ib5jZRkzRV4iqMyvI8KYZEBvJ/5jzttGHee1R leR4pYG81Iq1+AfDjtyR60Xso7yD82jaasv6C3E8hcbRFcDYcGnPYsHg7EjUvJT8S/vg EpXjA+3soimVCHUBPniU5O/56OagvY5p7M31b0f0AbVdj4wH7TyuCUssyJw/p4pGjYtY CuX3X1OlK2SQM+HovKBgxMhINdrm7aA2Qoxsa5XB8SuKh3OS3QLjmAN7FVXRNycmJ/p9 U2ZMU2a+g6RdiW/1dbdaz7CDfl9Eg2Ajz5Ltce8/PlzW1hIavJxyDvdy/kDo/84u8uee 90og== 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=wVirbNTZInVUFONn0SIObTcV5iSWwDq0/fSFMMgcheQ=; b=lRvvg8598uamg7scMMOMzRPO+51oZ+Tltv+7KPg+sVHnUmazkApjIFmrIWIEEm/tGm XizEI8I4We/Hedew+9jq7fgpvW1ww4Oo/fJ98pM0EbyUpRSIzQ/N8XUigZiEEDflvxUn bB0Q2EK7EyUOYlTt7wIdMOUYwCJURZ1gG0wzpZvlOYStP6krTbWLIJ47tpUDZt5C4yLj r+H92B81iTdlijUQvHBxXsOmNj7wrHfsfpWoZgz7QOWEdVLQz2hRcC0MteAhMe02QmLI DNebiUFzJKXhEJiVKyFxF18IbcxrhwPWsKE1OWNsZYwKdJoDctB5i7CHlI9nD81m4WmI MB8w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ZvshVGqJ; spf=pass (google.com: domain of hodges.r@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=hodges.r@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id n204sor13548566ion.229.2018.01.14.08.24.55 for (Google Transport Security); Sun, 14 Jan 2018 08:24:55 -0800 (PST) Received-SPF: pass (google.com: domain of hodges.r@gmail.com designates 209.85.220.65 as permitted sender) client-ip=209.85.220.65; X-Received: by 10.107.135.208 with SMTP id r77mr11148438ioi.248.1515947094997; Sun, 14 Jan 2018 08:24:54 -0800 (PST) Original-Received: by 10.2.126.75 with HTTP; Sun, 14 Jan 2018 08:24:54 -0800 (PST) In-Reply-To: X-Original-Sender: hodges.r@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ZvshVGqJ; spf=pass (google.com: domain of hodges.r@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=hodges.r@gmail.com; dmarc=pass (p=NONE sp=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:36622 Archived-At: --001a113fbfc6187d0c0562bef0f7 Content-Type: text/plain; charset="UTF-8" > This discussion will be pointless until C++ decides what it should do when built-in static analysers discover undefined behaviour. It's obvious to anyone but the isocpp committee what it should do. It should fail to compile and issue a meaningful diagnostic, whenever possible, for any and all UB unless that UB has been specifically opted-in through pragmas and/or attributes. Any other course of action is indefensible. On 14 January 2018 at 16:39, 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. > > > On Sunday, January 14, 2018, wrote: > >> Hello, >> In recent years there is a boom of static analysis - from new languages >> like Rust and Swift to the powerful tools, provided by C++ compilers. >> >> However I don't see it C++ language *mandating* any of these. I have a >> question - is this something the committee is looking into? Is there a >> working group for this? >> If a tool is a lifesaver, why is it not mandatory - who does not what to >> save lifes? >> >> I strongly believe bringing more (any?) static analysis into the >> language is away to keep it modern and relevant, especially, considering >> C++ very static language and has a lot of compile-time information the >> tools can work with. >> >> Any answers and thoughts are welcome. >> >> Now on a concrete idea - to *use static analysis to make *_view classes >> safe(er).* >> >> Here is a suggestion: >> >> struct A_view >> { >> A_view( [[dependent_lifetime]] A&& arg) : _a(&arg) {} >> A* _a; >> }; >> >> Now, given the code above using A_view, after ~A() is called on the >> variable arg points to. will be marked as an error: >> >> A_view ref(A{}); //< OK, no use of ref >> >> A_view (A{}).func(); //< OK , A outlives ref >> >> A_view ref(A{}); >> ref.func(); //< error/warning, ref used after A is destroyed >> >> I believed this can be enforced by *any* compiler, as* long as *these >> limitations apply. >> 1) A_view is not heap allocated >> 2) We forbid *all* uses of ref, not just uses involving _a; >> >> These two limitations are there to avoid tracking lifetime through >> pointers. >> >> Lifetime contract is exclusively b/w ref and *(&arg). >> Considering the compiler is responsible to destroy both of these, it >> *should* be possible to give a error/warning if variable ref is used >> after variable *(&arg) is destroyed. >> Copies of ref do not contribute to lifetime tracking - assumed is the >> view outlives the viewed the same way it is assumed when the view is >> created from a non-rvalue. >> >> Comments are more then welcome, both on the broader topic about mandating >> static analysis and the concrete proposal. >> >> Thanks >> Mihail Naydenov >> >> -- >> 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/is >> ocpp.org/d/msgid/std-proposals/0087c1a4-0b36-40ca-8d43- >> 5bfaf0af62ca%40isocpp.org >> >> . >> > -- > 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/CAFQaeCDQyFB8zoRoBzBJsjQGUi2wJ > VsW8Yn5LRgzAyc0abLiyQ%40mail.gmail.com > > . > -- 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/CALvx3hYc2dwGc%3DU7N7tcnaFpk6Wa-vhNeAgrhQ%3DqCCciF_G9-A%40mail.gmail.com. --001a113fbfc6187d0c0562bef0f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0This discussion= will be pointless until C++ decides what it should do when built-in static= analysers discover undefined behaviour.

It's o= bvious to anyone but the isocpp committee=C2=A0what it should do. It should= fail to compile and issue a meaningful diagnostic, whenever possible, for = any and all UB unless that UB has been specifically opted-in through pragma= s and/or attributes.

=
Any other course of acti= on is indefensible.

<= /span>


On 14 January 2018 = at 16:39, j c <james.a.cooper@gmail.com> wrote:
This discussion will be pointless until C++ de= cides what it should do when built-in static analysers discover undefined b= ehaviour.
Right now they use it as an excuse to generate heavily optimi= sed, but ultimately incorrect, programs instead of just bailing out of the = compile.


On Sunday, January 14, 2018, <mihailnajdenov@= gmail.com> wrote:
Hello,
In recent years there is a boom of static analysis = - from new languages like Rust and Swift to the powerful tools, provided by= C++ compilers.

However I don't see it C++ lan= guage mandating any of these. I have a question - is this something = the committee is looking into? Is there a working group for this?=C2=A0
If a tool is a lifesaver, why is it not mandatory - who does not wha= t to save lifes?

I strongly believe bringing more = (any?) stat= ic analysis into the language is away to keep it modern and relevant, espec= ially, considering C++ very static language and has a lot of compile-time i= nformation the tools can work with.

Any ans= wers and thoughts are welcome.

Now on a concrete i= dea - to use static anal= ysis to make *_view classes safe(er).

Here is a suggestion:

struct A_view
{
=C2=A0 A_vi= ew( [[dependent_lifetime]]=C2=A0 A&& arg) : _a(&arg) {}<= /div>
=C2=A0 A* _a;
};

Now, given the code above using= A_view, after ~A() is called on the variable arg points to. will be marked= as an error:

A_view ref(A{}); //< OK, no use of ref

A_view (A{}).func(); //< OK , A outlives ref
<= div>
A_view ref(A{});
ref.func(); //< error/warning, ref used after A is destroyed=

<= font face=3D"arial,sans-serif">I believed this can be enforced by any compiler, as long as these limitations apply.=
1) A_view is not heap allocated=C2=A0
2) We forbid = all uses of ref, not just u= ses involving _a;

These two limitations are there = to avoid tracking lifetime through pointers.

Lifet= ime contract is exclusively b/w ref and *(&arg).=C2=A0
Considering the compiler is responsible to destroy both of these, it = should be possible to give a error/warning if variable ref is used after variable=C2=A0*(&arg) is destroyed.
Copies of <= /div>

Comments are more then welcome, both on = the broader topic about mandating static analysis and the concrete proposal= ..

Thanks=C2=A0
Mihail Naydenov

--
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-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/0087= c1a4-0b36-40ca-8d43-5bfaf0af62ca%40isocpp.org.

--
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-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/CAFQaeCDQyFB8zoRoBzBJsjQGUi2wJVsW8Yn5LRgzAyc0abLiy= Q%40mail.gmail.com.

--
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/CALvx3hYc2dwG= c%3DU7N7tcnaFpk6Wa-vhNeAgrhQ%3DqCCciF_G9-A%40mail.gmail.com.
--001a113fbfc6187d0c0562bef0f7-- .