220 37324 <1a250082-a1d8-4f36-93a3-8540056ff279@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: =?UTF-8?Q?=5Bstd=2Dproposals=5D_Re=3A_Enforcing_safe_coding_techniques?= =?UTF-8?Q?_using_=E2=80=9Csafe=E2=80=9D_and_=E2=80=9Ctrusted=E2=80=9D_function_qualifiers?= Date: Tue, 13 Mar 2018 19:51:36 -0700 (PDT) Lines: 188 Approved: news@gmane.org Message-ID: <1a250082-a1d8-4f36-93a3-8540056ff279@isocpp.org> References: <245f1f1b-d168-4434-a605-f82bff4a99af@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4001_1572353424.1520995896437" X-Trace: blaine.gmane.org 1520995776 26482 195.159.176.226 (14 Mar 2018 02:49:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 14 Mar 2018 02:49:36 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBOM4ULKQKGQETMP7FOA@isocpp.org Wed Mar 14 03:49:31 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f72.google.com ([209.85.213.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1evwTr-0006ms-Jg for gclcip-std-proposals@m.gmane.org; Wed, 14 Mar 2018 03:49:31 +0100 Original-Received: by mail-vk0-f72.google.com with SMTP id h23sf1220610vke.20 for ; Tue, 13 Mar 2018 19:51:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=OulRsEVpNAuCC9/g71AU+Yw4vdYiRvUAX/dO5nQDJ/A=; b=MfeRvgSJM6MzQxkJDwQqstjNaRlsEJwit44Ij4V50ouHq4pUKgKfdxVxzhgUndq2gd G3B4PSRsu52iIaxCiwCfv0pb26yzR+9YgnKuoEpXyXjRP5nS16+rcN2nJqUmYxQWlcv0 HxOheuNV/YST1r/e5OZmznZ42bFe2TBtDtEPwtesm3vBIZ+/QRCv7fFAbGGIB6hZr9Ae Lh385VckZD6k4xmIO7bBXV7MJItkNvNWorBtzdfh/m364fCfW+FzNnTgMZ2vGCvcW8LR O6OvI3mJSWgRMvcM4XkpwyzsRb9DwGmmgxBmPhWzEK9Q/jct8tFFUpm4Qb/7Xf6UoVyn PgfQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=OulRsEVpNAuCC9/g71AU+Yw4vdYiRvUAX/dO5nQDJ/A=; b=DAd/XcYx4UBQl51mB6tl1JVOobsfymO50FjBBN70gL5buRqNiTZDsO4+vHQTrgrRt2 0kEhw6fyyX+lKNmpfDXKEqQ+DChPvJQGCwPmglpO4V6PgUz94Y6ThR3Mp5bnXowzCqQR hgU8shzC7KUa00pQVvcooot6CGCS7Mjhb8GuA2SRBEjddFT/msVZG0pPD+p+mRxtrCUd 2kPMU+197nWB+GPHVvu1pKpp3kmkj7sX8RvB3jG9vw8vovOrmsQ8rZV56+Pz4qbVk5oC FpuByrbeuOzQYg1BMq5XP4B7gQzB6JOcNIOT6mXghYue9BceuxxMuCwqv6D2zrx7vtgr Ui5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=OulRsEVpNAuCC9/g71AU+Yw4vdYiRvUAX/dO5nQDJ/A=; b=T78eN6j6RWBR5n6NhLW5K2Zl23gj3mMQZtX1uKQ3/gbmpYRHj7+9oAbLxGXaS8MSSO zcpkyUjWRN81jju3EgmAigSSv5Ld7HZhjb0/4ruSh4Nq0Bu8eX9NLVk/GKbef2+7OKy4 gOGPMz2KuWPU4Do4XCijAC4ZBCI/0JCSTrttuYGpOnF6hsF8qpK1KmH/0TDWSrOma9a1 j+zIGo+4YO+U8Se13kX3YXQvyUdQdQNakKqwanpx5SdrI/rFbGsQDmnpkkdZZqCin7Fa ErY18ewZyICRQFNno4xJw2wlG9mPzXA3wFYfsKjL0xmeo9j/oQoEzkrbfWuW0CKMkb1t onJw== X-Gm-Message-State: AElRT7FYYZ9028JGiXZr6G2wxPaVg1fs7CSyf/4WSOtjvcuzvMozQa/t OycT0nmN8h93eXBWPIa4MGzntg== X-Google-Smtp-Source: AG47ELvJBF0hPteNoOhBCFqGiaDOLDTpAbrktGNCa3J8/bhS9GuI0+EPFe9J9itA+GJb+spYLTiyGg== X-Received: by 10.31.201.194 with SMTP id z185mr13175vkf.78.1520995898320; Tue, 13 Mar 2018 19:51:38 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.232.6 with SMTP id f6ls278734vkh.6.gmail; Tue, 13 Mar 2018 19:51:37 -0700 (PDT) X-Received: by 10.31.180.79 with SMTP id d76mr381807vkf.7.1520995896990; Tue, 13 Mar 2018 19:51:36 -0700 (PDT) In-Reply-To: <245f1f1b-d168-4434-a605-f82bff4a99af@isocpp.org> X-Original-Sender: jmckesson@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:37324 Archived-At: ------=_Part_4001_1572353424.1520995896437 Content-Type: multipart/alternative; boundary="----=_Part_4002_1590594207.1520995896437" ------=_Part_4002_1590594207.1520995896437 Content-Type: text/plain; charset="UTF-8" Consider this: struct S { shared_ptr ptr; int val; }; auto ptr1 = make_shared(nullptr, 4); auto ptr2 = make_shared(ptr1, 6); auto ptr3 = make_shared(ptr2, -3); ptr1.ptr = ptr3; Ignore the fact that `make_shared` doesn't work with aggregates. Can you provide a simple rule which would let the compiler decide that this code is "unsafe"? What if each of those pointer creation and assignment functions were hidden behind several layers of functions, so that the compiler can't see everything? Just because all individual parts are "safe" doesn't mean that the whole is. And if you're going to define a subset of C++ that you consider "safe", it had better *actually be safe*. The last thing C++ programmers need is having language features that give them a false sense of security about how "safe" their code is. Now consider this: int arr[3] = {5, 2, -13}; arr[1] = 6; This is perfectly, 100% functional code. Given everything we can see here, there is zero chance of UB or other such. Would this be considered "safe" code? And if not, why not? From your description of the actions you want to consider "unsafe", what you really mean is "low-level" or "not-modern". Neither is genuinely "safe"; it may be "safe*r*", but that's a lot different from "safe". And that sort of thing is far better left up to each individual programmer and their static analysis tools of choice. -- 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/1a250082-a1d8-4f36-93a3-8540056ff279%40isocpp.org. ------=_Part_4002_1590594207.1520995896437 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Consider this:

struct S
{
=C2=A0 shared_ptr<S> ptr;=
=C2=A0= int val;
};

auto ptr1 =3D make_shared<S= >(nullp= tr,= 4);
auto ptr2 =3D make_shared<S>= (ptr1, 6);
auto ptr3 =3D make_shared<S<= /span>>(ptr2, -3);
ptr1.pt= r =3D ptr3;

Ignore the fact that `make_shared` doesn't work with aggregates. = Can you provide a simple rule which would let the compiler decide that this= code is "unsafe"? What if each of those pointer creation and ass= ignment functions were hidden behind several layers of functions, so that t= he compiler can't see everything?

Just because all individual pa= rts are "safe" doesn't mean that the whole is. And if you'= ;re going to define a subset of C++ that you consider "safe", it = had better actually be safe. The last thing C++ programmers need is = having language features that=20 give them a false sense of security about how "safe" their code i= s.

Now consider this:

int arr[3= ] <= span style=3D"color: #660;" class=3D"styled-by-prettify">=3D {5, 2, -13};
arr[1] =3D 6;

This is = perfectly, 100% functional code. Given everything we can see here, there is= zero chance of UB or other such. Would this be considered "safe"= code? And if not, why not?

From your description of the actions you= want to consider "unsafe", what you really mean is "low-lev= el" or "not-modern". Neither is genuinely "safe"; = it may be "safer", but that's a lot diff= erent from "safe".

And that sort of thing is far better le= ft up to each individual programmer and their static analysis tools of choi= ce.

--
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/1a250082-a1d8-4f36-93a3-8540056ff279= %40isocpp.org.
------=_Part_4002_1590594207.1520995896437-- ------=_Part_4001_1572353424.1520995896437-- .