220 37386 article Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?B?TWlrbMOzcyBQw6Fs?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: =?UTF-8?Q?Re=3A_=5Bstd=2Dproposals=5D_Re=3A_Enforcing_safe_coding_techni?= =?UTF-8?Q?ques_using_=E2=80=9Csafe=E2=80=9D_and_=E2=80=9Ctrusted=E2=80=9D_function_qualifiers?= Date: Sun, 18 Mar 2018 22:39:41 +0100 Lines: 358 Approved: news@gmane.org Message-ID: References: <245f1f1b-d168-4434-a605-f82bff4a99af@isocpp.org> <85942f26-7a66-4543-9a38-d46a1bdf6cb3@isocpp.org> <9ac56f78-bd1c-48b9-a142-215d1028a826@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000d91cfb0567b6ad00" X-Trace: blaine.gmane.org 1521409063 28123 195.159.176.226 (18 Mar 2018 21:37:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 18 Mar 2018 21:37:43 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCV7TDH354ARBHVZXPKQKGQECLNSH3Y@isocpp.org Sun Mar 18 22:37:39 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ot0-f199.google.com ([74.125.82.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1exfzl-0007Bs-G1 for gclcip-std-proposals@m.gmane.org; Sun, 18 Mar 2018 22:37:37 +0100 Original-Received: by mail-ot0-f199.google.com with SMTP id k18-v6sf8782990otj.10 for ; Sun, 18 Mar 2018 14:39:44 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1521409184; cv=pass; d=google.com; s=arc-20160816; b=sqqRT36DLsa7r+O2a08K6GS/w23H9B2Ucl+HhYtfWelvP01snMGS7w3Yx+WLKDuh4u zXvRBPBN9jsqdslQzNwsDwWb5DQUp23Gcn9XUMjy8tDoAyyCZuub8qWPHMM8OaoKBNZG JVW9+XU45q6t/auqaRHCM13LaMHeFN0smOe2T3HKflA3NAv2/iQcgh9PE/t3Q1TdWbuO 51GgnIa4DKy5E2ScPy0ZvWUpVPBDpScjKNv6nZuPioVXJjdJVhVzq1iX/noC4egt7QTg IcoTjFghM9oyRCwGx6pKbJ/VX0UVg8lIz8Q2iYvyXdNJIuIIbH8kSLx4QuVDKwkFfkTt /88Q== 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=wP7MbpMRAA15ChpsBvdIdFW6KQ7wpvcE2sJ+Abq9/f4=; b=Xui3SnIX7WYeLV0845pxj/HvOoWREnSnom2UsRn4qTXbvG87wjFlwHiQmbSP8JA/DN Zjq326dSLEC2fdyq+m9+ex24C09r9tBpd3+SkB3AZfnzgA18f3ZdxurncXGvLZAr4mfx LeOQx9HEH+UAbi6+e0fdc8TG5aUze3aHdjN2nmLjS+UsTF0IdRJOMmi6K2G2Rxqto2CN sOoXZT8/C92PwU4T3EQb+FtXUuEVIpnZX5tEjSXhyW2bDa3rK9Nvr7BoXts/7YcchpiX Kklv3mLT7zTOcF3lccEjINoaRRCSOFy5iwAcZ/tUvLzjUeL5ivBrv8HcamaNhnNmElVl V2Vg== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=G9pqStZm; spf=pass (google.com: domain of palmiklos@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=palmiklos@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE 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=wP7MbpMRAA15ChpsBvdIdFW6KQ7wpvcE2sJ+Abq9/f4=; b=eDrV5p+D72tfD7wgRV9yIjrcpQ2aX7bLRFVKHtZWfKRC9xq/Ejn5efcYbC2vpJJDAv aIfKwqffQzu5Jo01a33tDNq+nUkDvkGOE6IWvb0IDbFvy4ECDgNqj5IteK49bucoJj69 pQaGCkUNTIuqPIJzaERx6mOgAcOmBiMg9xbcuSA2lxMUxhQmkdZFCxubN/EHZKwtqVxz NQ+1xOiTkOucANh2fQvVIpmrMLT/zffMZtWzqNJfPiwyLaloVK0+01F57IzAGeonc44r TSeFAjsJpxVPjDmZD1XdF+5TWTNgUzcYdOEBTsKFMnAdVrbsa3zjImnFMzaVYrmT/9VP 3Odg== 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=wP7MbpMRAA15ChpsBvdIdFW6KQ7wpvcE2sJ+Abq9/f4=; b=CwtCjQJD3d/rLx8J3NFVp4fxDBLV2raWX96V0Mh7MYx+du13YoDdLWkfTabzzxIf+i YzrLbBAGz8qPyDr8Q3KsTx2GkJeEsoIoQLsHq8Me8iWhxwbmUlqUrYt6XdAi5xcHgKYc U6dqfJPjYm4E15R7EPwtMR9rNIOjtLDCaENf66ZkNGMVjQwKAbDPGuYuRNJ6yLN+M7uW OHnoI/av63+PFnH25oY79Vrhn5VhM+qHXrHHkE6vJaz5EhGffsge8EK94DDnnIxtphqU ptuFn1Kr+J0rQXy+yOJnjOoPubDlarhN/FInwJk1OqJHkYQ2ZCadalgYbEIyKnSykg7A 7Q/g== X-Gm-Message-State: AElRT7GYB5r295qPc8Ozx4ycMy3Mh81ejyhgMeS5Z7fNumT6hy6w7Wsz 3rTW11A52HkqzcXBjc8/BjohDw== X-Google-Smtp-Source: AG47ELub7F9vDlsGkw1tHzpdu8R+egCurnhh/Lvzc1UKsCyaXyXyq1m5kzG/sR4ofkEhBoDbzv6yCA== X-Received: by 2002:a9d:46a:: with SMTP id 97-v6mr3307446otc.87.1521409184096; Sun, 18 Mar 2018 14:39:44 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.202.93.10 with SMTP id r10ls1395886oib.13.gmail; Sun, 18 Mar 2018 14:39:42 -0700 (PDT) X-Received: by 10.202.98.193 with SMTP id w184mr6038243oib.286.1521409182688; Sun, 18 Mar 2018 14:39:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521409182; cv=none; d=google.com; s=arc-20160816; b=KfCWyivjsPdyGU8zkRgHyiAjzC8WJPwWmCy7WsQAzcnb3tek2jU5t3/cCEAgLBS3+G RgZliKO7OiDF86/RhK0L7CaF5Z0OhnWFaIuXQERbvaJ4DVSV8AGSelgXz80FN+cp2eiI /36CjZq0LqcfMcdAkR9X3rBEJd2oGf0tR2OfHjpastj3ikppeF/16By7cdDcIQvkiqkX kc7XIKN64Y3Pg8gY1KnUzQ1knPDJqIEqUDn/2eZIIVZlF0P54x8C82wTK3ZjTG3w0LIP eZ2H/fY/B8s+b5zbPrb1TxoB9+ZmCwRmvKZiiffMt4Q2gYUklGddzCVFTwhfhjL14vQ2 BFYQ== 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=W4SFHpk+Iaq7/3D7yKTz9uQnKMYdBHXHZDyuGlE6/e4=; b=FHrbEHisUTtNDw6TwYIqsIVL8xYzX+FqgrBVoxXXNIFfq0FYtDr4AXLIjjNxqowsXW I8YoH70xClFsuuU2VJMXtGrBKxlWtFjdMJfQdllcFicWJID7sDro5+k81RWKN0uij17A tIAEfcb3Dyk0LR6izSi5Gkq/5Itar9Vz4MGgpzPxqZulczSnv2UrwzKt/Djh0BnDAwIZ ip3hMQrtyE1FCF578mbb5lwcpDXzHR+t/sG7rg1dw/17gHKrsS6RaKNZRIlm+8E1g29h FRe4XukHGtP6RUYbJ5q1+LgeRHSxOdAej+8FX3WkJzAXMc4gTUGFzBLoSd3+FIr6XoX7 4KCw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=G9pqStZm; spf=pass (google.com: domain of palmiklos@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=palmiklos@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE 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 f18sor5399389otc.292.2018.03.18.14.39.42 for (Google Transport Security); Sun, 18 Mar 2018 14:39:42 -0700 (PDT) Received-SPF: pass (google.com: domain of palmiklos@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 2002:a9d:fb9:: with SMTP id d54-v6mr6789086otd.340.1521409181947; Sun, 18 Mar 2018 14:39:41 -0700 (PDT) Original-Received: by 2002:a9d:4c0c:0:0:0:0:0 with HTTP; Sun, 18 Mar 2018 14:39:41 -0700 (PDT) In-Reply-To: <9ac56f78-bd1c-48b9-a142-215d1028a826@isocpp.org> X-Original-Sender: palmiklos@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=G9pqStZm; spf=pass (google.com: domain of palmiklos@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=palmiklos@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE 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:37386 Archived-At: --000000000000d91cfb0567b6ad00 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear All, I accept your opoinions, and accept that following my proposal, we can't reach proven code safty. My goal was to make the development of large apps safer by disallowing coding techniquies, which frequently lead to errors, and have safe replacements, but not restrincting the language for the development of the whole source code. Code annotations (pre and post-contions, etc.) with source code analysers probably can provide better safety. ***** Fingers crossed for C++ contracts. ***** Anyway, I clarify some points: >> ...then there is no difference in practice between "trusted" and "unqualified" code True, if we consider the code itself, but my rules allow "trusted" code, but don't allow unqualified code to be called from qualified code. This is the difference. Unqualified code is defined for compatibility. >> ...in "safe"-qualified code, the compiler will be checking that the code is provably correct. No. In my point of view, the compiler doesn't prove correctness of "safe" code, just disallows some unsafe language constructions. >> We already have "provably not undefined behavior"; it's spelled constexpr. I agree, and like this recognition, but my proposal is more about run-time behavior of non-constexpr code. >> That is, we must annotate our "safe"-qualified code with preconditions and postconditions anyway.) In my proposal, I didn't consider code annotations designed for giving additional information for code correctness analyser tools (contracts). I started out from the current C++ language. Such annotations can make unsafe constructions safe again. For example, let's start with the unsafe strlen. If a pre-condition requires that the input is a null-terminated string having a given maximum length, and a code analyser tool can prove that the pre-condition is met on each usage, our call of strlen is safe. I've already used Microsof's SAL annotations and static code analyser, and found it useful for making better, safer code. I'd be glad if such annotations (contracts) appeared in a future C++ standard. On Fri, Mar 16, 2018 at 12:46 AM, Edward Catmur wrote: > > > On Thursday, 15 March 2018 20:36:14 UTC, Arthur O'Dwyer wrote: >> >> On Tuesday, March 13, 2018 at 4:32:51 PM UTC-7, Mikl=C3=B3s P=C3=A1l wro= te: >>> >>> Proposed qualifiers: >>> >>> =E2=80=9Csafe=E2=80=9D: qualifies functions, where unsafe coding techni= ques are not >>> allowed by the compiler. >>> >>> =E2=80=9Ctrusted=E2=80=9D: qualifies functions, where unsafe coding tec= hniques are >>> allowed, but their correctness is proven by the author. >>> >>> Unqualified code: functions, where unsafe coding techniques are allowed= , >>> and their correctness is unknown. >>> >> >> This idea is very similar to Rust in theory. But in practice, in C++, I >> guess I don't see why you need these qualifiers at all. >> >> In the definition of "trusted"-qualified code, you say that the >> correctness of trusted code must be "proven". If this means an informal, >> math-style paper proof, then there is no difference in practice between >> "trusted" and "unqualified" code =E2=80=94 both of them are formally unp= roven and >> unsafe, with some human being standing outside the computer going "hey, >> trust me, I write good code." >> So let's assume that by "proven" you mean in the formal program-proof >> sense: "trusted" code may use unsafe constructs, but it carries a progra= m >> proof of its correctness, using annotations essentially like the Contrac= ts >> proposals coming from people like Lisa Lippincott. The compiler (or some >> compiler-like tool) can read these annotations and check them for >> correctness-of-proof. >> >> So then in the definition of "safe"-qualified code, you say that the >> compiler should disallow "unsafe" coding techniques. The only meaning I = can >> assign to the word "unsafe" here is "coding techniques that (might) lead= to >> program-incorrectness." So, in "safe"-qualified code, the compiler will = be >> checking that the code is provably correct. In other words, there is no >> difference between "safe"-qualified code and "trusted"-qualified code, >> except that in "safe" code we expect to write fewer annotations. (But >> certainly we can't write *no* annotations =E2=80=94 since the compiler i= s to >> check the correctness of our code, we still need to tell the compiler wh= at >> it *means* to be correct! That is, we must annotate our "safe"-qualified >> code with preconditions and postconditions anyway.) >> >> So at this point we have two kinds of code: >> - Code with "sufficiently many" annotations, where the tool is supposed >> to check our work. Safe code has few annotations; trusted code has more >> annotations. >> - Code with no annotations, where we admit that we are doing unsafe >> things (and suppressing the tool) but promise that it's okay. >> (And of course there might be some code with "insufficiently many" >> annotations, which will be rejected by the tool.) >> >> This sounds like it could all be done with something as simple as >> "#pragma checking on" and "#pragma checking off" (say, at function >> granularity). >> I don't think it requires or even suggests any *core language* changes. >> >> It seems to me that the hard work here (which, again, at least some of >> which is being done by the Contracts people) is in designing the >> proof-checking tool and in designing the annotation syntax that allows u= s >> to communicate our invariants to the tool (e.g. the syntax of the operan= ds >> to [[expects:]] and [[ensures:]]). >> >> =E2=80=93Arthur >> >> P.S. =E2=80=94 If there is a flaw in my argument, I think it is that I a= m >> combining both "undesired behavior" and "undefined behavior" under the >> single rubric of "program incorrectness." I think Rust's "safe" correspo= nds >> not to "provably correct" but merely "provably *not undefined behavior*" >> (i.e. each function's precondition is merely "UB has not yet occurred" a= nd >> its postcondition is "UB has still not occurred"). Unfortunately I can't >> see how to achieve "provably *not undefined behavior*" in C++ given the >> existence of multithreading and non-owning references. >> > > We already have "provably not undefined behavior"; it's spelled constexpr= .. > This is achieved by banning access to mutable state external to the > evaluation in question. > > Unfortunately, just because a function is constexpr doesn't mean it's saf= e > to process untrusted user input; a constexpr function only has to be > UB-free on a non-empty subset of inputs. But perhaps this could be a > starting point. > > -- > You received this message because you are subscribed to a topic in the > Google Groups "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this topic, visit https://groups.google.com/a/ > isocpp.org/d/topic/std-proposals/DyAMYDvMPg8/unsubscribe. > To unsubscribe from this group and all its topics, 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/9ac56f78-bd1c-48b9- > a142-215d1028a826%40isocpp.org > > . > --=20 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 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/CAHP9XZGA7gh9P6DBykOxKTKTZWNgyBk_rF3y1EgyFKMkXkN= i1Q%40mail.gmail.com. --000000000000d91cfb0567b6ad00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,

