220 36618 article Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?Micha=C5=82_Dominiak?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Static analysis and the future of C++ Date: Sun, 14 Jan 2018 15:58:11 +0000 Lines: 290 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="089e08205a5c225f360562be9111" X-Trace: blaine.gmane.org 1515945387 21828 195.159.176.226 (14 Jan 2018 15:56:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 14 Jan 2018 15:56:27 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCA6D5ULVYBRBHX45XJAKGQEPBHMPQQ@isocpp.org Sun Jan 14 16:56:22 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f69.google.com ([209.85.213.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eakdw-0005CW-J1 for gclcip-std-proposals@m.gmane.org; Sun, 14 Jan 2018 16:56:20 +0100 Original-Received: by mail-vk0-f69.google.com with SMTP id d130sf6278823vkf.6 for ; Sun, 14 Jan 2018 07:58:24 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1515945504; cv=pass; d=google.com; s=arc-20160816; b=mYWn5gVtB/p7LJYCeOJS3bAbIVXDoDVBFi89uoRHOZLvNdbL99y2HsGVsgxl20TQHP YPAapxc6n4Re4hjQxZj6+jOqXQnkfgweqKlNf0qRXtQpgqBKDdK9CiaJfc0aeJq8Rp/l cu8e7oaqsxrD9PaEDc3QKfqK6krzvSuzM72UX9hWZUfi8UmeHOcyJMI77CX9MPnUNyPX 2fAMrRAb71sPtmKHtoiTpZGiDpJyOUU3O29cx719yIrhpUoicrXW/gEa9aAxesyG88hN bhnI+l7hk6+TgrFlEsGpkPdP6llA4OWDyfUR2ySJLMku/ZMluSj7cVHCBajCL9Ejs3H9 wXYA== 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:in-reply-to:references:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=GxuEZCtLblQ1p/rBueFaTP8QG/r9J8NJIRpQesZknsA=; b=A7hzRqHdXI8c6AyLchsdyKwZfjHHrMIUYdUIrwuD4RWWqE3aVs/kVmm5+MJNNO/KgR Q3Cdp0YqMeixXenZ2UjjOoEV4qJK9AUsvnPBwz7ELJtuU3mpNEY+Dvhfe7mElKPdfhfs 4fL0gQrRL3+l231cZFVwZa3YkbjbywG3GHtKyft7tJXd1kkXKq6IXYWnKtTAcxoXRtUw lncunTX0kpCaNplQO6nLTMS/sP2M+azvgrR9rENRr6xgNyZT7Dnbk4qnmmpoNYayZSL+ ZosDnqFZHNZIvPR63e/CLiyEOM0E2zNPYt6iSN5J3JISI9RwPcjyTz/lthqn2ueeY8VI FJFQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@griwes-info.20150623.gappssmtp.com header.s=20150623 header.b=OaAFIrzt; spf=neutral (google.com: 209.85.220.41 is neither permitted nor denied by best guess record for domain of admin@griwes.info) smtp.mailfrom=admin@griwes.info DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to: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=GxuEZCtLblQ1p/rBueFaTP8QG/r9J8NJIRpQesZknsA=; b=nsbtpQLXca3DWp4jLeW5nGE3seA6rqXkKObW4qk1j99BQVEIEQJO4xK5zKOH/rE+hC riaAIIMJ7KOfyM8KqcRCavbDpCqgmemaHhESeozVwKnjFjKV5p4YWaGgbADNhjvLRPkr lgGFjx+xRt6pQsvMA3rwS/u/vGG8alCQUZMzpAiqL7hmivvinrX1SCzbkI8+6/KwXOYI 4Dl2IOiN8mtfhpEG/zRtfpy5b+/NnCb5PSGdy7BaFIWCSb9DIUO4covz4d1N3ICx1rPb z4QYP4p1e0+AvypNGXaoP1AATc/GJZ25+ark+UoxV68fRKZ4W2pBriMa//YY3R6WwEXw wL2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to: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=GxuEZCtLblQ1p/rBueFaTP8QG/r9J8NJIRpQesZknsA=; b=khhmIykBZ0Cz0liltG5Rz4i/laTQT09WB11iNLXDVBkjGcnP+SwxKpubYHGiSJU/ow 9nPR7cMgDl9uwi+S/ejSK6F5GZrqYsnyrPxOKGEdtFcx06EU/0m7kykF4sw9BI0CEqaa eKSWiwOzLTKv2SA6ioSD2bvoHWqHkvDMde3bOnwo4LSGVSK8megQqiGnZ1xnjmvU8+6m BScdtfIUG5rFXvYcURCDst1YcPtn5yD253F9R2Sp9SRRMw3FTmxArOgxDi60tD96IVRo e3Hve+kliCaQlwEMKsB3AfTeDpUQmLHCp4rz6r/qKutDkjgNHV1f/1qdF4C0Nugtmj3r z9mA== X-Gm-Message-State: AKwxytfErUrfj17h2BLtKx4W5VQ63FF0LzYa1DEdK70pfz0XVAMcKWhR GI2VCIwQh+ref7YM6ekJPVg= X-Google-Smtp-Source: ACJfBouJfikgT04eMXAeJtsNfCizfWpuolx5jxRnyNcBwQquO93Ds7VYLncS5MvOUoEe4f84vqZlfw== X-Received: by 10.31.194.69 with SMTP id s66mr14864568vkf.90.1515945504220; Sun, 14 Jan 2018 07:58:24 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.176.70.10 with SMTP id m10ls1833834uaa.11.gmail; Sun, 14 Jan 2018 07:58:22 -0800 (PST) X-Received: by 10.31.200.195 with SMTP id y186mr28427149vkf.137.1515945502480; Sun, 14 Jan 2018 07:58:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1515945502; cv=none; d=google.com; s=arc-20160816; b=M3wjOOyS1+P58NHNHsDQD/8uQA/982Cuj/2bhsdXft4w7pxoMhCk+nuGaSozyHew30 +I40zbBTEsdHlFN6PPYCE/qJLZtc/ZAJchrxqtNXAGTDiKMzc68VbaOgRokzZFgIE/od bV+nckOuxJJpUoeU8KN0/xc2kYQgxfJOVY54kfVC7OPa7/bzOOoj7BtJqe6ubkLjWIlL K0AL4uutV5i/wDY5zs9muUyGk8W91Si9qhkwZApf2a+kcz/IxaKSDxPyVb7rsSjI2plQ 1TXqwB5wTcCbCGQSIiwXxKjKr6lR4PQt9pulOh4HwP8Fyhk6JZiXX3QR7nhmZplNCWoN Y+gQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature:arc-authentication-results; bh=Y2KGgp1FibN6Z2A05eB31lEadw01ZaDx0iPhSOrpRHQ=; b=kBB4bq1CS9nmcc5jXywONj1Y5MpdJKVbKzj0EL17NAov8C5JbCXT6ivHmzBlQiRq2C Y6b1hLbMO93gcZPtkE2ARWz0Gqu5E+YSclPxrKhOOZ4l9FiZ38iVy/e9fOcvcGzIdd4K By8iKI7zk9Bj+MkppCW1EMsBI87vJiWWX/cAjMSVnBnzr+fkZ67i7Vygk6wQaR7DV+P9 chfbDbV9s4hLcHJJ3kpH0Y7yNEpMQa083WSWwli3V6rkSI6luQb2nSyUA7qCSVslVFiB 2XLzzFlnLQydRAzHaod3JRKS7wm3tKSh+kHT1/iFlR5Iip7rscWZqBiHNV2azRuyAh97 Xsxw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@griwes-info.20150623.gappssmtp.com header.s=20150623 header.b=OaAFIrzt; spf=neutral (google.com: 209.85.220.41 is neither permitted nor denied by best guess record for domain of admin@griwes.info) smtp.mailfrom=admin@griwes.info Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id n1sor1992727uaa.180.2018.01.14.07.58.22 for (Google Transport Security); Sun, 14 Jan 2018 07:58:22 -0800 (PST) Received-SPF: neutral (google.com: 209.85.220.41 is neither permitted nor denied by best guess record for domain of admin@griwes.info) client-ip=209.85.220.41; X-Received: by 10.176.95.134 with SMTP id b6mr22893832uaj.161.1515945501804; Sun, 14 Jan 2018 07:58:21 -0800 (PST) In-Reply-To: X-Original-Sender: griwes@griwes.info X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@griwes-info.20150623.gappssmtp.com header.s=20150623 header.b=OaAFIrzt; spf=neutral (google.com: 209.85.220.41 is neither permitted nor denied by best guess record for domain of admin@griwes.info) smtp.mailfrom=admin@griwes.info 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:36618 Archived-At: --089e08205a5c225f360562be9111 Content-Type: text/plain; charset="UTF-8" On Sun, Jan 14, 2018 at 4:39 PM 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. > > If you find that your implementation generates an incorrect program out of your code, then file a bug against that implementation. Of course it is meaningless to speak about program correctness when your program violates the rules given by the specification, which includes actually executing through undefined behavior. > 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 > > . > -- 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/CAPCFJdS6%2BvR%3DsfU_-uD%3D_MQ%2BHz0bqfRmwss-ydBdh5yfO4%3DaVA%40mail.gmail.com. --089e08205a5c225f360562be9111 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jan 14= , 2018 at 4:39 PM j c <james= ..a.cooper@gmail.com> 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.

=

If you find that your implementation gener= ates an incorrect program out of your code, then file a bug against that im= plementation.

Of course it is meaningless to speak= about program correctness when your program violates the rules given by th= e specification, which includes actually executing through undefined behavi= or.


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++ language mandating any of these. I have a qu= estion - is this something the committee is looking into? Is there a workin= g group for this?=C2=A0
If a tool is a lifesaver, why is it not m= andatory - who does not what to save lifes?

I stro= ngly 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
{
=C2=A0 A_view( [[dependent_lifetime]]=C2=A0 A&& arg= ) : _a(&arg) {}
= =C2=A0 A* _a;
};

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

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

A_view (A{}).func(); //< OK , A outli= ves ref

<= /font>
A_view ref(A{});
ref.func(); //< error/warning, r= ef 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=C2= =A0
2) We forbid all uses of ref, not just uses involving _a;

Th= ese two limitations are there to avoid tracking lifetime through pointers.<= /div>

Lifetime 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/warnin= g if variable ref is used after= variable=C2=A0*(&arg) is destroyed.
Copies of ref do not contribute to lifetime tr= acking - assumed is the view outlives the viewed the same way it is assumed= when the view is created from a non-rvalue.

Comments a= re more then welcome, both on the broader topic about mandating static anal= ysis 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/0087c1a4-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-propo= sals/CAFQaeCDQyFB8zoRoBzBJsjQGUi2wJVsW8Yn5LRgzAyc0abLiyQ%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/CAPCFJd= S6%2BvR%3DsfU_-uD%3D_MQ%2BHz0bqfRmwss-ydBdh5yfO4%3DaVA%40mail.gmail.com= ..
--089e08205a5c225f360562be9111-- .