220 40387 article Path: news.gmane.org!.POSTED!not-for-mail From: Andrew Giese Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: more security concerns Date: Mon, 8 Oct 2018 12:02:59 -0700 (PDT) Lines: 312 Approved: news@gmane.org Message-ID: References: <94d79dd7-ba3b-4bf8-91ed-e5dc02b33670@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1745_459678325.1539025379160" X-Trace: blaine.gmane.org 1539025257 26269 195.159.176.226 (8 Oct 2018 19:00:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 8 Oct 2018 19:00:57 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCWM57OYTMFBBZGT53OQKGQEKIZPRBA@isocpp.org Mon Oct 08 21:00:53 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw1-f72.google.com ([209.85.161.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g9alv-0006hf-2S for gclcip-std-proposals@m.gmane.org; Mon, 08 Oct 2018 21:00:51 +0200 Original-Received: by mail-yw1-f72.google.com with SMTP id n143-v6sf6625877ywd.6 for ; Mon, 08 Oct 2018 12:03:01 -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=XbWG8Iymfm+Vbx9ieJ1WkUdEfc0omaiPjar+CCVIx6U=; b=GRDHSjRmH3/JvkNo204FaMc0yqCD5vkRfGgSEFeqj32YOXFhoe2jpSjShPIpbal7br Y9lxDvBNvsDJeS/RokP/fZ3pphyTXpdKV/8ku2ZVnbHLPlxfmjqajKxYshWeY72xAUbU roOipa43cwzm6KhHaqsxVdjX5rcCIOtqEpMGhFpO3aTu1OiSRed9RuBLrN15d5V+Qf57 MWAxP95BJ/KbpvyJCg3R/mORiA6sGOJ/M1zBg3VBk12FY4PLvKtm47N4jj2PCvLKsQ6D ninZ/CC/Z/lxeC9xDtJvEp/rL+idqR3pT+W5kWP34FO+OKEjrU/OUPTj0NMpI3oe1Qvb xFJg== 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=XbWG8Iymfm+Vbx9ieJ1WkUdEfc0omaiPjar+CCVIx6U=; b=p+dKwfpXCxnFv93+bTen5tZEIb+UElBa/rCTSNTELbtLAOY5wvlquD6kI2B+Ep16Hc EnxUZly8LV5w89AFmyoUlUdY0FdRayjy/CPgrgOZd8hE++8AIQ0B5rl5NvBv0Sa8yp84 dq6Plo4BbxWSLyF43xjqjlu6GVbHk2nAg7sMXq+9VvCdM+3EHlrGKISnUaWm7U30Xg/3 LtSFkCmz7k0OYsDRCnJdK5HmczC8nrFwK8hJgkvJGrLhFn4kCTCbhUUCDiH1lfBmMqAp c/hL9KJfB+IdTPKA+Q6fo+tV7PGlmx3CjwFwDkgZXvs5eJMK4cLoNaE09Ua69TUngW1F UMkA== 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=XbWG8Iymfm+Vbx9ieJ1WkUdEfc0omaiPjar+CCVIx6U=; b=Jj701wHRmbCV9EsfeZHMkvWWhd6d4TH0QLyanxLUQi/QWzuEm/egSa90uJv+q4ohNm hPluohdai/6P0JjlPdEy7LES52/w88SDoUoIH/EuJKVLeUBuWKCNzSuuYOQFPSx+yyTq 59f7qQusTz1/5NBqDpiRrmoCqzWnQ4BFop5GWE74+A9gh9rOkrGa9NcJ3azq2J697G9C H8e1e91Dqg2v1/IRBhi9YC+ce/SlLpSiJK9SfI67/n5oE5ob0XAan3HkgN6JhewgmyjL OJgaqDH8oVuaa9heOMFTzxJKvlxSjTfUtr3B4T9T8q8kVdqcLf/4NHGfBmI9/9dVvDyi TAQA== X-Gm-Message-State: ABuFfoi8W9/Qu1zp1Prw+AOrcwAd7FhAvjHb+/nmV19QjCwWzkUIjkoU VkMGOCTjVfue4nkK+XqOyNEC0A== X-Google-Smtp-Source: ACcGV62u1HYZqlXcjjCeQi72CYgRg5DUEwSvUSO7vxjZodRfbhP6HbfCqxLgDf0It9G9JPfP5guIdQ== X-Received: by 2002:a25:ba50:: with SMTP id z16-v6mr12168169ybj.18.1539025381268; Mon, 08 Oct 2018 12:03:01 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:74d7:: with SMTP id p206-v6ls421079ywc.5.gmail; Mon, 08 Oct 2018 12:03:00 -0700 (PDT) X-Received: by 2002:a81:1a07:: with SMTP id a7-v6mr268717ywa.1.1539025379759; Mon, 08 Oct 2018 12:02:59 -0700 (PDT) In-Reply-To: X-Original-Sender: Gieseanw@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:40387 Archived-At: ------=_Part_1745_459678325.1539025379160 Content-Type: multipart/alternative; boundary="----=_Part_1746_838144756.1539025379161" ------=_Part_1746_838144756.1539025379161 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What about using [[nodiscard]] as a null-statement? Similar to how [[fallthrough]] is a null statement intended to indicate to= =20 the compiler and reader that the fallthrough is intentional, a=20 [[nodiscard]] after an assignment or a memset should indicate that the=20 previous statement was intentional and should not be discarded. e.g.=20 memset(password, 0, PASSWORD_SIZE); [[nodiscard]]; // intentionally store before a free free(password); On Sunday, October 7, 2018 at 9:47:37 AM UTC-5, Daniel Gutson wrote: > > > > El dom., 7 oct. 2018 6:17, > escribi=C3= =B3: > >> >> >> Le dimanche 7 octobre 2018 06:44:28 UTC+2, Daniel Gutson a =C3=A9crit : >>> >>> >>> >>> El vie., 28 de sep. de 2018 a la(s) 11:36, =20 >>> escribi=C3=B3: >>> >>>> I completely understood what you meant, and yes what you are proposing= =20 >>>> is compatible with the current language. >>>> I just wanted to highlight that it might be misleading to have the sam= e=20 >>>> attribute with different meaning when it is used on a function declara= tion,=20 >>>> or on an expression (a declaration is also a statement). >>>> >>>> Also, after some thinking, in this case, the goal is not to force the= =20 >>>> last assignment, but to force the last value of the variable, wherever= the=20 >>>> variable is, even if the variable is both in register and stack. >>>> So in that case, you might be better with a [[undead]] attribute whose= =20 >>>> meaning would be that the object might be accessed after its lifetime = end=20 >>>> and so the last assignment should be kept and propagated to every stor= age=20 >>>> of the object: >>>> >>>> void f() { >>>> [[undead]] int secret; >>>> /* ... */ >>>> secret =3D 0; >>>> } >>>> That wouldn't mean the lifetime of the object is extended and it=20 >>>> becomes valid to access it afterwards. >>>> It would tell the compiler it should behave as-if the object *could*= =20 >>>> be accessed afterwards. >>>> >>> >>> Actually I would like to tell the compiler that the object should NOT b= e=20 >>> accessible afterwards. >>> >> >> What I said is not "the compiler makes the object accessible", but=20 >> "whatever the compiler will do, the object will remain accessible someho= w,=20 >> and so the correctness of the whole program depends on the last value no= t=20 >> being discarded". >> >> Your view is also correct, but a bit more magic: when this "destroy all= =20 >> the places where the object is" is performed? (the right answer is: just= =20 >> after its destructor is called) >> While in what I propose, it is done more explicitly when the last value= =20 >> is assigned. >> >> But both are good. It's just a matter of taste at this point. >> >> However, your first proposal doesn't work that well: ok you tell the=20 >> compiler to keep the assignment. But which location is used for this=20 >> assignment? All of them? The last one? The main one? A new one? >> And if you start standardizing which location should be assigned, then= =20 >> you're not talking about expressions anymore, but about objects. So=20 >> attributes on expressions is not the right tool for you. >> =20 >> >>> Additionally I would like to reuse the existing attribute name, though= =20 >>> this is of least importance now. >>> =20 >>> >> >> Here, I completely disagree.=20 >> > > Ok let's not discuss this. > > It should not be an already existing attribute name unless the feature is= =20 >> close enough to the original attribute. >> And the new meaning you proposed is (at least for me) too far from the= =20 >> original, and is misleading. >> >> An attribute is not a keyword, it is easy to create new ones (easier tha= n=20 >> repurposing an old one?). >> >> --=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "ISO C++ Standard - Future Proposals" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to std-proposal...@isocpp.org . >> To post to this group, send email to std-pr...@isocpp.org . >> To view this discussion on the web visit=20 >> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/dba0bf6d-92= da-440e-8e61-af336cacd537%40isocpp.org=20 >> >> . >> > --=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/c35b213e-cbfd-41e2-a8dd-e5cf93343b8c%40isocpp.or= g. ------=_Part_1746_838144756.1539025379161 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What about using [[nodiscard]] as a null-statement?
Similar to how [[fallthrough]] is a null statement intended to= indicate to the compiler and reader that the fallthrough is intentional, a= [[nodiscard]] after an assignment or a memset should indicate that the pre= vious statement was intentional and should not be discarded.