I acc= ept your opoinions, and accept that following my proposal, we can't rea= ch proven code safty.

My goal was to make the development of large a= pps safer by disallowing coding techniquies, which frequently lead to error= s, and have safe replacements, but not restrincting the language for the de= velopment of the whole source code.

Code annotations (pre and post-c= ontions, etc.) with source code analysers probably can provide better safet= y.

***** Fingers crossed for C++ contracts. *****

Anyway, I c= larify some points:

>> ...then there is no differen= ce in practice between "trusted" and "unqualified" code=

True, if we consider the code itself, but my rules allo= w "trusted" code, but don't allow unqualified code to be call= ed from qualified code. This is the difference.
Unqualified c= ode is defined for compatibility.

>> ...in "safe"-qualified code, the compile= r will be checking that the code is provably correct.

N= o. In my point of view, the compiler doesn't prove correctness of "= ;safe" code, just disallows some unsafe language constructions.
>>=20 We already have "provably not undefined behavior"; it's spell= ed constexpr.

I agree, and like this recognition, but my = proposal is more about run-time behavior of non-constexpr code.

>= >=20 That is, we must annotate our "safe"-qua= lified code with preconditions and postconditions anyway.)

In my proposal, I didn't consider code annotations design= ed for giving additional information for code correctness analyser tools (c= ontracts). I started out from the current C++ language. Such annotations ca= n make unsafe constructions safe again. For example, let's start with t= he unsafe strlen. If a pre-condition requires that the input is a null-term= inated string having a given maximum length, and a code analyser tool can p= rove that the pre-condition is met on each usage, our call of strlen is saf= e.

