220 36616 article Path: news.gmane.org!.POSTED!not-for-mail From: j c Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Static analysis and the future of C++ Date: Sun, 14 Jan 2018 15:39:04 +0000 Lines: 239 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="94eb2c0b04de2e3d1c0562be4ce9" X-Trace: blaine.gmane.org 1515944231 15995 195.159.176.226 (14 Jan 2018 15:37:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 14 Jan 2018 15:37:11 +0000 (UTC) To: "std-proposals@isocpp.org" Original-X-From: std-proposals+bncBCR6HLXQUAORBGPT5XJAKGQEK6YNT3Q@isocpp.org Sun Jan 14 16:37:06 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f199.google.com ([209.85.161.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eakLG-0003bb-VW for gclcip-std-proposals@m.gmane.org; Sun, 14 Jan 2018 16:37:03 +0100 Original-Received: by mail-yw0-f199.google.com with SMTP id b11sf535482ywc.16 for ; Sun, 14 Jan 2018 07:39:07 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1515944346; cv=pass; d=google.com; s=arc-20160816; b=wazuKUG2ZevHMJGuQf3MJJXv/Jtc8m01zZiR5VeD63xaUEqyCvK1VBH4ZZYWOAKL73 NsdPMcMtSVA5RO6iHJk+9KJ0VaHeIKopsMK3dcIcFVSdflcYo2oZwKG+oQa7TplzLBui lHRCgAtHRTiIQv6Xfi2yPJOH3tNiObxiV/XEPrRPMjGte4DfRv/634I0Q1dj2KJOL+VQ RMEzJcwMgBYj60uWlU8nTIGnXwvRz1C7oe7dIFR7fPYnJ2iaaQqtxKUThvlHNv8YV+QW wEcovatZYpqRCAetSS8GTtUW8VRaumwI13SKLQFYuL2k2i+nb3KB4yzt/iWJAJqHiP4r OFqg== 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=+t6I+9Xk4rX0k7MIJLxwucKgl9ZkIjh3nz2xLYE4wWk=; b=oWXeuBdfbsLb0N/xu9ckOqc8eTrgF1v+0oZu91XYeaZQ1jSvQbdx+F/i+Dtgfs2PCS j6CgdzSx5bd16Se4R09ZoQoW0br7bfaHeQm4GsGfkUyAt086qBeUFzamT/PTmxMRByuG 5EBm9gvzUINLQw5R4bCvrnK9PXmMY4lv3vGWHfwElilqTSw7iXeqcZMGoI+MuzLY0CZI lCRXJCXWddoeVNBblfvnBqZvxeNLEinsq7ogmSP1Cj7hkAw5xX9fAcE0P099nds6QtnS EE7i+PZwJT/WnxbaXfcb16MXFKA4P/Tp+KxmkmYdJwxDsVIwb0hRxvb1m2kR2hehwITr ZVHw== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=cz3K20dU; spf=pass (google.com: domain of james.a.cooper@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=james.a.cooper@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=+t6I+9Xk4rX0k7MIJLxwucKgl9ZkIjh3nz2xLYE4wWk=; b=ufUiccUeo+5PQ4zjN4Ccdw2F026cTzsbQGYRbvHpkCYfeaizLPBbiDyTR2Y11b9I+j PWyRsrtTzGLrLipq8cgfG3utPFoxuuNvNs0D/EeAwdTRJlXc7/fSfHGdOmvycSS56wNI MYeQ0u074bgeYxf+xvq/qwgf7sHXWDSVERjHCOY/tkeEu5epJ+P42gZo3MAMEUwGqUgm Ye8bnpcNK1TeANDnSI/HsqJ1+02JPT90Kx7APnWcG80Nh1oe/yG02DzxzOGpvKUsKF9n gkWqm7FHbbWR20BlduqK9K9MRGeHDbaXvSkIMIwe1/NYRzEIECjSnBEUaih6MOuCAILY ttoQ== 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=+t6I+9Xk4rX0k7MIJLxwucKgl9ZkIjh3nz2xLYE4wWk=; b=VRWgnTzbbLeoTe0M8cJvGcGInnypaLg7v8EypSI0ydRhPjyBOAMJwQ5SGz1mozUmKP kbGOMJbglFV1M4R76lOw1f7xtlFY1WKQP9vlgcIpmAER2g131onFj7S0VN/ldOzM7FRo kHXQhbHZ6AyO28mwB2BqU5OM1owAJC1XiKQ+p7MuXt2fwyjt/X7hKZSdSlvduT+9Js9A APA/ME2ret1Ai6p9gqrKmydMUzxwvZTVxQhyHDqwPEESvkzViwK+G/pPEOfCjCLFmx8V oLrkPsOHbBhcaL5fYMLTXCBRQ7vkaENG0qvuCN5M9biOM0CJpoRPIZmGgt9xKQ8uJfX7 sS/Q== X-Gm-Message-State: AKwxytclFRfxN7CxIQo3lIZuN/1Bt7zhLc0L2LQEBZSwoTdzZcxIW9V4 CW8oY9ap73ftAZQcIOf3pEZj+w== X-Google-Smtp-Source: ACJfBotgQ5lKW3S+q+YcEsUgqXQnLIxQbSdVdBZ9oaNFO8pnGA+LB7jP1I+N22wfCEjMx8N035J/sw== X-Received: by 10.129.68.6 with SMTP id r6mr8292445ywa.213.1515944346525; Sun, 14 Jan 2018 07:39:06 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.37.171.207 with SMTP id v73ls278502ybi.17.gmail; Sun, 14 Jan 2018 07:39:05 -0800 (PST) X-Received: by 10.13.216.74 with SMTP id a71mr20079916ywe.128.1515944345376; Sun, 14 Jan 2018 07:39:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1515944345; cv=none; d=google.com; s=arc-20160816; b=eHSA8RBbxAsgMUiq+9hd2eOt3QK9VVH+UdOJwWl5MtN7LORlL88SfGMmNVAJMSSSNf Jhwrl91GDBTsb7d6Ur/M8dUndMgg44WmVCFVisUBQbzl+f+JHSmknfjJBkDKxzMYNi6J u1cuYfwp9d1u+IAlOO4/3JfaiJngs5hN2K3WQrZukOyfMxpzMMxi1KZwIrUjkVVXks2j PgbG/96u3yFva+aELt3myxmQy7bAXuvh4VOLsD0zWHEi7nkpxdxci1IeScvU8FfaRjDR xALtaP+LPrpRrlSerYGYVu1pZNeQ0AsFVH56sZncdDF9ZEeoFn878wBSzzeWaKO04zpR WpIA== 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=e1ViUDcPKBYOW3EWKfYH5ZyF0CwurfdxTxgTT5G/wxE=; b=Vb8bwYxGeODKoczRrr0HVDeeiDx0Pg5VRFYtk+bxm5Z2hvA57p53ea7TeEYbNIqGrE +E7FtzRsqcTy6CEOJfim7jrXrGrX4j/mEzzMRsV/YQx/m3FPlSqU2oJnwwmbYI4HHdcK T7N+kpVliKhCmC263OfrCcBBrwdoMjBzy1fyLqTfa2uzdaQ7e0korily9hCoFtt8Ilks IueNtT0bCN++/74NhbpoT2UknYK23XPDaZTr1fVUeIt5h8+8VIIi34YuceutAuKe4yoU 7k7VYfaWZJtU6ynrsQAJ0sZE1yDvp8EfcwdZ5CNaCV0D57iAW9QU2VUtkPuR/AYefB3o D1+w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=cz3K20dU; spf=pass (google.com: domain of james.a.cooper@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=james.a.cooper@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.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 k3sor7752764ywl.165.2018.01.14.07.39.05 for (Google Transport Security); Sun, 14 Jan 2018 07:39:05 -0800 (PST) Received-SPF: pass (google.com: domain of james.a.cooper@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 10.129.120.85 with SMTP id t82mr13323966ywc.369.1515944344958; Sun, 14 Jan 2018 07:39:04 -0800 (PST) Original-Received: by 10.37.160.3 with HTTP; Sun, 14 Jan 2018 07:39:04 -0800 (PST) In-Reply-To: <0087c1a4-0b36-40ca-8d43-5bfaf0af62ca@isocpp.org> X-Original-Sender: james.a.cooper@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=cz3K20dU; spf=pass (google.com: domain of james.a.cooper@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=james.a.cooper@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:36616 Archived-At: --94eb2c0b04de2e3d1c0562be4ce9 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. 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/ > isocpp.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/CAFQaeCDQyFB8zoRoBzBJsjQGUi2wJVsW8Yn5LRgzAyc0abLiyQ%40mail.gmail.com. --94eb2c0b04de2e3d1c0562be4ce9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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, Ja= nuary 14, 2018, <mihailnajd= enov@gmail.com> wrote:
Hello,
In recent years there is a boom of static anal= ysis - from new languages like Rust and Swift to the powerful tools, provid= ed by C++ compilers.

However I don't see it C+= + language mandating any of these. I have a question - is this somet= hing 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 what to save lifes?

I strongly believe bringin= g 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 con= crete idea - to use stat= ic analysis to make *_view classes safe(er).

Here is a suggestion:

struct A_view
{
=C2= =A0 A_view( [[dependent_lifetime]]=C2=A0 A&& arg) : _a(&arg) {}=
=C2=A0 A* _a;=
};

Now, given the code abo= ve using A_view, after ~A() is called on the variable arg points to. will b= e 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= {});
re= f.func(); //< error/warning, ref used after A is d= estroyed

I believed this can be enforced by <= i>any compiler, as long as these limitations apply.
1) A_view is not heap allocated=C2=A0
2) We fo= rbid all uses of ref, no= t just uses involving _a;

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

Lifetime contract is exclusively b/w 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 ref do not contribute to lifetime tracking - assumed is th= e view outlives the viewed the same way it is assumed when the view is crea= ted from a non-rvalue.=

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

Thanks=C2=A0
Mihail Nay= denov

--
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-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 htt= ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFQaeCDQyFB8zoRo= BzBJsjQGUi2wJVsW8Yn5LRgzAyc0abLiyQ%40mail.gmail.com.
--94eb2c0b04de2e3d1c0562be4ce9-- .