=
e.g.=C2=A0

memset(password, 0, PASSWORD_SI= ZE);
[[nodiscard]]; // intentionally store before a free
free(password);


On Sunday, October 7, 2018 at 9:47:37 AM UTC-5, Daniel Gutson wrote:<= blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord= er-left: 1px #ccc solid;padding-left: 1ex;">


=
El dom., 7 oct. 2018 6:17, <= ;flor= ia...@gmail.com> escribi=C3=B3:


Le dimanche 7 octobre 2018 06:44:28 UTC+2, Dan= iel Gutson a =C3=A9crit=C2=A0:


El vie., 28= de sep. de 2018 a la(s) 11:36, <floria..= ..@gmail.com> escribi=C3=B3:
=
I completely understood what you meant, and yes what you a= re proposing is compatible with the current language.
I just wanted to h= ighlight that it might be misleading to have the same attribute with differ= ent meaning when it is used on a function declaration, or on an expression = (a declaration is also a statement).

Also, after some thinking, in t= his case, the goal is not to force the last assignment, but to force the la= st value of the variable, wherever the variable is, even if the variable is= both in register and stack.
So in that case, you might be better with a= [[undead]] attribute whose meaning would be that the object might be acces= sed after its lifetime end and so the last assignment should be kept and pr= opagated to every storage of the object:

void f() {
=C2=A0 [[undead]] int secret;
=C2=A0 /* ... */
=C2=A0 secret =3D 0;<= br>}
That wouldn't mean the lifetime of the objec= t is extended and it becomes valid to access it afterwards.
It would tel= l the compiler it should behave as-if the object could be accessed a= fterwards.

Actually I would like = to tell the compiler that the object should NOT be accessible afterwards.

What I said is not "t= he compiler makes the object accessible", but "whatever the compi= ler will do, the object will remain accessible somehow, and so the correctn= ess of the whole program depends on the last value not being discarded"= ;.

Your view is also correct, but a bit more magic= : when this "destroy all the places where the object is" is perfo= rmed? (the right answer is: just after its destructor is called)
= While in what I propose, it is done more explicitly when the last value is = assigned.

But both are good. It's just a matte= r of taste at this point.

However, your first prop= osal doesn't work that well: ok you tell the compiler to keep the assig= nment. But which location is used for this assignment? All of them? The las= t one? The main one? A new one?
And if you start standardizing wh= ich location should be assigned, then you're not talking about expressi= ons anymore, but about objects. So attributes on expressions is not the rig= ht tool for you.
=C2=A0
Additionally I wou= ld like to reuse the existing attribute name, though this is of least impor= tance now.
=C2=A0

Here, I completely disagree.

Ok let's not discuss this.

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
It should not be an alr= eady existing attribute name unless the feature is close enough to the orig= inal attribute.
And the new meaning you proposed is (at least for= me)=C2=A0 too far from the original, and is misleading.

An attribute is not a keyword, it is easy to create new ones (easier= than repurposing an old one?).

--
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-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com= /a/isocpp.org/d/msgid/std-proposals/dba0bf6d-92da-440e-8e61-= af336cacd537%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 https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/c35b213e-cbfd-41e2-a8dd-e5cf93343b8c= %40isocpp.org.
------=_Part_1746_838144756.1539025379161-- ------=_Part_1745_459678325.1539025379160-- .