I've already used Microsof's SAL annotations and static c= ode analyser, and found it useful for making better, safer code. I'd be= glad if such annotations (contracts) appeared in a future C++ standard.


On Fri, Mar 16, 2018 at 12:46 AM, Edward Catmur <ed@catmur= ..co.uk> wrote:


On Thursday, 15 March 2018 20:36:14 UTC, Arth= ur O'Dwyer wrote:
On Tuesday, March 13, 2018 at 4:32:51 PM UTC-7, Mikl=C3=B3s P=C3=A1l wr= ote:

Proposed qualifiers:

=E2=80=9Csafe=E2=80=9D: qualifies functions, where unsafe coding techniques are not allowed by the compiler.

=E2=80=9Ctrusted=E2=80=9D: qualifies functions, where unsafe coding techniques are allowed, but their correctness is proven by the author.

Unqualified code: functions, where unsafe coding techniques are allowed, and their correctness is unknown.


Th= is idea is very similar to Rust in theory. But in practice, in C++, I guess= I don't see why you need these qualifiers at all.

=
In the definition of "trusted"-qualified code, you say that = the correctness of trusted code must be "proven". If this means a= n informal, math-style paper proof, then there is no difference in practice= between "trusted" and "unqualified" code =E2=80=94 bot= h of them are formally unproven and unsafe, with some human being standing = outside the computer going "hey, trust me, I write good code."
So let's assume that by "proven" you mean in the form= al program-proof sense: "trusted" code may use unsafe constructs,= but it carries a program proof of its correctness, using annotations essen= tially like the Contracts proposals coming from people like Lisa Lippincott= .. The compiler (or some compiler-like tool) can read these annotations and = check them for correctness-of-proof.

So then in th= e definition of "safe"-qualified code, you say that the compiler = should disallow "unsafe" coding techniques. The only meaning I ca= n assign to the word "unsafe" here is "coding techniques tha= t (might) lead to program-incorrectness." So, in "safe"-qual= ified code, the compiler will be checking that the code is provably correct= .. In other words, there is no difference between "safe"-qualified= code and "trusted"-qualified code, except that in "safe&quo= t; code we expect to write fewer annotations. (But certainly we can't w= rite no annotations =E2=80=94 since the compiler is to check the cor= rectness of our code, we still need to tell the compiler what it means to be correct! That is, we must annotate our "safe"-qualified = code with preconditions and postconditions anyway.)

So at this point we have two kinds of code:
- Code with "s= ufficiently many" annotations, where the tool is supposed to check our= work. Safe code has few annotations; trusted code has more annotations.
- Code with no annotations, where we admit that we are doing unsafe= things (and suppressing the tool) but promise that it's okay.
(And of course there might be some code with "insufficiently many&qu= ot; annotations, which will be rejected by the tool.)

<= div>This sounds like it could all be done with something as simple as "= ;#pragma checking on" and "#pragma checking off" (say, at fu= nction granularity).
I don't think it requires or even sugges= ts any=C2=A0core language changes.

It seems= to me that the hard work here (which, again, at least some of which is bei= ng done by the Contracts people) is in designing the proof-checking tool an= d in designing the annotation syntax that allows us to communicate our inva= riants to the tool (e.g. the syntax of the operands to [[expects:]] and [[e= nsures:]]).

=E2=80=93Arthur

P.S. =E2=80=94 If there is a flaw in my argument, I think it is that I a= m combining both "undesired behavior" and "undefined behavio= r" under the single rubric of "program incorrectness." I thi= nk Rust's "safe" corresponds not to "provably correct&qu= ot; but merely "provably not undefined behavior" (i.e. eac= h function's precondition is merely "UB has not yet occurred"= and its postcondition is "UB has still not occurred"). Unfortuna= tely I can't see how to achieve "provably not undefined behavio= r" in C++ given the existence of multithreading and non-owning ref= erences.

We already have= "provably not undefined behavior"; it's spelled constexpr. T= his is achieved by banning access to mutable state external to the evaluati= on in question.=C2=A0

Unfortunately, just because = a function is constexpr doesn't mean it's safe to process untrusted= user input; a constexpr function only has to be UB-free on a non-empty sub= set of inputs. But perhaps this could be a starting point.

--
You received this message because you are subscribed to a topic in the Goog= le Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/D= yAMYDvMPg8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-prop= osals+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/9ac5= 6f78-bd1c-48b9-a142-215d1028a826%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/CAHP9XZGA7gh9P6DB= ykOxKTKTZWNgyBk_rF3y1EgyFKMkXkNi1Q%40mail.gmail.com.
--000000000000d91cfb0567b6ad00-- .