--000000000000ac260d0576ec8de4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Again, on the DSE related optimizations.

I'm at the Ekoparty where I will show a presentation about security
vulnerabilities caused by compiler optimizations. The subject is more and
more serious (e.g. [1]).

I want to propose to allow [[nodiscard]] in individual expressions, such as
calls to memset(), std::fill_n, and assignments (DSE happens with both
memory and registers).

Ideas? Co-authors?

--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=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/CAFdMc-0NqfbqeOhhH1YiVGxDRVPv7COKNqge3mLu8UE8Sgc=
XNw%40mail.gmail.com.

--000000000000ac260d0576ec8de4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Again, on the DSE related optimizations.<div><br></div><di=
v>I&#39;m at the Ekoparty where I will show a presentation about security v=
ulnerabilities caused by compiler optimizations. The subject is more and mo=
re serious (e.g. [1]).</div><div><br></div><div>I want to propose to allow =
[[nodiscard]] in individual expressions, such as calls to memset(), std::fi=
ll_n, and assignments (DSE happens with both memory and registers).</div><d=
iv><br></div><div>Ideas? Co-authors?=C2=A0<br clear=3D"all"><div><br></div>=
-- <br><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_s=
ignature">Who=E2=80=99s got the sweetest disposition?<br>One guess, that=E2=
=80=99s who?<br>Who=E2=80=99d never, ever start an argument?<br>Who never s=
hows a bit of temperament?<br>Who&#39;s never wrong but always right?<br>Wh=
o&#39;d never dream of starting a fight?<br>Who get stuck with all the bad =
luck? </div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-0NqfbqeOhhH1YiVGxDRVPv7COKNqge=
3mLu8UE8SgcXNw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-0NqfbqeOhh=
H1YiVGxDRVPv7COKNqge3mLu8UE8SgcXNw%40mail.gmail.com</a>.<br />

--000000000000ac260d0576ec8de4--

.

--0000000000004b713d0576ee7dd1
Content-Type: text/plain; charset="UTF-8"

I like the idea.
Function poisoning might also serve your needs. E.g.,
https://www.fluentcpp.com/2018/09/04/function-poisoning-in-cpp/

If gcc poison were standardized in some fashion, you could write your own
wrappers to those functions with all the [[nodiscard]] you might want.

Control in that case is a little less granular, indeed. Probably if you're
writing [[nodiscard]] on a per-expression basis you are not discarding the
result already.

Regards

--
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/CAO8_tC4kNZ6s-xMXo69n1D3dbOMkqt0fjLU44Uq5TfABp17hQQ%40mail.gmail.com.

--0000000000004b713d0576ee7dd1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div>I like the idea.<div dir=3D"auto">Function poisoning=
 might also serve your needs. E.g.,=C2=A0<a href=3D"https://www.fluentcpp.c=
om/2018/09/04/function-poisoning-in-cpp/" target=3D"_blank" rel=3D"noreferr=
er">https://www.fluentcpp.com/2018/09/04/function-poisoning-in-cpp/</a></di=
v><div dir=3D"auto"><br></div><div dir=3D"auto">If gcc poison were standard=
ized in some fashion, you could write your own wrappers to those functions =
with all the [[nodiscard]] you might want.</div><div dir=3D"auto"><br></div=
><div dir=3D"auto">Control in that case is a little less granular, indeed. =
Probably if you&#39;re writing [[nodiscard]] on a per-expression basis you =
are not discarding the result already.</div><div dir=3D"auto"><br></div><di=
v dir=3D"auto">Regards</div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAO8_tC4kNZ6s-xMXo69n1D3dbOMkqt0fjLU4=
4Uq5TfABp17hQQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAO8_tC4kNZ6s-xMX=
o69n1D3dbOMkqt0fjLU44Uq5TfABp17hQQ%40mail.gmail.com</a>.<br />

--0000000000004b713d0576ee7dd1--

.

--000000000000a2033c0576ee8b90
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Yeah.  But please note that this is not only for function calls.

void f()
{
   int secret;
   ....
   secret =3D 0;  //removed due to DSE
}

If I declare secret as volatile or write 0s to its address I may prevent
the compiler to use a register impacting in performance. That's why I want
to use the attribute here too.



El vie., 28 sept. 2018 10:32, Andrew Giese <gieseanw@gmail.com> escribi=C3=
=B3:

> I like the idea.
> Function poisoning might also serve your needs. E.g.,
> https://www.fluentcpp.com/2018/09/04/function-poisoning-in-cpp/
>
> If gcc poison were standardized in some fashion, you could write your own
> wrappers to those functions with all the [[nodiscard]] you might want.
>
> Control in that case is a little less granular, indeed. Probably if you'r=
e
> writing [[nodiscard]] on a per-expression basis you are not discarding th=
e
> result already.
>
> Regards
>
> --
> 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/CAO8_tC4kNZ6=
s-xMXo69n1D3dbOMkqt0fjLU44Uq5TfABp17hQQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAO8_tC4kNZ=
6s-xMXo69n1D3dbOMkqt0fjLU44Uq5TfABp17hQQ%40mail.gmail.com?utm_medium=3Demai=
l&utm_source=3Dfooter>
> .
>

--=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/CAFdMc-1DpAUkYDVyNmP5H49XyNVDq5_T6UkEVaQGMGA0YEh=
NGw%40mail.gmail.com.

--000000000000a2033c0576ee8b90
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div>Yeah.=C2=A0 But please note that this is not only fo=
r function calls.<div dir=3D"auto"><br></div><div dir=3D"auto">void f()</di=
v><div dir=3D"auto">{</div><div dir=3D"auto">=C2=A0 =C2=A0int secret;</div>=
<div dir=3D"auto">=C2=A0 =C2=A0....</div><div dir=3D"auto">=C2=A0 =C2=A0sec=
ret =3D 0;=C2=A0 //removed due to DSE</div><div dir=3D"auto">}</div><div di=
r=3D"auto"><br></div><div dir=3D"auto">If I declare secret as volatile or w=
rite 0s to its address I may prevent the compiler to use a register impacti=
ng in performance. That&#39;s why I want to use the attribute here too.</di=
v><div dir=3D"auto"><br></div><br><br><div class=3D"gmail_quote"><div dir=
=3D"ltr">El vie., 28 sept. 2018 10:32, Andrew Giese &lt;<a href=3D"mailto:g=
ieseanw@gmail.com">gieseanw@gmail.com</a>&gt; escribi=C3=B3:<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"auto"><div>I like the idea.<div dir=
=3D"auto">Function poisoning might also serve your needs. E.g.,=C2=A0<a hre=
f=3D"https://www.fluentcpp.com/2018/09/04/function-poisoning-in-cpp/" rel=
=3D"noreferrer noreferrer" target=3D"_blank">https://www.fluentcpp.com/2018=
/09/04/function-poisoning-in-cpp/</a></div><div dir=3D"auto"><br></div><div=
 dir=3D"auto">If gcc poison were standardized in some fashion, you could wr=
ite your own wrappers to those functions with all the [[nodiscard]] you mig=
ht want.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Control in that=
 case is a little less granular, indeed. Probably if you&#39;re writing [[n=
odiscard]] on a per-expression basis you are not discarding the result alre=
ady.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Regards</div>
</div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank" rel=3D"noreferrer">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">std-proposals@isocpp.org</a>.<br=
>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAO8_tC4kNZ6s-xMXo69n1D3dbOMkqt0fjLU4=
4Uq5TfABp17hQQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 target=3D"_blank" rel=3D"noreferrer">https://groups.google.com/a/isocpp.or=
g/d/msgid/std-proposals/CAO8_tC4kNZ6s-xMXo69n1D3dbOMkqt0fjLU44Uq5TfABp17hQQ=
%40mail.gmail.com</a>.<br>
</blockquote></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-1DpAUkYDVyNmP5H49XyNVDq5_T6UkE=
VaQGMGA0YEhNGw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-1DpAUkYDVy=
NmP5H49XyNVDq5_T6UkEVaQGMGA0YEhNGw%40mail.gmail.com</a>.<br />

--000000000000a2033c0576ee8b90--

.

------=_Part_358_140688532.1538144060833
Content-Type: multipart/alternative;
 boundary="----=_Part_359_2102590875.1538144060833"

------=_Part_359_2102590875.1538144060833
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I want to highlight that [[nodiscard]] on functions is not about forcing=20
the compiler to keep the value, but instead to emit a warning if the user=
=20
doesn't use the value.
So meaning would be different.
In that respect, another attribute name might be better.

Also, it is already possible (but cumbersome) to implement already without=
=20
volatile:
void f() {
  int secret_int;
  float secret_float;
  /* ... */
  secret_int =3D 0;
  secret_float =3D 0
  asm volatile ("" ::"irm"(secret_int), "xm"(secret_float));
}

I would really like an attribute for that, though.


Le vendredi 28 septembre 2018 15:36:42 UTC+2, Daniel Gutson a =C3=A9crit :
>
> Yeah.  But please note that this is not only for function calls.
>
> void f()
> {
>    int secret;
>    ....
>    secret =3D 0;  //removed due to DSE
> }
>
> If I declare secret as volatile or write 0s to its address I may prevent=
=20
> the compiler to use a register impacting in performance. That's why I wan=
t=20
> to use the attribute here too.
>
>
>
> El vie., 28 sept. 2018 10:32, Andrew Giese <gies...@gmail.com=20
> <javascript:>> escribi=C3=B3:
>
>> I like the idea.
>> Function poisoning might also serve your needs. E.g.,=20
>> https://www.fluentcpp.com/2018/09/04/function-poisoning-in-cpp/
>>
>> If gcc poison were standardized in some fashion, you could write your ow=
n=20
>> wrappers to those functions with all the [[nodiscard]] you might want.
>>
>> Control in that case is a little less granular, indeed. Probably if=20
>> you're writing [[nodiscard]] on a per-expression basis you are not=20
>> discarding the result already.
>>
>> Regards
>>
>> --=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 <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAO8_tC4kNZ=
6s-xMXo69n1D3dbOMkqt0fjLU44Uq5TfABp17hQQ%40mail.gmail.com=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAO8_tC4kN=
Z6s-xMXo69n1D3dbOMkqt0fjLU44Uq5TfABp17hQQ%40mail.gmail.com?utm_medium=3Dema=
il&utm_source=3Dfooter>
>> .
>>
>

--=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/94d79dd7-ba3b-4bf8-91ed-e5dc02b33670%40isocpp.or=
g.

------=_Part_359_2102590875.1538144060833
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I want to highlight that [[nodiscard]] on functions is not=
 about forcing the compiler to keep the value, but instead to emit a warnin=
g if the user doesn&#39;t use the value.<br>So meaning would be different.<=
br>In that respect, another attribute name might be better.<br><br>Also, it=
 is already possible (but cumbersome) to implement already without volatile=
:<br><div style=3D"background-color: rgb(250, 250, 250); border-color: rgb(=
187, 187, 187); border-style: solid; border-width: 1px; overflow-wrap: brea=
k-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"su=
bprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">voi=
d</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">f</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> secret_int</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">float</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> secret_float</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>=C2=A0 </span><span style=3D"color: #800;" class=3D"styled-by-prettify"=
>/* ... */</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>=C2=A0 secret_int </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 secret_floa=
t </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #066;" class=3D"styled-by-prettify">0</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">asm</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">volatile</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">(</span><span style=3D"color: #080;" class=3D"styled-by-pre=
ttify">&quot;&quot;</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
::</span><span style=3D"color: #080;" class=3D"styled-by-prettify">&quot;ir=
m&quot;</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">secret_int</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">),</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #080;" class=3D"styled-by-prettify">&quot;xm&quot;</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">secret_float</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">));</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></div></code></div><br>I would really li=
ke an attribute for that, though.<br><br><br>Le vendredi 28 septembre 2018 =
15:36:42 UTC+2, Daniel Gutson a =C3=A9crit=C2=A0:<blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"auto"><div>Yeah.=C2=A0 But please note that =
this is not only for function calls.<div dir=3D"auto"><br></div><div dir=3D=
"auto">void f()</div><div dir=3D"auto">{</div><div dir=3D"auto">=C2=A0 =C2=
=A0int secret;</div><div dir=3D"auto">=C2=A0 =C2=A0....</div><div dir=3D"au=
to">=C2=A0 =C2=A0secret =3D 0;=C2=A0 //removed due to DSE</div><div dir=3D"=
auto">}</div><div dir=3D"auto"><br></div><div dir=3D"auto">If I declare sec=
ret as volatile or write 0s to its address I may prevent the compiler to us=
e a register impacting in performance. That&#39;s why I want to use the att=
ribute here too.</div><div dir=3D"auto"><br></div><br><br><div class=3D"gma=
il_quote"><div dir=3D"ltr">El vie., 28 sept. 2018 10:32, Andrew Giese &lt;<=
a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"luZjexPSA=
AAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;retu=
rn true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">gies..=
..@gmail.com</a>&gt; escribi=C3=B3:<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div dir=3D"auto"><div>I like the idea.<div dir=3D"auto">Function poisoning=
 might also serve your needs. E.g.,=C2=A0<a href=3D"https://www.fluentcpp.c=
om/2018/09/04/function-poisoning-in-cpp/" rel=3D"nofollow" target=3D"_blank=
" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%=
2F%2Fwww.fluentcpp.com%2F2018%2F09%2F04%2Ffunction-poisoning-in-cpp%2F\x26s=
a\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF7-e2xXkIlyk3UcteakI63Ro7E0A&#39;;retur=
n true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%=
3A%2F%2Fwww.fluentcpp.com%2F2018%2F09%2F04%2Ffunction-poisoning-in-cpp%2F\x=
26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF7-e2xXkIlyk3UcteakI63Ro7E0A&#39;;re=
turn true;">https://www.fluentcpp.<wbr>com/2018/09/04/function-<wbr>poisoni=
ng-in-cpp/</a></div><div dir=3D"auto"><br></div><div dir=3D"auto">If gcc po=
ison were standardized in some fashion, you could write your own wrappers t=
o those functions with all the [[nodiscard]] you might want.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">Control in that case is a little less=
 granular, indeed. Probably if you&#39;re writing [[nodiscard]] on a per-ex=
pression basis you are not discarding the result already.</div><div dir=3D"=
auto"><br></div><div dir=3D"auto">Regards</div>
</div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" rel=3D"nofollow" target=3D"_blank" gdf-obfu=
scated-mailto=3D"luZjexPSAAAJ" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" rel=3D"nofollo=
w" target=3D"_blank" gdf-obfuscated-mailto=3D"luZjexPSAAAJ" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAO8_tC4kNZ6s-xMXo69n1D3dbOMkqt0fjLU4=
4Uq5TfABp17hQQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;https:/=
/groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAO8_tC4kNZ6s-xMXo69n=
1D3dbOMkqt0fjLU44Uq5TfABp17hQQ%40mail.gmail.com?utm_medium\x3demail\x26utm_=
source\x3dfooter&#39;;return true;" onclick=3D"this.href=3D&#39;https://gro=
ups.google.com/a/isocpp.org/d/msgid/std-proposals/CAO8_tC4kNZ6s-xMXo69n1D3d=
bOMkqt0fjLU44Uq5TfABp17hQQ%40mail.gmail.com?utm_medium\x3demail\x26utm_sour=
ce\x3dfooter&#39;;return true;">https://groups.google.com/a/<wbr>isocpp.org=
/d/msgid/std-<wbr>proposals/CAO8_tC4kNZ6s-<wbr>xMXo69n1D3dbOMkqt0fjLU44Uq5T=
fA<wbr>Bp17hQQ%40mail.gmail.com</a>.<br>
</blockquote></div></div></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/94d79dd7-ba3b-4bf8-91ed-e5dc02b33670%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/94d79dd7-ba3b-4bf8-91ed-e5dc02b33670=
%40isocpp.org</a>.<br />

------=_Part_359_2102590875.1538144060833--

------=_Part_358_140688532.1538144060833--

.

--000000000000ffc75a0576ef1f3f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

El vie., 28 sept. 2018 11:14, <florian.csdt@gmail.com> escribi=C3=B3:

> I want to highlight that [[nodiscard]] on functions is not about forcing
> the compiler to keep the value, but instead to emit a warning if the user
> doesn't use the value.
>

I'm proposing using [[nodiscard]] for statements rather than for
declarations.
That being said, it would be placed in the function call statement. I want
the compiler to still do DSE where appropriate and at the same time allow
the programmer to thoughtfully prevent it.


So meaning would be different.
> In that respect, another attribute name might be better.
>
> Also, it is already possible (but cumbersome) to implement already withou=
t
> volatile:
> void f() {
>   int secret_int;
>   float secret_float;
>   /* ... */
>   secret_int =3D 0;
>   secret_float =3D 0
>   asm volatile ("" ::"irm"(secret_int), "xm"(secret_float));
> }
>
> I would really like an attribute for that, though.
>
>
> Le vendredi 28 septembre 2018 15:36:42 UTC+2, Daniel Gutson a =C3=A9crit =
:
>>
>> Yeah.  But please note that this is not only for function calls.
>>
>> void f()
>> {
>>    int secret;
>>    ....
>>    secret =3D 0;  //removed due to DSE
>> }
>>
>> If I declare secret as volatile or write 0s to its address I may prevent
>> the compiler to use a register impacting in performance. That's why I wa=
nt
>> to use the attribute here too.
>>
>>
>>
>> El vie., 28 sept. 2018 10:32, Andrew Giese <gies...@gmail.com> escribi=
=C3=B3:
>>
>>> I like the idea.
>>> Function poisoning might also serve your needs. E.g.,
>>> https://www.fluentcpp.com/2018/09/04/function-poisoning-in-cpp/
>>>
>>> If gcc poison were standardized in some fashion, you could write your
>>> own wrappers to those functions with all the [[nodiscard]] you might wa=
nt.
>>>
>>> Control in that case is a little less granular, indeed. Probably if
>>> you're writing [[nodiscard]] on a per-expression basis you are not
>>> discarding the result already.
>>>
>>> Regards
>>>
>>> --
>>> 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-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/CAO8_tC4kN=
Z6s-xMXo69n1D3dbOMkqt0fjLU44Uq5TfABp17hQQ%40mail.gmail.com
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAO8_tC4k=
NZ6s-xMXo69n1D3dbOMkqt0fjLU44Uq5TfABp17hQQ%40mail.gmail.com?utm_medium=3Dem=
ail&utm_source=3Dfooter>
>>> .
>>>
>> --
> 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/94d79dd7-ba3=
b-4bf8-91ed-e5dc02b33670%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/94d79dd7-ba=
3b-4bf8-91ed-e5dc02b33670%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>

--=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/CAFdMc-1tpJj3bSzHgD%3DpxWD2eVokRX3ST2QE-oF6M8z1%=
3DDTEoQ%40mail.gmail.com.

--000000000000ffc75a0576ef1f3f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">=
El vie., 28 sept. 2018 11:14,  &lt;<a href=3D"mailto:florian.csdt@gmail.com=
">florian.csdt@gmail.com</a>&gt; escribi=C3=B3:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">I want to highlight that [[nodiscard]] on fu=
nctions is not about forcing the compiler to keep the value, but instead to=
 emit a warning if the user doesn&#39;t use the value.<br></div></blockquot=
e></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">I&#39;m proposi=
ng using [[nodiscard]] for statements rather than for declarations.</div><d=
iv dir=3D"auto">That being said, it would be placed in the function call st=
atement. I want the compiler to still do DSE where appropriate and at the s=
ame time allow the programmer to thoughtfully prevent it.</div><div dir=3D"=
auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D=
"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">So meaning wo=
uld be different.<br>In that respect, another attribute name might be bette=
r.<br><br>Also, it is already possible (but cumbersome) to implement alread=
y without volatile:<br><div style=3D"background-color:rgb(250,250,250);bord=
er-color:rgb(187,187,187);border-style:solid;border-width:1px" class=3D"m_1=
356521278005008546prettyprint"><code class=3D"m_1356521278005008546prettypr=
int"><div class=3D"m_1356521278005008546subprettyprint"><span style=3D"colo=
r:#008" class=3D"m_1356521278005008546styled-by-prettify">void</span><span =
style=3D"color:#000" class=3D"m_1356521278005008546styled-by-prettify"> </s=
pan><span style=3D"color:#000" class=3D"m_1356521278005008546styled-by-pret=
tify">f</span><span style=3D"color:#660" class=3D"m_1356521278005008546styl=
ed-by-prettify">()</span><span style=3D"color:#000" class=3D"m_135652127800=
5008546styled-by-prettify"> </span><span style=3D"color:#660" class=3D"m_13=
56521278005008546styled-by-prettify">{</span><span style=3D"color:#000" cla=
ss=3D"m_1356521278005008546styled-by-prettify"><br>=C2=A0 </span><span styl=
e=3D"color:#008" class=3D"m_1356521278005008546styled-by-prettify">int</spa=
n><span style=3D"color:#000" class=3D"m_1356521278005008546styled-by-pretti=
fy"> secret_int</span><span style=3D"color:#660" class=3D"m_135652127800500=
8546styled-by-prettify">;</span><span style=3D"color:#000" class=3D"m_13565=
21278005008546styled-by-prettify"><br>=C2=A0 </span><span style=3D"color:#0=
08" class=3D"m_1356521278005008546styled-by-prettify">float</span><span sty=
le=3D"color:#000" class=3D"m_1356521278005008546styled-by-prettify"> secret=
_float</span><span style=3D"color:#660" class=3D"m_1356521278005008546style=
d-by-prettify">;</span><span style=3D"color:#000" class=3D"m_13565212780050=
08546styled-by-prettify"><br>=C2=A0 </span><span style=3D"color:#800" class=
=3D"m_1356521278005008546styled-by-prettify">/* ... */</span><span style=3D=
"color:#000" class=3D"m_1356521278005008546styled-by-prettify"><br>=C2=A0 s=
ecret_int </span><span style=3D"color:#660" class=3D"m_1356521278005008546s=
tyled-by-prettify">=3D</span><span style=3D"color:#000" class=3D"m_13565212=
78005008546styled-by-prettify"> </span><span style=3D"color:#066" class=3D"=
m_1356521278005008546styled-by-prettify">0</span><span style=3D"color:#660"=
 class=3D"m_1356521278005008546styled-by-prettify">;</span><span style=3D"c=
olor:#000" class=3D"m_1356521278005008546styled-by-prettify"><br>=C2=A0 sec=
ret_float </span><span style=3D"color:#660" class=3D"m_1356521278005008546s=
tyled-by-prettify">=3D</span><span style=3D"color:#000" class=3D"m_13565212=
78005008546styled-by-prettify"> </span><span style=3D"color:#066" class=3D"=
m_1356521278005008546styled-by-prettify">0</span><span style=3D"color:#000"=
 class=3D"m_1356521278005008546styled-by-prettify"><br>=C2=A0 </span><span =
style=3D"color:#008" class=3D"m_1356521278005008546styled-by-prettify">asm<=
/span><span style=3D"color:#000" class=3D"m_1356521278005008546styled-by-pr=
ettify"> </span><span style=3D"color:#008" class=3D"m_1356521278005008546st=
yled-by-prettify">volatile</span><span style=3D"color:#000" class=3D"m_1356=
521278005008546styled-by-prettify"> </span><span style=3D"color:#660" class=
=3D"m_1356521278005008546styled-by-prettify">(</span><span style=3D"color:#=
080" class=3D"m_1356521278005008546styled-by-prettify">&quot;&quot;</span><=
span style=3D"color:#000" class=3D"m_1356521278005008546styled-by-prettify"=
> </span><span style=3D"color:#660" class=3D"m_1356521278005008546styled-by=
-prettify">::</span><span style=3D"color:#080" class=3D"m_13565212780050085=
46styled-by-prettify">&quot;irm&quot;</span><span style=3D"color:#660" clas=
s=3D"m_1356521278005008546styled-by-prettify">(</span><span style=3D"color:=
#000" class=3D"m_1356521278005008546styled-by-prettify">secret_int</span><s=
pan style=3D"color:#660" class=3D"m_1356521278005008546styled-by-prettify">=
),</span><span style=3D"color:#000" class=3D"m_1356521278005008546styled-by=
-prettify"> </span><span style=3D"color:#080" class=3D"m_135652127800500854=
6styled-by-prettify">&quot;xm&quot;</span><span style=3D"color:#660" class=
=3D"m_1356521278005008546styled-by-prettify">(</span><span style=3D"color:#=
000" class=3D"m_1356521278005008546styled-by-prettify">secret_float</span><=
span style=3D"color:#660" class=3D"m_1356521278005008546styled-by-prettify"=
>));</span><span style=3D"color:#000" class=3D"m_1356521278005008546styled-=
by-prettify"><br></span><span style=3D"color:#660" class=3D"m_1356521278005=
008546styled-by-prettify">}</span><span style=3D"color:#000" class=3D"m_135=
6521278005008546styled-by-prettify"><br></span></div></code></div><br>I wou=
ld really like an attribute for that, though.<br><br><br>Le vendredi 28 sep=
tembre 2018 15:36:42 UTC+2, Daniel Gutson a =C3=A9crit=C2=A0:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"auto"><div>Yeah.=C2=A0 But please not=
e that this is not only for function calls.<div dir=3D"auto"><br></div><div=
 dir=3D"auto">void f()</div><div dir=3D"auto">{</div><div dir=3D"auto">=C2=
=A0 =C2=A0int secret;</div><div dir=3D"auto">=C2=A0 =C2=A0....</div><div di=
r=3D"auto">=C2=A0 =C2=A0secret =3D 0;=C2=A0 //removed due to DSE</div><div =
dir=3D"auto">}</div><div dir=3D"auto"><br></div><div dir=3D"auto">If I decl=
are secret as volatile or write 0s to its address I may prevent the compile=
r to use a register impacting in performance. That&#39;s why I want to use =
the attribute here too.</div><div dir=3D"auto"><br></div><br><br><div class=
=3D"gmail_quote"><div dir=3D"ltr">El vie., 28 sept. 2018 10:32, Andrew Gies=
e &lt;<a rel=3D"nofollow noreferrer">gies...@gmail.com</a>&gt; escribi=C3=
=B3:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div>I like =
the idea.<div dir=3D"auto">Function poisoning might also serve your needs. =
E.g.,=C2=A0<a href=3D"https://www.fluentcpp.com/2018/09/04/function-poisoni=
ng-in-cpp/" rel=3D"nofollow noreferrer" target=3D"_blank">https://www.fluen=
tcpp.com/2018/09/04/function-poisoning-in-cpp/</a></div><div dir=3D"auto"><=
br></div><div dir=3D"auto">If gcc poison were standardized in some fashion,=
 you could write your own wrappers to those functions with all the [[nodisc=
ard]] you might want.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Co=
ntrol in that case is a little less granular, indeed. Probably if you&#39;r=
e writing [[nodiscard]] on a per-expression basis you are not discarding th=
e result already.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Regard=
s</div>
</div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow noreferrer">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow noreferrer">std-pr.=
...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAO8_tC4kNZ6s-xMXo69n1D3dbOMkqt0fjLU4=
4Uq5TfABp17hQQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 rel=3D"nofollow noreferrer" target=3D"_blank">https://groups.google.com/a/=
isocpp.org/d/msgid/std-proposals/CAO8_tC4kNZ6s-xMXo69n1D3dbOMkqt0fjLU44Uq5T=
fABp17hQQ%40mail.gmail.com</a>.<br>
</blockquote></div></div></div>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank" rel=3D"noreferrer">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">std-proposals@isocpp.org</a>.<br=
>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/94d79dd7-ba3b-4bf8-91ed-e5dc02b33670%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/94d79dd7-ba3b-4bf8-91ed-e5dc02b33670%40isocpp.org</a>.<br>
</blockquote></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-1tpJj3bSzHgD%3DpxWD2eVokRX3ST2=
QE-oF6M8z1%3DDTEoQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-1tpJj3=
bSzHgD%3DpxWD2eVokRX3ST2QE-oF6M8z1%3DDTEoQ%40mail.gmail.com</a>.<br />

--000000000000ffc75a0576ef1f3f--

.

--0000000000003f84ea0576ef2af1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

(Clarification)

El vie., 28 sept. 2018 11:17, Daniel Gutson <danielgutson@gmail.com>
escribi=C3=B3:

>
>
> El vie., 28 sept. 2018 11:14, <florian.csdt@gmail.com> escribi=C3=B3:
>
>> I want to highlight that [[nodiscard]] on functions is not about forcing
>> the compiler to keep the value, but instead to emit a warning if the use=
r
>> doesn't use the value.
>>
>

In THIS proposal....

>
> I'm proposing using [[nodiscard]] for statements rather than
>

...in addition to...

for declarations.
>
That being said, it would be placed in the function call statement. I want
> the compiler to still do DSE where appropriate and at the same time allow
> the programmer to thoughtfully prevent it.
>
>
> So meaning would be different.
>> In that respect, another attribute name might be better.
>>
>> Also, it is already possible (but cumbersome) to implement already
>> without volatile:
>> void f() {
>>   int secret_int;
>>   float secret_float;
>>   /* ... */
>>   secret_int =3D 0;
>>   secret_float =3D 0
>>   asm volatile ("" ::"irm"(secret_int), "xm"(secret_float));
>> }
>>
>> I would really like an attribute for that, though.
>>
>>
>> Le vendredi 28 septembre 2018 15:36:42 UTC+2, Daniel Gutson a =C3=A9crit=
 :
>>>
>>> Yeah.  But please note that this is not only for function calls.
>>>
>>> void f()
>>> {
>>>    int secret;
>>>    ....
>>>    secret =3D 0;  //removed due to DSE
>>> }
>>>
>>> If I declare secret as volatile or write 0s to its address I may preven=
t
>>> the compiler to use a register impacting in performance. That's why I w=
ant
>>> to use the attribute here too.
>>>
>>>
>>>
>>> El vie., 28 sept. 2018 10:32, Andrew Giese <gies...@gmail.com> escribi=
=C3=B3:
>>>
>>>> I like the idea.
>>>> Function poisoning might also serve your needs. E.g.,
>>>> https://www.fluentcpp.com/2018/09/04/function-poisoning-in-cpp/
>>>>
>>>> If gcc poison were standardized in some fashion, you could write your
>>>> own wrappers to those functions with all the [[nodiscard]] you might w=
ant.
>>>>
>>>> Control in that case is a little less granular, indeed. Probably if
>>>> you're writing [[nodiscard]] on a per-expression basis you are not
>>>> discarding the result already.
>>>>
>>>> Regards
>>>>
>>>> --
>>>> 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-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/CAO8_tC4k=
NZ6s-xMXo69n1D3dbOMkqt0fjLU44Uq5TfABp17hQQ%40mail.gmail.com
>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAO8_tC4=
kNZ6s-xMXo69n1D3dbOMkqt0fjLU44Uq5TfABp17hQQ%40mail.gmail.com?utm_medium=3De=
mail&utm_source=3Dfooter>
>>>> .
>>>>
>>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> 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/94d79dd7-ba=
3b-4bf8-91ed-e5dc02b33670%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/94d79dd7-b=
a3b-4bf8-91ed-e5dc02b33670%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>

--=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/CAFdMc-1rSKBc6aQh%2BZo7imJb8_1741RPuL0VyyByTcD8z=
HT_6Q%40mail.gmail.com.

--0000000000003f84ea0576ef2af1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div>(Clarification)<br><br><div class=3D"gmail_quote"><d=
iv dir=3D"ltr">El vie., 28 sept. 2018 11:17, Daniel Gutson &lt;<a href=3D"m=
ailto:danielgutson@gmail.com">danielgutson@gmail.com</a>&gt; escribi=C3=B3:=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div><br><br><di=
v class=3D"gmail_quote"><div dir=3D"ltr">El vie., 28 sept. 2018 11:14,  &lt=
;<a href=3D"mailto:florian.csdt@gmail.com" target=3D"_blank" rel=3D"norefer=
rer">florian.csdt@gmail.com</a>&gt; escribi=C3=B3:<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr">I want to highlight that [[nodiscard]] on =
functions is not about forcing the compiler to keep the value, but instead =
to emit a warning if the user doesn&#39;t use the value.<br></div></blockqu=
ote></div></div><div dir=3D"auto"></div></div></blockquote></div></div><div=
 dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto">In TH=
IS proposal....</div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto"><br></div><div di=
r=3D"auto">I&#39;m proposing using [[nodiscard]] for statements rather than=
</div></div></blockquote></div></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">..in addition to...</div><div dir=3D"auto"><br></div><div dir=3D"=
auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D=
"auto"><div dir=3D"auto">for declarations.</div></div></blockquote></div></=
div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"auto"><div dir=3D"auto">That being said, it would be place=
d in the function call statement. I want the compiler to still do DSE where=
 appropriate and at the same time allow the programmer to thoughtfully prev=
ent it.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div d=
ir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr">So meaning would be different.<br>In that respect, another attr=
ibute name might be better.<br><br>Also, it is already possible (but cumber=
some) to implement already without volatile:<br><div style=3D"background-co=
lor:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;borde=
r-width:1px" class=3D"m_2516448488950390465m_1356521278005008546prettyprint=
"><code class=3D"m_2516448488950390465m_1356521278005008546prettyprint"><di=
v class=3D"m_2516448488950390465m_1356521278005008546subprettyprint"><span =
style=3D"color:#008" class=3D"m_2516448488950390465m_1356521278005008546sty=
led-by-prettify">void</span><span style=3D"color:#000" class=3D"m_251644848=
8950390465m_1356521278005008546styled-by-prettify"> </span><span style=3D"c=
olor:#000" class=3D"m_2516448488950390465m_1356521278005008546styled-by-pre=
ttify">f</span><span style=3D"color:#660" class=3D"m_2516448488950390465m_1=
356521278005008546styled-by-prettify">()</span><span style=3D"color:#000" c=
lass=3D"m_2516448488950390465m_1356521278005008546styled-by-prettify"> </sp=
an><span style=3D"color:#660" class=3D"m_2516448488950390465m_1356521278005=
008546styled-by-prettify">{</span><span style=3D"color:#000" class=3D"m_251=
6448488950390465m_1356521278005008546styled-by-prettify"><br>=C2=A0 </span>=
<span style=3D"color:#008" class=3D"m_2516448488950390465m_1356521278005008=
546styled-by-prettify">int</span><span style=3D"color:#000" class=3D"m_2516=
448488950390465m_1356521278005008546styled-by-prettify"> secret_int</span><=
span style=3D"color:#660" class=3D"m_2516448488950390465m_13565212780050085=
46styled-by-prettify">;</span><span style=3D"color:#000" class=3D"m_2516448=
488950390465m_1356521278005008546styled-by-prettify"><br>=C2=A0 </span><spa=
n style=3D"color:#008" class=3D"m_2516448488950390465m_1356521278005008546s=
tyled-by-prettify">float</span><span style=3D"color:#000" class=3D"m_251644=
8488950390465m_1356521278005008546styled-by-prettify"> secret_float</span><=
span style=3D"color:#660" class=3D"m_2516448488950390465m_13565212780050085=
46styled-by-prettify">;</span><span style=3D"color:#000" class=3D"m_2516448=
488950390465m_1356521278005008546styled-by-prettify"><br>=C2=A0 </span><spa=
n style=3D"color:#800" class=3D"m_2516448488950390465m_1356521278005008546s=
tyled-by-prettify">/* ... */</span><span style=3D"color:#000" class=3D"m_25=
16448488950390465m_1356521278005008546styled-by-prettify"><br>=C2=A0 secret=
_int </span><span style=3D"color:#660" class=3D"m_2516448488950390465m_1356=
521278005008546styled-by-prettify">=3D</span><span style=3D"color:#000" cla=
ss=3D"m_2516448488950390465m_1356521278005008546styled-by-prettify"> </span=
><span style=3D"color:#066" class=3D"m_2516448488950390465m_135652127800500=
8546styled-by-prettify">0</span><span style=3D"color:#660" class=3D"m_25164=
48488950390465m_1356521278005008546styled-by-prettify">;</span><span style=
=3D"color:#000" class=3D"m_2516448488950390465m_1356521278005008546styled-b=
y-prettify"><br>=C2=A0 secret_float </span><span style=3D"color:#660" class=
=3D"m_2516448488950390465m_1356521278005008546styled-by-prettify">=3D</span=
><span style=3D"color:#000" class=3D"m_2516448488950390465m_135652127800500=
8546styled-by-prettify"> </span><span style=3D"color:#066" class=3D"m_25164=
48488950390465m_1356521278005008546styled-by-prettify">0</span><span style=
=3D"color:#000" class=3D"m_2516448488950390465m_1356521278005008546styled-b=
y-prettify"><br>=C2=A0 </span><span style=3D"color:#008" class=3D"m_2516448=
488950390465m_1356521278005008546styled-by-prettify">asm</span><span style=
=3D"color:#000" class=3D"m_2516448488950390465m_1356521278005008546styled-b=
y-prettify"> </span><span style=3D"color:#008" class=3D"m_25164484889503904=
65m_1356521278005008546styled-by-prettify">volatile</span><span style=3D"co=
lor:#000" class=3D"m_2516448488950390465m_1356521278005008546styled-by-pret=
tify"> </span><span style=3D"color:#660" class=3D"m_2516448488950390465m_13=
56521278005008546styled-by-prettify">(</span><span style=3D"color:#080" cla=
ss=3D"m_2516448488950390465m_1356521278005008546styled-by-prettify">&quot;&=
quot;</span><span style=3D"color:#000" class=3D"m_2516448488950390465m_1356=
521278005008546styled-by-prettify"> </span><span style=3D"color:#660" class=
=3D"m_2516448488950390465m_1356521278005008546styled-by-prettify">::</span>=
<span style=3D"color:#080" class=3D"m_2516448488950390465m_1356521278005008=
546styled-by-prettify">&quot;irm&quot;</span><span style=3D"color:#660" cla=
ss=3D"m_2516448488950390465m_1356521278005008546styled-by-prettify">(</span=
><span style=3D"color:#000" class=3D"m_2516448488950390465m_135652127800500=
8546styled-by-prettify">secret_int</span><span style=3D"color:#660" class=
=3D"m_2516448488950390465m_1356521278005008546styled-by-prettify">),</span>=
<span style=3D"color:#000" class=3D"m_2516448488950390465m_1356521278005008=
546styled-by-prettify"> </span><span style=3D"color:#080" class=3D"m_251644=
8488950390465m_1356521278005008546styled-by-prettify">&quot;xm&quot;</span>=
<span style=3D"color:#660" class=3D"m_2516448488950390465m_1356521278005008=
546styled-by-prettify">(</span><span style=3D"color:#000" class=3D"m_251644=
8488950390465m_1356521278005008546styled-by-prettify">secret_float</span><s=
pan style=3D"color:#660" class=3D"m_2516448488950390465m_135652127800500854=
6styled-by-prettify">));</span><span style=3D"color:#000" class=3D"m_251644=
8488950390465m_1356521278005008546styled-by-prettify"><br></span><span styl=
e=3D"color:#660" class=3D"m_2516448488950390465m_1356521278005008546styled-=
by-prettify">}</span><span style=3D"color:#000" class=3D"m_2516448488950390=
465m_1356521278005008546styled-by-prettify"><br></span></div></code></div><=
br>I would really like an attribute for that, though.<br><br><br>Le vendred=
i 28 septembre 2018 15:36:42 UTC+2, Daniel Gutson a =C3=A9crit=C2=A0:<block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div>Yeah.=C2=A0 But pl=
ease note that this is not only for function calls.<div dir=3D"auto"><br></=
div><div dir=3D"auto">void f()</div><div dir=3D"auto">{</div><div dir=3D"au=
to">=C2=A0 =C2=A0int secret;</div><div dir=3D"auto">=C2=A0 =C2=A0....</div>=
<div dir=3D"auto">=C2=A0 =C2=A0secret =3D 0;=C2=A0 //removed due to DSE</di=
v><div dir=3D"auto">}</div><div dir=3D"auto"><br></div><div dir=3D"auto">If=
 I declare secret as volatile or write 0s to its address I may prevent the =
compiler to use a register impacting in performance. That&#39;s why I want =
to use the attribute here too.</div><div dir=3D"auto"><br></div><br><br><di=
v class=3D"gmail_quote"><div dir=3D"ltr">El vie., 28 sept. 2018 10:32, Andr=
ew Giese &lt;<a rel=3D"nofollow noreferrer noreferrer">gies...@gmail.com</a=
>&gt; escribi=C3=B3:<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"au=
to"><div>I like the idea.<div dir=3D"auto">Function poisoning might also se=
rve your needs. E.g.,=C2=A0<a href=3D"https://www.fluentcpp.com/2018/09/04/=
function-poisoning-in-cpp/" rel=3D"nofollow noreferrer noreferrer" target=
=3D"_blank">https://www.fluentcpp.com/2018/09/04/function-poisoning-in-cpp/=
</a></div><div dir=3D"auto"><br></div><div dir=3D"auto">If gcc poison were =
standardized in some fashion, you could write your own wrappers to those fu=
nctions with all the [[nodiscard]] you might want.</div><div dir=3D"auto"><=
br></div><div dir=3D"auto">Control in that case is a little less granular, =
indeed. Probably if you&#39;re writing [[nodiscard]] on a per-expression ba=
sis you are not discarding the result already.</div><div dir=3D"auto"><br><=
/div><div dir=3D"auto">Regards</div>
</div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow noreferrer noreferrer">std-proposal...@isocpp.or=
g</a>.<br>
To post to this group, send email to <a rel=3D"nofollow noreferrer noreferr=
er">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAO8_tC4kNZ6s-xMXo69n1D3dbOMkqt0fjLU4=
4Uq5TfABp17hQQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 rel=3D"nofollow noreferrer noreferrer" target=3D"_blank">https://groups.go=
ogle.com/a/isocpp.org/d/msgid/std-proposals/CAO8_tC4kNZ6s-xMXo69n1D3dbOMkqt=
0fjLU44Uq5TfABp17hQQ%40mail.gmail.com</a>.<br>
</blockquote></div></div></div>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" rel=3D"nore=
ferrer noreferrer" target=3D"_blank">std-proposals+unsubscribe@isocpp.org</=
a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" rel=3D"noreferrer noreferrer" target=3D"_blank">std-proposals@isocpp.=
org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/94d79dd7-ba3b-4bf8-91ed-e5dc02b33670%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"noreferrer =
noreferrer" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgi=
d/std-proposals/94d79dd7-ba3b-4bf8-91ed-e5dc02b33670%40isocpp.org</a>.<br>
</blockquote></div></div></div>
</blockquote></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-1rSKBc6aQh%2BZo7imJb8_1741RPuL=
0VyyByTcD8zHT_6Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-1rSKBc6a=
Qh%2BZo7imJb8_1741RPuL0VyyByTcD8zHT_6Q%40mail.gmail.com</a>.<br />

--0000000000003f84ea0576ef2af1--

.

------=_Part_359_953444902.1538145396301
Content-Type: multipart/alternative;
 boundary="----=_Part_360_1783548938.1538145396302"

------=_Part_360_1783548938.1538145396302
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I completely understood what you meant, and yes what you are proposing is=
=20
compatible with the current language.
I just wanted to highlight that it might be misleading to have the same=20
attribute with different meaning when it is used on a function declaration,=
=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 last=
=20
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 storage=
=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 becomes=20
valid to access it afterwards.
It would tell the compiler it should behave as-if the object *could* be=20
accessed afterwards.


Le vendredi 28 septembre 2018 16:18:12 UTC+2, Daniel Gutson a =C3=A9crit :
>
>
>
> El vie., 28 sept. 2018 11:14, <floria...@gmail.com <javascript:>>=20
> escribi=C3=B3:
>
>> I want to highlight that [[nodiscard]] on functions is not about forcing=
=20
>> the compiler to keep the value, but instead to emit a warning if the use=
r=20
>> doesn't use the value.
>>
>
> I'm proposing using [[nodiscard]] for statements rather than for=20
> declarations.
> That being said, it would be placed in the function call statement. I wan=
t=20
> the compiler to still do DSE where appropriate and at the same time allow=
=20
> the programmer to thoughtfully prevent it.
>
>
> So meaning would be different.
>> In that respect, another attribute name might be better.
>>
>> Also, it is already possible (but cumbersome) to implement already=20
>> without volatile:
>> void f() {
>>   int secret_int;
>>   float secret_float;
>>   /* ... */
>>   secret_int =3D 0;
>>   secret_float =3D 0
>>   asm volatile ("" ::"irm"(secret_int), "xm"(secret_float));
>> }
>>
>> I would really like an attribute for that, though.
>>
>>
>> Le vendredi 28 septembre 2018 15:36:42 UTC+2, Daniel Gutson a =C3=A9crit=
 :
>>>
>>> Yeah.  But please note that this is not only for function calls.
>>>
>>> void f()
>>> {
>>>    int secret;
>>>    ....
>>>    secret =3D 0;  //removed due to DSE
>>> }
>>>
>>> If I declare secret as volatile or write 0s to its address I may preven=
t=20
>>> the compiler to use a register impacting in performance. That's why I w=
ant=20
>>> to use the attribute here too.
>>>
>>>
>>>
>>> El vie., 28 sept. 2018 10:32, Andrew Giese <gies...@gmail.com> escribi=
=C3=B3:
>>>
>>>> I like the idea.
>>>> Function poisoning might also serve your needs. E.g.,=20
>>>> https://www.fluentcpp.com/2018/09/04/function-poisoning-in-cpp/
>>>>
>>>> If gcc poison were standardized in some fashion, you could write your=
=20
>>>> own wrappers to those functions with all the [[nodiscard]] you might w=
ant.
>>>>
>>>> Control in that case is a little less granular, indeed. Probably if=20
>>>> you're writing [[nodiscard]] on a per-expression basis you are not=20
>>>> discarding the result already.
>>>>
>>>> Regards
>>>>
>>>> --=20
>>>> You received this message because you are subscribed to the Google=20
>>>> Groups "ISO C++ Standard - Future Proposals" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>>> an 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/CAO8_tC4k=
NZ6s-xMXo69n1D3dbOMkqt0fjLU44Uq5TfABp17hQQ%40mail.gmail.com=20
>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAO8_tC4=
kNZ6s-xMXo69n1D3dbOMkqt0fjLU44Uq5TfABp17hQQ%40mail.gmail.com?utm_medium=3De=
mail&utm_source=3Dfooter>
>>>> .
>>>>
>>> --=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 <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/94d79dd7-ba=
3b-4bf8-91ed-e5dc02b33670%40isocpp.org=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/94d79dd7-b=
a3b-4bf8-91ed-e5dc02b33670%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>

--=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/c71e2ca9-c5f4-4699-b2c1-b23245eef683%40isocpp.or=
g.

------=_Part_360_1783548938.1538145396302
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I completely understood what you meant, and yes what you a=
re proposing is compatible with the current language.<br>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).<br><br>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.<br>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:<br><br><div style=3D"background-co=
lor: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: so=
lid; border-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><=
code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> f</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>[[</span><span style=3D"color: #000;" class=3D"styled-by-prettify">undead<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">]]</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> secret</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #800;" =
class=3D"styled-by-prettify">/* ... */</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br>=C2=A0 secret </span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"=
styled-by-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></=
div></code></div>That wouldn&#39;t mean the lifetime of the object is exten=
ded and it becomes valid to access it afterwards.<br>It would tell the comp=
iler it should behave as-if the object <i>could</i> be accessed afterwards.=
<br><br><br>Le vendredi 28 septembre 2018 16:18:12 UTC+2, Daniel Gutson a =
=C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"a=
uto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">El vie., 28 s=
ept. 2018 11:14,  &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"YhkzDlfUAAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#3=
9;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#3=
9;;return true;">floria...@gmail.com</a>&gt; escribi=C3=B3:<br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div dir=3D"ltr">I want to highlight that [[nodisc=
ard]] on functions is not about forcing the compiler to keep the value, but=
 instead to emit a warning if the user doesn&#39;t use the value.<br></div>=
</blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">I&#3=
9;m proposing using [[nodiscard]] for statements rather than for declaratio=
ns.</div><div dir=3D"auto">That being said, it would be placed in the funct=
ion call statement. I want the compiler to still do DSE where appropriate a=
nd at the same time allow the programmer to thoughtfully prevent it.</div><=
div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto"><d=
iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">So=
 meaning would be different.<br>In that respect, another attribute name mig=
ht be better.<br><br>Also, it is already possible (but cumbersome) to imple=
ment already without volatile:<br><div style=3D"background-color:rgb(250,25=
0,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px"><=
code><div><span style=3D"color:#008">void</span><span style=3D"color:#000">=
 </span><span style=3D"color:#000">f</span><span style=3D"color:#660">()</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#660">{</span><=
span style=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#008">int<=
/span><span style=3D"color:#000"> secret_int</span><span style=3D"color:#66=
0">;</span><span style=3D"color:#000"><br>=C2=A0 </span><span style=3D"colo=
r:#008">float</span><span style=3D"color:#000"> secret_float</span><span st=
yle=3D"color:#660">;</span><span style=3D"color:#000"><br>=C2=A0 </span><sp=
an style=3D"color:#800">/* ... */</span><span style=3D"color:#000"><br>=C2=
=A0 secret_int </span><span style=3D"color:#660">=3D</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#066">0</span><span style=3D"color:=
#660">;</span><span style=3D"color:#000"><br>=C2=A0 secret_float </span><sp=
an style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><span =
style=3D"color:#066">0</span><span style=3D"color:#000"><br>=C2=A0 </span><=
span style=3D"color:#008">asm</span><span style=3D"color:#000"> </span><spa=
n style=3D"color:#008">volatile</span><span style=3D"color:#000"> </span><s=
pan style=3D"color:#660">(</span><span style=3D"color:#080">&quot;&quot;</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#660">::</span>=
<span style=3D"color:#080">&quot;irm&quot;</span><span style=3D"color:#660"=
>(</span><span style=3D"color:#000">secret_int</span><span style=3D"color:#=
660">),</span><span style=3D"color:#000"> </span><span style=3D"color:#080"=
>&quot;xm&quot;</span><span style=3D"color:#660">(</span><span style=3D"col=
or:#000">secret_float</span><span style=3D"color:#660">));</span><span styl=
e=3D"color:#000"><br></span><span style=3D"color:#660">}</span><span style=
=3D"color:#000"><br></span></div></code></div><br>I would really like an at=
tribute for that, though.<br><br><br>Le vendredi 28 septembre 2018 15:36:42=
 UTC+2, Daniel Gutson a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" =
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"auto"><div>Yeah.=C2=A0 But please note that this is not o=
nly for function calls.<div dir=3D"auto"><br></div><div dir=3D"auto">void f=
()</div><div dir=3D"auto">{</div><div dir=3D"auto">=C2=A0 =C2=A0int secret;=
</div><div dir=3D"auto">=C2=A0 =C2=A0....</div><div dir=3D"auto">=C2=A0 =C2=
=A0secret =3D 0;=C2=A0 //removed due to DSE</div><div dir=3D"auto">}</div><=
div dir=3D"auto"><br></div><div dir=3D"auto">If I declare secret as volatil=
e or write 0s to its address I may prevent the compiler to use a register i=
mpacting in performance. That&#39;s why I want to use the attribute here to=
o.</div><div dir=3D"auto"><br></div><br><br><div class=3D"gmail_quote"><div=
 dir=3D"ltr">El vie., 28 sept. 2018 10:32, Andrew Giese &lt;<a rel=3D"nofol=
low noreferrer">gies...@gmail.com</a>&gt; escribi=C3=B3:<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"auto"><div>I like the idea.<div dir=3D"au=
to">Function poisoning might also serve your needs. E.g.,=C2=A0<a href=3D"h=
ttps://www.fluentcpp.com/2018/09/04/function-poisoning-in-cpp/" rel=3D"nofo=
llow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;https://www.google.=
com/url?q\x3dhttps%3A%2F%2Fwww.fluentcpp.com%2F2018%2F09%2F04%2Ffunction-po=
isoning-in-cpp%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF7-e2xXkIlyk3Ucte=
akI63Ro7E0A&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.goog=
le.com/url?q\x3dhttps%3A%2F%2Fwww.fluentcpp.com%2F2018%2F09%2F04%2Ffunction=
-poisoning-in-cpp%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF7-e2xXkIlyk3U=
cteakI63Ro7E0A&#39;;return true;">https://www.fluentcpp.<wbr>com/2018/09/04=
/function-<wbr>poisoning-in-cpp/</a></div><div dir=3D"auto"><br></div><div =
dir=3D"auto">If gcc poison were standardized in some fashion, you could wri=
te your own wrappers to those functions with all the [[nodiscard]] you migh=
t want.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Control in that =
case is a little less granular, indeed. Probably if you&#39;re writing [[no=
discard]] on a per-expression basis you are not discarding the result alrea=
dy.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Regards</div>
</div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow noreferrer">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow noreferrer">std-pr.=
...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAO8_tC4kNZ6s-xMXo69n1D3dbOMkqt0fjLU4=
4Uq5TfABp17hQQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;https:/=
/groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAO8_tC4kNZ6s-xMXo69n=
1D3dbOMkqt0fjLU44Uq5TfABp17hQQ%40mail.gmail.com?utm_medium\x3demail\x26utm_=
source\x3dfooter&#39;;return true;" onclick=3D"this.href=3D&#39;https://gro=
ups.google.com/a/isocpp.org/d/msgid/std-proposals/CAO8_tC4kNZ6s-xMXo69n1D3d=
bOMkqt0fjLU44Uq5TfABp17hQQ%40mail.gmail.com?utm_medium\x3demail\x26utm_sour=
ce\x3dfooter&#39;;return true;">https://groups.google.com/a/<wbr>isocpp.org=
/d/msgid/std-<wbr>proposals/CAO8_tC4kNZ6s-<wbr>xMXo69n1D3dbOMkqt0fjLU44Uq5T=
fA<wbr>Bp17hQQ%40mail.gmail.com</a>.<br>
</blockquote></div></div></div>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" rel=3D"nofollow" target=3D"_blank" gdf-obfu=
scated-mailto=3D"YhkzDlfUAAAJ" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" rel=3D"nofollo=
w" target=3D"_blank" gdf-obfuscated-mailto=3D"YhkzDlfUAAAJ" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/94d79dd7-ba3b-4bf8-91ed-e5dc02b33670%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank" onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/94d79dd7-ba3b-4bf8-91ed-e5dc02b33670%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" on=
click=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/94d79dd7-ba3b-4bf8-91ed-e5dc02b33670%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/94d79dd7-ba3b-4bf8-<wbr>91ed-=
e5dc02b33670%40isocpp.org</a><wbr>.<br>
</blockquote></div></div></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c71e2ca9-c5f4-4699-b2c1-b23245eef683%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c71e2ca9-c5f4-4699-b2c1-b23245eef683=
%40isocpp.org</a>.<br />

------=_Part_360_1783548938.1538145396302--

------=_Part_359_953444902.1538145396301--

.

--00000000000011740e0576ef95e1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

El vie., 28 de sep. de 2018 a la(s) 11:36, <florian.csdt@gmail.com>
escribi=C3=B3:

> I completely understood what you meant, and yes what you are proposing is
> compatible with the current language.
> I just wanted to highlight that it might be misleading to have the same
> attribute with different meaning when it is used on a function declaratio=
n,
> or on an expression (a declaration is also a statement).
>
> Also, after some thinking, in this case, the goal is not to force the las=
t
> assignment, but to force
>

I just wanted to give a way to the programmer to tell the compiler that the
statement is important. Later, the compiler may just warn that it would
remove the statement (so the programmer has to look for another mean) or
honor the request by not removing anything (thus impacting in the final
binary).


> the last 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 accessed after its lifetime end
> and so the last assignment should be kept and propagated to every storage
> of the object:
>
> void f() {
>   [[undead]] int secret;
>   /* ... */
>   secret =3D 0;
> }
> That wouldn't mean the lifetime of the object is extended and it becomes
> valid to access it afterwards.
> It would tell the compiler it should behave as-if the object *could* be
> accessed afterwards.
>
>
> Le vendredi 28 septembre 2018 16:18:12 UTC+2, Daniel Gutson a =C3=A9crit =
:
>>
>>
>>
>> El vie., 28 sept. 2018 11:14, <floria...@gmail.com> escribi=C3=B3:
>>
>>> I want to highlight that [[nodiscard]] on functions is not about forcin=
g
>>> the compiler to keep the value, but instead to emit a warning if the us=
er
>>> doesn't use the value.
>>>
>>
>> I'm proposing using [[nodiscard]] for statements rather than for
>> declarations.
>> That being said, it would be placed in the function call statement. I
>> want the compiler to still do DSE where appropriate and at the same time
>> allow the programmer to thoughtfully prevent it.
>>
>>
>> So meaning would be different.
>>> In that respect, another attribute name might be better.
>>>
>>> Also, it is already possible (but cumbersome) to implement already
>>> without volatile:
>>> void f() {
>>>   int secret_int;
>>>   float secret_float;
>>>   /* ... */
>>>   secret_int =3D 0;
>>>   secret_float =3D 0
>>>   asm volatile ("" ::"irm"(secret_int), "xm"(secret_float));
>>> }
>>>
>>> I would really like an attribute for that, though.
>>>
>>>
>>> Le vendredi 28 septembre 2018 15:36:42 UTC+2, Daniel Gutson a =C3=A9cri=
t :
>>>>
>>>> Yeah.  But please note that this is not only for function calls.
>>>>
>>>> void f()
>>>> {
>>>>    int secret;
>>>>    ....
>>>>    secret =3D 0;  //removed due to DSE
>>>> }
>>>>
>>>> If I declare secret as volatile or write 0s to its address I may
>>>> prevent the compiler to use a register impacting in performance. That'=
s why
>>>> I want to use the attribute here too.
>>>>
>>>>
>>>>
>>>> El vie., 28 sept. 2018 10:32, Andrew Giese <gies...@gmail.com>
>>>> escribi=C3=B3:
>>>>
>>>>> I like the idea.
>>>>> Function poisoning might also serve your needs. E.g.,
>>>>> https://www.fluentcpp.com/2018/09/04/function-poisoning-in-cpp/
>>>>>
>>>>> If gcc poison were standardized in some fashion, you could write your
>>>>> own wrappers to those functions with all the [[nodiscard]] you might =
want.
>>>>>
>>>>> Control in that case is a little less granular, indeed. Probably if
>>>>> you're writing [[nodiscard]] on a per-expression basis you are not
>>>>> discarding the result already.
>>>>>
>>>>> Regards
>>>>>
>>>>> --
>>>>> 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, sen=
d
>>>>> an 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
>>>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAO8_tC4=
kNZ6s-xMXo69n1D3dbOMkqt0fjLU44Uq5TfABp17hQQ%40mail.gmail.com
>>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAO8_tC=
4kNZ6s-xMXo69n1D3dbOMkqt0fjLU44Uq5TfABp17hQQ%40mail.gmail.com?utm_medium=3D=
email&utm_source=3Dfooter>
>>>>> .
>>>>>
>>>> --
>>> 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-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/94d79dd7-b=
a3b-4bf8-91ed-e5dc02b33670%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/94d79dd7-=
ba3b-4bf8-91ed-e5dc02b33670%40isocpp.org?utm_medium=3Demail&utm_source=3Dfo=
oter>
>>> .
>>>
>> --
> 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/c71e2ca9-c5f=
4-4699-b2c1-b23245eef683%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c71e2ca9-c5=
f4-4699-b2c1-b23245eef683%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>


--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=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/CAFdMc-3rNrze-AUW-FNy6S_FRdWt78LGJyDzDGQPXqsbgHn=
DoQ%40mail.gmail.com.

--00000000000011740e0576ef95e1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">El vie=
.., 28 de sep. de 2018 a la(s) 11:36, &lt;<a href=3D"mailto:florian.csdt@gma=
il.com">florian.csdt@gmail.com</a>&gt; escribi=C3=B3:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr">I completely understood what you meant,=
 and yes what you are proposing is compatible with the current language.<br=
>I just wanted to highlight that it might be misleading to have the same at=
tribute with different meaning when it is used on a function declaration, o=
r on an expression (a declaration is also a statement).<br><br>Also, after =
some thinking, in this case, the goal is not to force the last assignment, =
but to force</div></blockquote><div><br></div><div>I just wanted to give a =
way to the programmer to tell the compiler that the statement is important.=
 Later, the compiler may just warn that it would remove the statement (so t=
he programmer has to look for another mean) or honor the request by not rem=
oving anything (thus impacting in the final binary).=C2=A0</div><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"> the last value of th=
e variable, wherever the variable is, even if the variable is both in regis=
ter and stack.<br>So in that case, you might be better with a [[undead]] at=
tribute whose meaning would be that the object might be accessed after its =
lifetime end and so the last assignment should be kept and propagated to ev=
ery storage of the object:<br><br><div style=3D"background-color:rgb(250,25=
0,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px" c=
lass=3D"m_-4790073964389657585prettyprint"><code class=3D"m_-47900739643896=
57585prettyprint"><div class=3D"m_-4790073964389657585subprettyprint"><span=
 style=3D"color:#008" class=3D"m_-4790073964389657585styled-by-prettify">vo=
id</span><span style=3D"color:#000" class=3D"m_-4790073964389657585styled-b=
y-prettify"> f</span><span style=3D"color:#660" class=3D"m_-479007396438965=
7585styled-by-prettify">()</span><span style=3D"color:#000" class=3D"m_-479=
0073964389657585styled-by-prettify"> </span><span style=3D"color:#660" clas=
s=3D"m_-4790073964389657585styled-by-prettify">{</span><span style=3D"color=
:#000" class=3D"m_-4790073964389657585styled-by-prettify"><br>=C2=A0 </span=
><span style=3D"color:#660" class=3D"m_-4790073964389657585styled-by-pretti=
fy">[[</span><span style=3D"color:#000" class=3D"m_-4790073964389657585styl=
ed-by-prettify">undead</span><span style=3D"color:#660" class=3D"m_-4790073=
964389657585styled-by-prettify">]]</span><span style=3D"color:#000" class=
=3D"m_-4790073964389657585styled-by-prettify"> </span><span style=3D"color:=
#008" class=3D"m_-4790073964389657585styled-by-prettify">int</span><span st=
yle=3D"color:#000" class=3D"m_-4790073964389657585styled-by-prettify"> secr=
et</span><span style=3D"color:#660" class=3D"m_-4790073964389657585styled-b=
y-prettify">;</span><span style=3D"color:#000" class=3D"m_-4790073964389657=
585styled-by-prettify"><br>=C2=A0 </span><span style=3D"color:#800" class=
=3D"m_-4790073964389657585styled-by-prettify">/* ... */</span><span style=
=3D"color:#000" class=3D"m_-4790073964389657585styled-by-prettify"><br>=C2=
=A0 secret </span><span style=3D"color:#660" class=3D"m_-479007396438965758=
5styled-by-prettify">=3D</span><span style=3D"color:#000" class=3D"m_-47900=
73964389657585styled-by-prettify"> </span><span style=3D"color:#066" class=
=3D"m_-4790073964389657585styled-by-prettify">0</span><span style=3D"color:=
#660" class=3D"m_-4790073964389657585styled-by-prettify">;</span><span styl=
e=3D"color:#000" class=3D"m_-4790073964389657585styled-by-prettify"><br></s=
pan><span style=3D"color:#660" class=3D"m_-4790073964389657585styled-by-pre=
ttify">}</span><span style=3D"color:#000" class=3D"m_-4790073964389657585st=
yled-by-prettify"><br></span></div></code></div>That wouldn&#39;t mean the =
lifetime of the object is extended and it becomes valid to access it afterw=
ards.<br>It would tell the compiler it should behave as-if the object <i>co=
uld</i> be accessed afterwards.<br><br><br>Le vendredi 28 septembre 2018 16=
:18:12 UTC+2, Daniel Gutson a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div =
dir=3D"ltr">El vie., 28 sept. 2018 11:14,  &lt;<a rel=3D"nofollow">floria..=
..@gmail.com</a>&gt; escribi=C3=B3:<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div dir=3D"ltr">I want to highlight that [[nodiscard]] on functions is not=
 about forcing the compiler to keep the value, but instead to emit a warnin=
g if the user doesn&#39;t use the value.<br></div></blockquote></div></div>=
<div dir=3D"auto"><br></div><div dir=3D"auto">I&#39;m proposing using [[nod=
iscard]] for statements rather than for declarations.</div><div dir=3D"auto=
">That being said, it would be placed in the function call statement. I wan=
t the compiler to still do DSE where appropriate and at the same time allow=
 the programmer to thoughtfully prevent it.</div><div dir=3D"auto"><br></di=
v><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">So meaning would be differe=
nt.<br>In that respect, another attribute name might be better.<br><br>Also=
, it is already possible (but cumbersome) to implement already without vola=
tile:<br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(1=
87,187,187);border-style:solid;border-width:1px"><code><div><span style=3D"=
color:#008">void</span><span style=3D"color:#000"> </span><span style=3D"co=
lor:#000">f</span><span style=3D"color:#660">()</span><span style=3D"color:=
#000"> </span><span style=3D"color:#660">{</span><span style=3D"color:#000"=
><br>=C2=A0 </span><span style=3D"color:#008">int</span><span style=3D"colo=
r:#000"> secret_int</span><span style=3D"color:#660">;</span><span style=3D=
"color:#000"><br>=C2=A0 </span><span style=3D"color:#008">float</span><span=
 style=3D"color:#000"> secret_float</span><span style=3D"color:#660">;</spa=
n><span style=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#800">/=
* ... */</span><span style=3D"color:#000"><br>=C2=A0 secret_int </span><spa=
n style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><span s=
tyle=3D"color:#066">0</span><span style=3D"color:#660">;</span><span style=
=3D"color:#000"><br>=C2=A0 secret_float </span><span style=3D"color:#660">=
=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#066">0</=
span><span style=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#008=
">asm</span><span style=3D"color:#000"> </span><span style=3D"color:#008">v=
olatile</span><span style=3D"color:#000"> </span><span style=3D"color:#660"=
>(</span><span style=3D"color:#080">&quot;&quot;</span><span style=3D"color=
:#000"> </span><span style=3D"color:#660">::</span><span style=3D"color:#08=
0">&quot;irm&quot;</span><span style=3D"color:#660">(</span><span style=3D"=
color:#000">secret_int</span><span style=3D"color:#660">),</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#080">&quot;xm&quot;</span><s=
pan style=3D"color:#660">(</span><span style=3D"color:#000">secret_float</s=
pan><span style=3D"color:#660">));</span><span style=3D"color:#000"><br></s=
pan><span style=3D"color:#660">}</span><span style=3D"color:#000"><br></spa=
n></div></code></div><br>I would really like an attribute for that, though.=
<br><br><br>Le vendredi 28 septembre 2018 15:36:42 UTC+2, Daniel Gutson a =
=C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin=
-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto">=
<div>Yeah.=C2=A0 But please note that this is not only for function calls.<=
div dir=3D"auto"><br></div><div dir=3D"auto">void f()</div><div dir=3D"auto=
">{</div><div dir=3D"auto">=C2=A0 =C2=A0int secret;</div><div dir=3D"auto">=
=C2=A0 =C2=A0....</div><div dir=3D"auto">=C2=A0 =C2=A0secret =3D 0;=C2=A0 /=
/removed due to DSE</div><div dir=3D"auto">}</div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">If I declare secret as volatile or write 0s to its add=
ress I may prevent the compiler to use a register impacting in performance.=
 That&#39;s why I want to use the attribute here too.</div><div dir=3D"auto=
"><br></div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">El vie., 28=
 sept. 2018 10:32, Andrew Giese &lt;<a rel=3D"nofollow noreferrer">gies...@=
gmail.com</a>&gt; escribi=C3=B3:<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"auto"><div>I like the idea.<div dir=3D"auto">Function poisoning m=
ight also serve your needs. E.g.,=C2=A0<a href=3D"https://www.fluentcpp.com=
/2018/09/04/function-poisoning-in-cpp/" rel=3D"nofollow" target=3D"_blank">=
https://www.fluentcpp.com/2018/09/04/function-poisoning-in-cpp/</a></div><d=
iv dir=3D"auto"><br></div><div dir=3D"auto">If gcc poison were standardized=
 in some fashion, you could write your own wrappers to those functions with=
 all the [[nodiscard]] you might want.</div><div dir=3D"auto"><br></div><di=
v dir=3D"auto">Control in that case is a little less granular, indeed. Prob=
ably if you&#39;re writing [[nodiscard]] on a per-expression basis you are =
not discarding the result already.</div><div dir=3D"auto"><br></div><div di=
r=3D"auto">Regards</div>
</div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow noreferrer">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow noreferrer">std-pr.=
...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAO8_tC4kNZ6s-xMXo69n1D3dbOMkqt0fjLU4=
4Uq5TfABp17hQQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 rel=3D"nofollow" target=3D"_blank">https://groups.google.com/a/isocpp.org/=
d/msgid/std-proposals/CAO8_tC4kNZ6s-xMXo69n1D3dbOMkqt0fjLU44Uq5TfABp17hQQ%4=
0mail.gmail.com</a>.<br>
</blockquote></div></div></div>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/94d79dd7-ba3b-4bf8-91ed-e5dc02b33670%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposa=
ls/94d79dd7-ba3b-4bf8-91ed-e5dc02b33670%40isocpp.org</a>.<br>
</blockquote></div></div></div>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c71e2ca9-c5f4-4699-b2c1-b23245eef683%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c71e2ca9-c5f4-=
4699-b2c1-b23245eef683%40isocpp.org</a>.<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"gmail_signature" data-smartmail=3D"gmail_signature">Who=E2=80=99s=
 got the sweetest disposition?<br>One guess, that=E2=80=99s who?<br>Who=E2=
=80=99d never, ever start an argument?<br>Who never shows a bit of temperam=
ent?<br>Who&#39;s never wrong but always right?<br>Who&#39;d never dream of=
 starting a fight?<br>Who get stuck with all the bad luck? </div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-3rNrze-AUW-FNy6S_FRdWt78LGJyDz=
DGQPXqsbgHnDoQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-3rNrze-AUW=
-FNy6S_FRdWt78LGJyDzDGQPXqsbgHnDoQ%40mail.gmail.com</a>.<br />

--00000000000011740e0576ef95e1--

.

--0000000000003d80360576efde2e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I think the primary opposition will come from the fact that DSE is, for the
moment, an implementation detail of the compiler. So, to have this
standardized, we might also need to standardize DSE.

The name of the attribute will also be endlessly debated I'm sure. The
existing attributes are about informing compilers and programmers of
program correctness (e.g., it's correct to fall through a case label), and
this one is only about compiler optimization. Reusing [[nodiscard]] in this
fashion might be argued to be disruptive, so we need to be ready for that.
On the other hand, the committee likes to avoid new reserved words, so
[[nodiscard]] may be preferable.

Regards
Andy


On Fri, Sep 28, 2018, 7:50 AM Daniel Gutson <danielgutson@gmail.com> wrote:

>
>
> El vie., 28 de sep. de 2018 a la(s) 11:36, <florian.csdt@gmail.com>
> escribi=C3=B3:
>
>> I completely understood what you meant, and yes what you are proposing i=
s
>> compatible with the current language.
>> I just wanted to highlight that it might be misleading to have the same
>> attribute with different meaning when it is used on a function declarati=
on,
>> or on an expression (a declaration is also a statement).
>>
>> Also, after some thinking, in this case, the goal is not to force the
>> last assignment, but to force
>>
>
> I just wanted to give a way to the programmer to tell the compiler that
> the statement is important. Later, the compiler may just warn that it wou=
ld
> remove the statement (so the programmer has to look for another mean) or
> honor the request by not removing anything (thus impacting in the final
> binary).
>
>
>> the last 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 accessed after its lifetime en=
d
>> and so the last assignment should be kept and propagated to every storag=
e
>> of the object:
>>
>> void f() {
>>   [[undead]] int secret;
>>   /* ... */
>>   secret =3D 0;
>> }
>> That wouldn't mean the lifetime of the object is extended and it becomes
>> valid to access it afterwards.
>> It would tell the compiler it should behave as-if the object *could* be
>> accessed afterwards.
>>
>>
>> Le vendredi 28 septembre 2018 16:18:12 UTC+2, Daniel Gutson a =C3=A9crit=
 :
>>>
>>>
>>>
>>> El vie., 28 sept. 2018 11:14, <floria...@gmail.com> escribi=C3=B3:
>>>
>>>> I want to highlight that [[nodiscard]] on functions is not about
>>>> forcing the compiler to keep the value, but instead to emit a warning =
if
>>>> the user doesn't use the value.
>>>>
>>>
>>> I'm proposing using [[nodiscard]] for statements rather than for
>>> declarations.
>>> That being said, it would be placed in the function call statement. I
>>> want the compiler to still do DSE where appropriate and at the same tim=
e
>>> allow the programmer to thoughtfully prevent it.
>>>
>>>
>>> So meaning would be different.
>>>> In that respect, another attribute name might be better.
>>>>
>>>> Also, it is already possible (but cumbersome) to implement already
>>>> without volatile:
>>>> void f() {
>>>>   int secret_int;
>>>>   float secret_float;
>>>>   /* ... */
>>>>   secret_int =3D 0;
>>>>   secret_float =3D 0
>>>>   asm volatile ("" ::"irm"(secret_int), "xm"(secret_float));
>>>> }
>>>>
>>>> I would really like an attribute for that, though.
>>>>
>>>>
>>>> Le vendredi 28 septembre 2018 15:36:42 UTC+2, Daniel Gutson a =C3=A9cr=
it :
>>>>>
>>>>> Yeah.  But please note that this is not only for function calls.
>>>>>
>>>>> void f()
>>>>> {
>>>>>    int secret;
>>>>>    ....
>>>>>    secret =3D 0;  //removed due to DSE
>>>>> }
>>>>>
>>>>> If I declare secret as volatile or write 0s to its address I may
>>>>> prevent the compiler to use a register impacting in performance. That=
's why
>>>>> I want to use the attribute here too.
>>>>>
>>>>>
>>>>>
>>>>> El vie., 28 sept. 2018 10:32, Andrew Giese <gies...@gmail.com>
>>>>> escribi=C3=B3:
>>>>>
>>>>>> I like the idea.
>>>>>> Function poisoning might also serve your needs. E.g.,
>>>>>> https://www.fluentcpp.com/2018/09/04/function-poisoning-in-cpp/
>>>>>>
>>>>>> If gcc poison were standardized in some fashion, you could write you=
r
>>>>>> own wrappers to those functions with all the [[nodiscard]] you might=
 want.
>>>>>>
>>>>>> Control in that case is a little less granular, indeed. Probably if
>>>>>> you're writing [[nodiscard]] on a per-expression basis you are not
>>>>>> discarding the result already.
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> --
>>>>>> 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-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/CAO8_tC=
4kNZ6s-xMXo69n1D3dbOMkqt0fjLU44Uq5TfABp17hQQ%40mail.gmail.com
>>>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAO8_t=
C4kNZ6s-xMXo69n1D3dbOMkqt0fjLU44Uq5TfABp17hQQ%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter>
>>>>>> .
>>>>>>
>>>>> --
>>>> 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-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/94d79dd7-=
ba3b-4bf8-91ed-e5dc02b33670%40isocpp.org
>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/94d79dd7=
-ba3b-4bf8-91ed-e5dc02b33670%40isocpp.org?utm_medium=3Demail&utm_source=3Df=
ooter>
>>>> .
>>>>
>>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> 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/c71e2ca9-c5=
f4-4699-b2c1-b23245eef683%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c71e2ca9-c=
5f4-4699-b2c1-b23245eef683%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
>
> --
> Who=E2=80=99s got the sweetest disposition?
> One guess, that=E2=80=99s who?
> Who=E2=80=99d never, ever start an argument?
> Who never shows a bit of temperament?
> Who's never wrong but always right?
> Who'd never dream of starting a fight?
> Who get stuck with all the bad luck?
>
> --
> 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/CAFdMc-3rNrz=
e-AUW-FNy6S_FRdWt78LGJyDzDGQPXqsbgHnDoQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-3rNr=
ze-AUW-FNy6S_FRdWt78LGJyDzDGQPXqsbgHnDoQ%40mail.gmail.com?utm_medium=3Demai=
l&utm_source=3Dfooter>
> .
>

--=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/CAO8_tC4Mo6Cn8rAw%2BsukXyv%3DpsExWBjBehr%2B2G4SD=
B1sSvm-Rw%40mail.gmail.com.

--0000000000003d80360576efde2e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">I think the primary opposition will come from the fact th=
at DSE is, for the moment, an implementation detail of the compiler. So, to=
 have this standardized, we might also need to standardize DSE.<div dir=3D"=
auto"><br></div><div dir=3D"auto">The name of the attribute will also be en=
dlessly debated I&#39;m sure. The existing attributes are about informing c=
ompilers and programmers of program correctness (e.g., it&#39;s correct to =
fall through a case label), and this one is only about compiler optimizatio=
n. Reusing [[nodiscard]] in this fashion might be argued to be disruptive, =
so we need to be ready for that. On the other hand, the committee likes to =
avoid new reserved words, so [[nodiscard]] may be preferable.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">Regards</div><div dir=3D"auto">Andy</=
div><div dir=3D"auto"><br></div></div><br><div class=3D"gmail_quote"><div d=
ir=3D"ltr">On Fri, Sep 28, 2018, 7:50 AM Daniel Gutson &lt;<a href=3D"mailt=
o:danielgutson@gmail.com">danielgutson@gmail.com</a>&gt; wrote:<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br><div class=3D"gmail_q=
uote"><div dir=3D"ltr">El vie., 28 de sep. de 2018 a la(s) 11:36, &lt;<a hr=
ef=3D"mailto:florian.csdt@gmail.com" target=3D"_blank" rel=3D"noreferrer">f=
lorian.csdt@gmail.com</a>&gt; escribi=C3=B3:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr">I completely understood what you meant, and yes =
what you are proposing is compatible with the current language.<br>I just w=
anted to highlight that it might be misleading to have the same attribute w=
ith different meaning when it is used on a function declaration, or on an e=
xpression (a declaration is also a statement).<br><br>Also, after some thin=
king, in this case, the goal is not to force the last assignment, but to fo=
rce</div></blockquote><div><br></div><div>I just wanted to give a way to th=
e programmer to tell the compiler that the statement is important. Later, t=
he compiler may just warn that it would remove the statement (so the progra=
mmer has to look for another mean) or honor the request by not removing any=
thing (thus impacting in the final binary).=C2=A0</div><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"> the last value of the variabl=
e, wherever the variable is, even if the variable is both in register and s=
tack.<br>So in that case, you might be better with a [[undead]] attribute w=
hose meaning would be that the object might be accessed after its lifetime =
end and so the last assignment should be kept and propagated to every stora=
ge of the object:<br><br><div style=3D"background-color:rgb(250,250,250);bo=
rder-color:rgb(187,187,187);border-style:solid;border-width:1px" class=3D"m=
_-6113861466331700788m_-4790073964389657585prettyprint"><code class=3D"m_-6=
113861466331700788m_-4790073964389657585prettyprint"><div class=3D"m_-61138=
61466331700788m_-4790073964389657585subprettyprint"><span style=3D"color:#0=
08" class=3D"m_-6113861466331700788m_-4790073964389657585styled-by-prettify=
">void</span><span style=3D"color:#000" class=3D"m_-6113861466331700788m_-4=
790073964389657585styled-by-prettify"> f</span><span style=3D"color:#660" c=
lass=3D"m_-6113861466331700788m_-4790073964389657585styled-by-prettify">()<=
/span><span style=3D"color:#000" class=3D"m_-6113861466331700788m_-47900739=
64389657585styled-by-prettify"> </span><span style=3D"color:#660" class=3D"=
m_-6113861466331700788m_-4790073964389657585styled-by-prettify">{</span><sp=
an style=3D"color:#000" class=3D"m_-6113861466331700788m_-47900739643896575=
85styled-by-prettify"><br>=C2=A0 </span><span style=3D"color:#660" class=3D=
"m_-6113861466331700788m_-4790073964389657585styled-by-prettify">[[</span><=
span style=3D"color:#000" class=3D"m_-6113861466331700788m_-479007396438965=
7585styled-by-prettify">undead</span><span style=3D"color:#660" class=3D"m_=
-6113861466331700788m_-4790073964389657585styled-by-prettify">]]</span><spa=
n style=3D"color:#000" class=3D"m_-6113861466331700788m_-479007396438965758=
5styled-by-prettify"> </span><span style=3D"color:#008" class=3D"m_-6113861=
466331700788m_-4790073964389657585styled-by-prettify">int</span><span style=
=3D"color:#000" class=3D"m_-6113861466331700788m_-4790073964389657585styled=
-by-prettify"> secret</span><span style=3D"color:#660" class=3D"m_-61138614=
66331700788m_-4790073964389657585styled-by-prettify">;</span><span style=3D=
"color:#000" class=3D"m_-6113861466331700788m_-4790073964389657585styled-by=
-prettify"><br>=C2=A0 </span><span style=3D"color:#800" class=3D"m_-6113861=
466331700788m_-4790073964389657585styled-by-prettify">/* ... */</span><span=
 style=3D"color:#000" class=3D"m_-6113861466331700788m_-4790073964389657585=
styled-by-prettify"><br>=C2=A0 secret </span><span style=3D"color:#660" cla=
ss=3D"m_-6113861466331700788m_-4790073964389657585styled-by-prettify">=3D</=
span><span style=3D"color:#000" class=3D"m_-6113861466331700788m_-479007396=
4389657585styled-by-prettify"> </span><span style=3D"color:#066" class=3D"m=
_-6113861466331700788m_-4790073964389657585styled-by-prettify">0</span><spa=
n style=3D"color:#660" class=3D"m_-6113861466331700788m_-479007396438965758=
5styled-by-prettify">;</span><span style=3D"color:#000" class=3D"m_-6113861=
466331700788m_-4790073964389657585styled-by-prettify"><br></span><span styl=
e=3D"color:#660" class=3D"m_-6113861466331700788m_-4790073964389657585style=
d-by-prettify">}</span><span style=3D"color:#000" class=3D"m_-6113861466331=
700788m_-4790073964389657585styled-by-prettify"><br></span></div></code></d=
iv>That wouldn&#39;t mean the lifetime of the object is extended and it bec=
omes valid to access it afterwards.<br>It would tell the compiler it should=
 behave as-if the object <i>could</i> be accessed afterwards.<br><br><br>Le=
 vendredi 28 septembre 2018 16:18:12 UTC+2, Daniel Gutson a =C3=A9crit=C2=
=A0:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div><br><br>=
<div class=3D"gmail_quote"><div dir=3D"ltr">El vie., 28 sept. 2018 11:14,  =
&lt;<a rel=3D"nofollow noreferrer">floria...@gmail.com</a>&gt; escribi=C3=
=B3:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I want to hig=
hlight that [[nodiscard]] on functions is not about forcing the compiler to=
 keep the value, but instead to emit a warning if the user doesn&#39;t use =
the value.<br></div></blockquote></div></div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">I&#39;m proposing using [[nodiscard]] for statements rather=
 than for declarations.</div><div dir=3D"auto">That being said, it would be=
 placed in the function call statement. I want the compiler to still do DSE=
 where appropriate and at the same time allow the programmer to thoughtfull=
y prevent it.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div>=
<div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr">So meaning would be different.<br>In that respect, anothe=
r attribute name might be better.<br><br>Also, it is already possible (but =
cumbersome) to implement already without volatile:<br><div style=3D"backgro=
und-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid=
;border-width:1px"><code><div><span style=3D"color:#008">void</span><span s=
tyle=3D"color:#000"> </span><span style=3D"color:#000">f</span><span style=
=3D"color:#660">()</span><span style=3D"color:#000"> </span><span style=3D"=
color:#660">{</span><span style=3D"color:#000"><br>=C2=A0 </span><span styl=
e=3D"color:#008">int</span><span style=3D"color:#000"> secret_int</span><sp=
an style=3D"color:#660">;</span><span style=3D"color:#000"><br>=C2=A0 </spa=
n><span style=3D"color:#008">float</span><span style=3D"color:#000"> secret=
_float</span><span style=3D"color:#660">;</span><span style=3D"color:#000">=
<br>=C2=A0 </span><span style=3D"color:#800">/* ... */</span><span style=3D=
"color:#000"><br>=C2=A0 secret_int </span><span style=3D"color:#660">=3D</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#066">0</span><=
span style=3D"color:#660">;</span><span style=3D"color:#000"><br>=C2=A0 sec=
ret_float </span><span style=3D"color:#660">=3D</span><span style=3D"color:=
#000"> </span><span style=3D"color:#066">0</span><span style=3D"color:#000"=
><br>=C2=A0 </span><span style=3D"color:#008">asm</span><span style=3D"colo=
r:#000"> </span><span style=3D"color:#008">volatile</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#660">(</span><span style=3D"color:#=
080">&quot;&quot;</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#660">::</span><span style=3D"color:#080">&quot;irm&quot;</span><span =
style=3D"color:#660">(</span><span style=3D"color:#000">secret_int</span><s=
pan style=3D"color:#660">),</span><span style=3D"color:#000"> </span><span =
style=3D"color:#080">&quot;xm&quot;</span><span style=3D"color:#660">(</spa=
n><span style=3D"color:#000">secret_float</span><span style=3D"color:#660">=
));</span><span style=3D"color:#000"><br></span><span style=3D"color:#660">=
}</span><span style=3D"color:#000"><br></span></div></code></div><br>I woul=
d really like an attribute for that, though.<br><br><br>Le vendredi 28 sept=
embre 2018 15:36:42 UTC+2, Daniel Gutson a =C3=A9crit=C2=A0:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div dir=3D"auto"><div>Yeah.=C2=A0 But please note=
 that this is not only for function calls.<div dir=3D"auto"><br></div><div =
dir=3D"auto">void f()</div><div dir=3D"auto">{</div><div dir=3D"auto">=C2=
=A0 =C2=A0int secret;</div><div dir=3D"auto">=C2=A0 =C2=A0....</div><div di=
r=3D"auto">=C2=A0 =C2=A0secret =3D 0;=C2=A0 //removed due to DSE</div><div =
dir=3D"auto">}</div><div dir=3D"auto"><br></div><div dir=3D"auto">If I decl=
are secret as volatile or write 0s to its address I may prevent the compile=
r to use a register impacting in performance. That&#39;s why I want to use =
the attribute here too.</div><div dir=3D"auto"><br></div><br><br><div class=
=3D"gmail_quote"><div dir=3D"ltr">El vie., 28 sept. 2018 10:32, Andrew Gies=
e &lt;<a rel=3D"nofollow noreferrer noreferrer">gies...@gmail.com</a>&gt; e=
scribi=C3=B3:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><di=
v>I like the idea.<div dir=3D"auto">Function poisoning might also serve you=
r needs. E.g.,=C2=A0<a href=3D"https://www.fluentcpp.com/2018/09/04/functio=
n-poisoning-in-cpp/" rel=3D"nofollow noreferrer" target=3D"_blank">https://=
www.fluentcpp.com/2018/09/04/function-poisoning-in-cpp/</a></div><div dir=
=3D"auto"><br></div><div dir=3D"auto">If gcc poison were standardized in so=
me fashion, you could write your own wrappers to those functions with all t=
he [[nodiscard]] you might want.</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">Control in that case is a little less granular, indeed. Probably =
if you&#39;re writing [[nodiscard]] on a per-expression basis you are not d=
iscarding the result already.</div><div dir=3D"auto"><br></div><div dir=3D"=
auto">Regards</div>
</div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow noreferrer noreferrer">std-proposal...@isocpp.or=
g</a>.<br>
To post to this group, send email to <a rel=3D"nofollow noreferrer noreferr=
er">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAO8_tC4kNZ6s-xMXo69n1D3dbOMkqt0fjLU4=
4Uq5TfABp17hQQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 rel=3D"nofollow noreferrer" target=3D"_blank">https://groups.google.com/a/=
isocpp.org/d/msgid/std-proposals/CAO8_tC4kNZ6s-xMXo69n1D3dbOMkqt0fjLU44Uq5T=
fABp17hQQ%40mail.gmail.com</a>.<br>
</blockquote></div></div></div>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow noreferrer">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow noreferrer">std-pr.=
...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/94d79dd7-ba3b-4bf8-91ed-e5dc02b33670%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"nofollow no=
referrer" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/=
std-proposals/94d79dd7-ba3b-4bf8-91ed-e5dc02b33670%40isocpp.org</a>.<br>
</blockquote></div></div></div>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank" rel=3D"noreferrer">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">std-proposals@isocpp.org</a>.<br=
>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c71e2ca9-c5f4-4699-b2c1-b23245eef683%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/c71e2ca9-c5f4-4699-b2c1-b23245eef683%40isocpp.org</a>.<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"m_-6113861466331700788gmail_signature" data-smartmail=3D"gmail_si=
gnature">Who=E2=80=99s got the sweetest disposition?<br>One guess, that=E2=
=80=99s who?<br>Who=E2=80=99d never, ever start an argument?<br>Who never s=
hows a bit of temperament?<br>Who&#39;s never wrong but always right?<br>Wh=
o&#39;d never dream of starting a fight?<br>Who get stuck with all the bad =
luck? </div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank" rel=3D"noreferrer">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">std-proposals@isocpp.org</a>.<br=
>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-3rNrze-AUW-FNy6S_FRdWt78LGJyDz=
DGQPXqsbgHnDoQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 target=3D"_blank" rel=3D"noreferrer">https://groups.google.com/a/isocpp.or=
g/d/msgid/std-proposals/CAFdMc-3rNrze-AUW-FNy6S_FRdWt78LGJyDzDGQPXqsbgHnDoQ=
%40mail.gmail.com</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAO8_tC4Mo6Cn8rAw%2BsukXyv%3DpsExWBjB=
ehr%2B2G4SDB1sSvm-Rw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAO8_tC4Mo6=
Cn8rAw%2BsukXyv%3DpsExWBjBehr%2B2G4SDB1sSvm-Rw%40mail.gmail.com</a>.<br />

--0000000000003d80360576efde2e--

.

--000000000000ee228c0576f00391
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

El vie., 28 de sep. de 2018 a la(s) 12:11, Andrew Giese (gieseanw@gmail.com=
)
escribi=C3=B3:

> I think the primary opposition will come from the fact that DSE is, for
> the moment, an implementation detail of the compiler. So, to have this
> standardized, we might also need to standardize DSE.
>

I gently disagree: attributes are exactly targetted to QoI and compiler
implementations, they are ignorable, and they may target either
optimizations or diagnostics. Even the original (current) [[nodiscard]]
targets diagnostics; I'm proposing to extend it to other uses.
[[nodiscard]] used in statements could perfectly target the diagnostics
subsystem as well, but that will be QoI (it could either do nothing, or
prevent discarding).
In no way I pretend to standardize optimizations in general nor DSE in
particular. Otherwise then CSE will arrive, etc.


>
> The name of the attribute will also be endlessly debated I'm sure. The
> existing attributes are about informing compilers and programmers of
> program correctness (e.g., it's correct to fall through a case label), an=
d
> this one is only about compiler optimization. Reusing [[nodiscard]] in th=
is
> fashion might be argued to be disruptive, so we need to be ready for that=
..
> On the other hand, the committee likes to avoid new reserved words, so
> [[nodiscard]] may be preferable.
>
> Regards
> Andy
>
>
> On Fri, Sep 28, 2018, 7:50 AM Daniel Gutson <danielgutson@gmail.com>
> wrote:
>
>>
>>
>> El vie., 28 de sep. de 2018 a la(s) 11:36, <florian.csdt@gmail.com>
>> escribi=C3=B3:
>>
>>> I completely understood what you meant, and yes what you are proposing
>>> is compatible with the current language.
>>> I just wanted to highlight that it might be misleading to have the same
>>> attribute with different meaning when it is used on a function declarat=
ion,
>>> or on an expression (a declaration is also a statement).
>>>
>>> Also, after some thinking, in this case, the goal is not to force the
>>> last assignment, but to force
>>>
>>
>> I just wanted to give a way to the programmer to tell the compiler that
>> the statement is important. Later, the compiler may just warn that it wo=
uld
>> remove the statement (so the programmer has to look for another mean) or
>> honor the request by not removing anything (thus impacting in the final
>> binary).
>>
>>
>>> the last 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 accessed after its lifetime e=
nd
>>> and so the last assignment should be kept and propagated to every stora=
ge
>>> of the object:
>>>
>>> void f() {
>>>   [[undead]] int secret;
>>>   /* ... */
>>>   secret =3D 0;
>>> }
>>> That wouldn't mean the lifetime of the object is extended and it become=
s
>>> valid to access it afterwards.
>>> It would tell the compiler it should behave as-if the object *could* be
>>> accessed afterwards.
>>>
>>>
>>> Le vendredi 28 septembre 2018 16:18:12 UTC+2, Daniel Gutson a =C3=A9cri=
t :
>>>>
>>>>
>>>>
>>>> El vie., 28 sept. 2018 11:14, <floria...@gmail.com> escribi=C3=B3:
>>>>
>>>>> I want to highlight that [[nodiscard]] on functions is not about
>>>>> forcing the compiler to keep the value, but instead to emit a warning=
 if
>>>>> the user doesn't use the value.
>>>>>
>>>>
>>>> I'm proposing using [[nodiscard]] for statements rather than for
>>>> declarations.
>>>> That being said, it would be placed in the function call statement. I
>>>> want the compiler to still do DSE where appropriate and at the same ti=
me
>>>> allow the programmer to thoughtfully prevent it.
>>>>
>>>>
>>>> So meaning would be different.
>>>>> In that respect, another attribute name might be better.
>>>>>
>>>>> Also, it is already possible (but cumbersome) to implement already
>>>>> without volatile:
>>>>> void f() {
>>>>>   int secret_int;
>>>>>   float secret_float;
>>>>>   /* ... */
>>>>>   secret_int =3D 0;
>>>>>   secret_float =3D 0
>>>>>   asm volatile ("" ::"irm"(secret_int), "xm"(secret_float));
>>>>> }
>>>>>
>>>>> I would really like an attribute for that, though.
>>>>>
>>>>>
>>>>> Le vendredi 28 septembre 2018 15:36:42 UTC+2, Daniel Gutson a =C3=A9c=
rit :
>>>>>>
>>>>>> Yeah.  But please note that this is not only for function calls.
>>>>>>
>>>>>> void f()
>>>>>> {
>>>>>>    int secret;
>>>>>>    ....
>>>>>>    secret =3D 0;  //removed due to DSE
>>>>>> }
>>>>>>
>>>>>> If I declare secret as volatile or write 0s to its address I may
>>>>>> prevent the compiler to use a register impacting in performance. Tha=
t's why
>>>>>> I want to use the attribute here too.
>>>>>>
>>>>>>
>>>>>>
>>>>>> El vie., 28 sept. 2018 10:32, Andrew Giese <gies...@gmail.com>
>>>>>> escribi=C3=B3:
>>>>>>
>>>>>>> I like the idea.
>>>>>>> Function poisoning might also serve your needs. E.g.,
>>>>>>> https://www.fluentcpp.com/2018/09/04/function-poisoning-in-cpp/
>>>>>>>
>>>>>>> If gcc poison were standardized in some fashion, you could write
>>>>>>> your own wrappers to those functions with all the [[nodiscard]] you=
 might
>>>>>>> want.
>>>>>>>
>>>>>>> Control in that case is a little less granular, indeed. Probably if
>>>>>>> you're writing [[nodiscard]] on a per-expression basis you are not
>>>>>>> discarding the result already.
>>>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>> --
>>>>>>> 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-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/CAO8_t=
C4kNZ6s-xMXo69n1D3dbOMkqt0fjLU44Uq5TfABp17hQQ%40mail.gmail.com
>>>>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAO8_=
tC4kNZ6s-xMXo69n1D3dbOMkqt0fjLU44Uq5TfABp17hQQ%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter>
>>>>>>> .
>>>>>>>
>>>>>> --
>>>>> 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, sen=
d
>>>>> an 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
>>>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/94d79dd7=
-ba3b-4bf8-91ed-e5dc02b33670%40isocpp.org
>>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/94d79dd=
7-ba3b-4bf8-91ed-e5dc02b33670%40isocpp.org?utm_medium=3Demail&utm_source=3D=
footer>
>>>>> .
>>>>>
>>>> --
>>> 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/c71e2ca9-c=
5f4-4699-b2c1-b23245eef683%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c71e2ca9-=
c5f4-4699-b2c1-b23245eef683%40isocpp.org?utm_medium=3Demail&utm_source=3Dfo=
oter>
>>> .
>>>
>>
>>
>> --
>> Who=E2=80=99s got the sweetest disposition?
>> One guess, that=E2=80=99s who?
>> Who=E2=80=99d never, ever start an argument?
>> Who never shows a bit of temperament?
>> Who's never wrong but always right?
>> Who'd never dream of starting a fight?
>> Who get stuck with all the bad luck?
>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> 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/CAFdMc-3rNr=
ze-AUW-FNy6S_FRdWt78LGJyDzDGQPXqsbgHnDoQ%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-3rN=
rze-AUW-FNy6S_FRdWt78LGJyDzDGQPXqsbgHnDoQ%40mail.gmail.com?utm_medium=3Dema=
il&utm_source=3Dfooter>
>> .
>>
> --
> 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/CAO8_tC4Mo6C=
n8rAw%2BsukXyv%3DpsExWBjBehr%2B2G4SDB1sSvm-Rw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAO8_tC4Mo6=
Cn8rAw%2BsukXyv%3DpsExWBjBehr%2B2G4SDB1sSvm-Rw%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter>
> .
>


--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=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/CAFdMc-2Bmpf6LM2b5MJtBtkSRtDOgFWCMM%3DMqMrviETNy=
RhN-A%40mail.gmail.com.

--000000000000ee228c0576f00391
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">El vie=
.., 28 de sep. de 2018 a la(s) 12:11, Andrew Giese (<a href=3D"mailto:giesea=
nw@gmail.com">gieseanw@gmail.com</a>) escribi=C3=B3:<br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"auto">I think the primary opposition will com=
e from the fact that DSE is, for the moment, an implementation detail of th=
e compiler. So, to have this standardized, we might also need to standardiz=
e DSE.</div></blockquote><div><br></div><div>I gently disagree: attributes =
are exactly targetted to QoI and compiler implementations, they are ignorab=
le, and they may target either optimizations or diagnostics. Even the origi=
nal (current) [[nodiscard]] targets diagnostics; I&#39;m proposing to exten=
d it to other uses. [[nodiscard]] used in statements could perfectly target=
 the diagnostics subsystem as well, but that will be QoI (it could either d=
o nothing, or prevent discarding).</div><div>In no way I pretend to standar=
dize optimizations in general nor DSE in particular. Otherwise then CSE wil=
l arrive, etc.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"auto"><div dir=3D"auto"><br></div><div dir=3D"auto">The name of the at=
tribute will also be endlessly debated I&#39;m sure. The existing attribute=
s are about informing compilers and programmers of program correctness (e.g=
.., it&#39;s correct to fall through a case label), and this one is only abo=
ut compiler optimization. Reusing [[nodiscard]] in this fashion might be ar=
gued to be disruptive, so we need to be ready for that. On the other hand, =
the committee likes to avoid new reserved words, so [[nodiscard]] may be pr=
eferable.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Regards</div><=
div dir=3D"auto">Andy</div><div dir=3D"auto"><br></div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr">On Fri, Sep 28, 2018, 7:50 AM Daniel Guts=
on &lt;<a href=3D"mailto:danielgutson@gmail.com" target=3D"_blank">danielgu=
tson@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">El vie., 28=
 de sep. de 2018 a la(s) 11:36, &lt;<a href=3D"mailto:florian.csdt@gmail.co=
m" rel=3D"noreferrer" target=3D"_blank">florian.csdt@gmail.com</a>&gt; escr=
ibi=C3=B3:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I compl=
etely understood what you meant, and yes what you are proposing is compatib=
le with the current language.<br>I just wanted to highlight that it might b=
e misleading to have the same attribute with different meaning when it is u=
sed on a function declaration, or on an expression (a declaration is also a=
 statement).<br><br>Also, after some thinking, in this case, the goal is no=
t to force the last assignment, but to force</div></blockquote><div><br></d=
iv><div>I just wanted to give a way to the programmer to tell the compiler =
that the statement is important. Later, the compiler may just warn that it =
would remove the statement (so the programmer has to look for another mean)=
 or honor the request by not removing anything (thus impacting in the final=
 binary).=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"> the last value of the variable, wherever the variable is, even =
if the variable is both in register and stack.<br>So in that case, you migh=
t be better with a [[undead]] attribute whose meaning would be that the obj=
ect might be accessed after its lifetime end and so the last assignment sho=
uld be kept and propagated to every storage of the object:<br><br><div styl=
e=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);border=
-style:solid;border-width:1px" class=3D"m_4163359001443191033m_-61138614663=
31700788m_-4790073964389657585prettyprint"><code class=3D"m_416335900144319=
1033m_-6113861466331700788m_-4790073964389657585prettyprint"><div class=3D"=
m_4163359001443191033m_-6113861466331700788m_-4790073964389657585subprettyp=
rint"><span style=3D"color:#008" class=3D"m_4163359001443191033m_-611386146=
6331700788m_-4790073964389657585styled-by-prettify">void</span><span style=
=3D"color:#000" class=3D"m_4163359001443191033m_-6113861466331700788m_-4790=
073964389657585styled-by-prettify"> f</span><span style=3D"color:#660" clas=
s=3D"m_4163359001443191033m_-6113861466331700788m_-4790073964389657585style=
d-by-prettify">()</span><span style=3D"color:#000" class=3D"m_4163359001443=
191033m_-6113861466331700788m_-4790073964389657585styled-by-prettify"> </sp=
an><span style=3D"color:#660" class=3D"m_4163359001443191033m_-611386146633=
1700788m_-4790073964389657585styled-by-prettify">{</span><span style=3D"col=
or:#000" class=3D"m_4163359001443191033m_-6113861466331700788m_-47900739643=
89657585styled-by-prettify"><br>=C2=A0 </span><span style=3D"color:#660" cl=
ass=3D"m_4163359001443191033m_-6113861466331700788m_-4790073964389657585sty=
led-by-prettify">[[</span><span style=3D"color:#000" class=3D"m_41633590014=
43191033m_-6113861466331700788m_-4790073964389657585styled-by-prettify">und=
ead</span><span style=3D"color:#660" class=3D"m_4163359001443191033m_-61138=
61466331700788m_-4790073964389657585styled-by-prettify">]]</span><span styl=
e=3D"color:#000" class=3D"m_4163359001443191033m_-6113861466331700788m_-479=
0073964389657585styled-by-prettify"> </span><span style=3D"color:#008" clas=
s=3D"m_4163359001443191033m_-6113861466331700788m_-4790073964389657585style=
d-by-prettify">int</span><span style=3D"color:#000" class=3D"m_416335900144=
3191033m_-6113861466331700788m_-4790073964389657585styled-by-prettify"> sec=
ret</span><span style=3D"color:#660" class=3D"m_4163359001443191033m_-61138=
61466331700788m_-4790073964389657585styled-by-prettify">;</span><span style=
=3D"color:#000" class=3D"m_4163359001443191033m_-6113861466331700788m_-4790=
073964389657585styled-by-prettify"><br>=C2=A0 </span><span style=3D"color:#=
800" class=3D"m_4163359001443191033m_-6113861466331700788m_-479007396438965=
7585styled-by-prettify">/* ... */</span><span style=3D"color:#000" class=3D=
"m_4163359001443191033m_-6113861466331700788m_-4790073964389657585styled-by=
-prettify"><br>=C2=A0 secret </span><span style=3D"color:#660" class=3D"m_4=
163359001443191033m_-6113861466331700788m_-4790073964389657585styled-by-pre=
ttify">=3D</span><span style=3D"color:#000" class=3D"m_4163359001443191033m=
_-6113861466331700788m_-4790073964389657585styled-by-prettify"> </span><spa=
n style=3D"color:#066" class=3D"m_4163359001443191033m_-6113861466331700788=
m_-4790073964389657585styled-by-prettify">0</span><span style=3D"color:#660=
" class=3D"m_4163359001443191033m_-6113861466331700788m_-479007396438965758=
5styled-by-prettify">;</span><span style=3D"color:#000" class=3D"m_41633590=
01443191033m_-6113861466331700788m_-4790073964389657585styled-by-prettify">=
<br></span><span style=3D"color:#660" class=3D"m_4163359001443191033m_-6113=
861466331700788m_-4790073964389657585styled-by-prettify">}</span><span styl=
e=3D"color:#000" class=3D"m_4163359001443191033m_-6113861466331700788m_-479=
0073964389657585styled-by-prettify"><br></span></div></code></div>That woul=
dn&#39;t mean the lifetime of the object is extended and it becomes valid t=
o access it afterwards.<br>It would tell the compiler it should behave as-i=
f the object <i>could</i> be accessed afterwards.<br><br><br>Le vendredi 28=
 septembre 2018 16:18:12 UTC+2, Daniel Gutson a =C3=A9crit=C2=A0:<blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div dir=3D"auto"><div><br><br><div class=3D"=
gmail_quote"><div dir=3D"ltr">El vie., 28 sept. 2018 11:14,  &lt;<a rel=3D"=
nofollow noreferrer">floria...@gmail.com</a>&gt; escribi=C3=B3:<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr">I want to highlight that [[no=
discard]] on functions is not about forcing the compiler to keep the value,=
 but instead to emit a warning if the user doesn&#39;t use the value.<br></=
div></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">=
I&#39;m proposing using [[nodiscard]] for statements rather than for declar=
ations.</div><div dir=3D"auto">That being said, it would be placed in the f=
unction call statement. I want the compiler to still do DSE where appropria=
te and at the same time allow the programmer to thoughtfully prevent it.</d=
iv><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto=
"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
">So meaning would be different.<br>In that respect, another attribute name=
 might be better.<br><br>Also, it is already possible (but cumbersome) to i=
mplement already without volatile:<br><div style=3D"background-color:rgb(25=
0,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:1p=
x"><code><div><span style=3D"color:#008">void</span><span style=3D"color:#0=
00"> </span><span style=3D"color:#000">f</span><span style=3D"color:#660">(=
)</span><span style=3D"color:#000"> </span><span style=3D"color:#660">{</sp=
an><span style=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#008">=
int</span><span style=3D"color:#000"> secret_int</span><span style=3D"color=
:#660">;</span><span style=3D"color:#000"><br>=C2=A0 </span><span style=3D"=
color:#008">float</span><span style=3D"color:#000"> secret_float</span><spa=
n style=3D"color:#660">;</span><span style=3D"color:#000"><br>=C2=A0 </span=
><span style=3D"color:#800">/* ... */</span><span style=3D"color:#000"><br>=
=C2=A0 secret_int </span><span style=3D"color:#660">=3D</span><span style=
=3D"color:#000"> </span><span style=3D"color:#066">0</span><span style=3D"c=
olor:#660">;</span><span style=3D"color:#000"><br>=C2=A0 secret_float </spa=
n><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><=
span style=3D"color:#066">0</span><span style=3D"color:#000"><br>=C2=A0 </s=
pan><span style=3D"color:#008">asm</span><span style=3D"color:#000"> </span=
><span style=3D"color:#008">volatile</span><span style=3D"color:#000"> </sp=
an><span style=3D"color:#660">(</span><span style=3D"color:#080">&quot;&quo=
t;</span><span style=3D"color:#000"> </span><span style=3D"color:#660">::</=
span><span style=3D"color:#080">&quot;irm&quot;</span><span style=3D"color:=
#660">(</span><span style=3D"color:#000">secret_int</span><span style=3D"co=
lor:#660">),</span><span style=3D"color:#000"> </span><span style=3D"color:=
#080">&quot;xm&quot;</span><span style=3D"color:#660">(</span><span style=
=3D"color:#000">secret_float</span><span style=3D"color:#660">));</span><sp=
an style=3D"color:#000"><br></span><span style=3D"color:#660">}</span><span=
 style=3D"color:#000"><br></span></div></code></div><br>I would really like=
 an attribute for that, though.<br><br><br>Le vendredi 28 septembre 2018 15=
:36:42 UTC+2, Daniel Gutson a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"auto"><div>Yeah.=C2=A0 But please note that this is=
 not only for function calls.<div dir=3D"auto"><br></div><div dir=3D"auto">=
void f()</div><div dir=3D"auto">{</div><div dir=3D"auto">=C2=A0 =C2=A0int s=
ecret;</div><div dir=3D"auto">=C2=A0 =C2=A0....</div><div dir=3D"auto">=C2=
=A0 =C2=A0secret =3D 0;=C2=A0 //removed due to DSE</div><div dir=3D"auto">}=
</div><div dir=3D"auto"><br></div><div dir=3D"auto">If I declare secret as =
volatile or write 0s to its address I may prevent the compiler to use a reg=
ister impacting in performance. That&#39;s why I want to use the attribute =
here too.</div><div dir=3D"auto"><br></div><br><br><div class=3D"gmail_quot=
e"><div dir=3D"ltr">El vie., 28 sept. 2018 10:32, Andrew Giese &lt;<a rel=
=3D"nofollow noreferrer noreferrer">gies...@gmail.com</a>&gt; escribi=C3=B3=
:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div>I like the=
 idea.<div dir=3D"auto">Function poisoning might also serve your needs. E.g=
..,=C2=A0<a href=3D"https://www.fluentcpp.com/2018/09/04/function-poisoning-=
in-cpp/" rel=3D"nofollow noreferrer" target=3D"_blank">https://www.fluentcp=
p.com/2018/09/04/function-poisoning-in-cpp/</a></div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">If gcc poison were standardized in some fashion, yo=
u could write your own wrappers to those functions with all the [[nodiscard=
]] you might want.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Contr=
ol in that case is a little less granular, indeed. Probably if you&#39;re w=
riting [[nodiscard]] on a per-expression basis you are not discarding the r=
esult already.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Regards</=
div>
</div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow noreferrer noreferrer">std-proposal...@isocpp.or=
g</a>.<br>
To post to this group, send email to <a rel=3D"nofollow noreferrer noreferr=
er">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAO8_tC4kNZ6s-xMXo69n1D3dbOMkqt0fjLU4=
4Uq5TfABp17hQQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 rel=3D"nofollow noreferrer" target=3D"_blank">https://groups.google.com/a/=
isocpp.org/d/msgid/std-proposals/CAO8_tC4kNZ6s-xMXo69n1D3dbOMkqt0fjLU44Uq5T=
fABp17hQQ%40mail.gmail.com</a>.<br>
</blockquote></div></div></div>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow noreferrer">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow noreferrer">std-pr.=
...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/94d79dd7-ba3b-4bf8-91ed-e5dc02b33670%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"nofollow no=
referrer" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/=
std-proposals/94d79dd7-ba3b-4bf8-91ed-e5dc02b33670%40isocpp.org</a>.<br>
</blockquote></div></div></div>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" rel=3D"nore=
ferrer" target=3D"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" rel=3D"noreferrer" target=3D"_blank">std-proposals@isocpp.org</a>.<br=
>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c71e2ca9-c5f4-4699-b2c1-b23245eef683%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"noreferrer"=
 target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/c71e2ca9-c5f4-4699-b2c1-b23245eef683%40isocpp.org</a>.<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"m_4163359001443191033m_-6113861466331700788gmail_signature" data-=
smartmail=3D"gmail_signature">Who=E2=80=99s got the sweetest disposition?<b=
r>One guess, that=E2=80=99s who?<br>Who=E2=80=99d never, ever start an argu=
ment?<br>Who never shows a bit of temperament?<br>Who&#39;s never wrong but=
 always right?<br>Who&#39;d never dream of starting a fight?<br>Who get stu=
ck with all the bad luck? </div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" rel=3D"nore=
ferrer" target=3D"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" rel=3D"noreferrer" target=3D"_blank">std-proposals@isocpp.org</a>.<br=
>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-3rNrze-AUW-FNy6S_FRdWt78LGJyDz=
DGQPXqsbgHnDoQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/isocpp.or=
g/d/msgid/std-proposals/CAFdMc-3rNrze-AUW-FNy6S_FRdWt78LGJyDzDGQPXqsbgHnDoQ=
%40mail.gmail.com</a>.<br>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAO8_tC4Mo6Cn8rAw%2BsukXyv%3DpsExWBjB=
ehr%2B2G4SDB1sSvm-Rw%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std=
-proposals/CAO8_tC4Mo6Cn8rAw%2BsukXyv%3DpsExWBjBehr%2B2G4SDB1sSvm-Rw%40mail=
..gmail.com</a>.<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"gmail_signature" data-smartmail=3D"gmail_signature">Who=E2=80=99s=
 got the sweetest disposition?<br>One guess, that=E2=80=99s who?<br>Who=E2=
=80=99d never, ever start an argument?<br>Who never shows a bit of temperam=
ent?<br>Who&#39;s never wrong but always right?<br>Who&#39;d never dream of=
 starting a fight?<br>Who get stuck with all the bad luck? </div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-2Bmpf6LM2b5MJtBtkSRtDOgFWCMM%3=
DMqMrviETNyRhN-A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-2Bmpf6LM=
2b5MJtBtkSRtDOgFWCMM%3DMqMrviETNyRhN-A%40mail.gmail.com</a>.<br />

--000000000000ee228c0576f00391--

.

--00000000000076a8a80576f03b31
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

All good points. Either way, I'm in favor of it.

On Fri, Sep 28, 2018, 8:21 AM Daniel Gutson <danielgutson@gmail.com> wrote:

>
>
> El vie., 28 de sep. de 2018 a la(s) 12:11, Andrew Giese (
> gieseanw@gmail.com) escribi=C3=B3:
>
>> I think the primary opposition will come from the fact that DSE is, for
>> the moment, an implementation detail of the compiler. So, to have this
>> standardized, we might also need to standardize DSE.
>>
>
> I gently disagree: attributes are exactly targetted to QoI and compiler
> implementations, they are ignorable, and they may target either
> optimizations or diagnostics. Even the original (current) [[nodiscard]]
> targets diagnostics; I'm proposing to extend it to other uses.
> [[nodiscard]] used in statements could perfectly target the diagnostics
> subsystem as well, but that will be QoI (it could either do nothing, or
> prevent discarding).
> In no way I pretend to standardize optimizations in general nor DSE in
> particular. Otherwise then CSE will arrive, etc.
>
>
>>
>> The name of the attribute will also be endlessly debated I'm sure. The
>> existing attributes are about informing compilers and programmers of
>> program correctness (e.g., it's correct to fall through a case label), a=
nd
>> this one is only about compiler optimization. Reusing [[nodiscard]] in t=
his
>> fashion might be argued to be disruptive, so we need to be ready for tha=
t.
>> On the other hand, the committee likes to avoid new reserved words, so
>> [[nodiscard]] may be preferable.
>>
>> Regards
>> Andy
>>
>>
>> On Fri, Sep 28, 2018, 7:50 AM Daniel Gutson <danielgutson@gmail.com>
>> wrote:
>>
>>>
>>>
>>> El vie., 28 de sep. de 2018 a la(s) 11:36, <florian.csdt@gmail.com>
>>> escribi=C3=B3:
>>>
>>>> I completely understood what you meant, and yes what you are proposing
>>>> is compatible with the current language.
>>>> I just wanted to highlight that it might be misleading to have the sam=
e
>>>> attribute with different meaning when it is used on a function declara=
tion,
>>>> or on an expression (a declaration is also a statement).
>>>>
>>>> Also, after some thinking, in this case, the goal is not to force the
>>>> last assignment, but to force
>>>>
>>>
>>> I just wanted to give a way to the programmer to tell the compiler that
>>> the statement is important. Later, the compiler may just warn that it w=
ould
>>> remove the statement (so the programmer has to look for another mean) o=
r
>>> honor the request by not removing anything (thus impacting in the final
>>> binary).
>>>
>>>
>>>> the last 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 accessed after its lifetime =
end
>>>> and so the last assignment should be kept and propagated to every stor=
age
>>>> of the object:
>>>>
>>>> void f() {
>>>>   [[undead]] int secret;
>>>>   /* ... */
>>>>   secret =3D 0;
>>>> }
>>>> That wouldn't mean the lifetime of the object is extended and it
>>>> becomes valid to access it afterwards.
>>>> It would tell the compiler it should behave as-if the object *could*
>>>> be accessed afterwards.
>>>>
>>>>
>>>> Le vendredi 28 septembre 2018 16:18:12 UTC+2, Daniel Gutson a =C3=A9cr=
it :
>>>>>
>>>>>
>>>>>
>>>>> El vie., 28 sept. 2018 11:14, <floria...@gmail.com> escribi=C3=B3:
>>>>>
>>>>>> I want to highlight that [[nodiscard]] on functions is not about
>>>>>> forcing the compiler to keep the value, but instead to emit a warnin=
g if
>>>>>> the user doesn't use the value.
>>>>>>
>>>>>
>>>>> I'm proposing using [[nodiscard]] for statements rather than for
>>>>> declarations.
>>>>> That being said, it would be placed in the function call statement. I
>>>>> want the compiler to still do DSE where appropriate and at the same t=
ime
>>>>> allow the programmer to thoughtfully prevent it.
>>>>>
>>>>>
>>>>> So meaning would be different.
>>>>>> In that respect, another attribute name might be better.
>>>>>>
>>>>>> Also, it is already possible (but cumbersome) to implement already
>>>>>> without volatile:
>>>>>> void f() {
>>>>>>   int secret_int;
>>>>>>   float secret_float;
>>>>>>   /* ... */
>>>>>>   secret_int =3D 0;
>>>>>>   secret_float =3D 0
>>>>>>   asm volatile ("" ::"irm"(secret_int), "xm"(secret_float));
>>>>>> }
>>>>>>
>>>>>> I would really like an attribute for that, though.
>>>>>>
>>>>>>
>>>>>> Le vendredi 28 septembre 2018 15:36:42 UTC+2, Daniel Gutson a =C3=A9=
crit :
>>>>>>>
>>>>>>> Yeah.  But please note that this is not only for function calls.
>>>>>>>
>>>>>>> void f()
>>>>>>> {
>>>>>>>    int secret;
>>>>>>>    ....
>>>>>>>    secret =3D 0;  //removed due to DSE
>>>>>>> }
>>>>>>>
>>>>>>> If I declare secret as volatile or write 0s to its address I may
>>>>>>> prevent the compiler to use a register impacting in performance. Th=
at's why
>>>>>>> I want to use the attribute here too.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> El vie., 28 sept. 2018 10:32, Andrew Giese <gies...@gmail.com>
>>>>>>> escribi=C3=B3:
>>>>>>>
>>>>>>>> I like the idea.
>>>>>>>> Function poisoning might also serve your needs. E.g.,
>>>>>>>> https://www.fluentcpp.com/2018/09/04/function-poisoning-in-cpp/
>>>>>>>>
>>>>>>>> If gcc poison were standardized in some fashion, you could write
>>>>>>>> your own wrappers to those functions with all the [[nodiscard]] yo=
u might
>>>>>>>> want.
>>>>>>>>
>>>>>>>> Control in that case is a little less granular, indeed. Probably i=
f
>>>>>>>> you're writing [[nodiscard]] on a per-expression basis you are not
>>>>>>>> discarding the result already.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>>
>>>>>>>> --
>>>>>>>> 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-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/CAO8_=
tC4kNZ6s-xMXo69n1D3dbOMkqt0fjLU44Uq5TfABp17hQQ%40mail.gmail.com
>>>>>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAO8=
_tC4kNZ6s-xMXo69n1D3dbOMkqt0fjLU44Uq5TfABp17hQQ%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter>
>>>>>>>> .
>>>>>>>>
>>>>>>> --
>>>>>> 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-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/94d79dd=
7-ba3b-4bf8-91ed-e5dc02b33670%40isocpp.org
>>>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/94d79d=
d7-ba3b-4bf8-91ed-e5dc02b33670%40isocpp.org?utm_medium=3Demail&utm_source=
=3Dfooter>
>>>>>> .
>>>>>>
>>>>> --
>>>> 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/c71e2ca9-=
c5f4-4699-b2c1-b23245eef683%40isocpp.org
>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c71e2ca9=
-c5f4-4699-b2c1-b23245eef683%40isocpp.org?utm_medium=3Demail&utm_source=3Df=
ooter>
>>>> .
>>>>
>>>
>>>
>>> --
>>> Who=E2=80=99s got the sweetest disposition?
>>> One guess, that=E2=80=99s who?
>>> Who=E2=80=99d never, ever start an argument?
>>> Who never shows a bit of temperament?
>>> Who's never wrong but always right?
>>> Who'd never dream of starting a fight?
>>> Who get stuck with all the bad luck?
>>>
>>> --
>>> 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/CAFdMc-3rN=
rze-AUW-FNy6S_FRdWt78LGJyDzDGQPXqsbgHnDoQ%40mail.gmail.com
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-3r=
Nrze-AUW-FNy6S_FRdWt78LGJyDzDGQPXqsbgHnDoQ%40mail.gmail.com?utm_medium=3Dem=
ail&utm_source=3Dfooter>
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> 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/CAO8_tC4Mo6=
Cn8rAw%2BsukXyv%3DpsExWBjBehr%2B2G4SDB1sSvm-Rw%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAO8_tC4Mo=
6Cn8rAw%2BsukXyv%3DpsExWBjBehr%2B2G4SDB1sSvm-Rw%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter>
>> .
>>
>
>
> --
> Who=E2=80=99s got the sweetest disposition?
> One guess, that=E2=80=99s who?
> Who=E2=80=99d never, ever start an argument?
> Who never shows a bit of temperament?
> Who's never wrong but always right?
> Who'd never dream of starting a fight?
> Who get stuck with all the bad luck?
>
> --
> 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/CAFdMc-2Bmpf=
6LM2b5MJtBtkSRtDOgFWCMM%3DMqMrviETNyRhN-A%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-2Bmp=
f6LM2b5MJtBtkSRtDOgFWCMM%3DMqMrviETNyRhN-A%40mail.gmail.com?utm_medium=3Dem=
ail&utm_source=3Dfooter>
> .
>

--=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/CAO8_tC54sTj6XV0CdD9KdZ0dt%3D8M%3DoG_cngOKq%3DKP=
oNsGuegng%40mail.gmail.com.

--00000000000076a8a80576f03b31
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">All good points. Either way, I&#39;m in favor of it.</div=
><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Sep 28, 2018, 8:21=
 AM Daniel Gutson &lt;<a href=3D"mailto:danielgutson@gmail.com">danielgutso=
n@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">El vie., 28 de=
 sep. de 2018 a la(s) 12:11, Andrew Giese (<a href=3D"mailto:gieseanw@gmail=
..com" target=3D"_blank" rel=3D"noreferrer">gieseanw@gmail.com</a>) escribi=
=C3=B3:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto">I think t=
he primary opposition will come from the fact that DSE is, for the moment, =
an implementation detail of the compiler. So, to have this standardized, we=
 might also need to standardize DSE.</div></blockquote><div><br></div><div>=
I gently disagree: attributes are exactly targetted to QoI and compiler imp=
lementations, they are ignorable, and they may target either optimizations =
or diagnostics. Even the original (current) [[nodiscard]] targets diagnosti=
cs; I&#39;m proposing to extend it to other uses. [[nodiscard]] used in sta=
tements could perfectly target the diagnostics subsystem as well, but that =
will be QoI (it could either do nothing, or prevent discarding).</div><div>=
In no way I pretend to standardize optimizations in general nor DSE in part=
icular. Otherwise then CSE will arrive, etc.</div><div>=C2=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto"><br></div><div d=
ir=3D"auto">The name of the attribute will also be endlessly debated I&#39;=
m sure. The existing attributes are about informing compilers and programme=
rs of program correctness (e.g., it&#39;s correct to fall through a case la=
bel), and this one is only about compiler optimization. Reusing [[nodiscard=
]] in this fashion might be argued to be disruptive, so we need to be ready=
 for that. On the other hand, the committee likes to avoid new reserved wor=
ds, so [[nodiscard]] may be preferable.</div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">Regards</div><div dir=3D"auto">Andy</div><div dir=3D"auto">=
<br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Sep=
 28, 2018, 7:50 AM Daniel Gutson &lt;<a href=3D"mailto:danielgutson@gmail.c=
om" target=3D"_blank" rel=3D"noreferrer">danielgutson@gmail.com</a>&gt; wro=
te:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br><div c=
lass=3D"gmail_quote"><div dir=3D"ltr">El vie., 28 de sep. de 2018 a la(s) 1=
1:36, &lt;<a href=3D"mailto:florian.csdt@gmail.com" rel=3D"noreferrer noref=
errer" target=3D"_blank">florian.csdt@gmail.com</a>&gt; escribi=C3=B3:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I completely understoo=
d what you meant, and yes what you are proposing is compatible with the cur=
rent language.<br>I just wanted to highlight that it might be misleading to=
 have the same attribute with different meaning when it is used on a functi=
on declaration, or on an expression (a declaration is also a statement).<br=
><br>Also, after some thinking, in this case, the goal is not to force the =
last assignment, but to force</div></blockquote><div><br></div><div>I just =
wanted to give a way to the programmer to tell the compiler that the statem=
ent is important. Later, the compiler may just warn that it would remove th=
e statement (so the programmer has to look for another mean) or honor the r=
equest by not removing anything (thus impacting in the final binary).=C2=A0=
</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"> the=
 last value of the variable, wherever the variable is, even if the variable=
 is both in register and stack.<br>So in that case, you might be better wit=
h a [[undead]] attribute whose meaning would be that the object might be ac=
cessed after its lifetime end and so the last assignment should be kept and=
 propagated to every storage of the object:<br><br><div style=3D"background=
-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;bo=
rder-width:1px" class=3D"m_-1158832929682602393m_4163359001443191033m_-6113=
861466331700788m_-4790073964389657585prettyprint"><code class=3D"m_-1158832=
929682602393m_4163359001443191033m_-6113861466331700788m_-47900739643896575=
85prettyprint"><div class=3D"m_-1158832929682602393m_4163359001443191033m_-=
6113861466331700788m_-4790073964389657585subprettyprint"><span style=3D"col=
or:#008" class=3D"m_-1158832929682602393m_4163359001443191033m_-61138614663=
31700788m_-4790073964389657585styled-by-prettify">void</span><span style=3D=
"color:#000" class=3D"m_-1158832929682602393m_4163359001443191033m_-6113861=
466331700788m_-4790073964389657585styled-by-prettify"> f</span><span style=
=3D"color:#660" class=3D"m_-1158832929682602393m_4163359001443191033m_-6113=
861466331700788m_-4790073964389657585styled-by-prettify">()</span><span sty=
le=3D"color:#000" class=3D"m_-1158832929682602393m_4163359001443191033m_-61=
13861466331700788m_-4790073964389657585styled-by-prettify"> </span><span st=
yle=3D"color:#660" class=3D"m_-1158832929682602393m_4163359001443191033m_-6=
113861466331700788m_-4790073964389657585styled-by-prettify">{</span><span s=
tyle=3D"color:#000" class=3D"m_-1158832929682602393m_4163359001443191033m_-=
6113861466331700788m_-4790073964389657585styled-by-prettify"><br>=C2=A0 </s=
pan><span style=3D"color:#660" class=3D"m_-1158832929682602393m_41633590014=
43191033m_-6113861466331700788m_-4790073964389657585styled-by-prettify">[[<=
/span><span style=3D"color:#000" class=3D"m_-1158832929682602393m_416335900=
1443191033m_-6113861466331700788m_-4790073964389657585styled-by-prettify">u=
ndead</span><span style=3D"color:#660" class=3D"m_-1158832929682602393m_416=
3359001443191033m_-6113861466331700788m_-4790073964389657585styled-by-prett=
ify">]]</span><span style=3D"color:#000" class=3D"m_-1158832929682602393m_4=
163359001443191033m_-6113861466331700788m_-4790073964389657585styled-by-pre=
ttify"> </span><span style=3D"color:#008" class=3D"m_-1158832929682602393m_=
4163359001443191033m_-6113861466331700788m_-4790073964389657585styled-by-pr=
ettify">int</span><span style=3D"color:#000" class=3D"m_-115883292968260239=
3m_4163359001443191033m_-6113861466331700788m_-4790073964389657585styled-by=
-prettify"> secret</span><span style=3D"color:#660" class=3D"m_-11588329296=
82602393m_4163359001443191033m_-6113861466331700788m_-4790073964389657585st=
yled-by-prettify">;</span><span style=3D"color:#000" class=3D"m_-1158832929=
682602393m_4163359001443191033m_-6113861466331700788m_-4790073964389657585s=
tyled-by-prettify"><br>=C2=A0 </span><span style=3D"color:#800" class=3D"m_=
-1158832929682602393m_4163359001443191033m_-6113861466331700788m_-479007396=
4389657585styled-by-prettify">/* ... */</span><span style=3D"color:#000" cl=
ass=3D"m_-1158832929682602393m_4163359001443191033m_-6113861466331700788m_-=
4790073964389657585styled-by-prettify"><br>=C2=A0 secret </span><span style=
=3D"color:#660" class=3D"m_-1158832929682602393m_4163359001443191033m_-6113=
861466331700788m_-4790073964389657585styled-by-prettify">=3D</span><span st=
yle=3D"color:#000" class=3D"m_-1158832929682602393m_4163359001443191033m_-6=
113861466331700788m_-4790073964389657585styled-by-prettify"> </span><span s=
tyle=3D"color:#066" class=3D"m_-1158832929682602393m_4163359001443191033m_-=
6113861466331700788m_-4790073964389657585styled-by-prettify">0</span><span =
style=3D"color:#660" class=3D"m_-1158832929682602393m_4163359001443191033m_=
-6113861466331700788m_-4790073964389657585styled-by-prettify">;</span><span=
 style=3D"color:#000" class=3D"m_-1158832929682602393m_4163359001443191033m=
_-6113861466331700788m_-4790073964389657585styled-by-prettify"><br></span><=
span style=3D"color:#660" class=3D"m_-1158832929682602393m_4163359001443191=
033m_-6113861466331700788m_-4790073964389657585styled-by-prettify">}</span>=
<span style=3D"color:#000" class=3D"m_-1158832929682602393m_416335900144319=
1033m_-6113861466331700788m_-4790073964389657585styled-by-prettify"><br></s=
pan></div></code></div>That wouldn&#39;t mean the lifetime of the object is=
 extended and it becomes valid to access it afterwards.<br>It would tell th=
e compiler it should behave as-if the object <i>could</i> be accessed after=
wards.<br><br><br>Le vendredi 28 septembre 2018 16:18:12 UTC+2, Daniel Guts=
on a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"a=
uto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">El vie., 28 s=
ept. 2018 11:14,  &lt;<a rel=3D"nofollow noreferrer noreferrer">floria...@g=
mail.com</a>&gt; escribi=C3=B3:<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr">I want to highlight that [[nodiscard]] on functions is not ab=
out forcing the compiler to keep the value, but instead to emit a warning i=
f the user doesn&#39;t use the value.<br></div></blockquote></div></div><di=
v dir=3D"auto"><br></div><div dir=3D"auto">I&#39;m proposing using [[nodisc=
ard]] for statements rather than for declarations.</div><div dir=3D"auto">T=
hat being said, it would be placed in the function call statement. I want t=
he compiler to still do DSE where appropriate and at the same time allow th=
e programmer to thoughtfully prevent it.</div><div dir=3D"auto"><br></div><=
div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr">So meaning would be different.=
<br>In that respect, another attribute name might be better.<br><br>Also, i=
t is already possible (but cumbersome) to implement already without volatil=
e:<br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,=
187,187);border-style:solid;border-width:1px"><code><div><span style=3D"col=
or:#008">void</span><span style=3D"color:#000"> </span><span style=3D"color=
:#000">f</span><span style=3D"color:#660">()</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#660">{</span><span style=3D"color:#000"><b=
r>=C2=A0 </span><span style=3D"color:#008">int</span><span style=3D"color:#=
000"> secret_int</span><span style=3D"color:#660">;</span><span style=3D"co=
lor:#000"><br>=C2=A0 </span><span style=3D"color:#008">float</span><span st=
yle=3D"color:#000"> secret_float</span><span style=3D"color:#660">;</span><=
span style=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#800">/* .=
... */</span><span style=3D"color:#000"><br>=C2=A0 secret_int </span><span s=
tyle=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><span styl=
e=3D"color:#066">0</span><span style=3D"color:#660">;</span><span style=3D"=
color:#000"><br>=C2=A0 secret_float </span><span style=3D"color:#660">=3D</=
span><span style=3D"color:#000"> </span><span style=3D"color:#066">0</span>=
<span style=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#008">asm=
</span><span style=3D"color:#000"> </span><span style=3D"color:#008">volati=
le</span><span style=3D"color:#000"> </span><span style=3D"color:#660">(</s=
pan><span style=3D"color:#080">&quot;&quot;</span><span style=3D"color:#000=
"> </span><span style=3D"color:#660">::</span><span style=3D"color:#080">&q=
uot;irm&quot;</span><span style=3D"color:#660">(</span><span style=3D"color=
:#000">secret_int</span><span style=3D"color:#660">),</span><span style=3D"=
color:#000"> </span><span style=3D"color:#080">&quot;xm&quot;</span><span s=
tyle=3D"color:#660">(</span><span style=3D"color:#000">secret_float</span><=
span style=3D"color:#660">));</span><span style=3D"color:#000"><br></span><=
span style=3D"color:#660">}</span><span style=3D"color:#000"><br></span></d=
iv></code></div><br>I would really like an attribute for that, though.<br><=
br><br>Le vendredi 28 septembre 2018 15:36:42 UTC+2, Daniel Gutson a =C3=A9=
crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:=
0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div>Y=
eah.=C2=A0 But please note that this is not only for function calls.<div di=
r=3D"auto"><br></div><div dir=3D"auto">void f()</div><div dir=3D"auto">{</d=
iv><div dir=3D"auto">=C2=A0 =C2=A0int secret;</div><div dir=3D"auto">=C2=A0=
 =C2=A0....</div><div dir=3D"auto">=C2=A0 =C2=A0secret =3D 0;=C2=A0 //remov=
ed due to DSE</div><div dir=3D"auto">}</div><div dir=3D"auto"><br></div><di=
v dir=3D"auto">If I declare secret as volatile or write 0s to its address I=
 may prevent the compiler to use a register impacting in performance. That&=
#39;s why I want to use the attribute here too.</div><div dir=3D"auto"><br>=
</div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">El vie., 28 sept.=
 2018 10:32, Andrew Giese &lt;<a rel=3D"nofollow noreferrer noreferrer nore=
ferrer">gies...@gmail.com</a>&gt; escribi=C3=B3:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"auto"><div>I like the idea.<div dir=3D"auto">Func=
tion poisoning might also serve your needs. E.g.,=C2=A0<a href=3D"https://w=
ww.fluentcpp.com/2018/09/04/function-poisoning-in-cpp/" rel=3D"nofollow nor=
eferrer noreferrer" target=3D"_blank">https://www.fluentcpp.com/2018/09/04/=
function-poisoning-in-cpp/</a></div><div dir=3D"auto"><br></div><div dir=3D=
"auto">If gcc poison were standardized in some fashion, you could write you=
r own wrappers to those functions with all the [[nodiscard]] you might want=
..</div><div dir=3D"auto"><br></div><div dir=3D"auto">Control in that case i=
s a little less granular, indeed. Probably if you&#39;re writing [[nodiscar=
d]] on a per-expression basis you are not discarding the result already.</d=
iv><div dir=3D"auto"><br></div><div dir=3D"auto">Regards</div>
</div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow noreferrer noreferrer noreferrer">std-proposal..=
..@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow noreferrer noreferr=
er noreferrer">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAO8_tC4kNZ6s-xMXo69n1D3dbOMkqt0fjLU4=
4Uq5TfABp17hQQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 rel=3D"nofollow noreferrer noreferrer" target=3D"_blank">https://groups.go=
ogle.com/a/isocpp.org/d/msgid/std-proposals/CAO8_tC4kNZ6s-xMXo69n1D3dbOMkqt=
0fjLU44Uq5TfABp17hQQ%40mail.gmail.com</a>.<br>
</blockquote></div></div></div>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow noreferrer noreferrer">std-proposal...@isocpp.or=
g</a>.<br>
To post to this group, send email to <a rel=3D"nofollow noreferrer noreferr=
er">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/94d79dd7-ba3b-4bf8-91ed-e5dc02b33670%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"nofollow no=
referrer noreferrer" target=3D"_blank">https://groups.google.com/a/isocpp.o=
rg/d/msgid/std-proposals/94d79dd7-ba3b-4bf8-91ed-e5dc02b33670%40isocpp.org<=
/a>.<br>
</blockquote></div></div></div>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" rel=3D"nore=
ferrer noreferrer" target=3D"_blank">std-proposals+unsubscribe@isocpp.org</=
a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" rel=3D"noreferrer noreferrer" target=3D"_blank">std-proposals@isocpp.=
org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c71e2ca9-c5f4-4699-b2c1-b23245eef683%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"noreferrer =
noreferrer" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgi=
d/std-proposals/c71e2ca9-c5f4-4699-b2c1-b23245eef683%40isocpp.org</a>.<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"m_-1158832929682602393m_4163359001443191033m_-6113861466331700788=
gmail_signature" data-smartmail=3D"gmail_signature">Who=E2=80=99s got the s=
weetest disposition?<br>One guess, that=E2=80=99s who?<br>Who=E2=80=99d nev=
er, ever start an argument?<br>Who never shows a bit of temperament?<br>Who=
&#39;s never wrong but always right?<br>Who&#39;d never dream of starting a=
 fight?<br>Who get stuck with all the bad luck? </div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" rel=3D"nore=
ferrer noreferrer" target=3D"_blank">std-proposals+unsubscribe@isocpp.org</=
a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" rel=3D"noreferrer noreferrer" target=3D"_blank">std-proposals@isocpp.=
org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-3rNrze-AUW-FNy6S_FRdWt78LGJyDz=
DGQPXqsbgHnDoQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 rel=3D"noreferrer noreferrer" target=3D"_blank">https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/CAFdMc-3rNrze-AUW-FNy6S_FRdWt78LGJyDzDGQ=
PXqsbgHnDoQ%40mail.gmail.com</a>.<br>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank" rel=3D"noreferrer">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">std-proposals@isocpp.org</a>.<br=
>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAO8_tC4Mo6Cn8rAw%2BsukXyv%3DpsExWBjB=
ehr%2B2G4SDB1sSvm-Rw%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Df=
ooter" target=3D"_blank" rel=3D"noreferrer">https://groups.google.com/a/iso=
cpp.org/d/msgid/std-proposals/CAO8_tC4Mo6Cn8rAw%2BsukXyv%3DpsExWBjBehr%2B2G=
4SDB1sSvm-Rw%40mail.gmail.com</a>.<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"m_-1158832929682602393gmail_signature" data-smartmail=3D"gmail_si=
gnature">Who=E2=80=99s got the sweetest disposition?<br>One guess, that=E2=
=80=99s who?<br>Who=E2=80=99d never, ever start an argument?<br>Who never s=
hows a bit of temperament?<br>Who&#39;s never wrong but always right?<br>Wh=
o&#39;d never dream of starting a fight?<br>Who get stuck with all the bad =
luck? </div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank" rel=3D"noreferrer">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">std-proposals@isocpp.org</a>.<br=
>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-2Bmpf6LM2b5MJtBtkSRtDOgFWCMM%3=
DMqMrviETNyRhN-A%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank" rel=3D"noreferrer">https://groups.google.com/a/isocpp.=
org/d/msgid/std-proposals/CAFdMc-2Bmpf6LM2b5MJtBtkSRtDOgFWCMM%3DMqMrviETNyR=
hN-A%40mail.gmail.com</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAO8_tC54sTj6XV0CdD9KdZ0dt%3D8M%3DoG_=
cngOKq%3DKPoNsGuegng%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAO8_tC54sT=
j6XV0CdD9KdZ0dt%3D8M%3DoG_cngOKq%3DKPoNsGuegng%40mail.gmail.com</a>.<br />

--00000000000076a8a80576f03b31--

.

------=_Part_589_1900344182.1538173345269
Content-Type: multipart/alternative;
 boundary="----=_Part_590_1884812630.1538173345270"

------=_Part_590_1884812630.1538173345270
Content-Type: text/plain; charset="UTF-8"

On Friday, September 28, 2018 at 7:14:20 AM UTC-7, floria...@gmail.com
wrote:
>
> I want to highlight that [[nodiscard]] on functions is not about forcing
> the compiler to keep the value, but instead to emit a warning if the user
> doesn't use the value.
> So meaning would be different.
> In that respect, another attribute name might be better.
>

Right. The standard attribute [[nodiscard]] goes in a *library* and
instructs the compiler to kick* the user* if the user has *forgotten to use* the
result of some *library call*.

Daniel, what you are asking for is an attribute that goes in *user code*
and instructs the compiler to kick *itself?* if the user has *forgotten to
use* the result of some *assignment expression*.


Also, it is already possible (but cumbersome) to implement already without
> volatile:
> void f() {
>   int secret_int;
>   float secret_float;
>   /* ... */
>   secret_int = 0;
>   secret_float = 0
>   asm volatile ("" ::"irm"(secret_int), "xm"(secret_float));
> }
>

This certainly seems to make sure that the write reaches L1 cache, but do
you know whether the write is guaranteed to have reached and overwritten
any copies of the data that might remain in L2 and main memory?
What about the swap partition? Are you worried that a copy of the secret
may have been swapped out to disk?  (Reductio ad absurdum: What if it was
swapped out to removable media that has since been ejected?)

Before you can start talking meaningfully about preventing the compiler
from eliminating your dead "=0" statements, you need to have a mental model
that explains what good those "=0" statements are supposed to do in the
first place.

HTH,
Arthur

--
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/1442c15c-6a58-4f3e-83cf-9f5554fb9981%40isocpp.org.

------=_Part_590_1884812630.1538173345270
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, September 28, 2018 at 7:14:20 AM UTC-7, floria.=
...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr">I want to highlight that [[nodiscard]] on functions is not about forc=
ing the compiler to keep the value, but instead to emit a warning if the us=
er doesn&#39;t use the value.<br>So meaning would be different.<br>In that =
respect, another attribute name might be better.<br></div></blockquote><div=
><br></div><div>Right. The standard attribute [[nodiscard]] goes in a <i>li=
brary</i> and instructs the compiler to kick<i>=C2=A0the user</i> if the us=
er has=C2=A0<i>forgotten to use</i>=C2=A0the result of some <i>library call=
</i>.</div><div><br></div><div>Daniel, what you are asking for is an attrib=
ute that goes in <i>user code</i> and instructs the compiler to kick <i>its=
elf?</i>=C2=A0if the user has <i>forgotten to use</i>=C2=A0the result of so=
me <i>assignment expression</i>.</div><div><br></div><div><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Also, it is already =
possible (but cumbersome) to implement already without volatile:<br><div st=
yle=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);bord=
er-style:solid;border-width:1px"><code><div><span style=3D"color:#008">void=
</span><span style=3D"color:#000"> </span><span style=3D"color:#000">f</spa=
n><span style=3D"color:#660">()</span><span style=3D"color:#000"> </span><s=
pan style=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=A0 </sp=
an><span style=3D"color:#008">int</span><span style=3D"color:#000"> secret_=
int</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><br=
>=C2=A0 </span><span style=3D"color:#008">float</span><span style=3D"color:=
#000"> secret_float</span><span style=3D"color:#660">;</span><span style=3D=
"color:#000"><br>=C2=A0 </span><span style=3D"color:#800">/* ... */</span><=
span style=3D"color:#000"><br>=C2=A0 secret_int </span><span style=3D"color=
:#660">=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#0=
66">0</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><=
br>=C2=A0 secret_float </span><span style=3D"color:#660">=3D</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#066">0</span><span style=
=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#008">asm</span><spa=
n style=3D"color:#000"> </span><span style=3D"color:#008">volatile</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#660">(</span><span s=
tyle=3D"color:#080">&quot;&quot;</span><span style=3D"color:#000"> </span><=
span style=3D"color:#660">::</span><span style=3D"color:#080">&quot;irm&quo=
t;</span><span style=3D"color:#660">(</span><span style=3D"color:#000">secr=
et_int</span><span style=3D"color:#660">),</span><span style=3D"color:#000"=
> </span><span style=3D"color:#080">&quot;xm&quot;</span><span style=3D"col=
or:#660">(</span><span style=3D"color:#000">secret_float</span><span style=
=3D"color:#660">));</span><span style=3D"color:#000"><br></span><span style=
=3D"color:#660">}</span></div></code></div></div></blockquote><div><br></di=
v><div>This certainly seems to make sure that the write reaches L1 cache, b=
ut do you know whether the write is guaranteed to have reached and overwrit=
ten any copies of the data that might remain in L2 and main memory?</div><d=
iv>What about the swap partition? Are you worried that a copy of the secret=
 may have been swapped out to disk? =C2=A0(Reductio ad absurdum: What if it=
 was swapped out to removable media that has since been ejected?)</div><div=
><br></div><div>Before you can start talking meaningfully about preventing =
the compiler from eliminating your dead &quot;=3D0&quot; statements, you ne=
ed to have a mental model that explains what good those &quot;=3D0&quot; st=
atements are supposed to do in the first place.</div><div><br></div><div>HT=
H,</div><div>Arthur</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1442c15c-6a58-4f3e-83cf-9f5554fb9981%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1442c15c-6a58-4f3e-83cf-9f5554fb9981=
%40isocpp.org</a>.<br />

------=_Part_590_1884812630.1538173345270--

------=_Part_589_1900344182.1538173345269--

.

------=_Part_606_868251907.1538174035161
Content-Type: multipart/alternative;
 boundary="----=_Part_607_936912246.1538174035161"

------=_Part_607_936912246.1538174035161
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



Le samedi 29 septembre 2018 00:22:25 UTC+2, Arthur O'Dwyer a =C3=A9crit :
>
> On Friday, September 28, 2018 at 7:14:20 AM UTC-7, floria...@gmail.com=20
> wrote:
>>
>> I want to highlight that [[nodiscard]] on functions is not about forcing=
=20
>> the compiler to keep the value, but instead to emit a warning if the use=
r=20
>> doesn't use the value.
>> So meaning would be different.
>> In that respect, another attribute name might be better.
>>
>
> Right. The standard attribute [[nodiscard]] goes in a *library* and=20
> instructs the compiler to kick* the user* if the user has *forgotten to=
=20
> use* the result of some *library call*.
>
> Daniel, what you are asking for is an attribute that goes in *user code*=
=20
> and instructs the compiler to kick *itself?* if the user has *forgotten=
=20
> to use* the result of some *assignment expression*.
>
>
> Also, it is already possible (but cumbersome) to implement already withou=
t=20
>> volatile:
>> void f() {
>>   int secret_int;
>>   float secret_float;
>>   /* ... */
>>   secret_int =3D 0;
>>   secret_float =3D 0
>>   asm volatile ("" ::"irm"(secret_int), "xm"(secret_float));
>> }
>>
>
> This certainly seems to make sure that the write reaches L1 cache, but do=
=20
> you know whether the write is guaranteed to have reached and overwritten=
=20
> any copies of the data that might remain in L2 and main memory?
> What about the swap partition? Are you worried that a copy of the secret=
=20
> may have been swapped out to disk?  (Reductio ad absurdum: What if it was=
=20
> swapped out to removable media that has since been ejected?)
>
> Before you can start talking meaningfully about preventing the compiler=
=20
> from eliminating your dead "=3D0" statements, you need to have a mental m=
odel=20
> that explains what good those "=3D0" statements are supposed to do in the=
=20
> first place.
>

That's why I introduced the [[undead]] attribute: to let the compiler do=20
what is necessary to propagate the value where it is meaningful, and=20
flushing the according cacheline might be part of this process (I assume=20
user code can flush a specific cache line).
Because you don't care about the assignment per se, but you care about the=
=20
value that is visible afterwards.

--=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/866660c0-4c90-4ce9-bd5c-16ff593d35d6%40isocpp.or=
g.

------=_Part_607_936912246.1538174035161
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>Le samedi 29 septembre 2018 00:22:25 UTC+2, Arthur=
 O&#39;Dwyer a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"><div dir=3D"ltr">On Friday, September 28, 2018 at 7:14:20 AM UTC-7, <a>fl=
oria...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr">I want to highlight that [[nodiscard]] on functions is not about =
forcing the compiler to keep the value, but instead to emit a warning if th=
e user doesn&#39;t use the value.<br>So meaning would be different.<br>In t=
hat respect, another attribute name might be better.<br></div></blockquote>=
<div><br></div><div>Right. The standard attribute [[nodiscard]] goes in a <=
i>library</i> and instructs the compiler to kick<i>=C2=A0the user</i> if th=
e user has=C2=A0<i>forgotten to use</i>=C2=A0the result of some <i>library =
call</i>.</div><div><br></div><div>Daniel, what you are asking for is an at=
tribute that goes in <i>user code</i> and instructs the compiler to kick <i=
>itself?</i>=C2=A0if the user has <i>forgotten to use</i>=C2=A0the result o=
f some <i>assignment expression</i>.</div><div><br></div><div><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Also, it is already p=
ossible (but cumbersome) to implement already without volatile:<br><div sty=
le=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);borde=
r-style:solid;border-width:1px"><code><div><span style=3D"color:#008">void<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#000">f</span=
><span style=3D"color:#660">()</span><span style=3D"color:#000"> </span><sp=
an style=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=A0 </spa=
n><span style=3D"color:#008">int</span><span style=3D"color:#000"> secret_i=
nt</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><br>=
=C2=A0 </span><span style=3D"color:#008">float</span><span style=3D"color:#=
000"> secret_float</span><span style=3D"color:#660">;</span><span style=3D"=
color:#000"><br>=C2=A0 </span><span style=3D"color:#800">/* ... */</span><s=
pan style=3D"color:#000"><br>=C2=A0 secret_int </span><span style=3D"color:=
#660">=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#06=
6">0</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><b=
r>=C2=A0 secret_float </span><span style=3D"color:#660">=3D</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#066">0</span><span style=3D=
"color:#000"><br>=C2=A0 </span><span style=3D"color:#008">asm</span><span s=
tyle=3D"color:#000"> </span><span style=3D"color:#008">volatile</span><span=
 style=3D"color:#000"> </span><span style=3D"color:#660">(</span><span styl=
e=3D"color:#080">&quot;&quot;</span><span style=3D"color:#000"> </span><spa=
n style=3D"color:#660">::</span><span style=3D"color:#080">&quot;irm&quot;<=
/span><span style=3D"color:#660">(</span><span style=3D"color:#000">secret_=
int</span><span style=3D"color:#660">),</span><span style=3D"color:#000"> <=
/span><span style=3D"color:#080">&quot;xm&quot;</span><span style=3D"color:=
#660">(</span><span style=3D"color:#000">secret_float</span><span style=3D"=
color:#660">));</span><span style=3D"color:#000"><br></span><span style=3D"=
color:#660">}</span></div></code></div></div></blockquote><div><br></div><d=
iv>This certainly seems to make sure that the write reaches L1 cache, but d=
o you know whether the write is guaranteed to have reached and overwritten =
any copies of the data that might remain in L2 and main memory?</div><div>W=
hat about the swap partition? Are you worried that a copy of the secret may=
 have been swapped out to disk? =C2=A0(Reductio ad absurdum: What if it was=
 swapped out to removable media that has since been ejected?)</div><div><br=
></div><div>Before you can start talking meaningfully about preventing the =
compiler from eliminating your dead &quot;=3D0&quot; statements, you need t=
o have a mental model that explains what good those &quot;=3D0&quot; statem=
ents are supposed to do in the first place.</div></div></blockquote><div><b=
r></div><div>That&#39;s why I introduced the [[undead]] attribute: to let t=
he compiler do what is necessary to propagate the value where it is meaning=
ful, and flushing the according cacheline might be part of this process (I =
assume user code can flush a specific cache line).</div><div>Because you do=
n&#39;t care about the assignment per se, but you care about the value that=
 is visible afterwards.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/866660c0-4c90-4ce9-bd5c-16ff593d35d6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/866660c0-4c90-4ce9-bd5c-16ff593d35d6=
%40isocpp.org</a>.<br />

------=_Part_607_936912246.1538174035161--

------=_Part_606_868251907.1538174035161--

.

------=_Part_1010_1402507887.1538386079632
Content-Type: multipart/alternative;
 boundary="----=_Part_1011_663466676.1538386079632"

------=_Part_1011_663466676.1538386079632
Content-Type: text/plain; charset="UTF-8"



Op vrijdag 28 september 2018 13:14:06 UTC+2 schreef Daniel Gutson:
>
> Again, on the DSE related optimizations.
>
> I'm at the Ekoparty where I will show a presentation about security
> vulnerabilities caused by compiler optimizations. The subject is more and
> more serious (e.g. [1]).
>
> I want to propose to allow [[nodiscard]] in individual expressions, such
> as calls to memset(), std::fill_n, and assignments (DSE happens with both
> memory and registers).
>
> What's DSE?
And what's [1]?

--
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/8fa2ebcf-19c5-4b32-a8c6-9fa503010467%40isocpp.org.

------=_Part_1011_663466676.1538386079632
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>Op vrijdag 28 september 2018 13:14:06 UTC+2 schree=
f Daniel Gutson:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">Again, on the DSE related optimizations.<div><br></div><div>I&#39;m at t=
he Ekoparty where I will show a presentation about security vulnerabilities=
 caused by compiler optimizations. The subject is more and more serious (e.=
g. [1]).</div><div><br></div><div>I want to propose to allow [[nodiscard]] =
in individual expressions, such as calls to memset(), std::fill_n, and assi=
gnments (DSE happens with both memory and registers).</div><div><br></div><=
/div></blockquote><div>What&#39;s DSE?</div><div>And what&#39;s [1]?=C2=A0<=
/div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8fa2ebcf-19c5-4b32-a8c6-9fa503010467%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8fa2ebcf-19c5-4b32-a8c6-9fa503010467=
%40isocpp.org</a>.<br />

------=_Part_1011_663466676.1538386079632--

------=_Part_1010_1402507887.1538386079632--

.

------=_Part_1490_1217156924.1538450237132
Content-Type: multipart/alternative;
 boundary="----=_Part_1491_1277321005.1538450237132"

------=_Part_1491_1277321005.1538450237132
Content-Type: text/plain; charset="UTF-8"

Arthur,

Sure, it wouldn't provide *perfect* security, but ensuring the secret is
overwritten, whether that's in L1 cache or elsewhere, ensures that at
minimum it's can't be recovered without some special exploit, side-channel
or physical access to the hardware. And if Eve has some exploit that lets
her read from arbitrary DRAM or storage on Alice's computer, then Alice is
pretty much screwed anyway; there's very little you can do to harden
software against an attacker who has so thoroughly compromised the host
system.

-Ray

--
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/8aa1ec5f-ebde-43de-b3c4-a30a434c552d%40isocpp.org.

------=_Part_1491_1277321005.1538450237132
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Arthur,</div><div><br></div><div>Sure, it wouldn&#39;=
t provide <i>perfect</i> security, but ensuring the secret is overwritten, =
whether that&#39;s in L1 cache or elsewhere, ensures that at minimum it&#39=
;s can&#39;t be recovered without some special exploit, side-channel or phy=
sical access to the hardware. And if Eve has some exploit that lets her rea=
d from arbitrary DRAM or storage on Alice&#39;s computer, then Alice is pre=
tty much screwed anyway; there&#39;s very little you can do to harden softw=
are against an attacker who has so thoroughly compromised the host system.<=
br></div><div><br></div><div>-Ray<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8aa1ec5f-ebde-43de-b3c4-a30a434c552d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8aa1ec5f-ebde-43de-b3c4-a30a434c552d=
%40isocpp.org</a>.<br />

------=_Part_1491_1277321005.1538450237132--

------=_Part_1490_1217156924.1538450237132--

.

--000000000000c3674b05779c28ae
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

El vie., 28 de sep. de 2018 a la(s) 11:36, <florian.csdt@gmail.com>
escribi=C3=B3:

> I completely understood what you meant, and yes what you are proposing is
> compatible with the current language.
> I just wanted to highlight that it might be misleading to have the same
> attribute with different meaning when it is used on a function declaratio=
n,
> or on an expression (a declaration is also a statement).
>
> Also, after some thinking, in this case, the goal is not to force the las=
t
> assignment, but to force the last 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 accessed after its lifetime end
> and so the last assignment should be kept and propagated to every storage
> of the object:
>
> void f() {
>   [[undead]] int secret;
>   /* ... */
>   secret =3D 0;
> }
> That wouldn't mean the lifetime of the object is extended and it becomes
> valid to access it afterwards.
> It would tell the compiler it should behave as-if the object *could* be
> accessed afterwards.
>

Actually I would like to tell the compiler that the object should NOT be
accessible afterwards.
Additionally I would like to reuse the existing attribute name, though this
is of least importance now.


>
>
> Le vendredi 28 septembre 2018 16:18:12 UTC+2, Daniel Gutson a =C3=A9crit =
:
>>
>>
>>
>> El vie., 28 sept. 2018 11:14, <floria...@gmail.com> escribi=C3=B3:
>>
>>> I want to highlight that [[nodiscard]] on functions is not about forcin=
g
>>> the compiler to keep the value, but instead to emit a warning if the us=
er
>>> doesn't use the value.
>>>
>>
>> I'm proposing using [[nodiscard]] for statements rather than for
>> declarations.
>> That being said, it would be placed in the function call statement. I
>> want the compiler to still do DSE where appropriate and at the same time
>> allow the programmer to thoughtfully prevent it.
>>
>>
>> So meaning would be different.
>>> In that respect, another attribute name might be better.
>>>
>>> Also, it is already possible (but cumbersome) to implement already
>>> without volatile:
>>> void f() {
>>>   int secret_int;
>>>   float secret_float;
>>>   /* ... */
>>>   secret_int =3D 0;
>>>   secret_float =3D 0
>>>   asm volatile ("" ::"irm"(secret_int), "xm"(secret_float));
>>> }
>>>
>>> I would really like an attribute for that, though.
>>>
>>>
>>> Le vendredi 28 septembre 2018 15:36:42 UTC+2, Daniel Gutson a =C3=A9cri=
t :
>>>>
>>>> Yeah.  But please note that this is not only for function calls.
>>>>
>>>> void f()
>>>> {
>>>>    int secret;
>>>>    ....
>>>>    secret =3D 0;  //removed due to DSE
>>>> }
>>>>
>>>> If I declare secret as volatile or write 0s to its address I may
>>>> prevent the compiler to use a register impacting in performance. That'=
s why
>>>> I want to use the attribute here too.
>>>>
>>>>
>>>>
>>>> El vie., 28 sept. 2018 10:32, Andrew Giese <gies...@gmail.com>
>>>> escribi=C3=B3:
>>>>
>>>>> I like the idea.
>>>>> Function poisoning might also serve your needs. E.g.,
>>>>> https://www.fluentcpp.com/2018/09/04/function-poisoning-in-cpp/
>>>>>
>>>>> If gcc poison were standardized in some fashion, you could write your
>>>>> own wrappers to those functions with all the [[nodiscard]] you might =
want.
>>>>>
>>>>> Control in that case is a little less granular, indeed. Probably if
>>>>> you're writing [[nodiscard]] on a per-expression basis you are not
>>>>> discarding the result already.
>>>>>
>>>>> Regards
>>>>>
>>>>> --
>>>>> 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, sen=
d
>>>>> an 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
>>>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAO8_tC4=
kNZ6s-xMXo69n1D3dbOMkqt0fjLU44Uq5TfABp17hQQ%40mail.gmail.com
>>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAO8_tC=
4kNZ6s-xMXo69n1D3dbOMkqt0fjLU44Uq5TfABp17hQQ%40mail.gmail.com?utm_medium=3D=
email&utm_source=3Dfooter>
>>>>> .
>>>>>
>>>> --
>>> 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-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/94d79dd7-b=
a3b-4bf8-91ed-e5dc02b33670%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/94d79dd7-=
ba3b-4bf8-91ed-e5dc02b33670%40isocpp.org?utm_medium=3Demail&utm_source=3Dfo=
oter>
>>> .
>>>
>> --
> 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/c71e2ca9-c5f=
4-4699-b2c1-b23245eef683%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c71e2ca9-c5=
f4-4699-b2c1-b23245eef683%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>


--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=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/CAFdMc-3RRFoPYsyyQAX0w0eshYRytoes00VkoDPLrOPjWjj=
v3A%40mail.gmail.com.

--000000000000c3674b05779c28ae
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">El vie=
.., 28 de sep. de 2018 a la(s) 11:36, &lt;<a href=3D"mailto:florian.csdt@gma=
il.com">florian.csdt@gmail.com</a>&gt; escribi=C3=B3:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr">I completely understood what you meant,=
 and yes what you are proposing is compatible with the current language.<br=
>I just wanted to highlight that it might be misleading to have the same at=
tribute with different meaning when it is used on a function declaration, o=
r on an expression (a declaration is also a statement).<br><br>Also, after =
some thinking, in this case, the goal is not to force the last assignment, =
but to force the last value of the variable, wherever the variable is, even=
 if the variable is both in register and stack.<br>So in that case, you mig=
ht be better with a [[undead]] attribute whose meaning would be that the ob=
ject might be accessed after its lifetime end and so the last assignment sh=
ould be kept and propagated to every storage of the object:<br><br><div sty=
le=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);borde=
r-style:solid;border-width:1px" class=3D"m_-4639272485624672150prettyprint"=
><code class=3D"m_-4639272485624672150prettyprint"><div class=3D"m_-4639272=
485624672150subprettyprint"><span style=3D"color:#008" class=3D"m_-46392724=
85624672150styled-by-prettify">void</span><span style=3D"color:#000" class=
=3D"m_-4639272485624672150styled-by-prettify"> f</span><span style=3D"color=
:#660" class=3D"m_-4639272485624672150styled-by-prettify">()</span><span st=
yle=3D"color:#000" class=3D"m_-4639272485624672150styled-by-prettify"> </sp=
an><span style=3D"color:#660" class=3D"m_-4639272485624672150styled-by-pret=
tify">{</span><span style=3D"color:#000" class=3D"m_-4639272485624672150sty=
led-by-prettify"><br>=C2=A0 </span><span style=3D"color:#660" class=3D"m_-4=
639272485624672150styled-by-prettify">[[</span><span style=3D"color:#000" c=
lass=3D"m_-4639272485624672150styled-by-prettify">undead</span><span style=
=3D"color:#660" class=3D"m_-4639272485624672150styled-by-prettify">]]</span=
><span style=3D"color:#000" class=3D"m_-4639272485624672150styled-by-pretti=
fy"> </span><span style=3D"color:#008" class=3D"m_-4639272485624672150style=
d-by-prettify">int</span><span style=3D"color:#000" class=3D"m_-46392724856=
24672150styled-by-prettify"> secret</span><span style=3D"color:#660" class=
=3D"m_-4639272485624672150styled-by-prettify">;</span><span style=3D"color:=
#000" class=3D"m_-4639272485624672150styled-by-prettify"><br>=C2=A0 </span>=
<span style=3D"color:#800" class=3D"m_-4639272485624672150styled-by-prettif=
y">/* ... */</span><span style=3D"color:#000" class=3D"m_-46392724856246721=
50styled-by-prettify"><br>=C2=A0 secret </span><span style=3D"color:#660" c=
lass=3D"m_-4639272485624672150styled-by-prettify">=3D</span><span style=3D"=
color:#000" class=3D"m_-4639272485624672150styled-by-prettify"> </span><spa=
n style=3D"color:#066" class=3D"m_-4639272485624672150styled-by-prettify">0=
</span><span style=3D"color:#660" class=3D"m_-4639272485624672150styled-by-=
prettify">;</span><span style=3D"color:#000" class=3D"m_-463927248562467215=
0styled-by-prettify"><br></span><span style=3D"color:#660" class=3D"m_-4639=
272485624672150styled-by-prettify">}</span><span style=3D"color:#000" class=
=3D"m_-4639272485624672150styled-by-prettify"><br></span></div></code></div=
>That wouldn&#39;t mean the lifetime of the object is extended and it becom=
es valid to access it afterwards.<br>It would tell the compiler it should b=
ehave as-if the object <i>could</i> be accessed afterwards.<br></div></bloc=
kquote><div><br></div><div>Actually I would like to tell the compiler that =
the object should NOT be accessible afterwards.</div><div>Additionally I wo=
uld like to reuse the existing attribute name, though this is of least impo=
rtance now.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><br><br>Le vendredi 28 septembre 2018 16:18:12 UTC+2, Daniel Gutso=
n a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"au=
to"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">El vie., 28 se=
pt. 2018 11:14,  &lt;<a rel=3D"nofollow">floria...@gmail.com</a>&gt; escrib=
i=C3=B3:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I want to=
 highlight that [[nodiscard]] on functions is not about forcing the compile=
r to keep the value, but instead to emit a warning if the user doesn&#39;t =
use the value.<br></div></blockquote></div></div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">I&#39;m proposing using [[nodiscard]] for statements ra=
ther than for declarations.</div><div dir=3D"auto">That being said, it woul=
d be placed in the function call statement. I want the compiler to still do=
 DSE where appropriate and at the same time allow the programmer to thought=
fully prevent it.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></=
div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr">So meaning would be different.<br>In that respect, an=
other attribute name might be better.<br><br>Also, it is already possible (=
but cumbersome) to implement already without volatile:<br><div style=3D"bac=
kground-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:s=
olid;border-width:1px"><code><div><span style=3D"color:#008">void</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#000">f</span><span st=
yle=3D"color:#660">()</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=A0 </span><span =
style=3D"color:#008">int</span><span style=3D"color:#000"> secret_int</span=
><span style=3D"color:#660">;</span><span style=3D"color:#000"><br>=C2=A0 <=
/span><span style=3D"color:#008">float</span><span style=3D"color:#000"> se=
cret_float</span><span style=3D"color:#660">;</span><span style=3D"color:#0=
00"><br>=C2=A0 </span><span style=3D"color:#800">/* ... */</span><span styl=
e=3D"color:#000"><br>=C2=A0 secret_int </span><span style=3D"color:#660">=
=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#066">0</=
span><span style=3D"color:#660">;</span><span style=3D"color:#000"><br>=C2=
=A0 secret_float </span><span style=3D"color:#660">=3D</span><span style=3D=
"color:#000"> </span><span style=3D"color:#066">0</span><span style=3D"colo=
r:#000"><br>=C2=A0 </span><span style=3D"color:#008">asm</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">volatile</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#660">(</span><span style=3D=
"color:#080">&quot;&quot;</span><span style=3D"color:#000"> </span><span st=
yle=3D"color:#660">::</span><span style=3D"color:#080">&quot;irm&quot;</spa=
n><span style=3D"color:#660">(</span><span style=3D"color:#000">secret_int<=
/span><span style=3D"color:#660">),</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#080">&quot;xm&quot;</span><span style=3D"color:#660=
">(</span><span style=3D"color:#000">secret_float</span><span style=3D"colo=
r:#660">));</span><span style=3D"color:#000"><br></span><span style=3D"colo=
r:#660">}</span><span style=3D"color:#000"><br></span></div></code></div><b=
r>I would really like an attribute for that, though.<br><br><br>Le vendredi=
 28 septembre 2018 15:36:42 UTC+2, Daniel Gutson a =C3=A9crit=C2=A0:<blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div>Yeah.=C2=A0 But ple=
ase note that this is not only for function calls.<div dir=3D"auto"><br></d=
iv><div dir=3D"auto">void f()</div><div dir=3D"auto">{</div><div dir=3D"aut=
o">=C2=A0 =C2=A0int secret;</div><div dir=3D"auto">=C2=A0 =C2=A0....</div><=
div dir=3D"auto">=C2=A0 =C2=A0secret =3D 0;=C2=A0 //removed due to DSE</div=
><div dir=3D"auto">}</div><div dir=3D"auto"><br></div><div dir=3D"auto">If =
I declare secret as volatile or write 0s to its address I may prevent the c=
ompiler to use a register impacting in performance. That&#39;s why I want t=
o use the attribute here too.</div><div dir=3D"auto"><br></div><br><br><div=
 class=3D"gmail_quote"><div dir=3D"ltr">El vie., 28 sept. 2018 10:32, Andre=
w Giese &lt;<a rel=3D"nofollow noreferrer">gies...@gmail.com</a>&gt; escrib=
i=C3=B3:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div>I l=
ike the idea.<div dir=3D"auto">Function poisoning might also serve your nee=
ds. E.g.,=C2=A0<a href=3D"https://www.fluentcpp.com/2018/09/04/function-poi=
soning-in-cpp/" rel=3D"nofollow" target=3D"_blank">https://www.fluentcpp.co=
m/2018/09/04/function-poisoning-in-cpp/</a></div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">If gcc poison were standardized in some fashion, you co=
uld write your own wrappers to those functions with all the [[nodiscard]] y=
ou might want.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Control i=
n that case is a little less granular, indeed. Probably if you&#39;re writi=
ng [[nodiscard]] on a per-expression basis you are not discarding the resul=
t already.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Regards</div>
</div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow noreferrer">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow noreferrer">std-pr.=
...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAO8_tC4kNZ6s-xMXo69n1D3dbOMkqt0fjLU4=
4Uq5TfABp17hQQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 rel=3D"nofollow" target=3D"_blank">https://groups.google.com/a/isocpp.org/=
d/msgid/std-proposals/CAO8_tC4kNZ6s-xMXo69n1D3dbOMkqt0fjLU44Uq5TfABp17hQQ%4=
0mail.gmail.com</a>.<br>
</blockquote></div></div></div>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/94d79dd7-ba3b-4bf8-91ed-e5dc02b33670%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposa=
ls/94d79dd7-ba3b-4bf8-91ed-e5dc02b33670%40isocpp.org</a>.<br>
</blockquote></div></div></div>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c71e2ca9-c5f4-4699-b2c1-b23245eef683%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c71e2ca9-c5f4-=
4699-b2c1-b23245eef683%40isocpp.org</a>.<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"gmail_signature" data-smartmail=3D"gmail_signature">Who=E2=80=99s=
 got the sweetest disposition?<br>One guess, that=E2=80=99s who?<br>Who=E2=
=80=99d never, ever start an argument?<br>Who never shows a bit of temperam=
ent?<br>Who&#39;s never wrong but always right?<br>Who&#39;d never dream of=
 starting a fight?<br>Who get stuck with all the bad luck? </div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-3RRFoPYsyyQAX0w0eshYRytoes00Vk=
oDPLrOPjWjjv3A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-3RRFoPYsyy=
QAX0w0eshYRytoes00VkoDPLrOPjWjjv3A%40mail.gmail.com</a>.<br />

--000000000000c3674b05779c28ae--

.

--000000000000439aa705779c3e4b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

El vie., 28 de sep. de 2018 a la(s) 19:22, Arthur O'Dwyer (
arthur.j.odwyer@gmail.com) escribi=C3=B3:

> On Friday, September 28, 2018 at 7:14:20 AM UTC-7, floria...@gmail.com
> wrote:
>>
>> I want to highlight that [[nodiscard]] on functions is not about forcing
>> the compiler to keep the value, but instead to emit a warning if the use=
r
>> doesn't use the value.
>> So meaning would be different.
>> In that respect, another attribute name might be better.
>>
>
> Right. The standard attribute [[nodiscard]] goes in a *library* and
> instructs the compiler to kick* the user* if the user has *forgotten to
> use* the result of some *library call*.
>
> Daniel, what you are asking for is an attribute that goes in *user code*
> and instructs the compiler to kick *itself?* if the user has *forgotten
> to use* the result of some *assignment expression*.
>

Let's see. First, I don't see a need to distinguish between user code and
library code in this context (whereas it makes sense for [[nodiscard]] on
functions). What I am asking for goes anywhere, either user or library code=
..
Second, the attribute targets the compiler: is a tool that the programmer
can use to tell the compiler "this statement should not be discarded". What
the compiler does with that information is implementation defined: it can
just ignore it, it can honor it and not discard the statement, or it can
warn the user that it will discard it anyways (a warning), so the user can
later decide what to do (for example, recode the snippet, use volatile,
etc.).


>
>
> Also, it is already possible (but cumbersome) to implement already withou=
t
>> volatile:
>> void f() {
>>   int secret_int;
>>   float secret_float;
>>   /* ... */
>>   secret_int =3D 0;
>>   secret_float =3D 0
>>   asm volatile ("" ::"irm"(secret_int), "xm"(secret_float));
>> }
>>
>
> This certainly seems to make sure that the write reaches L1 cache, but do
> you know whether the write is guaranteed to have reached and overwritten
> any copies of the data that might remain in L2 and main memory?
> What about the swap partition? Are you worried that a copy of the secret
> may have been swapped out to disk?  (Reductio ad absurdum: What if it was
> swapped out to removable media that has since been ejected?)
>
> Before you can start talking meaningfully about preventing the compiler
> from eliminating your dead "=3D0" statements, you need to have a mental m=
odel
> that explains what good those "=3D0" statements are supposed to do in the
> first place.
>
> HTH,
> Arthur
>
> --
> 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/1442c15c-6a5=
8-4f3e-83cf-9f5554fb9981%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1442c15c-6a=
58-4f3e-83cf-9f5554fb9981%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>


--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=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/CAFdMc-2WAF_RZR_fTAXdhP842WaBJ-m27nbTaCXDK3me1Y6=
1tw%40mail.gmail.com.

--000000000000439aa705779c3e4b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">El vie=
.., 28 de sep. de 2018 a la(s) 19:22, Arthur O&#39;Dwyer (<a href=3D"mailto:=
arthur.j.odwyer@gmail.com">arthur.j.odwyer@gmail.com</a>) escribi=C3=B3:<br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Friday, September=
 28, 2018 at 7:14:20 AM UTC-7, <a href=3D"mailto:floria...@gmail.com" targe=
t=3D"_blank">floria...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr">I want to highlight that [[nodiscard]] on function=
s is not about forcing the compiler to keep the value, but instead to emit =
a warning if the user doesn&#39;t use the value.<br>So meaning would be dif=
ferent.<br>In that respect, another attribute name might be better.<br></di=
v></blockquote><div><br></div><div>Right. The standard attribute [[nodiscar=
d]] goes in a <i>library</i> and instructs the compiler to kick<i>=C2=A0the=
 user</i> if the user has=C2=A0<i>forgotten to use</i>=C2=A0the result of s=
ome <i>library call</i>.</div><div><br></div><div>Daniel, what you are aski=
ng for is an attribute that goes in <i>user code</i> and instructs the comp=
iler to kick <i>itself?</i>=C2=A0if the user has <i>forgotten to use</i>=C2=
=A0the result of some <i>assignment expression</i>.</div></div></blockquote=
><div><br></div><div>Let&#39;s see. First, I don&#39;t see a need to distin=
guish between user code and library code in this context (whereas it makes =
sense for [[nodiscard]] on functions). What I am asking for goes anywhere, =
either user or library code.</div><div>Second, the attribute targets the co=
mpiler: is a tool that the programmer can use to tell the compiler &quot;th=
is statement should not be discarded&quot;. What the compiler does with tha=
t information is implementation defined: it can just ignore it, it can hono=
r it and not discard the statement, or it can warn the user that it will di=
scard it anyways (a warning), so the user can later decide what to do (for =
example, recode the snippet, use volatile, etc.).</div><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><div><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Also, it is alread=
y possible (but cumbersome) to implement already without volatile:<br><div =
style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);bo=
rder-style:solid;border-width:1px"><code><div><span style=3D"color:#008">vo=
id</span><span style=3D"color:#000"> </span><span style=3D"color:#000">f</s=
pan><span style=3D"color:#660">()</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=A0 </=
span><span style=3D"color:#008">int</span><span style=3D"color:#000"> secre=
t_int</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><=
br>=C2=A0 </span><span style=3D"color:#008">float</span><span style=3D"colo=
r:#000"> secret_float</span><span style=3D"color:#660">;</span><span style=
=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#800">/* ... */</spa=
n><span style=3D"color:#000"><br>=C2=A0 secret_int </span><span style=3D"co=
lor:#660">=3D</span><span style=3D"color:#000"> </span><span style=3D"color=
:#066">0</span><span style=3D"color:#660">;</span><span style=3D"color:#000=
"><br>=C2=A0 secret_float </span><span style=3D"color:#660">=3D</span><span=
 style=3D"color:#000"> </span><span style=3D"color:#066">0</span><span styl=
e=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#008">asm</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#008">volatile</span><=
span style=3D"color:#000"> </span><span style=3D"color:#660">(</span><span =
style=3D"color:#080">&quot;&quot;</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#660">::</span><span style=3D"color:#080">&quot;irm&qu=
ot;</span><span style=3D"color:#660">(</span><span style=3D"color:#000">sec=
ret_int</span><span style=3D"color:#660">),</span><span style=3D"color:#000=
"> </span><span style=3D"color:#080">&quot;xm&quot;</span><span style=3D"co=
lor:#660">(</span><span style=3D"color:#000">secret_float</span><span style=
=3D"color:#660">));</span><span style=3D"color:#000"><br></span><span style=
=3D"color:#660">}</span></div></code></div></div></blockquote><div><br></di=
v><div>This certainly seems to make sure that the write reaches L1 cache, b=
ut do you know whether the write is guaranteed to have reached and overwrit=
ten any copies of the data that might remain in L2 and main memory?</div><d=
iv>What about the swap partition? Are you worried that a copy of the secret=
 may have been swapped out to disk? =C2=A0(Reductio ad absurdum: What if it=
 was swapped out to removable media that has since been ejected?)</div><div=
><br></div><div>Before you can start talking meaningfully about preventing =
the compiler from eliminating your dead &quot;=3D0&quot; statements, you ne=
ed to have a mental model that explains what good those &quot;=3D0&quot; st=
atements are supposed to do in the first place.</div><div><br></div><div>HT=
H,</div><div>Arthur</div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1442c15c-6a58-4f3e-83cf-9f5554fb9981%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1442c15c-6a58-=
4f3e-83cf-9f5554fb9981%40isocpp.org</a>.<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"gmail_signature" data-smartmail=3D"gmail_signature">Who=E2=80=99s=
 got the sweetest disposition?<br>One guess, that=E2=80=99s who?<br>Who=E2=
=80=99d never, ever start an argument?<br>Who never shows a bit of temperam=
ent?<br>Who&#39;s never wrong but always right?<br>Who&#39;d never dream of=
 starting a fight?<br>Who get stuck with all the bad luck? </div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-2WAF_RZR_fTAXdhP842WaBJ-m27nbT=
aCXDK3me1Y61tw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-2WAF_RZR_f=
TAXdhP842WaBJ-m27nbTaCXDK3me1Y61tw%40mail.gmail.com</a>.<br />

--000000000000439aa705779c3e4b--

.

--00000000000037717905779c4dfa
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

El lun., 1 de oct. de 2018 a la(s) 06:28, <olaf@join.cc> escribi=C3=B3:

>
>
> Op vrijdag 28 september 2018 13:14:06 UTC+2 schreef Daniel Gutson:
>>
>> Again, on the DSE related optimizations.
>>
>> I'm at the Ekoparty where I will show a presentation about security
>> vulnerabilities caused by compiler optimizations. The subject is more an=
d
>> more serious (e.g. [1]).
>>
>> I want to propose to allow [[nodiscard]] in individual expressions, such
>> as calls to memset(), std::fill_n, and assignments (DSE happens with bot=
h
>> memory and registers).
>>
>> What's DSE?
> And what's [1]?
>

Sorry for the lack of context, I strongly suggest people to take a look at
these papers without further participating in this discussion:
https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-yang.=
pdf
https://nebelwelt.net/publications/files/15LangSec.pdf

Comments:
https://wiki.sei.cmu.edu/confluence/display/c/MSC06-C.+Beware+of+compiler+o=
ptimizations
There are plenty of issues filed to the gcc and clang issue trackers about
this that were systematically closed as invalid. But the problem remains
and is deadly serious. I did a demonstration at the Ekoparty of an exploit
using this.


>
>
> --
> 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/8fa2ebcf-19c=
5-4b32-a8c6-9fa503010467%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8fa2ebcf-19=
c5-4b32-a8c6-9fa503010467%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>


--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=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/CAFdMc-3ow7TvHO%2B2Y9Ww12PwGRj6H5hq3aennxt2Jq7-X=
GLzmw%40mail.gmail.com.

--00000000000037717905779c4dfa
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><br><br=
><div class=3D"gmail_quote"><div dir=3D"ltr">El lun., 1 de oct. de 2018 a l=
a(s) 06:28, &lt;olaf@join.cc&gt; escribi=C3=B3:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><br><br>Op vrijdag 28 sep=
tember 2018 13:14:06 UTC+2 schreef Daniel Gutson:<blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex"><div dir=3D"ltr">Again, on the DSE related optimiza=
tions.<div><br></div><div>I&#39;m at the Ekoparty where I will show a prese=
ntation about security vulnerabilities caused by compiler optimizations. Th=
e subject is more and more serious (e.g. [1]).</div><div><br></div><div>I w=
ant to propose to allow [[nodiscard]] in individual expressions, such as ca=
lls to memset(), std::fill_n, and assignments (DSE happens with both memory=
 and registers).</div><div><br></div></div></blockquote><div>What&#39;s DSE=
?</div><div>And what&#39;s [1]?</div></div></blockquote><div><br></div><div=
>Sorry for the lack of context, I strongly suggest people to take a look at=
 these papers without further participating in this discussion:=C2=A0</div>=
<div><a href=3D"https://www.usenix.org/system/files/conference/usenixsecuri=
ty17/sec17-yang.pdf">https://www.usenix.org/system/files/conference/usenixs=
ecurity17/sec17-yang.pdf</a><br></div><div><a href=3D"https://nebelwelt.net=
/publications/files/15LangSec.pdf">https://nebelwelt.net/publications/files=
/15LangSec.pdf</a><br></div><div><br></div><div>Comments:=C2=A0<a href=3D"h=
ttps://wiki.sei.cmu.edu/confluence/display/c/MSC06-C.+Beware+of+compiler+op=
timizations">https://wiki.sei.cmu.edu/confluence/display/c/MSC06-C.+Beware+=
of+compiler+optimizations</a></div><div>There are plenty of issues filed to=
 the gcc and clang issue trackers about this that were systematically close=
d as invalid. But the problem remains and is deadly serious. I did a demons=
tration at the Ekoparty of an exploit using this.</div><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>=C2=A0=
</div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8fa2ebcf-19c5-4b32-a8c6-9fa503010467%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8fa2ebcf-19c5-=
4b32-a8c6-9fa503010467%40isocpp.org</a>.<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"gmail_signature">Who=E2=80=99s got the sweetest disposition?<br>O=
ne guess, that=E2=80=99s who?<br>Who=E2=80=99d never, ever start an argumen=
t?<br>Who never shows a bit of temperament?<br>Who&#39;s never wrong but al=
ways right?<br>Who&#39;d never dream of starting a fight?<br>Who get stuck =
with all the bad luck? </div></div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-3ow7TvHO%2B2Y9Ww12PwGRj6H5hq3a=
ennxt2Jq7-XGLzmw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-3ow7TvHO=
%2B2Y9Ww12PwGRj6H5hq3aennxt2Jq7-XGLzmw%40mail.gmail.com</a>.<br />

--00000000000037717905779c4dfa--

.

--000000000000c4b9fc05779c57cc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

El mar., 2 de oct. de 2018 a la(s) 00:18, Ray Hamel (rayghamel@gmail.com)
escribi=C3=B3:

> Arthur,
>
> Sure, it wouldn't provide *perfect* security, but ensuring the secret is
> overwritten, whether that's in L1 cache or elsewhere, ensures that at
> minimum it's can't be recovered without some special exploit, side-channe=
l
> or physical access to the hardware. And if Eve has some exploit that lets
> her read from arbitrary DRAM or storage on Alice's computer, then Alice i=
s
> pretty much screwed anyway; there's very little you can do to harden
> software against an attacker who has so thoroughly compromised the host
> system.
>

I thought of memory (stack, heap, red zone), and registers. I didn't think
of cache. This would open yet another exploit surface. Though very hard to
exploit.
I still think that the attribute solution is a very good start and
addresses a lot of existing problems.


>
> -Ray
>
> --
> 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/8aa1ec5f-ebd=
e-43de-b3c4-a30a434c552d%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8aa1ec5f-eb=
de-43de-b3c4-a30a434c552d%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>


--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=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/CAFdMc-1%2BKdnbjB8F3Hsa9KS5R1KdvMqPnARKPeM963Pgg=
DwNCQ%40mail.gmail.com.

--000000000000c4b9fc05779c57cc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">El mar=
.., 2 de oct. de 2018 a la(s) 00:18, Ray Hamel (<a href=3D"mailto:rayghamel@=
gmail.com">rayghamel@gmail.com</a>) escribi=C3=B3:<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div>Arthur,</div><div><br></div><div>Sure=
, it wouldn&#39;t provide <i>perfect</i> security, but ensuring the secret =
is overwritten, whether that&#39;s in L1 cache or elsewhere, ensures that a=
t minimum it&#39;s can&#39;t be recovered without some special exploit, sid=
e-channel or physical access to the hardware. And if Eve has some exploit t=
hat lets her read from arbitrary DRAM or storage on Alice&#39;s computer, t=
hen Alice is pretty much screwed anyway; there&#39;s very little you can do=
 to harden software against an attacker who has so thoroughly compromised t=
he host system.<br></div></div></blockquote><div><br></div><div>I thought o=
f memory (stack, heap, red zone), and registers. I didn&#39;t think of cach=
e. This would open yet another exploit surface. Though very hard to exploit=
..</div><div>I still think that the attribute solution is a very good start =
and addresses a lot of existing problems.</div><div>=C2=A0</div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div></div><div><br></div><div>-Ray<br=
></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8aa1ec5f-ebde-43de-b3c4-a30a434c552d%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8aa1ec5f-ebde-=
43de-b3c4-a30a434c552d%40isocpp.org</a>.<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"gmail_signature" data-smartmail=3D"gmail_signature">Who=E2=80=99s=
 got the sweetest disposition?<br>One guess, that=E2=80=99s who?<br>Who=E2=
=80=99d never, ever start an argument?<br>Who never shows a bit of temperam=
ent?<br>Who&#39;s never wrong but always right?<br>Who&#39;d never dream of=
 starting a fight?<br>Who get stuck with all the bad luck? </div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-1%2BKdnbjB8F3Hsa9KS5R1KdvMqPnA=
RKPeM963PggDwNCQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-1%2BKdnb=
jB8F3Hsa9KS5R1KdvMqPnARKPeM963PggDwNCQ%40mail.gmail.com</a>.<br />

--000000000000c4b9fc05779c57cc--

.

On Friday, 28 September 2018 15:22:25 PDT Arthur O'Dwyer wrote:
> This certainly seems to make sure that the write reaches L1 cache, but do
> you know whether the write is guaranteed to have reached and overwritten
> any copies of the data that might remain in L2 and main memory?
> What about the swap partition? Are you worried that a copy of the secret
> may have been swapped out to disk?  (Reductio ad absurdum: What if it was
> swapped out to removable media that has since been ejected?)
>
> Before you can start talking meaningfully about preventing the compiler
> from eliminating your dead "=0" statements, you need to have a mental model
> that explains what good those "=0" statements are supposed to do in the
> first place.

I agree, this needs some further thinking to define the problem. Just tackling
the problem of eliminated stores is insufficient, since the same data could be
found elsewhere, like in registers. That's why the -mzero-caller-saved-regs
patch exists for GCC
  https://github.com/clearlinux-pkgs/gcc/blob/master/zero-regs-gcc8.patch

A function attribute is the best way to solve the problem of local variables:
just tell the compiler to clear ALL variables, both in stack and in registers.
Or maybe provide hints to the compiler of which variables are hazardous and
must be cleared, so it won't spend CPU cycles clearing a large but innocuous
buffer.

Similarly for memory-allocated blocks, as the compilers do understand free()
and that any stores prior to that are dead. But I also don't think this is
that big a security issue, as secure code must have used mlock() to prevent
swapping out, so it will have to use munlock() after it cleared the memory,
meaning the compiler cannot conclude it's a dead store.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
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/2144977.3D1Rvy5359%40tjmaciei-mobl1.

.

------=_Part_21_1581914887.1538903872926
Content-Type: multipart/alternative;
 boundary="----=_Part_22_304993778.1538903872927"

------=_Part_22_304993778.1538903872927
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



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, <floria...@gmail.com=20
> <javascript:>> escribi=C3=B3:
>
>> I completely understood what you meant, and yes what you are proposing i=
s=20
>> compatible with the current language.
>> I just wanted to highlight that it might be misleading to have the same=
=20
>> attribute with different meaning when it is used on a function declarati=
on,=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 t=
he=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 en=
d=20
>> and so the last assignment should be kept and propagated to every storag=
e=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 becomes=
=20
>> valid to access it afterwards.
>> It would tell the compiler it should behave as-if the object *could* be=
=20
>> accessed afterwards.
>>
>
> Actually I would like to tell the compiler that the object should NOT be=
=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 somehow,=
=20
and so the correctness of the whole program depends on the last value not=
=20
being discarded".

Your view is also correct, but a bit more magic: when this "destroy all the=
=20
places where the object is" is performed? (the right answer is: just after=
=20
its destructor is called)
While in what I propose, it is done more explicitly when the last value is=
=20
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. It should not be an already existing attribute=
=20
name unless the feature is 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 than=
=20
repurposing an old one?).

--=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/dba0bf6d-92da-440e-8e61-af336cacd537%40isocpp.or=
g.

------=_Part_22_304993778.1538903872927
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>Le dimanche 7 octobre 2018 06:44:28 UTC+2, Daniel =
Gutson a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div=
 dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">El vie., 2=
8 de sep. de 2018 a la(s) 11:36, &lt;<a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"x3yJYXelAwAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">floria...@gmail.com</a>&gt; escribi=C3=B3:<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I completely under=
stood what you meant, and yes what you are proposing is compatible with the=
 current language.<br>I just wanted to highlight that it might be misleadin=
g to have the same attribute with different meaning when it is used on a fu=
nction declaration, or on an expression (a declaration is also a statement)=
..<br><br>Also, after some thinking, in this case, the goal is not to force =
the last assignment, but to force the last value of the variable, wherever =
the variable is, even if the variable is both in register and stack.<br>So =
in that case, you might be better with a [[undead]] attribute whose meaning=
 would be that the object might be accessed after its lifetime end and so t=
he last assignment should be kept and propagated to every storage of the ob=
ject:<br><br><div style=3D"background-color:rgb(250,250,250);border-color:r=
gb(187,187,187);border-style:solid;border-width:1px"><code><div><span style=
=3D"color:#008">void</span><span style=3D"color:#000"> f</span><span style=
=3D"color:#660">()</span><span style=3D"color:#000"> </span><span style=3D"=
color:#660">{</span><span style=3D"color:#000"><br>=C2=A0 </span><span styl=
e=3D"color:#660">[[</span><span style=3D"color:#000">undead</span><span sty=
le=3D"color:#660">]]</span><span style=3D"color:#000"> </span><span style=
=3D"color:#008">int</span><span style=3D"color:#000"> secret</span><span st=
yle=3D"color:#660">;</span><span style=3D"color:#000"><br>=C2=A0 </span><sp=
an style=3D"color:#800">/* ... */</span><span style=3D"color:#000"><br>=C2=
=A0 secret </span><span style=3D"color:#660">=3D</span><span style=3D"color=
:#000"> </span><span style=3D"color:#066">0</span><span style=3D"color:#660=
">;</span><span style=3D"color:#000"><br></span><span style=3D"color:#660">=
}</span><span style=3D"color:#000"><br></span></div></code></div>That would=
n&#39;t mean the lifetime of the object is extended and it becomes valid to=
 access it afterwards.<br>It would tell the compiler it should behave as-if=
 the object <i>could</i> be accessed afterwards.<br></div></blockquote><div=
><br></div><div>Actually I would like to tell the compiler that the object =
should NOT be accessible afterwards.</div></div></div></blockquote><div><br=
></div><div>What I said is not &quot;the compiler makes the object accessib=
le&quot;, but &quot;whatever the compiler will do, the object will remain a=
ccessible somehow, and so the correctness of the whole program depends on t=
he last value not being discarded&quot;.</div><div><br></div><div>Your view=
 is also correct, but a bit more magic: when this &quot;destroy all the pla=
ces where the object is&quot; is performed? (the right answer is: just afte=
r its destructor is called)</div><div>While in what I propose, it is done m=
ore explicitly when the last value is assigned.</div><div><br></div><div>Bu=
t both are good. It&#39;s just a matter of taste at this point.</div><div><=
br></div><div>However, your first proposal doesn&#39;t work that well: ok y=
ou tell the compiler to keep the assignment. But which location is used for=
 this assignment? All of them? The last one? The main one? A new one?</div>=
<div>And if you start standardizing which location should be assigned, then=
 you&#39;re not talking about expressions anymore, but about objects. So at=
tributes on expressions is not the right tool for you.<br></div><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div cl=
ass=3D"gmail_quote"><div>Additionally I would like to reuse the existing at=
tribute name, though this is of least importance now.</div><div>=C2=A0</div=
></div></div></blockquote><div><br></div><div>Here, I completely disagree. =
It should not be an already existing attribute name unless the feature is c=
lose enough to the original attribute.</div><div>And the new meaning you pr=
oposed is (at least for me)=C2=A0 too far from the original, and is mislead=
ing.</div><div><br></div><div>An attribute is not a keyword, it is easy to =
create new ones (easier than repurposing an old one?).<br></div><div><br></=
div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/dba0bf6d-92da-440e-8e61-af336cacd537%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/dba0bf6d-92da-440e-8e61-af336cacd537=
%40isocpp.org</a>.<br />

------=_Part_22_304993778.1538903872927--

------=_Part_21_1581914887.1538903872926--

.

--0000000000005d4eea0577a493f6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

El dom., 7 oct. 2018 4:30, Thiago Macieira <thiago@macieira.org> escribi=C3=
=B3:

> On Friday, 28 September 2018 15:22:25 PDT Arthur O'Dwyer wrote:
> > This certainly seems to make sure that the write reaches L1 cache, but =
do
> > you know whether the write is guaranteed to have reached and overwritte=
n
> > any copies of the data that might remain in L2 and main memory?
> > What about the swap partition? Are you worried that a copy of the secre=
t
> > may have been swapped out to disk?  (Reductio ad absurdum: What if it w=
as
> > swapped out to removable media that has since been ejected?)
> >
> > Before you can start talking meaningfully about preventing the compiler
> > from eliminating your dead "=3D0" statements, you need to have a mental
> model
> > that explains what good those "=3D0" statements are supposed to do in t=
he
> > first place.
>
> I agree, this needs some further thinking to define the problem. Just
> tackling
> the problem of eliminated stores is insufficient, since the same data
> could be
> found elsewhere, like in registers. That's why the
> -mzero-caller-saved-regs
> patch exists for GCC
>   https://github.com/clearlinux-pkgs/gcc/blob/master/zero-regs-gcc8.patch
>
> A function attribute is the best way to solve the problem of local
> variables:
> just tell the compiler to clear ALL variables, both in stack and in
> registers.


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D69976

:)


> Or maybe provide hints to the compiler of which variables are hazardous
> and
> must be cleared, so it won't spend CPU cycles clearing a large but
> innocuous
> buffer.
>

I think this is both incomplete and extracomplicated. You all are thinking
in stores only (yes, I started it ny mentioning DSE in the first place, I
admit it), but I want to make it statement-wise and let the implementation
decide what to do.
Function level attributes are useful for a separate matter (Return Oriented
Programming prevention, filed Intel IP here :( which I highly regret now)
but for DSEs is an overkill. For example a function may declare a local
buffer and an index to iterate it; the buffer may be sensible but the index
whould normally be placed in a register which is safe. Marking the function
as sensible may cause reloading and a large performance overhead. Not
useful.
I stick to the idea of marking statements being assignments, function
calls, whatever, letting the compiler decide what to do.


> Similarly for memory-allocated blocks, as the compilers do understand
> free()
> and that any stores prior to that are dead. But I also don't think this i=
s
> that big a security issue, as secure code must have used mlock() to
> prevent
> swapping out, so it will have to use munlock() after it cleared the
> memory,
> meaning the compiler cannot conclude it's a dead store.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
>
>
> --
> 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/2144977.3D1R=
vy5359%40tjmaciei-mobl1
> .
>

--=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/CAFdMc-0DixoBS5y_0GwE2AydDa2AMx8ie-mL1PD_WAivunC=
ENw%40mail.gmail.com.

--0000000000005d4eea0577a493f6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">=
El dom., 7 oct. 2018 4:30, Thiago Macieira &lt;<a href=3D"mailto:thiago@mac=
ieira.org">thiago@macieira.org</a>&gt; escribi=C3=B3:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">On Friday, 28 September 2018 15:22:25 PDT Arthur O&#39;D=
wyer wrote:<br>
&gt; This certainly seems to make sure that the write reaches L1 cache, but=
 do<br>
&gt; you know whether the write is guaranteed to have reached and overwritt=
en<br>
&gt; any copies of the data that might remain in L2 and main memory?<br>
&gt; What about the swap partition? Are you worried that a copy of the secr=
et<br>
&gt; may have been swapped out to disk?=C2=A0 (Reductio ad absurdum: What i=
f it was<br>
&gt; swapped out to removable media that has since been ejected?)<br>
&gt;<br>
&gt; Before you can start talking meaningfully about preventing the compile=
r<br>
&gt; from eliminating your dead &quot;=3D0&quot; statements, you need to ha=
ve a mental model<br>
&gt; that explains what good those &quot;=3D0&quot; statements are supposed=
 to do in the<br>
&gt; first place.<br>
<br>
I agree, this needs some further thinking to define the problem. Just tackl=
ing <br>
the problem of eliminated stores is insufficient, since the same data could=
 be <br>
found elsewhere, like in registers. That&#39;s why the -mzero-caller-saved-=
regs <br>
patch exists for GCC<br>
=C2=A0 <a href=3D"https://github.com/clearlinux-pkgs/gcc/blob/master/zero-r=
egs-gcc8.patch" rel=3D"noreferrer noreferrer" target=3D"_blank">https://git=
hub.com/clearlinux-pkgs/gcc/blob/master/zero-regs-gcc8.patch</a><br>
<br>
A function attribute is the best way to solve the problem of local variable=
s: <br>
just tell the compiler to clear ALL variables, both in stack and in registe=
rs.</blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto"><=
a href=3D"https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D69976">https://gcc=
..gnu.org/bugzilla/show_bug.cgi?id=3D69976</a><br></div><div dir=3D"auto"><b=
r></div><div dir=3D"auto">:)</div><div dir=3D"auto"><br></div><div dir=3D"a=
uto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
Or maybe provide hints to the compiler of which variables are hazardous and=
 <br>
must be cleared, so it won&#39;t spend CPU cycles clearing a large but inno=
cuous <br>
buffer.<br></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D=
"auto">I think this is both incomplete and extracomplicated. You all are th=
inking in stores only (yes, I started it ny mentioning DSE in the first pla=
ce, I admit it), but I want to make it statement-wise and let the implement=
ation decide what to do.</div><div dir=3D"auto">Function level attributes a=
re useful for a separate matter (Return Oriented Programming prevention, fi=
led Intel IP here :( which I highly regret now) but for DSEs is an overkill=
.. For example a function may declare a local buffer and an index to iterate=
 it; the buffer may be sensible but the index whould normally be placed in =
a register which is safe. Marking the function as sensible may cause reload=
ing and a large performance overhead. Not useful.</div><div dir=3D"auto">I =
stick to the idea of marking statements being assignments, function calls, =
whatever, letting the compiler decide what to do.</div><div dir=3D"auto"><b=
r></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">
<br>
Similarly for memory-allocated blocks, as the compilers do understand free(=
) <br>
and that any stores prior to that are dead. But I also don&#39;t think this=
 is <br>
that big a security issue, as secure code must have used mlock() to prevent=
 <br>
swapping out, so it will have to use munlock() after it cleared the memory,=
 <br>
meaning the compiler cannot conclude it&#39;s a dead store.<br>
<br>
-- <br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer noreferrer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=
=3D"http://kde.org" rel=3D"noreferrer noreferrer" target=3D"_blank">kde.org=
</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
<br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank" rel=3D"noreferrer">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">std-proposals@isocpp.org</a>.<br=
>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2144977.3D1Rvy5359%40tjmaciei-mobl1" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://groups.google.com/a=
/isocpp.org/d/msgid/std-proposals/2144977.3D1Rvy5359%40tjmaciei-mobl1</a>.<=
br>
</blockquote></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-0DixoBS5y_0GwE2AydDa2AMx8ie-mL=
1PD_WAivunCENw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-0DixoBS5y_=
0GwE2AydDa2AMx8ie-mL1PD_WAivunCENw%40mail.gmail.com</a>.<br />

--0000000000005d4eea0577a493f6--

.

--000000000000d3f6f20577a495e8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

El dom., 7 oct. 2018 6:17, <florian.csdt@gmail.com> 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, <floria...@gmail.com>
>> escribi=C3=B3:
>>
>>> I completely understood what you meant, and yes what you are proposing
>>> is compatible with the current language.
>>> I just wanted to highlight that it might be misleading to have the same
>>> attribute with different meaning when it is used on a function declarat=
ion,
>>> or on an expression (a declaration is also a statement).
>>>
>>> Also, after some thinking, in this case, the goal is not to force the
>>> last assignment, but to force the last 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 accessed after its lifetime e=
nd
>>> and so the last assignment should be kept and propagated to every stora=
ge
>>> of the object:
>>>
>>> void f() {
>>>   [[undead]] int secret;
>>>   /* ... */
>>>   secret =3D 0;
>>> }
>>> That wouldn't mean the lifetime of the object is extended and it become=
s
>>> valid to access it afterwards.
>>> It would tell the compiler it should behave as-if the object *could* be
>>> accessed afterwards.
>>>
>>
>> Actually I would like to tell the compiler that the object should NOT be
>> accessible afterwards.
>>
>
> What I said is not "the compiler makes the object accessible", but
> "whatever the compiler will do, the object will remain accessible somehow=
,
> and so the correctness 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 performed? (the right answer is: just
> after its destructor is called)
> While in what I propose, it is done more explicitly when the last value i=
s
> 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
> compiler to keep the assignment. But which location is used for this
> assignment? All of them? The last one? The main one? A new one?
> And if you start standardizing which location should be assigned, then
> you're not talking about expressions anymore, but about objects. So
> attributes on expressions is not the right tool for you.
>
>
>> Additionally I would like to reuse the existing attribute name, though
>> this is of least importance now.
>>
>>
>
> Here, I completely disagree.
>

Ok let's not discuss this.

It should not be an already existing attribute name unless the feature is
> close enough to the original attribute.
> And the new meaning you proposed is (at least for me)  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
> "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/dba0bf6d-92d=
a-440e-8e61-af336cacd537%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/dba0bf6d-92=
da-440e-8e61-af336cacd537%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>

--=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/CAFdMc-1cyt1gnCvvtrE%2BJOW0s%3Dwab%3D0eU1APYzdrw=
ejxjqc1zg%40mail.gmail.com.

--000000000000d3f6f20577a495e8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">=
El dom., 7 oct. 2018 6:17,  &lt;<a href=3D"mailto:florian.csdt@gmail.com">f=
lorian.csdt@gmail.com</a>&gt; escribi=C3=B3:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><br><br>Le dimanche 7 octobre 2018 06:44:28 UTC+=
2, Daniel Gutson a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">El vi=
e., 28 de sep. de 2018 a la(s) 11:36, &lt;<a rel=3D"nofollow noreferrer">fl=
oria...@gmail.com</a>&gt; escribi=C3=B3:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr">I completely understood what you meant, and yes what=
 you are proposing is compatible with the current language.<br>I just wante=
d to highlight that it might be misleading to have the same attribute with =
different meaning when it is used on a function declaration, or on an expre=
ssion (a declaration is also a statement).<br><br>Also, after some thinking=
, in this case, the goal is not to force the last assignment, but to force =
the last value of the variable, wherever the variable is, even if the varia=
ble is both in register and stack.<br>So in that case, you might be better =
with a [[undead]] attribute whose meaning would be that the object might be=
 accessed after its lifetime end and so the last assignment should be kept =
and propagated to every storage of the object:<br><br><div style=3D"backgro=
und-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid=
;border-width:1px"><code><div><span style=3D"color:#008">void</span><span s=
tyle=3D"color:#000"> f</span><span style=3D"color:#660">()</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#660">{</span><span style=3D"=
color:#000"><br>=C2=A0 </span><span style=3D"color:#660">[[</span><span sty=
le=3D"color:#000">undead</span><span style=3D"color:#660">]]</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#008">int</span><span style=
=3D"color:#000"> secret</span><span style=3D"color:#660">;</span><span styl=
e=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#800">/* ... */</sp=
an><span style=3D"color:#000"><br>=C2=A0 secret </span><span style=3D"color=
:#660">=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#0=
66">0</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><=
br></span><span style=3D"color:#660">}</span><span style=3D"color:#000"><br=
></span></div></code></div>That wouldn&#39;t mean the lifetime of the objec=
t is extended and it becomes valid to access it afterwards.<br>It would tel=
l the compiler it should behave as-if the object <i>could</i> be accessed a=
fterwards.<br></div></blockquote><div><br></div><div>Actually I would like =
to tell the compiler that the object should NOT be accessible afterwards.</=
div></div></div></blockquote><div><br></div><div>What I said is not &quot;t=
he compiler makes the object accessible&quot;, but &quot;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&quot=
;.</div><div><br></div><div>Your view is also correct, but a bit more magic=
: when this &quot;destroy all the places where the object is&quot; is perfo=
rmed? (the right answer is: just after its destructor is called)</div><div>=
While in what I propose, it is done more explicitly when the last value is =
assigned.</div><div><br></div><div>But both are good. It&#39;s just a matte=
r of taste at this point.</div><div><br></div><div>However, your first prop=
osal doesn&#39;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?</div><div>And if you start standardizing wh=
ich location should be assigned, then you&#39;re not talking about expressi=
ons anymore, but about objects. So attributes on expressions is not the rig=
ht tool for you.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>Additionally I wou=
ld like to reuse the existing attribute name, though this is of least impor=
tance now.</div><div>=C2=A0</div></div></div></blockquote><div><br></div><d=
iv>Here, I completely disagree. </div></div></blockquote></div></div><div d=
ir=3D"auto"><br></div><div dir=3D"auto">Ok let&#39;s not discuss this.</div=
><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>It should not be an alr=
eady existing attribute name unless the feature is close enough to the orig=
inal attribute.</div><div>And the new meaning you proposed is (at least for=
 me)=C2=A0 too far from the original, and is misleading.</div><div><br></di=
v><div>An attribute is not a keyword, it is easy to create new ones (easier=
 than repurposing an old one?).<br></div><div><br></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank" rel=3D"noreferrer">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">std-proposals@isocpp.org</a>.<br=
>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/dba0bf6d-92da-440e-8e61-af336cacd537%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/dba0bf6d-92da-440e-8e61-af336cacd537%40isocpp.org</a>.<br>
</blockquote></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-1cyt1gnCvvtrE%2BJOW0s%3Dwab%3D=
0eU1APYzdrwejxjqc1zg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-1cyt=
1gnCvvtrE%2BJOW0s%3Dwab%3D0eU1APYzdrwejxjqc1zg%40mail.gmail.com</a>.<br />

--000000000000d3f6f20577a495e8--

.

------=_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, <floria...@gmail.com <javascript:>> 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, <floria...@gmail.com>=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 <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> 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
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/dba0bf6d-9=
2da-440e-8e61-af336cacd537%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>

--=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

<div dir=3D"ltr">What about using [[nodiscard]] as a null-statement?<div><b=
r></div><div>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.</div><div><br>=
</div><div>e.g.=C2=A0</div><div><br></div><div class=3D"prettyprint" style=
=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187);=
 border-style: solid; border-width: 1px; overflow-wrap: break-word;"><code =
class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #=
000;" class=3D"styled-by-prettify">memset</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">password</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-pret=
tify">0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> PASSWORD_SI=
ZE</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">[[</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">nodiscard</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">]];</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;=
" class=3D"styled-by-prettify">// intentionally </span><span style=3D"color=
: #800;" class=3D"styled-by-prettify">store before a free</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>free</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">password</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">);</span></div></code></div><div><br><b=
r><br>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;"><div dir=3D"auto"><div><br><br>=
<div class=3D"gmail_quote"><div dir=3D"ltr">El dom., 7 oct. 2018 6:17,  &lt=
;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"cEo_WGH=
GAwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;re=
turn true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">flor=
ia...@gmail.com</a>&gt; escribi=C3=B3:<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><br><br>Le dimanche 7 octobre 2018 06:44:28 UTC+2, Dan=
iel Gutson a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">El vie., 28=
 de sep. de 2018 a la(s) 11:36, &lt;<a rel=3D"nofollow noreferrer">floria..=
..@gmail.com</a>&gt; escribi=C3=B3:<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div dir=3D"ltr">I completely understood what you meant, and yes what you a=
re proposing is compatible with the current language.<br>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).<br><br>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.<br>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:<br><br><div style=3D"background-co=
lor:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;borde=
r-width:1px"><code><div><span style=3D"color:#008">void</span><span style=
=3D"color:#000"> f</span><span style=3D"color:#660">()</span><span style=3D=
"color:#000"> </span><span style=3D"color:#660">{</span><span style=3D"colo=
r:#000"><br>=C2=A0 </span><span style=3D"color:#660">[[</span><span style=
=3D"color:#000">undead</span><span style=3D"color:#660">]]</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#008">int</span><span style=
=3D"color:#000"> secret</span><span style=3D"color:#660">;</span><span styl=
e=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#800">/* ... */</sp=
an><span style=3D"color:#000"><br>=C2=A0 secret </span><span style=3D"color=
:#660">=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#0=
66">0</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><=
br></span><span style=3D"color:#660">}</span><span style=3D"color:#000"><br=
></span></div></code></div>That wouldn&#39;t mean the lifetime of the objec=
t is extended and it becomes valid to access it afterwards.<br>It would tel=
l the compiler it should behave as-if the object <i>could</i> be accessed a=
fterwards.<br></div></blockquote><div><br></div><div>Actually I would like =
to tell the compiler that the object should NOT be accessible afterwards.</=
div></div></div></blockquote><div><br></div><div>What I said is not &quot;t=
he compiler makes the object accessible&quot;, but &quot;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&quot=
;.</div><div><br></div><div>Your view is also correct, but a bit more magic=
: when this &quot;destroy all the places where the object is&quot; is perfo=
rmed? (the right answer is: just after its destructor is called)</div><div>=
While in what I propose, it is done more explicitly when the last value is =
assigned.</div><div><br></div><div>But both are good. It&#39;s just a matte=
r of taste at this point.</div><div><br></div><div>However, your first prop=
osal doesn&#39;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?</div><div>And if you start standardizing wh=
ich location should be assigned, then you&#39;re not talking about expressi=
ons anymore, but about objects. So attributes on expressions is not the rig=
ht tool for you.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>Additionally I wou=
ld like to reuse the existing attribute name, though this is of least impor=
tance now.</div><div>=C2=A0</div></div></div></blockquote><div><br></div><d=
iv>Here, I completely disagree. </div></div></blockquote></div></div><div d=
ir=3D"auto"><br></div><div dir=3D"auto">Ok let&#39;s not discuss this.</div=
><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>It should not be an alr=
eady existing attribute name unless the feature is close enough to the orig=
inal attribute.</div><div>And the new meaning you proposed is (at least for=
 me)=C2=A0 too far from the original, and is misleading.</div><div><br></di=
v><div>An attribute is not a keyword, it is easy to create new ones (easier=
 than repurposing an old one?).<br></div><div><br></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" rel=3D"nofollow" target=3D"_blank" gdf-obfu=
scated-mailto=3D"cEo_WGHGAwAJ" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" rel=3D"nofollo=
w" target=3D"_blank" gdf-obfuscated-mailto=3D"cEo_WGHGAwAJ" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/dba0bf6d-92da-440e-8e61-af336cacd537%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank" onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/dba0bf6d-92da-440e-8e61-af336cacd537%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" on=
click=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/dba0bf6d-92da-440e-8e61-af336cacd537%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/dba0bf6d-92da-440e-<wbr>8e61-=
af336cacd537%40isocpp.org</a><wbr>.<br>
</blockquote></div></div></div>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c35b213e-cbfd-41e2-a8dd-e5cf93343b8c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c35b213e-cbfd-41e2-a8dd-e5cf93343b8c=
%40isocpp.org</a>.<br />

------=_Part_1746_838144756.1539025379161--

------=_Part_1745_459678325.1539025379160--

.

------=_Part_1872_1453039916.1539045501848
Content-Type: multipart/alternative;
 boundary="----=_Part_1873_488615191.1539045501848"

------=_Part_1873_488615191.1539045501848
Content-Type: text/plain; charset="UTF-8"

That could be easily broken if someone replaced memset() with another
super_memset() function or similar which did more than one write. How would
the compiler know which write inside of the memset() function it has to
keep? Would it only work for memset and assignments? I don't like the idea
of an attribute that only works for memset() but not other functions.


On Tuesday, 9 October 2018 06:02:59 UTC+11, Andrew Giese wrote:
>
> 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
> previous statement was intentional and should not be discarded.
>
> e.g.
>
> memset(password, 0, PASSWORD_SIZE);
> [[nodiscard]]; // intentionally store before a free
> free(password);
>
>

--
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/bf24037e-142a-4730-84e0-1886f6235e45%40isocpp.org.

------=_Part_1873_488615191.1539045501848
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>That could be easily broken if someone replaced memse=
t() with another super_memset() function or similar which did more than one=
 write. How would the compiler know which write inside of the memset() func=
tion it has to keep? Would it only work for memset and assignments? I don&#=
39;t like the idea of an attribute that only works for memset() but not oth=
er functions.</div><div></div><div><br></div><br>On Tuesday, 9 October 2018=
 06:02:59 UTC+11, Andrew Giese  wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div dir=3D"ltr">What about using [[nodiscard]] as a null-statement=
?<div><br></div><div>Similar to how [[fallthrough]] is a null statement int=
ended to indicate to the compiler and reader that the fallthrough is intent=
ional, a [[nodiscard]] after an assignment or a memset should indicate that=
 the previous statement was intentional and should not be discarded.</div><=
div><br></div><div>e.g.=C2=A0</div><div><br></div><div style=3D"background-=
color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;bor=
der-width:1px"><code><div><span style=3D"color:#000">memset</span><span sty=
le=3D"color:#660">(</span><span style=3D"color:#000">password</span><span s=
tyle=3D"color:#660">,</span><span style=3D"color:#000"> </span><span style=
=3D"color:#066">0</span><span style=3D"color:#660">,</span><span style=3D"c=
olor:#000"> PASSWORD_SIZE</span><span style=3D"color:#660">);</span><span s=
tyle=3D"color:#000"><br></span><span style=3D"color:#660">[[</span><span st=
yle=3D"color:#000">nodiscard</span><span style=3D"color:#660">]];</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#800">// intentionally=
 </span><span style=3D"color:#800">store before a free</span><span style=3D=
"color:#000"><br>free</span><span style=3D"color:#660">(</span><span style=
=3D"color:#000">password</span><span style=3D"color:#660">);</span></div></=
code></div><div><br></div></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/bf24037e-142a-4730-84e0-1886f6235e45%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bf24037e-142a-4730-84e0-1886f6235e45=
%40isocpp.org</a>.<br />

------=_Part_1873_488615191.1539045501848--

------=_Part_1872_1453039916.1539045501848--

.

------=_Part_1774_569460791.1539050103460
Content-Type: multipart/alternative;
 boundary="----=_Part_1775_9839791.1539050103460"

------=_Part_1775_9839791.1539050103460
Content-Type: text/plain; charset="UTF-8"


>
> That could be easily broken if someone replaced memset() with another
> super_memset() function or similar which did more than one write

I'm not sure it's any more easy to break than [[fallthrough]] is by, say,
the introduction of a new case label that shouldn't be fallen into (which
has bitten me before).

How would the compiler know which write inside of the memset() function it
> has to keep?

I think all I'd want it to mean is that the compiler should, under no
circumstances, discard the statement directly above the [[nodiscard]] null
statement. That is, it's a signal of intent that "I want all the side
effects of the above statement to happen". Devs must be careful during
refactoring. Fortunately, whether the store was discarded or not can likely
be tested via unit testing.

I'm no compiler expert, so I don't know the practicalities of something
like this.

Regards,
-Andy

--
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/6a3de61e-037c-48cc-8704-e26ca2ec1213%40isocpp.org.

------=_Part_1775_9839791.1539050103460
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">=
That could be easily broken if someone replaced memset() with another super=
_memset() function or similar which did more than one write</blockquote>I&#=
39;m not sure it&#39;s any more easy to break than [[fallthrough]] is by, s=
ay, the introduction of a new case label that shouldn&#39;t be fallen into =
(which has bitten me before).=C2=A0<div><br><div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204,=
 204, 204); padding-left: 1ex;">How would the compiler know which write ins=
ide of the memset() function it has to keep?</blockquote><div>I think all I=
&#39;d want it to mean is that the compiler should, under no circumstances,=
 discard the statement directly above the [[nodiscard]] null statement. Tha=
t is, it&#39;s a signal of intent that &quot;I want all the side effects of=
 the above statement to happen&quot;. Devs must be careful during refactori=
ng. Fortunately, whether the store was discarded or not can likely be teste=
d via unit testing.</div><div><br></div><div>I&#39;m no compiler expert, so=
 I don&#39;t know the practicalities of something like this.</div><div><br>=
</div><div>Regards,</div><div>-Andy</div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6a3de61e-037c-48cc-8704-e26ca2ec1213%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6a3de61e-037c-48cc-8704-e26ca2ec1213=
%40isocpp.org</a>.<br />

------=_Part_1775_9839791.1539050103460--

------=_Part_1774_569460791.1539050103460--

.

--0000000000004157f50577c271c8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

El lun., 8 oct. 2018 21:38, <mutant.sheepdog@gmail.com> escribi=C3=B3:

> That could be easily broken if someone replaced memset() with another
> super_memset() function or similar which did more than one write. How wou=
ld
> the compiler know which write inside of the memset() function it has to
> keep? Would it only work for memset and assignments? I don't like the ide=
a
> of an attribute that only works for memset() but not other functions.
>

That's why I'm struggling to explain that this attribute is statement-wise
rather than for annotating function *calls* only


>
> On Tuesday, 9 October 2018 06:02:59 UTC+11, Andrew Giese wrote:
>>
>> 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
>> previous statement was intentional and should not be discarded.
>>
>> e.g.
>>
>> memset(password, 0, PASSWORD_SIZE);
>> [[nodiscard]]; // intentionally store before a free
>> free(password);
>>
>> --
> 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/bf24037e-142=
a-4730-84e0-1886f6235e45%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/bf24037e-14=
2a-4730-84e0-1886f6235e45%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>

--=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/CAFdMc-1nTmSAMa4zOg5tAbm%3DrspsbMv0Z_sBfpTTHHvau=
JKiJg%40mail.gmail.com.

--0000000000004157f50577c271c8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">=
El lun., 8 oct. 2018 21:38,  &lt;<a href=3D"mailto:mutant.sheepdog@gmail.co=
m">mutant.sheepdog@gmail.com</a>&gt; escribi=C3=B3:<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div>That could be easily broken if someo=
ne replaced memset() with another super_memset() function or similar which =
did more than one write. How would the compiler know which write inside of =
the memset() function it has to keep? Would it only work for memset and ass=
ignments? I don&#39;t like the idea of an attribute that only works for mem=
set() but not other functions.</div></div></blockquote></div></div><div dir=
=3D"auto"><br></div><div dir=3D"auto">That&#39;s why I&#39;m struggling to =
explain that this attribute is statement-wise rather than for annotating fu=
nction *calls* only</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div=
 class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div=
></div><div><br></div><br>On Tuesday, 9 October 2018 06:02:59 UTC+11, Andre=
w Giese  wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Wha=
t about using [[nodiscard]] as a null-statement?<div><br></div><div>Similar=
 to how [[fallthrough]] is a null statement intended to indicate to the com=
piler and reader that the fallthrough is intentional, a [[nodiscard]] after=
 an assignment or a memset should indicate that the previous statement was =
intentional and should not be discarded.</div><div><br></div><div>e.g.=C2=
=A0</div><div><br></div><div style=3D"background-color:rgb(250,250,250);bor=
der-color:rgb(187,187,187);border-style:solid;border-width:1px"><code><div>=
<span style=3D"color:#000">memset</span><span style=3D"color:#660">(</span>=
<span style=3D"color:#000">password</span><span style=3D"color:#660">,</spa=
n><span style=3D"color:#000"> </span><span style=3D"color:#066">0</span><sp=
an style=3D"color:#660">,</span><span style=3D"color:#000"> PASSWORD_SIZE</=
span><span style=3D"color:#660">);</span><span style=3D"color:#000"><br></s=
pan><span style=3D"color:#660">[[</span><span style=3D"color:#000">nodiscar=
d</span><span style=3D"color:#660">]];</span><span style=3D"color:#000"> </=
span><span style=3D"color:#800">// intentionally </span><span style=3D"colo=
r:#800">store before a free</span><span style=3D"color:#000"><br>free</span=
><span style=3D"color:#660">(</span><span style=3D"color:#000">password</sp=
an><span style=3D"color:#660">);</span></div></code></div><div><br></div></=
div></blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank" rel=3D"noreferrer">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">std-proposals@isocpp.org</a>.<br=
>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/bf24037e-142a-4730-84e0-1886f6235e45%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/bf24037e-142a-4730-84e0-1886f6235e45%40isocpp.org</a>.<br>
</blockquote></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-1nTmSAMa4zOg5tAbm%3DrspsbMv0Z_=
sBfpTTHHvauJKiJg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-1nTmSAMa=
4zOg5tAbm%3DrspsbMv0Z_sBfpTTHHvauJKiJg%40mail.gmail.com</a>.<br />

--0000000000004157f50577c271c8--

.

On Mon, Oct 08, 2018 at 12:02:59PM -0700, Andrew Giese wrote:
> What about using [[nodiscard]] as a null-statement?
>=20
> Similar to how [[fallthrough]] is a null statement intended to indicate t=
o=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.
>=20
> e.g.=20
>=20
> memset(password, 0, PASSWORD_SIZE);
> [[nodiscard]]; // intentionally store before a free
> free(password);

I think the use of an attribute for this purpose is problematic.

The first reason is the good old attributes may be ignored argument - this
means that if a compiler ain't supporting this attribute then the resulting
code is broken, no diagnostic allowed.

The second reason is that what is cared about here is the values. If the
compiler is told that the value is used after the memset then it won't
remove it so I think something like

void use(T) { }

and

void use(T*, size_t) { }


but somehow marked to tell the compiler that the argument passed is
used so you better don't optimize it away is more useful.

memset(password, 0, PASSWORD_SIZE);
use(password, PASSWOD_SIZE);
free(password);

/MF

>=20
>=20
> On Sunday, October 7, 2018 at 9:47:37 AM UTC-5, Daniel Gutson wrote:
> >
> >
> >
> > El dom., 7 oct. 2018 6:17, <floria...@gmail.com <javascript:>> 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, <floria...@gmail.com>=20
> >>> escribi=C3=B3:
> >>>
> >>>> I completely understood what you meant, and yes what you are proposi=
ng=20
> >>>> is compatible with the current language.
> >>>> I just wanted to highlight that it might be misleading to have the s=
ame=20
> >>>> attribute with different meaning when it is used on a function decla=
ration,=20
> >>>> or on an expression (a declaration is also a statement).
> >>>>
> >>>> Also, after some thinking, in this case, the goal is not to force th=
e=20
> >>>> last assignment, but to force the last value of the variable, wherev=
er 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 who=
se=20
> >>>> meaning would be that the object might be accessed after its lifetim=
e end=20
> >>>> and so the last assignment should be kept and propagated to every st=
orage=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=
 be=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 some=
how,=20
> >> and so the correctness of the whole program depends on the last value =
not=20
> >> being discarded".
> >>
> >> Your view is also correct, but a bit more magic: when this "destroy al=
l=20
> >> the places where the object is" is performed? (the right answer is: ju=
st=20
> >> after its destructor is called)
> >> While in what I propose, it is done more explicitly when the last valu=
e=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, thoug=
h=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 th=
e=20
> >> original, and is misleading.
> >>
> >> An attribute is not a keyword, it is easy to create new ones (easier t=
han=20
> >> repurposing an old one?).
> >>
> >> --=20
> >> You received this message because you are subscribed to the Google Gro=
ups=20
> >> "ISO C++ Standard - Future Proposals" group.
> >> To unsubscribe from this group and stop receiving emails from it, send=
 an=20
> >> email to std-proposal...@isocpp.org <javascript:>.
> >> To post to this group, send email to std-pr...@isocpp.org <javascript:=
>.
> >> To view this discussion on the web visit=20
> >> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/dba0bf6d-=
92da-440e-8e61-af336cacd537%40isocpp.org=20
> >> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/dba0bf6d=
-92da-440e-8e61-af336cacd537%40isocpp.org?utm_medium=3Demail&utm_source=3Df=
ooter>
> >> .
> >>
> >
>=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=
 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/isoc=
pp.org/d/msgid/std-proposals/c35b213e-cbfd-41e2-a8dd-e5cf93343b8c%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/20181009062157.GA4566%40noemi.bahnhof.se.

.

Hi Daniel,

On Fri, Sep 28, 2018 at 3:36 PM Daniel Gutson <danielgutson@gmail.com> wrote:
>
> Yeah.  But please note that this is not only for function calls.
>
> void f()
> {
>    int secret;
>    ....
>    secret = 0;  //removed due to DSE
> }
>

For this specific case (data that must be kept as secret as reasonably
possible, like passwords, secrets, keying data...), I am proposing
`secure_clear` (a memset_s-like function and function template) and
`secure_val` (a new class template) in P1315 for the next mailing.
Meanwhile that is out, please take a look at:

  https://ojeda.io/cpp/secure_val

As long as your proposal allows to write functionality like
`secure_clear` and `secure_val` as portably and easily as possible, it
seems useful!

Cheers,
Miguel

--
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/CANiq72%3D4-NBXg28AVBbaY83jLgTNRowmKiMT8Sgk28jTUu2xfw%40mail.gmail.com.

.

------=_Part_1965_1321297405.1539069948469
Content-Type: multipart/alternative;
 boundary="----=_Part_1966_2029531398.1539069948470"

------=_Part_1966_2029531398.1539069948470
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Wouldn't something like this as a std:: function work?

template<class T>
    inline add_volatile<T>&
    make_volatile (T& t)
    {
        return t;
    }

Then later:

int a =3D 5;
=E2=80=A6
make_volatile (a) =3D 0;


std::best_regards();

On Tuesday, October 9, 2018 at 9:02:41 AM UTC+2, Miguel Ojeda wrote:
>
> Hi Daniel,=20
>
> For this specific case (data that must be kept as secret as reasonably=20
> possible, like passwords, secrets, keying data...), I am proposing=20
> `secure_clear` (a memset_s-like function and function template) and=20
> `secure_val` (a new class template) in P1315 for the next mailing.=20
> Meanwhile that is out, please take a look at:=20
>
>   https://ojeda.io/cpp/secure_val=20
>
> As long as your proposal allows to write functionality like=20
> `secure_clear` and `secure_val` as portably and easily as possible, it=20
> seems useful!=20
>
> Cheers,=20
> Miguel=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/1aa6c911-439e-4469-806d-bdc39989ad40%40isocpp.or=
g.

------=_Part_1966_2029531398.1539069948470
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Wouldn&#39;t something like this as a std:: function work?=
<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250,=
 250); border-color: rgb(187, 187, 187); border-style: solid; border-width:=
 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"sub=
prettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">temp=
late</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">class</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">inline</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> add_volatile</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">&gt;&amp;</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 make_volatile </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> t</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">return</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> t</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span></div></code></div><div><br></div><div>Then la=
ter:</div><div><br></div><div><div class=3D"prettyprint" style=3D"backgroun=
d-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style=
: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettypr=
int"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> a </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #066;" class=3D"styled-by-prettify">5</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">=E2=80=A6</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br>make_volatile </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">a</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span></div=
></code></div><br></div><div><br>std::best_regards();<br><br>On Tuesday, Oc=
tober 9, 2018 at 9:02:41 AM UTC+2, Miguel Ojeda wrote:<blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;">Hi Daniel,
<br>
<br>For this specific case (data that must be kept as secret as reasonably
<br>possible, like passwords, secrets, keying data...), I am proposing
<br>`secure_clear` (a memset_s-like function and function template) and
<br>`secure_val` (a new class template) in P1315 for the next mailing.
<br>Meanwhile that is out, please take a look at:
<br>
<br>=C2=A0 <a href=3D"https://ojeda.io/cpp/secure_val" target=3D"_blank" re=
l=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q=
\x3dhttps%3A%2F%2Fojeda.io%2Fcpp%2Fsecure_val\x26sa\x3dD\x26sntz\x3d1\x26us=
g\x3dAFQjCNF-Z2fPlRu8XiZWvsdOeh1PS9HiIg&#39;;return true;" onclick=3D"this.=
href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fojeda.io%2Fcpp%2F=
secure_val\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF-Z2fPlRu8XiZWvsdOeh1PS9=
HiIg&#39;;return true;">https://ojeda.io/cpp/secure_<wbr>val</a>
<br>
<br>As long as your proposal allows to write functionality like
<br>`secure_clear` and `secure_val` as portably and easily as possible, it
<br>seems useful!
<br>
<br>Cheers,
<br>Miguel
<br></blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1aa6c911-439e-4469-806d-bdc39989ad40%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1aa6c911-439e-4469-806d-bdc39989ad40=
%40isocpp.org</a>.<br />

------=_Part_1966_2029531398.1539069948470--

------=_Part_1965_1321297405.1539069948469--

.

------=_Part_1998_711717152.1539073114382
Content-Type: multipart/alternative;
 boundary="----=_Part_1999_452760052.1539073114382"

------=_Part_1999_452760052.1539073114382
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Le mardi 9 octobre 2018 04:24:53 UTC+2, Daniel Gutson a =C3=A9crit :
>
>
>
> El lun., 8 oct. 2018 21:38, <mutant....@gmail.com <javascript:>> escribi=
=C3=B3:
>
>> That could be easily broken if someone replaced memset() with another=20
>> super_memset() function or similar which did more than one write. How wo=
uld=20
>> the compiler know which write inside of the memset() function it has to=
=20
>> keep? Would it only work for memset and assignments? I don't like the id=
ea=20
>> of an attribute that only works for memset() but not other functions.
>>
>
> That's why I'm struggling to explain that this attribute is statement-wis=
e=20
> rather than for annotating function *calls* only
>

Your very first example is not suited for an attribute on a statement, but=
=20
for an attribute on the object itself because you don't know (and will=20
never know) where the object is (in register? in memory? both?) and on=20
which location the last assignment is done.
Even if you could force the assignment both in register and in memory, are=
=20
you sure the assignment in register has overridden the right register?
So enforcing that the last assignment is done gives you almost nothing in=
=20
that case (That's why I proposed the [[undead]] attribute, but alternatives=
=20
are fine).

However, for other purposes I think it's fine (the memset example on heap=
=20
memory) and here I completely agree that an attribute on the statement is=
=20
the right way to do (I just disagree on the name of of the attribute=20
because I find it misleading).
I also want to mention here, that it is already possible to do it with=20
inline asm (not standard).

--=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/e7edc1e3-a9b3-421c-a72f-623d6c34b104%40isocpp.or=
g.

------=_Part_1999_452760052.1539073114382
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Le mardi 9 octobre 2018 04:24:53 UTC+2, Daniel Gutson a =
=C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"a=
uto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">El lun., 8 oc=
t. 2018 21:38,  &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscate=
d-mailto=3D"tJzbmQI7BAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;=
javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;=
;return true;">mutant....@gmail.com</a>&gt; escribi=C3=B3:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div>That could be easily broken i=
f someone replaced memset() with another super_memset() function or similar=
 which did more than one write. How would the compiler know which write ins=
ide of the memset() function it has to keep? Would it only work for memset =
and assignments? I don&#39;t like the idea of an attribute that only works =
for memset() but not other functions.</div></div></blockquote></div></div><=
div dir=3D"auto"><br></div><div dir=3D"auto">That&#39;s why I&#39;m struggl=
ing to explain that this attribute is statement-wise rather than for annota=
ting function *calls* only</div></div></blockquote><div><br></div><div>Your=
 very first example is not suited for an attribute on a statement, but for =
an attribute on the object itself because you don&#39;t know (and will neve=
r know) where the object is (in register? in memory? both?) and on which lo=
cation the last assignment is done.</div><div>Even if you could force the a=
ssignment both in register and in memory, are you sure the assignment in re=
gister has overridden the right register?<br></div><div>So enforcing that t=
he last assignment is done gives you almost nothing in that case (That&#39;=
s why I proposed the [[undead]] attribute, but alternatives are fine).</div=
><div><br></div><div>However, for other purposes I think it&#39;s fine (the=
 memset example on heap memory) and here I completely agree that an attribu=
te on the statement is the right way to do (I just disagree on the name of =
of the attribute because I find it misleading).</div><div>I also want to me=
ntion here, that it is already possible to do it with inline asm (not stand=
ard).<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e7edc1e3-a9b3-421c-a72f-623d6c34b104%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e7edc1e3-a9b3-421c-a72f-623d6c34b104=
%40isocpp.org</a>.<br />

------=_Part_1999_452760052.1539073114382--

------=_Part_1998_711717152.1539073114382--

.

--0000000000000752e10577c93815
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 9 Oct 2018 at 09:25, Micha=C5=82 Gawron <mcvsama@gmail.com> wrote:

> Wouldn't something like this as a std:: function work?
>
> template<class T>
>     inline add_volatile<T>&
>     make_volatile (T& t)
>     {
>         return t;
>     }
>
>
I had the same thought. The old assembler/c-hacker in me, which screams
"it's all just bl**dy memory!!" completely agrees with you (although
shouldn't it be `add_volatile_t<T>&` ?.

Would this require a language change?




> Then later:
>
> int a =3D 5;
> =E2=80=A6
> make_volatile (a) =3D 0;
>
>
> std::best_regards();
>
> On Tuesday, October 9, 2018 at 9:02:41 AM UTC+2, Miguel Ojeda wrote:
>>
>> Hi Daniel,
>>
>> For this specific case (data that must be kept as secret as reasonably
>> possible, like passwords, secrets, keying data...), I am proposing
>> `secure_clear` (a memset_s-like function and function template) and
>> `secure_val` (a new class template) in P1315 for the next mailing.
>> Meanwhile that is out, please take a look at:
>>
>>   https://ojeda.io/cpp/secure_val
>>
>> As long as your proposal allows to write functionality like
>> `secure_clear` and `secure_val` as portably and easily as possible, it
>> seems useful!
>>
>> Cheers,
>> Miguel
>>
> --
> 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/1aa6c911-439=
e-4469-806d-bdc39989ad40%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1aa6c911-43=
9e-4469-806d-bdc39989ad40%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>

--=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/CALvx3hboWxMcpiQbiUbRCZK8jdskm_3Hn%3DHx5ATGf7MnL=
HhdgA%40mail.gmail.com.

--0000000000000752e10577c93815
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue=
, 9 Oct 2018 at 09:25, Micha=C5=82 Gawron &lt;<a href=3D"mailto:mcvsama@gma=
il.com">mcvsama@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr">Wouldn&#39;t something like this as a std:: function=
 work?<br><br><div class=3D"m_-1580269167637698904prettyprint" style=3D"bac=
kground-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:s=
olid;border-width:1px;word-wrap:break-word"><code class=3D"m_-1580269167637=
698904prettyprint"><div class=3D"m_-1580269167637698904subprettyprint"><spa=
n style=3D"color:#008" class=3D"m_-1580269167637698904styled-by-prettify">t=
emplate</span><span style=3D"color:#660" class=3D"m_-1580269167637698904sty=
led-by-prettify">&lt;</span><span style=3D"color:#008" class=3D"m_-15802691=
67637698904styled-by-prettify">class</span><span style=3D"color:#000" class=
=3D"m_-1580269167637698904styled-by-prettify"> T</span><span style=3D"color=
:#660" class=3D"m_-1580269167637698904styled-by-prettify">&gt;</span><span =
style=3D"color:#000" class=3D"m_-1580269167637698904styled-by-prettify"><br=
>=C2=A0 =C2=A0 </span><span style=3D"color:#008" class=3D"m_-15802691676376=
98904styled-by-prettify">inline</span><span style=3D"color:#000" class=3D"m=
_-1580269167637698904styled-by-prettify"> add_volatile</span><span style=3D=
"color:#660" class=3D"m_-1580269167637698904styled-by-prettify">&lt;</span>=
<span style=3D"color:#000" class=3D"m_-1580269167637698904styled-by-prettif=
y">T</span><span style=3D"color:#660" class=3D"m_-1580269167637698904styled=
-by-prettify">&gt;&amp;</span><span style=3D"color:#000" class=3D"m_-158026=
9167637698904styled-by-prettify"><br>=C2=A0 =C2=A0 make_volatile </span><sp=
an style=3D"color:#660" class=3D"m_-1580269167637698904styled-by-prettify">=
(</span><span style=3D"color:#000" class=3D"m_-1580269167637698904styled-by=
-prettify">T</span><span style=3D"color:#660" class=3D"m_-15802691676376989=
04styled-by-prettify">&amp;</span><span style=3D"color:#000" class=3D"m_-15=
80269167637698904styled-by-prettify"> t</span><span style=3D"color:#660" cl=
ass=3D"m_-1580269167637698904styled-by-prettify">)</span><span style=3D"col=
or:#000" class=3D"m_-1580269167637698904styled-by-prettify"><br>=C2=A0 =C2=
=A0 </span><span style=3D"color:#660" class=3D"m_-1580269167637698904styled=
-by-prettify">{</span><span style=3D"color:#000" class=3D"m_-15802691676376=
98904styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=
=3D"color:#008" class=3D"m_-1580269167637698904styled-by-prettify">return</=
span><span style=3D"color:#000" class=3D"m_-1580269167637698904styled-by-pr=
ettify"> t</span><span style=3D"color:#660" class=3D"m_-1580269167637698904=
styled-by-prettify">;</span><span style=3D"color:#000" class=3D"m_-15802691=
67637698904styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"colo=
r:#660" class=3D"m_-1580269167637698904styled-by-prettify">}</span><span st=
yle=3D"color:#000" class=3D"m_-1580269167637698904styled-by-prettify"><br><=
/span></div></code></div><div><br></div></div></blockquote><div><br></div><=
div>I had the same thought. The old assembler/c-hacker in me, which screams=
 &quot;it&#39;s all just bl**dy memory!!&quot; completely agrees with you (=
although shouldn&#39;t it be `<font face=3D"monospace, monospace">add_volat=
ile_t&lt;T&gt;&amp;</font>` ?.</div><div><br></div><div>Would this require =
a language change?</div><div><br></div><div><br></div><div>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>Then later:</di=
v><div><br></div><div><div class=3D"m_-1580269167637698904prettyprint" styl=
e=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);border=
-style:solid;border-width:1px;word-wrap:break-word"><code class=3D"m_-15802=
69167637698904prettyprint"><div class=3D"m_-1580269167637698904subprettypri=
nt"><span style=3D"color:#008" class=3D"m_-1580269167637698904styled-by-pre=
ttify">int</span><span style=3D"color:#000" class=3D"m_-1580269167637698904=
styled-by-prettify"> a </span><span style=3D"color:#660" class=3D"m_-158026=
9167637698904styled-by-prettify">=3D</span><span style=3D"color:#000" class=
=3D"m_-1580269167637698904styled-by-prettify"> </span><span style=3D"color:=
#066" class=3D"m_-1580269167637698904styled-by-prettify">5</span><span styl=
e=3D"color:#660" class=3D"m_-1580269167637698904styled-by-prettify">;</span=
><span style=3D"color:#000" class=3D"m_-1580269167637698904styled-by-pretti=
fy"><br></span><span style=3D"color:#660" class=3D"m_-1580269167637698904st=
yled-by-prettify">=E2=80=A6</span><span style=3D"color:#000" class=3D"m_-15=
80269167637698904styled-by-prettify"><br>make_volatile </span><span style=
=3D"color:#660" class=3D"m_-1580269167637698904styled-by-prettify">(</span>=
<span style=3D"color:#000" class=3D"m_-1580269167637698904styled-by-prettif=
y">a</span><span style=3D"color:#660" class=3D"m_-1580269167637698904styled=
-by-prettify">)</span><span style=3D"color:#000" class=3D"m_-15802691676376=
98904styled-by-prettify"> </span><span style=3D"color:#660" class=3D"m_-158=
0269167637698904styled-by-prettify">=3D</span><span style=3D"color:#000" cl=
ass=3D"m_-1580269167637698904styled-by-prettify"> </span><span style=3D"col=
or:#066" class=3D"m_-1580269167637698904styled-by-prettify">0</span><span s=
tyle=3D"color:#660" class=3D"m_-1580269167637698904styled-by-prettify">;</s=
pan></div></code></div><br></div><div><br>std::best_regards();<br><br>On Tu=
esday, October 9, 2018 at 9:02:41 AM UTC+2, Miguel Ojeda wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #=
ccc solid;padding-left:1ex">Hi Daniel,
<br>
<br>For this specific case (data that must be kept as secret as reasonably
<br>possible, like passwords, secrets, keying data...), I am proposing
<br>`secure_clear` (a memset_s-like function and function template) and
<br>`secure_val` (a new class template) in P1315 for the next mailing.
<br>Meanwhile that is out, please take a look at:
<br>
<br>=C2=A0 <a href=3D"https://ojeda.io/cpp/secure_val" rel=3D"nofollow" tar=
get=3D"_blank">https://ojeda.io/cpp/secure_val</a>
<br>
<br>As long as your proposal allows to write functionality like
<br>`secure_clear` and `secure_val` as portably and easily as possible, it
<br>seems useful!
<br>
<br>Cheers,
<br>Miguel
<br></blockquote></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1aa6c911-439e-4469-806d-bdc39989ad40%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1aa6c911-439e-=
4469-806d-bdc39989ad40%40isocpp.org</a>.<br>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hboWxMcpiQbiUbRCZK8jdskm_3Hn%3D=
Hx5ATGf7MnLHhdgA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hboWxMcpi=
QbiUbRCZK8jdskm_3Hn%3DHx5ATGf7MnLHhdgA%40mail.gmail.com</a>.<br />

--0000000000000752e10577c93815--

.

--000000000000abbe800577c93804
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

El mar., 9 oct. 2018 3:22, Magnus Fromreide <magfr@lysator.liu.se> escribi=
=C3=B3:

> On Mon, Oct 08, 2018 at 12:02:59PM -0700, Andrew Giese wrote:
> > 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
> > previous statement was intentional and should not be discarded.
> >
> > e.g.
> >
> > memset(password, 0, PASSWORD_SIZE);
> > [[nodiscard]]; // intentionally store before a free
> > free(password);
>
> I think the use of an attribute for this purpose is problematic.
>
> The first reason is the good old attributes may be ignored argument - thi=
s
> means that if a compiler ain't supporting this attribute then the resulti=
ng
> code is broken, no diagnostic allowed.
>

What would exactly broken mean here?


> The second reason is that what is cared about here is the values. If the
> compiler is told that the value is used after the memset then it won't
> remove it so I think something like
>
> void use(T) { }
>
> and
>
> void use(T*, size_t) { }
>
>
> but somehow marked to tell the compiler that the argument passed is
> used so you better don't optimize it away is more useful.
>
> memset(password, 0, PASSWORD_SIZE);
> use(password, PASSWOD_SIZE);
>

This may allow
  use(password, PASSWORD_SIZE-1)
or
  use(password+1, ...)
 for example.
We don't want to mess the value tracker that way.
I stick to the attribute version.
See my related answer below to Miguel Ojeda.


free(password);
>
> /MF
>
> >
> >
> > On Sunday, October 7, 2018 at 9:47:37 AM UTC-5, Daniel Gutson wrote:
> > >
> > >
> > >
> > > El dom., 7 oct. 2018 6:17, <floria...@gmail.com <javascript:>>
> escribi=C3=B3:
> > >
> > >>
> > >>
> > >> Le dimanche 7 octobre 2018 06:44:28 UTC+2, Daniel Gutson a =C3=A9cri=
t :
> > >>>
> > >>>
> > >>>
> > >>> 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 are
> proposing
> > >>>> is compatible with the current language.
> > >>>> I just wanted to highlight that it might be misleading to have the
> same
> > >>>> attribute with different meaning when it is used on a function
> declaration,
> > >>>> or on an expression (a declaration is also a statement).
> > >>>>
> > >>>> Also, after some thinking, in this case, the goal is not to force
> the
> > >>>> last assignment, but to force the last 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 accessed after its
> lifetime end
> > >>>> and so the last assignment should be kept and propagated to every
> storage
> > >>>> of the object:
> > >>>>
> > >>>> void f() {
> > >>>>   [[undead]] int secret;
> > >>>>   /* ... */
> > >>>>   secret =3D 0;
> > >>>> }
> > >>>> That wouldn't mean the lifetime of the object is extended and it
> > >>>> becomes valid to access it afterwards.
> > >>>> It would tell the compiler it should behave as-if the object
> *could*
> > >>>> be accessed afterwards.
> > >>>>
> > >>>
> > >>> Actually I would like to tell the compiler that the object should
> NOT be
> > >>> accessible afterwards.
> > >>>
> > >>
> > >> What I said is not "the compiler makes the object accessible", but
> > >> "whatever the compiler will do, the object will remain accessible
> somehow,
> > >> and so the correctness of the whole program depends on the last valu=
e
> not
> > >> being discarded".
> > >>
> > >> Your view is also correct, but a bit more magic: when this "destroy
> all
> > >> the places where the object is" is performed? (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 matter of taste at this point.
> > >>
> > >> However, your first proposal doesn't work that well: ok you tell the
> > >> compiler to keep the assignment. But which location is used for this
> > >> assignment? All of them? The last one? The main one? A new one?
> > >> And if you start standardizing which location should be assigned,
> then
> > >> you're not talking about expressions anymore, but about objects. So
> > >> attributes on expressions is not the right tool for you.
> > >>
> > >>
> > >>> Additionally I would like to reuse the existing attribute name,
> though
> > >>> this is of least importance now.
> > >>>
> > >>>
> > >>
> > >> Here, I completely disagree.
> > >>
> > >
> > > Ok let's not discuss this.
> > >
> > > It should not be an already existing attribute name unless the featur=
e
> is
> > >> close enough to the original attribute.
> > >> And the new meaning you proposed is (at least for me)  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
> > >> "ISO C++ Standard - Future Proposals" group.
> > >> To unsubscribe from this group and stop receiving emails from it,
> send an
> > >> email to std-proposal...@isocpp.org <javascript:>.
> > >> To post to this group, send email to std-pr...@isocpp.org
> <javascript:>.
> > >> To view this discussion on the web visit
> > >>
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/dba0bf6d-92d=
a-440e-8e61-af336cacd537%40isocpp.org
> > >> <
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/dba0bf6d-92d=
a-440e-8e61-af336cacd537%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoote=
r
> >
> > >> .
> > >>
> > >
> >
> > --
> > 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/c35b213e-cbf=
d-41e2-a8dd-e5cf93343b8c%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/201810090621=
57.GA4566%40noemi.bahnhof.se
> .
>

--=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/CAFdMc-0wY9Qs8hS%2B2UpeqKY-NkZ2edcrfcLW4Jt8UpahX=
xOLZg%40mail.gmail.com.

--000000000000abbe800577c93804
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">=
El mar., 9 oct. 2018 3:22, Magnus Fromreide &lt;<a href=3D"mailto:magfr@lys=
ator.liu.se">magfr@lysator.liu.se</a>&gt; escribi=C3=B3:<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">On Mon, Oct 08, 2018 at 12:02:59PM -0700, Andrew Gies=
e wrote:<br>
&gt; What about using [[nodiscard]] as a null-statement?<br>
&gt; <br>
&gt; Similar to how [[fallthrough]] is a null statement intended to indicat=
e to <br>
&gt; the compiler and reader that the fallthrough is intentional, a <br>
&gt; [[nodiscard]] after an assignment or a memset should indicate that the=
 <br>
&gt; previous statement was intentional and should not be discarded.<br>
&gt; <br>
&gt; e.g. <br>
&gt; <br>
&gt; memset(password, 0, PASSWORD_SIZE);<br>
&gt; [[nodiscard]]; // intentionally store before a free<br>
&gt; free(password);<br>
<br>
I think the use of an attribute for this purpose is problematic.<br>
<br>
The first reason is the good old attributes may be ignored argument - this<=
br>
means that if a compiler ain&#39;t supporting this attribute then the resul=
ting<br>
code is broken, no diagnostic allowed.<br></blockquote></div></div><div dir=
=3D"auto"><br></div><div dir=3D"auto">What would exactly broken mean here?<=
/div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quot=
e"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">
<br>
The second reason is that what is cared about here is the values. If the<br=
>
compiler is told that the value is used after the memset then it won&#39;t<=
br>
remove it so I think something like<br>
<br>
void use(T) { }<br>
<br>
and<br>
<br>
void use(T*, size_t) { }<br>
<br>
<br>
but somehow marked to tell the compiler that the argument passed is<br>
used so you better don&#39;t optimize it away is more useful.<br>
<br>
memset(password, 0, PASSWORD_SIZE);<br>
use(password, PASSWOD_SIZE);<br></blockquote></div></div><div dir=3D"auto">=
<br></div><div dir=3D"auto">This may allow=C2=A0</div><div dir=3D"auto">=C2=
=A0 use(password, PASSWORD_SIZE-1)</div><div dir=3D"auto">or</div><div dir=
=3D"auto">=C2=A0 use(password+1, ...)</div><div dir=3D"auto">=C2=A0for exam=
ple.</div><div dir=3D"auto">We don&#39;t want to mess the value tracker tha=
t way.</div><div dir=3D"auto">I stick to the attribute version.</div><div d=
ir=3D"auto">See my related answer below to Miguel Ojeda.</div><div dir=3D"a=
uto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"=
gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex">
free(password);<br>
<br>
/MF<br>
<br>
&gt; <br>
&gt; <br>
&gt; On Sunday, October 7, 2018 at 9:47:37 AM UTC-5, Daniel Gutson wrote:<b=
r>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; El dom., 7 oct. 2018 6:17, &lt;<a href=3D"mailto:floria...@gmail.=
com" target=3D"_blank" rel=3D"noreferrer">floria...@gmail.com</a> &lt;javas=
cript:&gt;&gt; escribi=C3=B3:<br>
&gt; &gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Le dimanche 7 octobre 2018 06:44:28 UTC+2, Daniel Gutson a =
=C3=A9crit :<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; El vie., 28 de sep. de 2018 a la(s) 11:36, &lt;<a href=3D=
"mailto:floria...@gmail.com" target=3D"_blank" rel=3D"noreferrer">floria...=
@gmail.com</a>&gt; <br>
&gt; &gt;&gt;&gt; escribi=C3=B3:<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt; I completely understood what you meant, and yes what =
you are proposing <br>
&gt; &gt;&gt;&gt;&gt; is compatible with the current language.<br>
&gt; &gt;&gt;&gt;&gt; I just wanted to highlight that it might be misleadin=
g to have the same <br>
&gt; &gt;&gt;&gt;&gt; attribute with different meaning when it is used on a=
 function declaration, <br>
&gt; &gt;&gt;&gt;&gt; or on an expression (a declaration is also a statemen=
t).<br>
&gt; &gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt; Also, after some thinking, in this case, the goal is =
not to force the <br>
&gt; &gt;&gt;&gt;&gt; last assignment, but to force the last value of the v=
ariable, wherever the <br>
&gt; &gt;&gt;&gt;&gt; variable is, even if the variable is both in register=
 and stack.<br>
&gt; &gt;&gt;&gt;&gt; So in that case, you might be better with a [[undead]=
] attribute whose <br>
&gt; &gt;&gt;&gt;&gt; meaning would be that the object might be accessed af=
ter its lifetime end <br>
&gt; &gt;&gt;&gt;&gt; and so the last assignment should be kept and propaga=
ted to every storage <br>
&gt; &gt;&gt;&gt;&gt; of the object:<br>
&gt; &gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt; void f() {<br>
&gt; &gt;&gt;&gt;&gt;=C2=A0 =C2=A0[[undead]] int secret;<br>
&gt; &gt;&gt;&gt;&gt;=C2=A0 =C2=A0/* ... */<br>
&gt; &gt;&gt;&gt;&gt;=C2=A0 =C2=A0secret =3D 0;<br>
&gt; &gt;&gt;&gt;&gt; }<br>
&gt; &gt;&gt;&gt;&gt; That wouldn&#39;t mean the lifetime of the object is =
extended and it <br>
&gt; &gt;&gt;&gt;&gt; becomes valid to access it afterwards.<br>
&gt; &gt;&gt;&gt;&gt; It would tell the compiler it should behave as-if the=
 object *could* <br>
&gt; &gt;&gt;&gt;&gt; be accessed afterwards.<br>
&gt; &gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; Actually I would like to tell the compiler that the objec=
t should NOT be <br>
&gt; &gt;&gt;&gt; accessible afterwards.<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; What I said is not &quot;the compiler makes the object access=
ible&quot;, but <br>
&gt; &gt;&gt; &quot;whatever the compiler will do, the object will remain a=
ccessible somehow, <br>
&gt; &gt;&gt; and so the correctness of the whole program depends on the la=
st value not <br>
&gt; &gt;&gt; being discarded&quot;.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Your view is also correct, but a bit more magic: when this &q=
uot;destroy all <br>
&gt; &gt;&gt; the places where the object is&quot; is performed? (the right=
 answer is: just <br>
&gt; &gt;&gt; after its destructor is called)<br>
&gt; &gt;&gt; While in what I propose, it is done more explicitly when the =
last value <br>
&gt; &gt;&gt; is assigned.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; But both are good. It&#39;s just a matter of taste at this po=
int.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; However, your first proposal doesn&#39;t work that well: ok y=
ou tell the <br>
&gt; &gt;&gt; compiler to keep the assignment. But which location is used f=
or this <br>
&gt; &gt;&gt; assignment? All of them? The last one? The main one? A new on=
e?<br>
&gt; &gt;&gt; And if you start standardizing which location should be assig=
ned, then <br>
&gt; &gt;&gt; you&#39;re not talking about expressions anymore, but about o=
bjects. So <br>
&gt; &gt;&gt; attributes on expressions is not the right tool for you.<br>
&gt; &gt;&gt;=C2=A0 <br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;&gt; Additionally I would like to reuse the existing attribute=
 name, though <br>
&gt; &gt;&gt;&gt; this is of least importance now.<br>
&gt; &gt;&gt;&gt;=C2=A0 <br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Here, I completely disagree. <br>
&gt; &gt;&gt;<br>
&gt; &gt;<br>
&gt; &gt; Ok let&#39;s not discuss this.<br>
&gt; &gt;<br>
&gt; &gt; It should not be an already existing attribute name unless the fe=
ature is <br>
&gt; &gt;&gt; close enough to the original attribute.<br>
&gt; &gt;&gt; And the new meaning you proposed is (at least for me)=C2=A0 t=
oo far from the <br>
&gt; &gt;&gt; original, and is misleading.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; An attribute is not a keyword, it is easy to create new ones =
(easier than <br>
&gt; &gt;&gt; repurposing an old one?).<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; -- <br>
&gt; &gt;&gt; You received this message because you are subscribed to the G=
oogle Groups <br>
&gt; &gt;&gt; &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; &gt;&gt; To unsubscribe from this group and stop receiving emails from=
 it, send an <br>
&gt; &gt;&gt; email to <a href=3D"mailto:std-proposal...@isocpp.org" target=
=3D"_blank" rel=3D"noreferrer">std-proposal...@isocpp.org</a> &lt;javascrip=
t:&gt;.<br>
&gt; &gt;&gt; To post to this group, send email to <a href=3D"mailto:std-pr=
....@isocpp.org" target=3D"_blank" rel=3D"noreferrer">std-pr...@isocpp.org</=
a> &lt;javascript:&gt;.<br>
&gt; &gt;&gt; To view this discussion on the web visit <br>
&gt; &gt;&gt; <a href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std=
-proposals/dba0bf6d-92da-440e-8e61-af336cacd537%40isocpp.org" rel=3D"norefe=
rrer noreferrer" target=3D"_blank">https://groups.google.com/a/isocpp.org/d=
/msgid/std-proposals/dba0bf6d-92da-440e-8e61-af336cacd537%40isocpp.org</a> =
<br>
&gt; &gt;&gt; &lt;<a href=3D"https://groups.google.com/a/isocpp.org/d/msgid=
/std-proposals/dba0bf6d-92da-440e-8e61-af336cacd537%40isocpp.org?utm_medium=
=3Demail&amp;utm_source=3Dfooter" rel=3D"noreferrer noreferrer" target=3D"_=
blank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/dba0bf6=
d-92da-440e-8e61-af336cacd537%40isocpp.org?utm_medium=3Demail&amp;utm_sourc=
e=3Dfooter</a>&gt;<br>
&gt; &gt;&gt; .<br>
&gt; &gt;&gt;<br>
&gt; &gt;<br>
&gt; <br>
&gt; -- <br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" targ=
et=3D"_blank" rel=3D"noreferrer">std-proposals+unsubscribe@isocpp.org</a>.<=
br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org" target=3D"_blank" rel=3D"noreferrer">std-proposals@isocpp.org</a=
>.<br>
&gt; To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/c35b213e-cbfd-41e2-a8dd-e5cf9334=
3b8c%40isocpp.org" rel=3D"noreferrer noreferrer" target=3D"_blank">https://=
groups.google.com/a/isocpp.org/d/msgid/std-proposals/c35b213e-cbfd-41e2-a8d=
d-e5cf93343b8c%40isocpp.org</a>.<br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank" rel=3D"noreferrer">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">std-proposals@isocpp.org</a>.<br=
>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/20181009062157.GA4566%40noemi.bahnhof=
..se" rel=3D"noreferrer noreferrer" target=3D"_blank">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/20181009062157.GA4566%40noemi.bahnho=
f.se</a>.<br>
</blockquote></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-0wY9Qs8hS%2B2UpeqKY-NkZ2edcrfc=
LW4Jt8UpahXxOLZg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-0wY9Qs8h=
S%2B2UpeqKY-NkZ2edcrfcLW4Jt8UpahXxOLZg%40mail.gmail.com</a>.<br />

--000000000000abbe800577c93804--

.

--000000000000f56bdc0577c949b8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

El mar., 9 oct. 2018 4:02, Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
escribi=C3=B3:

> Hi Daniel,
>

Hola Miguel,


> On Fri, Sep 28, 2018 at 3:36 PM Daniel Gutson <danielgutson@gmail.com>
> wrote:
> >
> > Yeah.  But please note that this is not only for function calls.
> >
> > void f()
> > {
> >    int secret;
> >    ....
> >    secret =3D 0;  //removed due to DSE
> > }
> >
>
> For this specific case (data that must be kept as secret as reasonably
> possible, like passwords, secrets, keying data...), I am proposing
> `secure_clear` (a memset_s-like function and function template) and
> `secure_val` (a new class template) in P1315 for the next mailing.
> Meanwhile that is out, please take a look at:
>
>   https://ojeda.io/cpp/secure_val
>
> As long as your proposal allows to write functionality like
> `secure_clear` and `secure_val` as portably and easily as possible, it
> seems useful!
>

I just read the proposal and I'm glad I'm not alone :)
Please keep in mind that there are other cases. For example, doing stuff
over IO mapped memory.
This particularly may be a bug and a different thread, but a call to
std::fill_n over a volatile-qualified buffer gets removed in the gcc,
clang, icc and MSVC.
OTOH does your secure_val allow the value placed in registers?


> Cheers,
> Miguel
>
> --
> 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/CANiq72%3D4-=
NBXg28AVBbaY83jLgTNRowmKiMT8Sgk28jTUu2xfw%40mail.gmail.com
> .
>

--=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/CAFdMc-2KfkjwOaiQCbqCnMOH0LfMUdVJouJ-uRSUFZzhqk3=
7tg%40mail.gmail.com.

--000000000000f56bdc0577c949b8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">=
El mar., 9 oct. 2018 4:02, Miguel Ojeda &lt;<a href=3D"mailto:miguel.ojeda.=
sandonis@gmail.com">miguel.ojeda.sandonis@gmail.com</a>&gt; escribi=C3=B3:<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">Hi Daniel,<br></blockquote></div></=
div><div dir=3D"auto"><br></div><div dir=3D"auto">Hola Miguel,</div><div di=
r=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">
<br>
On Fri, Sep 28, 2018 at 3:36 PM Daniel Gutson &lt;<a href=3D"mailto:danielg=
utson@gmail.com" target=3D"_blank" rel=3D"noreferrer">danielgutson@gmail.co=
m</a>&gt; wrote:<br>
&gt;<br>
&gt; Yeah.=C2=A0 But please note that this is not only for function calls.<=
br>
&gt;<br>
&gt; void f()<br>
&gt; {<br>
&gt;=C2=A0 =C2=A0 int secret;<br>
&gt;=C2=A0 =C2=A0 ....<br>
&gt;=C2=A0 =C2=A0 secret =3D 0;=C2=A0 //removed due to DSE<br>
&gt; }<br>
&gt;<br>
<br>
For this specific case (data that must be kept as secret as reasonably<br>
possible, like passwords, secrets, keying data...), I am proposing<br>
`secure_clear` (a memset_s-like function and function template) and<br>
`secure_val` (a new class template) in P1315 for the next mailing.<br>
Meanwhile that is out, please take a look at:<br>
<br>
=C2=A0 <a href=3D"https://ojeda.io/cpp/secure_val" rel=3D"noreferrer norefe=
rrer" target=3D"_blank">https://ojeda.io/cpp/secure_val</a><br>
<br>
As long as your proposal allows to write functionality like<br>
`secure_clear` and `secure_val` as portably and easily as possible, it<br>
seems useful!<br></blockquote></div></div><div dir=3D"auto"><br></div><div =
dir=3D"auto">I just read the proposal and I&#39;m glad I&#39;m not alone :)=
</div><div dir=3D"auto">Please keep in mind that there are other cases. For=
 example, doing stuff over IO mapped memory.</div><div dir=3D"auto">This pa=
rticularly may be a bug and a different thread, but a call to std::fill_n o=
ver a volatile-qualified buffer gets removed in the gcc, clang, icc and MSV=
C.</div><div dir=3D"auto">OTOH does your secure_val allow the value placed =
in registers?</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
Miguel<br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank" rel=3D"noreferrer">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">std-proposals@isocpp.org</a>.<br=
>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANiq72%3D4-NBXg28AVBbaY83jLgTNRowmKi=
MT8Sgk28jTUu2xfw%40mail.gmail.com" rel=3D"noreferrer noreferrer" target=3D"=
_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANiq7=
2%3D4-NBXg28AVBbaY83jLgTNRowmKiMT8Sgk28jTUu2xfw%40mail.gmail.com</a>.<br>
</blockquote></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-2KfkjwOaiQCbqCnMOH0LfMUdVJouJ-=
uRSUFZzhqk37tg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-2KfkjwOaiQ=
CbqCnMOH0LfMUdVJouJ-uRSUFZzhqk37tg%40mail.gmail.com</a>.<br />

--000000000000f56bdc0577c949b8--

.

--000000000000ae873c0577c951a2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

El mar., 9 oct. 2018 4:25, Micha=C5=82 Gawron <mcvsama@gmail.com> escribi=
=C3=B3:

> Wouldn't something like this as a std:: function work?
>
> template<class T>
>     inline add_volatile<T>&
>     make_volatile (T& t)
>     {
>         return t;
>     }
>
> Then later:
>
> int a =3D 5;
> =E2=80=A6
> make_volatile (a) =3D 0;
>

What about function calls? What about memory regions?


>
> std::best_regards();
>
> On Tuesday, October 9, 2018 at 9:02:41 AM UTC+2, Miguel Ojeda wrote:
>>
>> Hi Daniel,
>>
>> For this specific case (data that must be kept as secret as reasonably
>> possible, like passwords, secrets, keying data...), I am proposing
>> `secure_clear` (a memset_s-like function and function template) and
>> `secure_val` (a new class template) in P1315 for the next mailing.
>> Meanwhile that is out, please take a look at:
>>
>>   https://ojeda.io/cpp/secure_val
>>
>> As long as your proposal allows to write functionality like
>> `secure_clear` and `secure_val` as portably and easily as possible, it
>> seems useful!
>>
>> Cheers,
>> Miguel
>>
> --
> 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/1aa6c911-439=
e-4469-806d-bdc39989ad40%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1aa6c911-43=
9e-4469-806d-bdc39989ad40%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>

--=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/CAFdMc-0dqO7n9miYxbWYafWSV%2B_E2LO0%3DKmTd5%3D_4=
xem2bZJ2Q%40mail.gmail.com.

--000000000000ae873c0577c951a2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">=
El mar., 9 oct. 2018 4:25, Micha=C5=82 Gawron &lt;<a href=3D"mailto:mcvsama=
@gmail.com">mcvsama@gmail.com</a>&gt; escribi=C3=B3:<br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr">Wouldn&#39;t something like this as a st=
d:: function work?<br><br><div class=3D"m_1236661646361963502prettyprint" s=
tyle=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);bor=
der-style:solid;border-width:1px;word-wrap:break-word"><code class=3D"m_123=
6661646361963502prettyprint"><div class=3D"m_1236661646361963502subprettypr=
int"><span style=3D"color:#008" class=3D"m_1236661646361963502styled-by-pre=
ttify">template</span><span style=3D"color:#660" class=3D"m_123666164636196=
3502styled-by-prettify">&lt;</span><span style=3D"color:#008" class=3D"m_12=
36661646361963502styled-by-prettify">class</span><span style=3D"color:#000"=
 class=3D"m_1236661646361963502styled-by-prettify"> T</span><span style=3D"=
color:#660" class=3D"m_1236661646361963502styled-by-prettify">&gt;</span><s=
pan style=3D"color:#000" class=3D"m_1236661646361963502styled-by-prettify">=
<br>=C2=A0 =C2=A0 </span><span style=3D"color:#008" class=3D"m_123666164636=
1963502styled-by-prettify">inline</span><span style=3D"color:#000" class=3D=
"m_1236661646361963502styled-by-prettify"> add_volatile</span><span style=
=3D"color:#660" class=3D"m_1236661646361963502styled-by-prettify">&lt;</spa=
n><span style=3D"color:#000" class=3D"m_1236661646361963502styled-by-pretti=
fy">T</span><span style=3D"color:#660" class=3D"m_1236661646361963502styled=
-by-prettify">&gt;&amp;</span><span style=3D"color:#000" class=3D"m_1236661=
646361963502styled-by-prettify"><br>=C2=A0 =C2=A0 make_volatile </span><spa=
n style=3D"color:#660" class=3D"m_1236661646361963502styled-by-prettify">(<=
/span><span style=3D"color:#000" class=3D"m_1236661646361963502styled-by-pr=
ettify">T</span><span style=3D"color:#660" class=3D"m_1236661646361963502st=
yled-by-prettify">&amp;</span><span style=3D"color:#000" class=3D"m_1236661=
646361963502styled-by-prettify"> t</span><span style=3D"color:#660" class=
=3D"m_1236661646361963502styled-by-prettify">)</span><span style=3D"color:#=
000" class=3D"m_1236661646361963502styled-by-prettify"><br>=C2=A0 =C2=A0 </=
span><span style=3D"color:#660" class=3D"m_1236661646361963502styled-by-pre=
ttify">{</span><span style=3D"color:#000" class=3D"m_1236661646361963502sty=
led-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"colo=
r:#008" class=3D"m_1236661646361963502styled-by-prettify">return</span><spa=
n style=3D"color:#000" class=3D"m_1236661646361963502styled-by-prettify"> t=
</span><span style=3D"color:#660" class=3D"m_1236661646361963502styled-by-p=
rettify">;</span><span style=3D"color:#000" class=3D"m_1236661646361963502s=
tyled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#660" clas=
s=3D"m_1236661646361963502styled-by-prettify">}</span><span style=3D"color:=
#000" class=3D"m_1236661646361963502styled-by-prettify"><br></span></div></=
code></div><div><br></div><div>Then later:</div><div><br></div><div><div cl=
ass=3D"m_1236661646361963502prettyprint" style=3D"background-color:rgb(250,=
250,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px;=
word-wrap:break-word"><code class=3D"m_1236661646361963502prettyprint"><div=
 class=3D"m_1236661646361963502subprettyprint"><span style=3D"color:#008" c=
lass=3D"m_1236661646361963502styled-by-prettify">int</span><span style=3D"c=
olor:#000" class=3D"m_1236661646361963502styled-by-prettify"> a </span><spa=
n style=3D"color:#660" class=3D"m_1236661646361963502styled-by-prettify">=
=3D</span><span style=3D"color:#000" class=3D"m_1236661646361963502styled-b=
y-prettify"> </span><span style=3D"color:#066" class=3D"m_12366616463619635=
02styled-by-prettify">5</span><span style=3D"color:#660" class=3D"m_1236661=
646361963502styled-by-prettify">;</span><span style=3D"color:#000" class=3D=
"m_1236661646361963502styled-by-prettify"><br></span><span style=3D"color:#=
660" class=3D"m_1236661646361963502styled-by-prettify">=E2=80=A6</span><spa=
n style=3D"color:#000" class=3D"m_1236661646361963502styled-by-prettify"><b=
r>make_volatile </span><span style=3D"color:#660" class=3D"m_12366616463619=
63502styled-by-prettify">(</span><span style=3D"color:#000" class=3D"m_1236=
661646361963502styled-by-prettify">a</span><span style=3D"color:#660" class=
=3D"m_1236661646361963502styled-by-prettify">)</span><span style=3D"color:#=
000" class=3D"m_1236661646361963502styled-by-prettify"> </span><span style=
=3D"color:#660" class=3D"m_1236661646361963502styled-by-prettify">=3D</span=
><span style=3D"color:#000" class=3D"m_1236661646361963502styled-by-prettif=
y"> </span><span style=3D"color:#066" class=3D"m_1236661646361963502styled-=
by-prettify">0</span><span style=3D"color:#660" class=3D"m_1236661646361963=
502styled-by-prettify">;</span></div></code></div></div></div></blockquote>=
</div></div><div dir=3D"auto"><br></div><div dir=3D"auto">What about functi=
on calls? What about memory regions?</div><div dir=3D"auto"><br></div><div =
dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><div><br></div><div><br>std::best_regards();<br><br>On Tuesday=
, October 9, 2018 at 9:02:41 AM UTC+2, Miguel Ojeda wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex">Hi Daniel,
<br>
<br>For this specific case (data that must be kept as secret as reasonably
<br>possible, like passwords, secrets, keying data...), I am proposing
<br>`secure_clear` (a memset_s-like function and function template) and
<br>`secure_val` (a new class template) in P1315 for the next mailing.
<br>Meanwhile that is out, please take a look at:
<br>
<br>=C2=A0 <a href=3D"https://ojeda.io/cpp/secure_val" rel=3D"nofollow nore=
ferrer" target=3D"_blank">https://ojeda.io/cpp/secure_val</a>
<br>
<br>As long as your proposal allows to write functionality like
<br>`secure_clear` and `secure_val` as portably and easily as possible, it
<br>seems useful!
<br>
<br>Cheers,
<br>Miguel
<br></blockquote></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank" rel=3D"noreferrer">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">std-proposals@isocpp.org</a>.<br=
>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1aa6c911-439e-4469-806d-bdc39989ad40%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/1aa6c911-439e-4469-806d-bdc39989ad40%40isocpp.org</a>.<br>
</blockquote></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-0dqO7n9miYxbWYafWSV%2B_E2LO0%3=
DKmTd5%3D_4xem2bZJ2Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-0dqO=
7n9miYxbWYafWSV%2B_E2LO0%3DKmTd5%3D_4xem2bZJ2Q%40mail.gmail.com</a>.<br />

--000000000000ae873c0577c951a2--

.

--000000000000caf9840577c960e2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

El mar., 9 oct. 2018 5:18, <florian.csdt@gmail.com> escribi=C3=B3:

> Le mardi 9 octobre 2018 04:24:53 UTC+2, Daniel Gutson a =C3=A9crit :
>>
>>
>>
>> El lun., 8 oct. 2018 21:38, <mutant....@gmail.com> escribi=C3=B3:
>>
>>> That could be easily broken if someone replaced memset() with another
>>> super_memset() function or similar which did more than one write. How w=
ould
>>> the compiler know which write inside of the memset() function it has to
>>> keep? Would it only work for memset and assignments? I don't like the i=
dea
>>> of an attribute that only works for memset() but not other functions.
>>>
>>
>> That's why I'm struggling to explain that this attribute is
>> statement-wise rather than for annotating function *calls* only
>>
>
> Your very first example is not suited for an attribute on a statement, bu=
t
> for an attribute on the object itself because you don't know (and will
> never know) where the object is (in register? in memory? both?) and on
> which location the last assignment is done.
> Even if you could force the assignment both in register and in memory, ar=
e
> you sure the assignment in register has overridden the right register?
>

Are you saying that the object may undergo internal copies for optimization
purposes (e.g. if it is in a register it may be copied to other registers
as a temporal)? It could also be arithmetically operated in other registers
which would still turn it recoverable by applying the reverse operation.
Hm. Is that what you are saying?

So enforcing that the last assignment is done gives you almost nothing in
> that case (That's why I proposed the [[undead]] attribute, but alternativ=
es
> are fine).
>
> However, for other purposes I think it's fine (the memset example on heap
> memory) and here I completely agree that an attribute on the statement is
> the right way to do (I just disagree on the name of of the attribute
> because I find it misleading).
> I also want to mention here, that it is already possible to do it with
> inline asm (not standard).
>
> --
> 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/e7edc1e3-a9b=
3-421c-a72f-623d6c34b104%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e7edc1e3-a9=
b3-421c-a72f-623d6c34b104%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>

--=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/CAFdMc-0-p7rOo3MYrfa%2Bx_zc21h58fZb_Qt5a1g6ocasC=
qyJXw%40mail.gmail.com.

--000000000000caf9840577c960e2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">=
El mar., 9 oct. 2018 5:18,  &lt;<a href=3D"mailto:florian.csdt@gmail.com">f=
lorian.csdt@gmail.com</a>&gt; escribi=C3=B3:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr">Le mardi 9 octobre 2018 04:24:53 UTC+2, Daniel G=
utson a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">El lun.,=
 8 oct. 2018 21:38,  &lt;<a rel=3D"nofollow noreferrer">mutant....@gmail.co=
m</a>&gt; escribi=C3=B3:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div>That could be easily broken if someone replaced memset() with=
 another super_memset() function or similar which did more than one write. =
How would the compiler know which write inside of the memset() function it =
has to keep? Would it only work for memset and assignments? I don&#39;t lik=
e the idea of an attribute that only works for memset() but not other funct=
ions.</div></div></blockquote></div></div><div dir=3D"auto"><br></div><div =
dir=3D"auto">That&#39;s why I&#39;m struggling to explain that this attribu=
te is statement-wise rather than for annotating function *calls* only</div>=
</div></blockquote><div><br></div><div>Your very first example is not suite=
d for an attribute on a statement, but for an attribute on the object itsel=
f because you don&#39;t know (and will never know) where the object is (in =
register? in memory? both?) and on which location the last assignment is do=
ne.</div><div>Even if you could force the assignment both in register and i=
n memory, are you sure the assignment in register has overridden the right =
register?<br></div></div></blockquote></div></div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">Are you saying that the object may undergo internal co=
pies for optimization purposes (e.g. if it is in a register it may be copie=
d to other registers as a temporal)? It could also be arithmetically operat=
ed in other registers which would still turn it recoverable by applying the=
 reverse operation.</div><div dir=3D"auto">Hm. Is that what you are saying?=
</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quo=
te"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>So enfo=
rcing that the last assignment is done gives you almost nothing in that cas=
e (That&#39;s why I proposed the [[undead]] attribute, but alternatives are=
 fine).</div><div><br></div><div>However, for other purposes I think it&#39=
;s fine (the memset example on heap memory) and here I completely agree tha=
t an attribute on the statement is the right way to do (I just disagree on =
the name of of the attribute because I find it misleading).</div><div>I als=
o want to mention here, that it is already possible to do it with inline as=
m (not standard).<br></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank" rel=3D"noreferrer">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">std-proposals@isocpp.org</a>.<br=
>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e7edc1e3-a9b3-421c-a72f-623d6c34b104%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/e7edc1e3-a9b3-421c-a72f-623d6c34b104%40isocpp.org</a>.<br>
</blockquote></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-0-p7rOo3MYrfa%2Bx_zc21h58fZb_Q=
t5a1g6ocasCqyJXw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-0-p7rOo3=
MYrfa%2Bx_zc21h58fZb_Qt5a1g6ocasCqyJXw%40mail.gmail.com</a>.<br />

--000000000000caf9840577c960e2--

.

--0000000000003af18f0577ca9ff6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

El 28 sept. 2018 8:13, "Daniel Gutson" <danielgutson@gmail.com> escribi=C3=
=B3:

Again, on the DSE related optimizations.


After thinking based on some feedbacks (especially from what I understood
from Florian) I concluded that the problem is bigger (value taunting) and
my attribute-based approach is not enough.
Evenmore none of the proposed solutions covers the scenarios. Moreover the
exploits have not been described AFAIK.

Thanks Florian, Miguel Ojeda and all those provided feedbacks.

I will come up with a further explanation and more complete solution in a
new thread after more research.



I'm at the Ekoparty where I will show a presentation about security
vulnerabilities caused by compiler optimizations. The subject is more and
more serious (e.g. [1]).

I want to propose to allow [[nodiscard]] in individual expressions, such as
calls to memset(), std::fill_n, and assignments (DSE happens with both
memory and registers).

Ideas? Co-authors?


--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=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/CAFdMc-2UXSNGCYophb_mVhMTJBjHCWDxFekpXDY7HGY1upc=
4bw%40mail.gmail.com.

--0000000000003af18f0577ca9ff6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div dir=3D"auto"></div><div class=3D"gmail_extra"><br><d=
iv class=3D"gmail_quote">El 28 sept. 2018 8:13, &quot;Daniel Gutson&quot; &=
lt;<a href=3D"mailto:danielgutson@gmail.com" target=3D"_blank" rel=3D"noref=
errer">danielgutson@gmail.com</a>&gt; escribi=C3=B3:<br type=3D"attribution=
"><blockquote class=3D"m_5377029607949429805quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Again, on =
the DSE related optimizations.</div></blockquote></div></div><div dir=3D"au=
to"><br></div><div dir=3D"auto">After thinking based on some feedbacks (esp=
ecially from what I understood from Florian) I concluded that the problem i=
s bigger (value taunting) and my attribute-based approach is not enough.=C2=
=A0</div><div dir=3D"auto">Evenmore none of the proposed solutions covers t=
he scenarios. Moreover the exploits have not been described AFAIK.=C2=A0=C2=
=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">Thanks Florian, Migu=
el Ojeda and all those provided feedbacks.</div><div dir=3D"auto"><br></div=
><div dir=3D"auto">I will come up with a further explanation and more compl=
ete solution in a new thread after more research.</div><div dir=3D"auto"><b=
r></div><div dir=3D"auto"><br></div><div class=3D"gmail_extra" dir=3D"auto"=
><div class=3D"gmail_quote"><blockquote class=3D"m_5377029607949429805quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr"><div><br></div><div>I&#39;m at the Ekoparty where I will sh=
ow a presentation about security vulnerabilities caused by compiler optimiz=
ations. The subject is more and more serious (e.g. [1]).</div><div><br></di=
v><div>I want to propose to allow [[nodiscard]] in individual expressions, =
such as calls to memset(), std::fill_n, and assignments (DSE happens with b=
oth memory and registers).</div><div><br></div><div>Ideas? Co-authors?=C2=
=A0<div class=3D"m_5377029607949429805signature-text"><br clear=3D"all"><di=
v><br></div>-- <br><div dir=3D"ltr" class=3D"m_5377029607949429805m_-888302=
1163269597694gmail_signature" data-smartmail=3D"gmail_signature">Who=E2=80=
=99s got the sweetest disposition?<br>One guess, that=E2=80=99s who?<br>Who=
=E2=80=99d never, ever start an argument?<br>Who never shows a bit of tempe=
rament?<br>Who&#39;s never wrong but always right?<br>Who&#39;d never dream=
 of starting a fight?<br>Who get stuck with all the bad luck? </div></div><=
/div></div>
</blockquote></div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-2UXSNGCYophb_mVhMTJBjHCWDxFekp=
XDY7HGY1upc4bw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-2UXSNGCYop=
hb_mVhMTJBjHCWDxFekpXDY7HGY1upc4bw%40mail.gmail.com</a>.<br />

--0000000000003af18f0577ca9ff6--

.

------=_Part_2078_644091601.1539087872565
Content-Type: multipart/alternative;
 boundary="----=_Part_2079_1005233533.1539087872566"

------=_Part_2079_1005233533.1539087872566
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



Le mardi 9 octobre 2018 12:41:21 UTC+2, Daniel Gutson a =C3=A9crit :
>
>
>
> El mar., 9 oct. 2018 5:18, <floria...@gmail.com <javascript:>> escribi=C3=
=B3:
>
>> Le mardi 9 octobre 2018 04:24:53 UTC+2, Daniel Gutson a =C3=A9crit :
>>>
>>>
>>>
>>> El lun., 8 oct. 2018 21:38, <mutant....@gmail.com> escribi=C3=B3:
>>>
>>>> That could be easily broken if someone replaced memset() with another=
=20
>>>> super_memset() function or similar which did more than one write. How =
would=20
>>>> the compiler know which write inside of the memset() function it has t=
o=20
>>>> keep? Would it only work for memset and assignments? I don't like the =
idea=20
>>>> of an attribute that only works for memset() but not other functions.
>>>>
>>>
>>> That's why I'm struggling to explain that this attribute is=20
>>> statement-wise rather than for annotating function *calls* only
>>>
>>
>> Your very first example is not suited for an attribute on a statement,=
=20
>> but for an attribute on the object itself because you don't know (and wi=
ll=20
>> never know) where the object is (in register? in memory? both?) and on=
=20
>> which location the last assignment is done.
>> Even if you could force the assignment both in register and in memory,=
=20
>> are you sure the assignment in register has overridden the right registe=
r?
>>
>
> Are you saying that the object may undergo internal copies for=20
> optimization purposes (e.g. if it is in a register it may be copied to=20
> other registers as a temporal)? It could also be arithmetically operated =
in=20
> other registers which would still turn it recoverable by applying the=20
> reverse operation.
> Hm. Is that what you are saying?
>

Yes for the first, no (but maybe yes) for the second:
Yes the compiler might duplicate the object in register for optimizations=
=20
purposes (eg: as a consequence of the SSA form). And yes, those registers=
=20
might outilive the function call (callee-saved vs caller-saved).
Actually, it might be even worse: a compiler can put you local object in=20
register, and because of the register pressure, the compiler spills your=20
object off to the stack, at a different place.

For your second point, I didn't think about it yet. So I didn't take it=20
into consideration when I proposed the [[undead]] attribute. But if your=20
goal is security, then you would also need to take into consideration this.
Let's imagine an attribute [[secret]].
Every object marked as [[secret]] will be cleaned before function exit.
This cleaning means set to zero every location that still contains the=20
object (known to the compiler).
Also, in order to not deduce the secret from other temporaries, any value=
=20
depending on a [[secret]] object is also marked implicitly as [[secret]].

This does not address cache persistency, but it can be covered if the=20
[[secret]] can take an optional argument to ensure cache lines related to=
=20
this object are flushed (done by the compiler).

With this, you start to have a pretty strong security plan for stack=20
objects. But the heap objects cannot be marked as secret. So for that,=20
maybe you could mark the delete statement as [[secret]] and let the=20
compiler do the same thing for heap objects.
And also, a [[secret]] reference would need mark every dependant objects as=
=20
[[secret]], but the referenced object itself would not be cleaned.
Here I'm just throwing ideas into the wild, but I think you get the idea.

All in all, I think it is possible to improve security with such=20
attributes, but I don't think an attribute on statements is the right way.
=20

>
> So enforcing that the last assignment is done gives you almost nothing in=
=20
>> that case (That's why I proposed the [[undead]] attribute, but alternati=
ves=20
>> are fine).
>>
>> However, for other purposes I think it's fine (the memset example on hea=
p=20
>> memory) and here I completely agree that an attribute on the statement i=
s=20
>> the right way to do (I just disagree on the name of of the attribute=20
>> because I find it misleading).
>> I also want to mention here, that it is already possible to do it with=
=20
>> inline asm (not standard).
>>
>> --=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 <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e7edc1e3-a9=
b3-421c-a72f-623d6c34b104%40isocpp.org=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e7edc1e3-a=
9b3-421c-a72f-623d6c34b104%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>

--=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/f5b06d59-bfc0-491b-b553-aca1c1050ee1%40isocpp.or=
g.

------=_Part_2079_1005233533.1539087872566
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>Le mardi 9 octobre 2018 12:41:21 UTC+2, Daniel Gut=
son a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">El mar.=
, 9 oct. 2018 5:18,  &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfu=
scated-mailto=3D"FcLbLRpWBAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D=
&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:=
&#39;;return true;">floria...@gmail.com</a>&gt; escribi=C3=B3:<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr">Le mardi 9 octobre 2018 04:24:=
53 UTC+2, Daniel Gutson a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=
=3D"ltr">El lun., 8 oct. 2018 21:38,  &lt;<a rel=3D"nofollow noreferrer">mu=
tant....@gmail.com</a>&gt; escribi=C3=B3:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><div>That could be easily broken if someone replace=
d memset() with another super_memset() function or similar which did more t=
han one write. How would the compiler know which write inside of the memset=
() function it has to keep? Would it only work for memset and assignments? =
I don&#39;t like the idea of an attribute that only works for memset() but =
not other functions.</div></div></blockquote></div></div><div dir=3D"auto">=
<br></div><div dir=3D"auto">That&#39;s why I&#39;m struggling to explain th=
at this attribute is statement-wise rather than for annotating function *ca=
lls* only</div></div></blockquote><div><br></div><div>Your very first examp=
le is not suited for an attribute on a statement, but for an attribute on t=
he object itself because you don&#39;t know (and will never know) where the=
 object is (in register? in memory? both?) and on which location the last a=
ssignment is done.</div><div>Even if you could force the assignment both in=
 register and in memory, are you sure the assignment in register has overri=
dden the right register?<br></div></div></blockquote></div></div><div dir=
=3D"auto"><br></div><div dir=3D"auto">Are you saying that the object may un=
dergo internal copies for optimization purposes (e.g. if it is in a registe=
r it may be copied to other registers as a temporal)? It could also be arit=
hmetically operated in other registers which would still turn it recoverabl=
e by applying the reverse operation.</div><div dir=3D"auto">Hm. Is that wha=
t you are saying?</div></div></blockquote><div><br></div><div>Yes for the f=
irst, no (but maybe yes) for the second:</div><div>Yes the compiler might d=
uplicate the object in register for optimizations purposes (eg: as a conseq=
uence of the SSA form). And yes, those registers might outilive the functio=
n call (callee-saved vs caller-saved).</div><div>Actually, it might be even=
 worse: a compiler can put you local object in register, and because of the=
 register pressure, the compiler spills your object off to the stack, at a =
different place.</div><div><br></div><div>For your second point, I didn&#39=
;t think about it yet. So I didn&#39;t take it into consideration when I pr=
oposed the [[undead]] attribute. But if your goal is security, then you wou=
ld also need to take into consideration this.</div><div>Let&#39;s imagine a=
n attribute [[secret]].</div><div>Every object marked as [[secret]] will be=
 cleaned before function exit.</div><div>This cleaning means set to zero ev=
ery location that still contains the object (known to the compiler).</div><=
div>Also, in order to not deduce the secret from other temporaries, any val=
ue depending on a [[secret]] object is also marked implicitly as [[secret]]=
..</div><div><br></div><div>This does not address cache persistency, but it =
can be covered if the [[secret]] can take an optional argument to ensure ca=
che lines related to this object are flushed (done by the compiler).</div><=
div><br></div><div>With this, you start to have a pretty strong security pl=
an for stack objects. But the heap objects cannot be marked as secret. So f=
or that, maybe you could mark the delete statement as [[secret]] and let th=
e compiler do the same thing for heap objects.</div><div>And also, a [[secr=
et]] reference would need mark every dependant objects as [[secret]], but t=
he referenced object itself would not be cleaned.</div><div>Here I&#39;m ju=
st throwing ideas into the wild, but I think you get the idea.</div><div><b=
r></div><div>All in all, I think it is possible to improve security with su=
ch attributes, but I don&#39;t think an attribute on statements is the righ=
t way.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><div dir=3D"auto"><div dir=3D"auto"><br></div><div dir=3D"auto"><div cla=
ss=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></d=
iv><div>So enforcing that the last assignment is done gives you almost noth=
ing in that case (That&#39;s why I proposed the [[undead]] attribute, but a=
lternatives are fine).</div><div><br></div><div>However, for other purposes=
 I think it&#39;s fine (the memset example on heap memory) and here I compl=
etely agree that an attribute on the statement is the right way to do (I ju=
st disagree on the name of of the attribute because I find it misleading).<=
/div><div>I also want to mention here, that it is already possible to do it=
 with inline asm (not standard).<br></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" rel=3D"nofollow" target=3D"_blank" gdf-obfu=
scated-mailto=3D"FcLbLRpWBAAJ" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" rel=3D"nofollo=
w" target=3D"_blank" gdf-obfuscated-mailto=3D"FcLbLRpWBAAJ" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e7edc1e3-a9b3-421c-a72f-623d6c34b104%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank" onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/e7edc1e3-a9b3-421c-a72f-623d6c34b104%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" on=
click=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/e7edc1e3-a9b3-421c-a72f-623d6c34b104%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/e7edc1e3-a9b3-421c-<wbr>a72f-=
623d6c34b104%40isocpp.org</a><wbr>.<br>
</blockquote></div></div></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f5b06d59-bfc0-491b-b553-aca1c1050ee1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f5b06d59-bfc0-491b-b553-aca1c1050ee1=
%40isocpp.org</a>.<br />

------=_Part_2079_1005233533.1539087872566--

------=_Part_2078_644091601.1539087872565--

.

Hi Daniel,

On Tue, Oct 9, 2018 at 12:34 PM Daniel Gutson <danielgutson@gmail.com> wrote:
>
> I just read the proposal and I'm glad I'm not alone :)
> Please keep in mind that there are other cases. For example, doing stuff over IO mapped memory.
> This particularly may be a bug and a different thread, but a call to std::fill_n over a volatile-qualified buffer gets removed in the gcc, clang, icc and MSVC.
> OTOH does your secure_val allow the value placed in registers?
>

Sure, and actually a vendor may be encouraged to place such memory in
registers if at all possible, since that would directly remove any
concerns about leaks from the memory or the cache; as explained in the
proposal.

The proposal does not specify where the value should be stored -- that
is one of the keys: it could even be stored in some "special" kind of
memory. Basically, the implementer decides what is the best option for
the given T and their platform/OS/etc. What is important is that they
do as much effort as possible to protect the value for the users.

The goal, in the end, is that application users have an easy way to
mark what is supposed to be protected and when such value is accessed.

Cheers,
Miguel

--
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/CANiq72mnWuMGNT27jVueGTvnk4eGNKWsMbWPJnejC1tPxhT7WA%40mail.gmail.com.

.

Hi Florian,

On Tue, Oct 9, 2018 at 2:24 PM <florian.csdt@gmail.com> wrote:
>
> For your second point, I didn't think about it yet. So I didn't take it into consideration when I proposed the [[undead]] attribute. But if your goal is security, then you would also need to take into consideration this.
> Let's imagine an attribute [[secret]].
> Every object marked as [[secret]] will be cleaned before function exit.
> This cleaning means set to zero every location that still contains the object (known to the compiler).

This sounds very similar to secure_val, but as a variable attribute.

> Also, in order to not deduce the secret from other temporaries, any value depending on a [[secret]] object is also marked implicitly as [[secret]].
>
> This does not address cache persistency, but it can be covered if the [[secret]] can take an optional argument to ensure cache lines related to this object are flushed (done by the compiler).
>
> With this, you start to have a pretty strong security plan for stack objects. But the heap objects cannot be marked as secret. So for that, maybe you could mark the delete statement as [[secret]] and let the compiler do the same thing for heap objects.

I would say users should not care where or how the value is stored.
Having to mark delete statements with an attribute seems odd. As a
user, I would simply prefer to be able to mark my type T with
[[secret]] and then *that* could be put into the heap. That is the
reason I went for a template, because it looked natural to wrap values
with it:

  std::secure_val<int> my_very_secret_number;
  std::secure_val<char [N]> my_private_key;

etc.

> And also, a [[secret]] reference would need mark every dependant objects as [[secret]], but the referenced object itself would not be cleaned.
> Here I'm just throwing ideas into the wild, but I think you get the idea.
>
> All in all, I think it is possible to improve security with such attributes, but I don't think an attribute on statements is the right way.
>

Indeed, I think a better idea is to work on the storage side, not on
the statement level.

Cheers,
Miguel

--
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/CANiq72kBPp9uONTPvC7L9n8%2BrtnXtE12MM_YJQDw1JsbVQ9frA%40mail.gmail.com.

.

------=_Part_991_994715291.1539089789089
Content-Type: multipart/alternative;
 boundary="----=_Part_992_1576238945.1539089789089"

------=_Part_992_1576238945.1539089789089
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Le mardi 9 octobre 2018 14:42:10 UTC+2, Miguel Ojeda a =C3=A9crit :
>
> Hi Florian,=20
>
> On Tue, Oct 9, 2018 at 2:24 PM <floria...@gmail.com <javascript:>> wrote:=
=20
> >=20
> > For your second point, I didn't think about it yet. So I didn't take it=
=20
> into consideration when I proposed the [[undead]] attribute. But if your=
=20
> goal is security, then you would also need to take into consideration thi=
s.=20
> > Let's imagine an attribute [[secret]].=20
> > Every object marked as [[secret]] will be cleaned before function exit.=
=20
> > This cleaning means set to zero every location that still contains the=
=20
> object (known to the compiler).=20
>
> This sounds very similar to secure_val, but as a variable attribute.=20
>

Yes it is similar. But I think attribute is more appropriate because those=
=20
security issues are not about C++: in order to read a destroyed value, you=
=20
need to use undefined behavior somehow.
=20

>
> > Also, in order to not deduce the secret from other temporaries, any=20
> value depending on a [[secret]] object is also marked implicitly as=20
> [[secret]].=20
> >=20
> > This does not address cache persistency, but it can be covered if the=
=20
> [[secret]] can take an optional argument to ensure cache lines related to=
=20
> this object are flushed (done by the compiler).=20
> >=20
> > With this, you start to have a pretty strong security plan for stack=20
> objects. But the heap objects cannot be marked as secret. So for that,=20
> maybe you could mark the delete statement as [[secret]] and let the=20
> compiler do the same thing for heap objects.=20
>
> I would say users should not care where or how the value is stored.=20
> Having to mark delete statements with an attribute seems odd.=20


The problem is, when you create an object on the heap, on don't really own=
=20
the object. that's why it needs a special treatment.
Maybe marking the pointer type as [[secret]] could solve the issue.
If you delete a [[secret]] pointer, then the compiler needs to ensure every=
=20
location is cleaned afterwards.
=20

> As a=20
> user, I would simply prefer to be able to mark my type T with=20
> [[secret]] and then *that* could be put into the heap. That is the=20
> reason I went for a template, because it looked natural to wrap values=20
> with it:=20
>
>   std::secure_val<int> my_very_secret_number;=20
>   std::secure_val<char [N]> my_private_key;=20
>
> etc.=20
>

The problem with your template approach is: you don't have the cascade of=
=20
the secret property, so temporaries depending on your secure_val will not=
=20
be cleaned.
Also, your template is not safely implementable in C++: you need=20
cooperation from the compiler in the same way as with the attribute,=20
because of the possible mutliple locations of your object.

Maybe we would need to have this in type system itself (very hard) with a=
=20
new qualifier.
=20

>
> > And also, a [[secret]] reference would need mark every dependant object=
s=20
> as [[secret]], but the referenced object itself would not be cleaned.=20
> > Here I'm just throwing ideas into the wild, but I think you get the=20
> idea.=20
> >=20
> > All in all, I think it is possible to improve security with such=20
> attributes, but I don't think an attribute on statements is the right way=
..=20
> >=20
>
> Indeed, I think a better idea is to work on the storage side, not on=20
> the statement level.=20
>
> Cheers,=20
> Miguel=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/199794e8-8362-489b-818f-ab6c510c5c84%40isocpp.or=
g.

------=_Part_992_1576238945.1539089789089
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>Le mardi 9 octobre 2018 14:42:10 UTC+2, Miguel Ojeda a=
 =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi Florian,
<br>
<br>On Tue, Oct 9, 2018 at 2:24 PM &lt;<a href=3D"javascript:" target=3D"_b=
lank" gdf-obfuscated-mailto=3D"MpAO4bFcBAAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D=
&#39;javascript:&#39;;return true;">floria...@gmail.com</a>&gt; wrote:
<br>&gt;
<br>&gt; For your second point, I didn&#39;t think about it yet. So I didn&=
#39;t take it into consideration when I proposed the [[undead]] attribute. =
But if your goal is security, then you would also need to take into conside=
ration this.
<br>&gt; Let&#39;s imagine an attribute [[secret]].
<br>&gt; Every object marked as [[secret]] will be cleaned before function =
exit.
<br>&gt; This cleaning means set to zero every location that still contains=
 the object (known to the compiler).
<br>
<br>This sounds very similar to secure_val, but as a variable attribute.
<br></blockquote><div><br></div><div>Yes it is similar. But I think attribu=
te is more appropriate because those security issues are not about C++: in =
order to read a destroyed value, you need to use undefined behavior somehow=
..<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>&gt; Also, in order to not deduce the secret from other temporaries, an=
y value depending on a [[secret]] object is also marked implicitly as [[sec=
ret]].
<br>&gt;
<br>&gt; This does not address cache persistency, but it can be covered if =
the [[secret]] can take an optional argument to ensure cache lines related =
to this object are flushed (done by the compiler).
<br>&gt;
<br>&gt; With this, you start to have a pretty strong security plan for sta=
ck objects. But the heap objects cannot be marked as secret. So for that, m=
aybe you could mark the delete statement as [[secret]] and let the compiler=
 do the same thing for heap objects.
<br>
<br>I would say users should not care where or how the value is stored.
<br>Having to mark delete statements with an attribute seems odd. </blockqu=
ote><div><br></div><div></div><div>The problem is, when you create an objec=
t on the heap, on don&#39;t really own the object. that&#39;s why it needs =
a special treatment.</div><div>Maybe marking the pointer type as [[secret]]=
 could solve the issue.</div><div>If you delete a [[secret]] pointer, then =
the compiler needs to ensure every location is cleaned afterwards.<br></div=
><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">As a
<br>user, I would simply prefer to be able to mark my type T with
<br>[[secret]] and then *that* could be put into the heap. That is the
<br>reason I went for a template, because it looked natural to wrap values
<br>with it:
<br>
<br>=C2=A0 std::secure_val&lt;int&gt; my_very_secret_number;
<br>=C2=A0 std::secure_val&lt;char [N]&gt; my_private_key;
<br>
<br>etc.
<br></blockquote><div><br></div><div>The problem with your template approac=
h is: you don&#39;t have the cascade of the secret property, so temporaries=
 depending on your secure_val will not be cleaned.</div><div>Also, your tem=
plate is not safely implementable in C++: you need cooperation from the com=
piler in the same way as with the attribute, because of the possible mutlip=
le locations of your object.</div><div><br></div><div>Maybe we would need t=
o have this in type system itself (very hard) with a new qualifier.<br></di=
v><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>&gt; And also, a [[secret]] reference would need mark every dependant o=
bjects as [[secret]], but the referenced object itself would not be cleaned=
..
<br>&gt; Here I&#39;m just throwing ideas into the wild, but I think you ge=
t the idea.
<br>&gt;
<br>&gt; All in all, I think it is possible to improve security with such a=
ttributes, but I don&#39;t think an attribute on statements is the right wa=
y.
<br>&gt;
<br>
<br>Indeed, I think a better idea is to work on the storage side, not on
<br>the statement level.
<br>
<br>Cheers,
<br>Miguel
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/199794e8-8362-489b-818f-ab6c510c5c84%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/199794e8-8362-489b-818f-ab6c510c5c84=
%40isocpp.org</a>.<br />

------=_Part_992_1576238945.1539089789089--

------=_Part_991_994715291.1539089789089--

.

--000000000000106e8f0577cb49f2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

(Top posting intentional)

I will wrote a detailed case ofnthe issue once I research the security
issue (and try to write an exploit as a PoC) before any language proposal.

At language proposal I will start over a new thread because it should cover
value tainting and containers (both user defined and standard).
For example
   std::vector<std::string>
with or without specially fitted destructors.
I will not engange in any further discussion until I understand the broader
situation I referred to.
I think that this should involve type strongness since a function my pass a
sensitive function to a callee, and the "sensitiveness" of data should be
propagated for any operations the callee may do.
I already experienced this before when using C's FILE* where the io library
caches data internally forcing me to call setbuff(nullptr) (didn't
experiment with the C++'s streaming library yet).

Again, thanks for all the useful feedback. I don't want to spam more people
and want to "stop and think" quietly :)

It even leads to a security conference paper.

El mar., 9 oct. 2018 9:42, Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
escribi=C3=B3:

> Hi Florian,
>
> On Tue, Oct 9, 2018 at 2:24 PM <florian.csdt@gmail.com> wrote:
> >
> > For your second point, I didn't think about it yet. So I didn't take it
> into consideration when I proposed the [[undead]] attribute. But if your
> goal is security, then you would also need to take into consideration thi=
s.
> > Let's imagine an attribute [[secret]].
> > Every object marked as [[secret]] will be cleaned before function exit.
> > This cleaning means set to zero every location that still contains the
> object (known to the compiler).
>
> This sounds very similar to secure_val, but as a variable attribute.
>
> > Also, in order to not deduce the secret from other temporaries, any
> value depending on a [[secret]] object is also marked implicitly as
> [[secret]].
> >
> > This does not address cache persistency, but it can be covered if the
> [[secret]] can take an optional argument to ensure cache lines related to
> this object are flushed (done by the compiler).
> >
> > With this, you start to have a pretty strong security plan for stack
> objects. But the heap objects cannot be marked as secret. So for that,
> maybe you could mark the delete statement as [[secret]] and let the
> compiler do the same thing for heap objects.
>
> I would say users should not care where or how the value is stored.
> Having to mark delete statements with an attribute seems odd. As a
> user, I would simply prefer to be able to mark my type T with
> [[secret]] and then *that* could be put into the heap. That is the
> reason I went for a template, because it looked natural to wrap values
> with it:
>
>   std::secure_val<int> my_very_secret_number;
>   std::secure_val<char [N]> my_private_key;
>
> etc.
>
> > And also, a [[secret]] reference would need mark every dependant object=
s
> as [[secret]], but the referenced object itself would not be cleaned.
> > Here I'm just throwing ideas into the wild, but I think you get the ide=
a.
> >
> > All in all, I think it is possible to improve security with such
> attributes, but I don't think an attribute on statements is the right way=
..
> >
>
> Indeed, I think a better idea is to work on the storage side, not on
> the statement level.
>
> Cheers,
> Miguel
>
> --
> 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/CANiq72kBPp9=
uONTPvC7L9n8%2BrtnXtE12MM_YJQDw1JsbVQ9frA%40mail.gmail.com
> .
>

--=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/CAFdMc-2oUcYW6CrwESORd4JF8qvKNxABtweWb_nSei5xoMd=
K%3DA%40mail.gmail.com.

--000000000000106e8f0577cb49f2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">(Top posting intentional)<div dir=3D"auto"><br></div><div=
 dir=3D"auto">I will wrote a detailed case ofnthe issue once I research the=
 security issue (and try to write an exploit as a PoC) before any language =
proposal.</div><div dir=3D"auto"><br></div><div dir=3D"auto">At language pr=
oposal I will start over a new thread because it should cover value taintin=
g and containers (both user defined and standard).</div><div dir=3D"auto">F=
or example</div><div dir=3D"auto">=C2=A0 =C2=A0std::vector&lt;std::string&g=
t;</div><div dir=3D"auto">with or without specially fitted destructors.</di=
v><div dir=3D"auto">I will not engange in any further discussion until I un=
derstand the broader situation I referred to.</div><div dir=3D"auto">I thin=
k that this should involve type strongness since a function my pass a sensi=
tive function to a callee, and the &quot;sensitiveness&quot; of data should=
 be propagated for any operations the callee may do.</div><div dir=3D"auto"=
>I already experienced this before when using C&#39;s FILE* where the io li=
brary caches data internally forcing me to call setbuff(nullptr) (didn&#39;=
t experiment with the C++&#39;s streaming library yet).</div><div dir=3D"au=
to"><br></div><div dir=3D"auto">Again, thanks for all the useful feedback. =
I don&#39;t want to spam more people and want to &quot;stop and think&quot;=
 quietly :)</div><div dir=3D"auto"><br></div><div dir=3D"auto">It even lead=
s to a security conference paper.</div></div><br><div class=3D"gmail_quote"=
><div dir=3D"ltr">El mar., 9 oct. 2018 9:42, Miguel Ojeda &lt;<a href=3D"ma=
ilto:miguel.ojeda.sandonis@gmail.com">miguel.ojeda.sandonis@gmail.com</a>&g=
t; escribi=C3=B3:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Florian,<br>
<br>
On Tue, Oct 9, 2018 at 2:24 PM &lt;<a href=3D"mailto:florian.csdt@gmail.com=
" target=3D"_blank" rel=3D"noreferrer">florian.csdt@gmail.com</a>&gt; wrote=
:<br>
&gt;<br>
&gt; For your second point, I didn&#39;t think about it yet. So I didn&#39;=
t take it into consideration when I proposed the [[undead]] attribute. But =
if your goal is security, then you would also need to take into considerati=
on this.<br>
&gt; Let&#39;s imagine an attribute [[secret]].<br>
&gt; Every object marked as [[secret]] will be cleaned before function exit=
..<br>
&gt; This cleaning means set to zero every location that still contains the=
 object (known to the compiler).<br>
<br>
This sounds very similar to secure_val, but as a variable attribute.<br>
<br>
&gt; Also, in order to not deduce the secret from other temporaries, any va=
lue depending on a [[secret]] object is also marked implicitly as [[secret]=
].<br>
&gt;<br>
&gt; This does not address cache persistency, but it can be covered if the =
[[secret]] can take an optional argument to ensure cache lines related to t=
his object are flushed (done by the compiler).<br>
&gt;<br>
&gt; With this, you start to have a pretty strong security plan for stack o=
bjects. But the heap objects cannot be marked as secret. So for that, maybe=
 you could mark the delete statement as [[secret]] and let the compiler do =
the same thing for heap objects.<br>
<br>
I would say users should not care where or how the value is stored.<br>
Having to mark delete statements with an attribute seems odd. As a<br>
user, I would simply prefer to be able to mark my type T with<br>
[[secret]] and then *that* could be put into the heap. That is the<br>
reason I went for a template, because it looked natural to wrap values<br>
with it:<br>
<br>
=C2=A0 std::secure_val&lt;int&gt; my_very_secret_number;<br>
=C2=A0 std::secure_val&lt;char [N]&gt; my_private_key;<br>
<br>
etc.<br>
<br>
&gt; And also, a [[secret]] reference would need mark every dependant objec=
ts as [[secret]], but the referenced object itself would not be cleaned.<br=
>
&gt; Here I&#39;m just throwing ideas into the wild, but I think you get th=
e idea.<br>
&gt;<br>
&gt; All in all, I think it is possible to improve security with such attri=
butes, but I don&#39;t think an attribute on statements is the right way.<b=
r>
&gt;<br>
<br>
Indeed, I think a better idea is to work on the storage side, not on<br>
the statement level.<br>
<br>
Cheers,<br>
Miguel<br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank" rel=3D"noreferrer">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">std-proposals@isocpp.org</a>.<br=
>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANiq72kBPp9uONTPvC7L9n8%2BrtnXtE12MM=
_YJQDw1JsbVQ9frA%40mail.gmail.com" rel=3D"noreferrer noreferrer" target=3D"=
_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANiq7=
2kBPp9uONTPvC7L9n8%2BrtnXtE12MM_YJQDw1JsbVQ9frA%40mail.gmail.com</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-2oUcYW6CrwESORd4JF8qvKNxABtweW=
b_nSei5xoMdK%3DA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-2oUcYW6C=
rwESORd4JF8qvKNxABtweWb_nSei5xoMdK%3DA%40mail.gmail.com</a>.<br />

--000000000000106e8f0577cb49f2--

.

On Tue, Oct 9, 2018 at 2:56 PM <florian.csdt@gmail.com> wrote:
>
>
> Le mardi 9 octobre 2018 14:42:10 UTC+2, Miguel Ojeda a =C3=A9crit :
>>
>> Hi Florian,
>>
>> On Tue, Oct 9, 2018 at 2:24 PM <floria...@gmail.com> wrote:
>> >
>> > For your second point, I didn't think about it yet. So I didn't take i=
t into consideration when I proposed the [[undead]] attribute. But if your =
goal is security, then you would also need to take into consideration this.
>> > Let's imagine an attribute [[secret]].
>> > Every object marked as [[secret]] will be cleaned before function exit=
..
>> > This cleaning means set to zero every location that still contains the=
 object (known to the compiler).
>>
>> This sounds very similar to secure_val, but as a variable attribute.
>
>
> Yes it is similar. But I think attribute is more appropriate because thos=
e security issues are not about C++: in order to read a destroyed value, yo=
u need to use undefined behavior somehow.
>

I am not sure what you mean by "are not about C++" or by "reading a
destroyed value". Do you mean you want to have compiler support so
that other languages (like C) can take advantage of it?

Note that there are C++-only attributes; and that, anyway, it would be
nice to have a concrete use case (e.g. secure_val) where such features
could be used.

>>
>>
>> > Also, in order to not deduce the secret from other temporaries, any va=
lue depending on a [[secret]] object is also marked implicitly as [[secret]=
].
>> >
>> > This does not address cache persistency, but it can be covered if the =
[[secret]] can take an optional argument to ensure cache lines related to t=
his object are flushed (done by the compiler).
>> >
>> > With this, you start to have a pretty strong security plan for stack o=
bjects. But the heap objects cannot be marked as secret. So for that, maybe=
 you could mark the delete statement as [[secret]] and let the compiler do =
the same thing for heap objects.
>>
>> I would say users should not care where or how the value is stored.
>> Having to mark delete statements with an attribute seems odd.
>
>
> The problem is, when you create an object on the heap, on don't really ow=
n the object. that's why it needs a special treatment.
> Maybe marking the pointer type as [[secret]] could solve the issue.

Yes, exactly, that is why secure_val is a template: in my view, it has
to be applied the type; not on statements (Daniel's original proposal)
or variables (your initial [[secret]] proposal). If you create a type
attribute, then it could be used itself to implement (part of)
secure_val.

> If you delete a [[secret]] pointer, then the compiler needs to ensure eve=
ry location is cleaned afterwards.
>
>>
>> As a
>> user, I would simply prefer to be able to mark my type T with
>> [[secret]] and then *that* could be put into the heap. That is the
>> reason I went for a template, because it looked natural to wrap values
>> with it:
>>
>>   std::secure_val<int> my_very_secret_number;
>>   std::secure_val<char [N]> my_private_key;
>>
>> etc.
>
>
> The problem with your template approach is: you don't have the cascade of=
 the secret property, so temporaries depending on your secure_val will not =
be cleaned.

It depends. Note that the accesses to the secret value must go through
access(). This is intended so that code inside that block may be
treated specially by the compiler. The examples given in the proposal
about how this can be used are encryption (compiler support not needed
in principle), disabling speculation (compiler support needed), etc.

> Also, your template is not safely implementable in C++: you need cooperat=
ion from the compiler in the same way as with the attribute, because of the=
 possible mutliple locations of your object.
>

Of course it isn't, that is the whole point of secure_val. :-)

Let me put it this way: I would love secure_val to be implementable in
C++ (or at least part of it, e.g. the auto-clear [[secret]] part that
you are discussing). However, it is not clear yet how many things we
would need to add to the language or how. Some things, like
Spectre-class vulnerabilities, are still being researched. Therefore,
I suggested secure_val first to make the most common use case
concrete, and at the same time give developers a simple solution to
it. Since secure_val does not force almost anything on the vendors
(except the auto-clear), it can be updated to provide further
guarantees as time goes on.

Cheers,
Miguel

--=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/CANiq72mHdtv1H87QQWjRQzAa_BkCgr4SU9C2iOr7aJxGJJq=
f%2Bw%40mail.gmail.com.

.

------=_Part_2038_367397919.1539094357450
Content-Type: multipart/alternative;
 boundary="----=_Part_2039_335946979.1539094357450"

------=_Part_2039_335946979.1539094357450
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



Le mardi 9 octobre 2018 15:54:35 UTC+2, Miguel Ojeda a =C3=A9crit :
>
> On Tue, Oct 9, 2018 at 2:56 PM <floria...@gmail.com <javascript:>> wrote:=
=20
> >=20
> >=20
> > Le mardi 9 octobre 2018 14:42:10 UTC+2, Miguel Ojeda a =C3=A9crit :=20
> >>=20
> >> Hi Florian,=20
> >>=20
> >> On Tue, Oct 9, 2018 at 2:24 PM <floria...@gmail.com> wrote:=20
> >> >=20
> >> > For your second point, I didn't think about it yet. So I didn't take=
=20
> it into consideration when I proposed the [[undead]] attribute. But if yo=
ur=20
> goal is security, then you would also need to take into consideration thi=
s.=20
> >> > Let's imagine an attribute [[secret]].=20
> >> > Every object marked as [[secret]] will be cleaned before function=20
> exit.=20
> >> > This cleaning means set to zero every location that still contains=
=20
> the object (known to the compiler).=20
> >>=20
> >> This sounds very similar to secure_val, but as a variable attribute.=
=20
> >=20
> >=20
> > Yes it is similar. But I think attribute is more appropriate because=20
> those security issues are not about C++: in order to read a destroyed=20
> value, you need to use undefined behavior somehow.=20
> >=20
>
> I am not sure what you mean by "are not about C++" or by "reading a=20
> destroyed value". Do you mean you want to have compiler support so=20
> that other languages (like C) can take advantage of it?=20
>

No, I mean these security issues arise beyond the scope of C++.
As far as C++ is concerned, you cannot access a destroyed value (so the=20
secret remains secret).
Any attempt in doing that leads to undefined behaviours: meaning the result=
=20
does not depends on C++ semantic anymore.
So if every single undefined behavior would crash the program instant=20
(which is actually valid), there would be no secret leaking issue at all.

That's what I mean when I say it is not about C++.

I don't necessarily want to have it for other languages (but it would be=20
good if we do).
=20

>
> Note that there are C++-only attributes; and that, anyway, it would be=20
> nice to have a concrete use case (e.g. secure_val) where such features=20
> could be used.=20
>
> >>=20
> >>=20
> >> > Also, in order to not deduce the secret from other temporaries, any=
=20
> value depending on a [[secret]] object is also marked implicitly as=20
> [[secret]].=20
> >> >=20
> >> > This does not address cache persistency, but it can be covered if th=
e=20
> [[secret]] can take an optional argument to ensure cache lines related to=
=20
> this object are flushed (done by the compiler).=20
> >> >=20
> >> > With this, you start to have a pretty strong security plan for stack=
=20
> objects. But the heap objects cannot be marked as secret. So for that,=20
> maybe you could mark the delete statement as [[secret]] and let the=20
> compiler do the same thing for heap objects.=20
> >>=20
> >> I would say users should not care where or how the value is stored.=20
> >> Having to mark delete statements with an attribute seems odd.=20
> >=20
> >=20
> > The problem is, when you create an object on the heap, on don't really=
=20
> own the object. that's why it needs a special treatment.=20
> > Maybe marking the pointer type as [[secret]] could solve the issue.=20
>
> Yes, exactly, that is why secure_val is a template: in my view, it has=20
> to be applied the type; not on statements (Daniel's original proposal)=20
> or variables (your initial [[secret]] proposal). If you create a type=20
> attribute, then it could be used itself to implement (part of)=20
> secure_val.=20
>

true.
=20

>
> > If you delete a [[secret]] pointer, then the compiler needs to ensure=
=20
> every location is cleaned afterwards.=20
> >=20
> >>=20
> >> As a=20
> >> user, I would simply prefer to be able to mark my type T with=20
> >> [[secret]] and then *that* could be put into the heap. That is the=20
> >> reason I went for a template, because it looked natural to wrap values=
=20
> >> with it:=20
> >>=20
> >>   std::secure_val<int> my_very_secret_number;=20
> >>   std::secure_val<char [N]> my_private_key;=20
> >>=20
> >> etc.=20
> >=20
> >=20
> > The problem with your template approach is: you don't have the cascade=
=20
> of the secret property, so temporaries depending on your secure_val will=
=20
> not be cleaned.=20
>
> It depends. Note that the accesses to the secret value must go through=20
> access(). This is intended so that code inside that block may be=20
> treated specially by the compiler. The examples given in the proposal=20
> about how this can be used are encryption (compiler support not needed=20
> in principle), disabling speculation (compiler support needed), etc.=20
>

Your encryption use case actually needs compiler support if your compiler=
=20
is "smart" enough to duplicate your object location.
=20

>
> > Also, your template is not safely implementable in C++: you need=20
> cooperation from the compiler in the same way as with the attribute,=20
> because of the possible mutliple locations of your object.=20
> >=20
>
> Of course it isn't, that is the whole point of secure_val. :-)=20
>
> Let me put it this way: I would love secure_val to be implementable in=20
> C++ (or at least part of it, e.g. the auto-clear [[secret]] part that=20
> you are discussing). However, it is not clear yet how many things we=20
> would need to add to the language or how. Some things, like=20
> Spectre-class vulnerabilities, are still being researched. Therefore,=20
> I suggested secure_val first to make the most common use case=20
> concrete, and at the same time give developers a simple solution to=20
> it. Since secure_val does not force almost anything on the vendors=20
> (except the auto-clear), it can be updated to provide further=20
> guarantees as time goes on.=20
>

The auto-clear does require compiler support if you want a proper/safe=20
implementation of it.
But you're right: it can be done incrementally.
=20
Cheers,
Florian

--=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/171c3741-7ebf-4383-83eb-ed68b08b10b2%40isocpp.or=
g.

------=_Part_2039_335946979.1539094357450
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>Le mardi 9 octobre 2018 15:54:35 UTC+2, Miguel Oje=
da a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tue, =
Oct 9, 2018 at 2:56 PM &lt;<a href=3D"javascript:" target=3D"_blank" gdf-ob=
fuscated-mailto=3D"yXSXjqVgBAAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">floria...@gmail.com</a>&gt; wrote:
<br>&gt;
<br>&gt;
<br>&gt; Le mardi 9 octobre 2018 14:42:10 UTC+2, Miguel Ojeda a =C3=A9crit =
:
<br>&gt;&gt;
<br>&gt;&gt; Hi Florian,
<br>&gt;&gt;
<br>&gt;&gt; On Tue, Oct 9, 2018 at 2:24 PM &lt;<a>floria...@gmail.com</a>&=
gt; wrote:
<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt; For your second point, I didn&#39;t think about it yet. S=
o I didn&#39;t take it into consideration when I proposed the [[undead]] at=
tribute. But if your goal is security, then you would also need to take int=
o consideration this.
<br>&gt;&gt; &gt; Let&#39;s imagine an attribute [[secret]].
<br>&gt;&gt; &gt; Every object marked as [[secret]] will be cleaned before =
function exit.
<br>&gt;&gt; &gt; This cleaning means set to zero every location that still=
 contains the object (known to the compiler).
<br>&gt;&gt;
<br>&gt;&gt; This sounds very similar to secure_val, but as a variable attr=
ibute.
<br>&gt;
<br>&gt;
<br>&gt; Yes it is similar. But I think attribute is more appropriate becau=
se those security issues are not about C++: in order to read a destroyed va=
lue, you need to use undefined behavior somehow.
<br>&gt;
<br>
<br>I am not sure what you mean by &quot;are not about C++&quot; or by &quo=
t;reading a
<br>destroyed value&quot;. Do you mean you want to have compiler support so
<br>that other languages (like C) can take advantage of it?
<br></blockquote><div><br></div><div>No, I mean these security issues arise=
 beyond the scope of C++.</div><div>As far as C++ is concerned, you cannot =
access a destroyed value (so the secret remains secret).</div><div>Any atte=
mpt in doing that leads to undefined behaviours: meaning the result does no=
t depends on C++ semantic anymore.</div><div>So if every single undefined b=
ehavior would crash the program instant (which is actually valid), there wo=
uld be no secret leaking issue at all.</div><div><br></div><div>That&#39;s =
what I mean when I say it is not about C++.</div><div><br></div><div>I don&=
#39;t necessarily want to have it for other languages (but it would be good=
 if we do).<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;">
<br>Note that there are C++-only attributes; and that, anyway, it would be
<br>nice to have a concrete use case (e.g. secure_val) where such features
<br>could be used.
<br>
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; &gt; Also, in order to not deduce the secret from other tempor=
aries, any value depending on a [[secret]] object is also marked implicitly=
 as [[secret]].
<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt; This does not address cache persistency, but it can be co=
vered if the [[secret]] can take an optional argument to ensure cache lines=
 related to this object are flushed (done by the compiler).
<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt; With this, you start to have a pretty strong security pla=
n for stack objects. But the heap objects cannot be marked as secret. So fo=
r that, maybe you could mark the delete statement as [[secret]] and let the=
 compiler do the same thing for heap objects.
<br>&gt;&gt;
<br>&gt;&gt; I would say users should not care where or how the value is st=
ored.
<br>&gt;&gt; Having to mark delete statements with an attribute seems odd.
<br>&gt;
<br>&gt;
<br>&gt; The problem is, when you create an object on the heap, on don&#39;=
t really own the object. that&#39;s why it needs a special treatment.
<br>&gt; Maybe marking the pointer type as [[secret]] could solve the issue=
..
<br>
<br>Yes, exactly, that is why secure_val is a template: in my view, it has
<br>to be applied the type; not on statements (Daniel&#39;s original propos=
al)
<br>or variables (your initial [[secret]] proposal). If you create a type
<br>attribute, then it could be used itself to implement (part of)
<br>secure_val.
<br></blockquote><div><br></div><div>true.<br></div><div>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;">
<br>&gt; If you delete a [[secret]] pointer, then the compiler needs to ens=
ure every location is cleaned afterwards.
<br>&gt;
<br>&gt;&gt;
<br>&gt;&gt; As a
<br>&gt;&gt; user, I would simply prefer to be able to mark my type T with
<br>&gt;&gt; [[secret]] and then *that* could be put into the heap. That is=
 the
<br>&gt;&gt; reason I went for a template, because it looked natural to wra=
p values
<br>&gt;&gt; with it:
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 std::secure_val&lt;int&gt; my_very_secret_number;
<br>&gt;&gt; =C2=A0 std::secure_val&lt;char [N]&gt; my_private_key;
<br>&gt;&gt;
<br>&gt;&gt; etc.
<br>&gt;
<br>&gt;
<br>&gt; The problem with your template approach is: you don&#39;t have the=
 cascade of the secret property, so temporaries depending on your secure_va=
l will not be cleaned.
<br>
<br>It depends. Note that the accesses to the secret value must go through
<br>access(). This is intended so that code inside that block may be
<br>treated specially by the compiler. The examples given in the proposal
<br>about how this can be used are encryption (compiler support not needed
<br>in principle), disabling speculation (compiler support needed), etc.
<br></blockquote><div><br></div><div>Your encryption use case actually need=
s compiler support if your compiler is &quot;smart&quot; enough to duplicat=
e your object location.<br></div><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;">
<br>&gt; Also, your template is not safely implementable in C++: you need c=
ooperation from the compiler in the same way as with the attribute, because=
 of the possible mutliple locations of your object.
<br>&gt;
<br>
<br>Of course it isn&#39;t, that is the whole point of secure_val. :-)
<br>
<br>Let me put it this way: I would love secure_val to be implementable in
<br>C++ (or at least part of it, e.g. the auto-clear [[secret]] part that
<br>you are discussing). However, it is not clear yet how many things we
<br>would need to add to the language or how. Some things, like
<br>Spectre-class vulnerabilities, are still being researched. Therefore,
<br>I suggested secure_val first to make the most common use case
<br>concrete, and at the same time give developers a simple solution to
<br>it. Since secure_val does not force almost anything on the vendors
<br>(except the auto-clear), it can be updated to provide further
<br>guarantees as time goes on.
<br></blockquote><div><br></div><div>The auto-clear does require compiler s=
upport if you want a proper/safe implementation of it.</div><div>But you&#3=
9;re right: it can be done incrementally.<br></div><div>=C2=A0</div><div>Ch=
eers,</div><div>Florian<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/171c3741-7ebf-4383-83eb-ed68b08b10b2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/171c3741-7ebf-4383-83eb-ed68b08b10b2=
%40isocpp.org</a>.<br />

------=_Part_2039_335946979.1539094357450--

------=_Part_2038_367397919.1539094357450--

.

On Tue, Oct 9, 2018 at 4:12 PM <florian.csdt@gmail.com> wrote:
>
> Le mardi 9 octobre 2018 15:54:35 UTC+2, Miguel Ojeda a =C3=A9crit :
>>
>> I am not sure what you mean by "are not about C++" or by "reading a
>> destroyed value". Do you mean you want to have compiler support so
>> that other languages (like C) can take advantage of it?
>
> No, I mean these security issues arise beyond the scope of C++.

Agreed, but I am not following what you mean by that (see below).

> As far as C++ is concerned, you cannot access a destroyed value (so the s=
ecret remains secret).
> Any attempt in doing that leads to undefined behaviours: meaning the resu=
lt does not depends on C++ semantic anymore.
> So if every single undefined behavior would crash the program instant (wh=
ich is actually valid), there would be no secret leaking issue at all.

This is not only about code in the same process reading an old value
(the undefined behavior that I suspect you are talking about). You
also have other things, like core dumps, external agents... Of course,
all outside the scope of C++ in that sense.

In any case, regardless of that, I am not sure why you said "I think
attribute is more appropriate because those security issues are not
about C++". How is that related to this being implemented as an
attribute or not?

>
> That's what I mean when I say it is not about C++.
>

Agreed.

> I don't necessarily want to have it for other languages (but it would be =
good if we do).

Ditto.

>
>>
>> It depends. Note that the accesses to the secret value must go through
>> access(). This is intended so that code inside that block may be
>> treated specially by the compiler. The examples given in the proposal
>> about how this can be used are encryption (compiler support not needed
>> in principle), disabling speculation (compiler support needed), etc.
>
>
> Your encryption use case actually needs compiler support if your compiler=
 is "smart" enough to duplicate your object location.
>

That is why I said "in principle" :-)

>>
>>
>> > Also, your template is not safely implementable in C++: you need coope=
ration from the compiler in the same way as with the attribute, because of =
the possible mutliple locations of your object.
>> >
>>
>> Of course it isn't, that is the whole point of secure_val. :-)
>>
>> Let me put it this way: I would love secure_val to be implementable in
>> C++ (or at least part of it, e.g. the auto-clear [[secret]] part that
>> you are discussing). However, it is not clear yet how many things we
>> would need to add to the language or how. Some things, like
>> Spectre-class vulnerabilities, are still being researched. Therefore,
>> I suggested secure_val first to make the most common use case
>> concrete, and at the same time give developers a simple solution to
>> it. Since secure_val does not force almost anything on the vendors
>> (except the auto-clear), it can be updated to provide further
>> guarantees as time goes on.
>
>
> The auto-clear does require compiler support if you want a proper/safe im=
plementation of it.

I am confused: that is what I said, no?

By the way, to avoid confusion: the [[secret]] portion of the
auto-clear requires compiler support. The simple part of zero'ing
memory on destruction (in the sense of calling a secure clear function
that is not optimized away) can be done --- even if as a
workaround/hack --- without compiler support (as some projects/OSs
implement already).

Cheers,
Miguel

--=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/CANiq72m6M2YY50UGGKnr4GD7VXtS7isG1nQHh9MhKHFbG97=
bJw%40mail.gmail.com.

.

On Tue, Oct 09, 2018 at 07:29:52AM -0300, Daniel Gutson wrote:
> El mar., 9 oct. 2018 3:22, Magnus Fromreide <magfr@lysator.liu.se> escrib=
i=C3=B3:
>=20
> > On Mon, Oct 08, 2018 at 12:02:59PM -0700, Andrew Giese wrote:
> > > What about using [[nodiscard]] as a null-statement?
> > >
> > > Similar to how [[fallthrough]] is a null statement intended to indica=
te
> > to
> > > the compiler and reader that the fallthrough is intentional, a
> > > [[nodiscard]] after an assignment or a memset should indicate that th=
e
> > > previous statement was intentional and should not be discarded.
> > >
> > > e.g.
> > >
> > > memset(password, 0, PASSWORD_SIZE);
> > > [[nodiscard]]; // intentionally store before a free
> > > free(password);
> >
> > I think the use of an attribute for this purpose is problematic.
> >
> > The first reason is the good old attributes may be ignored argument - t=
his
> > means that if a compiler ain't supporting this attribute then the resul=
ting
> > code is broken, no diagnostic allowed.
> >
>=20
> What would exactly broken mean here?
>=20

It would mean that you can't detect if your compiler supports the feature y=
ou
are asking for in any way and that might be surprising for users that expec=
t
the clearing of the values to happen but instead they end upp with their
secrets still in memory, i.e. the same situation as today but worse.

>=20
> > The second reason is that what is cared about here is the values. If th=
e
> > compiler is told that the value is used after the memset then it won't
> > remove it so I think something like
> >
> > void use(T) { }
> >
> > and
> >
> > void use(T*, size_t) { }
> >
> >
> > but somehow marked to tell the compiler that the argument passed is
> > used so you better don't optimize it away is more useful.
> >
> > memset(password, 0, PASSWORD_SIZE);
> > use(password, PASSWOD_SIZE);
> >
>=20
> This may allow
>   use(password, PASSWORD_SIZE-1)
> or
>   use(password+1, ...)
>  for example.

True, but I expect this usage to be rare and you can write ugly code in all
languages (see below).

> We don't want to mess the value tracker that way.

I also think it is good to be explicit about what walue it is you are talki=
ng
about, consider

memset(foo1, 0, sizeof(foo1)), memset(&foo2, 0, sizeof(foo2));
[[nodiscard]];

Does nodiscard apply to foo1, *foo1, foo2 or some combination of them?

/MF

> I stick to the attribute version.
> See my related answer below to Miguel Ojeda.
>=20
>=20
> free(password);
> >
> > /MF
> >
> > >
> > >
> > > On Sunday, October 7, 2018 at 9:47:37 AM UTC-5, Daniel Gutson wrote:
> > > >
> > > >
> > > >
> > > > El dom., 7 oct. 2018 6:17, <floria...@gmail.com <javascript:>>
> > escribi=C3=B3:
> > > >
> > > >>
> > > >>
> > > >> Le dimanche 7 octobre 2018 06:44:28 UTC+2, Daniel Gutson a =C3=A9c=
rit :
> > > >>>
> > > >>>
> > > >>>
> > > >>> 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 are
> > proposing
> > > >>>> is compatible with the current language.
> > > >>>> I just wanted to highlight that it might be misleading to have t=
he
> > same
> > > >>>> attribute with different meaning when it is used on a function
> > declaration,
> > > >>>> or on an expression (a declaration is also a statement).
> > > >>>>
> > > >>>> Also, after some thinking, in this case, the goal is not to forc=
e
> > the
> > > >>>> last assignment, but to force the last 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 accessed after its
> > lifetime end
> > > >>>> and so the last assignment should be kept and propagated to ever=
y
> > storage
> > > >>>> of the object:
> > > >>>>
> > > >>>> void f() {
> > > >>>>   [[undead]] int secret;
> > > >>>>   /* ... */
> > > >>>>   secret =3D 0;
> > > >>>> }
> > > >>>> That wouldn't mean the lifetime of the object is extended and it
> > > >>>> becomes valid to access it afterwards.
> > > >>>> It would tell the compiler it should behave as-if the object
> > *could*
> > > >>>> be accessed afterwards.
> > > >>>>
> > > >>>
> > > >>> Actually I would like to tell the compiler that the object should
> > NOT be
> > > >>> accessible afterwards.
> > > >>>
> > > >>
> > > >> What I said is not "the compiler makes the object accessible", but
> > > >> "whatever the compiler will do, the object will remain accessible
> > somehow,
> > > >> and so the correctness of the whole program depends on the last va=
lue
> > not
> > > >> being discarded".
> > > >>
> > > >> Your view is also correct, but a bit more magic: when this "destro=
y
> > all
> > > >> the places where the object is" is performed? (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 matter of taste at this point.
> > > >>
> > > >> However, your first proposal doesn't work that well: ok you tell t=
he
> > > >> compiler to keep the assignment. But which location is used for th=
is
> > > >> assignment? All of them? The last one? The main one? A new one?
> > > >> And if you start standardizing which location should be assigned,
> > then
> > > >> you're not talking about expressions anymore, but about objects. S=
o
> > > >> attributes on expressions is not the right tool for you.
> > > >>
> > > >>
> > > >>> Additionally I would like to reuse the existing attribute name,
> > though
> > > >>> this is of least importance now.
> > > >>>
> > > >>>
> > > >>
> > > >> Here, I completely disagree.
> > > >>
> > > >
> > > > Ok let's not discuss this.
> > > >
> > > > It should not be an already existing attribute name unless the feat=
ure
> > is
> > > >> close enough to the original attribute.
> > > >> And the new meaning you proposed is (at least for me)  too far fro=
m
> > the
> > > >> original, and is misleading.
> > > >>
> > > >> An attribute is not a keyword, it is easy to create new ones (easi=
er
> > than
> > > >> repurposing an old one?).
> > > >>
> > > >> --
> > > >> 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-proposal...@isocpp.org <javascript:>.
> > > >> To post to this group, send email to std-pr...@isocpp.org
> > <javascript:>.
> > > >> To view this discussion on the web visit
> > > >>
> > https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/dba0bf6d-9=
2da-440e-8e61-af336cacd537%40isocpp.org
> > > >> <
> > https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/dba0bf6d-9=
2da-440e-8e61-af336cacd537%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter
> > >
> > > >> .
> > > >>
> > > >
> > >
> > > --
> > > 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, sen=
d
> > 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/c35b213e-c=
bfd-41e2-a8dd-e5cf93343b8c%40isocpp.org
> > .
> >
> > --
> > You received this message because you are subscribed to the Google Grou=
ps
> > "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/2018100906=
2157.GA4566%40noemi.bahnhof.se
> > .
> >
>=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=
 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/isoc=
pp.org/d/msgid/std-proposals/CAFdMc-0wY9Qs8hS%2B2UpeqKY-NkZ2edcrfcLW4Jt8Upa=
hXxOLZg%40mail.gmail.com.

--=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/20181009221354.GA8206%40noemi.bahnhof.se.

.

------=_Part_2573_1166269384.1539150916511
Content-Type: multipart/alternative;
 boundary="----=_Part_2574_2092616877.1539150916512"

------=_Part_2574_2092616877.1539150916512
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tuesday, October 9, 2018 at 3:13:59 PM UTC-7, Magnus Fromreide wrote:
>
> On Tue, Oct 09, 2018 at 07:29:52AM -0300, Daniel Gutson wrote:=20
> > El mar., 9 oct. 2018 3:22, Magnus Fromreide <ma...@lysator.liu.se=20
> <javascript:>> escribi=C3=B3:=20
> >=20
> > > On Mon, Oct 08, 2018 at 12:02:59PM -0700, Andrew Giese wrote:=20
> > > > What about using [[nodiscard]] as a null-statement?=20
> > > >=20
> > > > Similar to how [[fallthrough]] is a null statement intended to=20
> indicate to=20
> > > > the compiler and reader that the fallthrough is intentional, a=20
> > > > [[nodiscard]] after an assignment or a memset should indicate that=
=20
> the=20
> > > > previous statement was intentional and should not be discarded.=20
> > > >=20
> > > > e.g.=20
> > > >=20
> > > > memset(password, 0, PASSWORD_SIZE);=20
> > > > [[nodiscard]]; // intentionally store before a free=20
> > > > free(password);=20
> > >=20
> > > I think the use of an attribute for this purpose is problematic.=20
> > >=20
> > > The first reason is the good old attributes may be ignored argument -=
=20
> this=20
> > > means that if a compiler ain't supporting this attribute then the=20
> resulting=20
> > > code is broken, no diagnostic allowed.=20
> >=20
> > What would exactly broken mean here?=20
>
> It would mean that you can't detect if your compiler supports the feature=
=20
> you=20
> are asking for in any way and that might be surprising for users that=20
> expect=20
> the clearing of the values to happen but instead they end up with their=
=20
> secrets still in memory, i.e. the same situation as today but worse.=20
>
=20
FWIW, I must disagree narrowly with this reasoning. I myself do tend to=20
think this way, but I think the Committee (rightly) tends to take the long=
=20
view =E2=80=94 if it's a feature we really need, then it's better to suffer=
 a few=20
years of incomplete support in order to improve the lives of programmers=20
five or ten years down the road.
I concur with your opinion, though, that this "nodiscard statement" is *not=
*=20
something that we really need, at least not in this ill-specified and=20
ill-motivated form.

=20

> > > memset(password, 0, PASSWORD_SIZE);=20
> > > use(password, PASSWOD_SIZE);=20
> >=20
> > This may allow=20
> >   use(password, PASSWORD_SIZE-1)=20
> > or=20
> >   use(password+1, ...)=20
> >  for example.
> > We don't want to mess the value tracker that way.=20
>
> I also think it is good to be explicit about what walue it is you are=20
> talking=20
> about, consider=20
>
> memset(foo1, 0, sizeof(foo1)), memset(&foo2, 0, sizeof(foo2));=20
> [[nodiscard]];=20
>
> Does nodiscard apply to foo1, *foo1, foo2 or some combination of them?=20
>

This "nodiscard statement" idea is actually already implemented in=20
compilers today, with a much more sensible syntax. It's used in Google=20
Benchmark, for example. They spell it benchmark::ClobberMemory(), and the=
=20
implementation is in terms of a no-op "volatile __asm__" statement.=20
Programmers who need this sort of thing today should definitely be aware of=
=20
ClobberMemory().

https://github.com/google/benchmark#preventing-optimisation

This will avoid removing memset's "writes" to "memory"; but of course that=
=20
doesn't matter to the security angle, unless you're working on hardware=20
where you personally know what "write" and "memory" actually mean. (I doubt=
=20
many participants in this discussion are working on such platforms; and if=
=20
they are, they aren't concerned about security in this sense.)

=E2=80=93Arthur

--=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/47e783a1-ed11-4c62-be5f-065873b8e4aa%40isocpp.or=
g.

------=_Part_2574_2092616877.1539150916512
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, October 9, 2018 at 3:13:59 PM UTC-7, Magnus Fr=
omreide wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tue, Oct 09, =
2018 at 07:29:52AM -0300, Daniel Gutson wrote:
<br>&gt; El mar., 9 oct. 2018 3:22, Magnus Fromreide &lt;<a href=3D"javascr=
ipt:" target=3D"_blank" gdf-obfuscated-mailto=3D"TbSKo5ScAgAJ" rel=3D"nofol=
low" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=
=3D"this.href=3D&#39;javascript:&#39;;return true;">ma...@lysator.liu.se</a=
>&gt; escribi=C3=B3:
<br>&gt;=20
<br>&gt; &gt; On Mon, Oct 08, 2018 at 12:02:59PM -0700, Andrew Giese wrote:
<br>&gt; &gt; &gt; What about using [[nodiscard]] as a null-statement?
<br>&gt; &gt; &gt;
<br>&gt; &gt; &gt; Similar to how [[fallthrough]] is a null statement inten=
ded to indicate=C2=A0to
<br>&gt; &gt; &gt; the compiler and reader that the fallthrough is intentio=
nal, a
<br>&gt; &gt; &gt; [[nodiscard]] after an assignment or a memset should ind=
icate that the
<br>&gt; &gt; &gt; previous statement was intentional and should not be dis=
carded.
<br>&gt; &gt; &gt;
<br>&gt; &gt; &gt; e.g.
<br>&gt; &gt; &gt;
<br>&gt; &gt; &gt; memset(password, 0, PASSWORD_SIZE);
<br>&gt; &gt; &gt; [[nodiscard]]; // intentionally store before a free
<br>&gt; &gt; &gt; free(password);
<br>&gt; &gt;
<br>&gt; &gt; I think the use of an attribute for this purpose is problemat=
ic.
<br>&gt; &gt;
<br>&gt; &gt; The first reason is the good old attributes may be ignored ar=
gument - this
<br>&gt; &gt; means that if a compiler ain&#39;t supporting this attribute =
then the resulting
<br>&gt; &gt; code is broken, no diagnostic allowed.
<br>&gt;=20
<br>&gt; What would exactly broken mean here?
<br><br>It would mean that you can&#39;t detect if your compiler supports t=
he feature you
<br>are asking for in any way and that might be surprising for users that e=
xpect
<br>the clearing of the values to happen but instead they end up with their
<br>secrets still in memory, i.e. the same situation as today but worse.
<br></blockquote><div>=C2=A0</div><div>FWIW, I must disagree narrowly with =
this reasoning. I myself do tend to think this way, but I think the Committ=
ee (rightly) tends to take the long view =E2=80=94 if it&#39;s a feature we=
 really need, then it&#39;s better to suffer a few years of incomplete supp=
ort in order to improve the lives of programmers five or ten years down the=
 road.</div><div>I concur with your opinion, though, that this &quot;nodisc=
ard statement&quot; is <i>not</i> something that we really need, at least n=
ot in this ill-specified and ill-motivated form.</div><div><br></div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; &gt; memset(p=
assword, 0, PASSWORD_SIZE);
<br>&gt; &gt; use(password, PASSWOD_SIZE);
<br>&gt;=20
<br>&gt; This may allow
<br>&gt; =C2=A0 use(password, PASSWORD_SIZE-1)
<br>&gt; or
<br>&gt; =C2=A0 use(password+1, ...)
<br>&gt; =C2=A0for example.<br>&gt; We don&#39;t want to mess the value tra=
cker that way.
<br>
<br>I also think it is good to be explicit about what walue it is you are t=
alking
<br>about, consider
<br>
<br>memset(foo1, 0, sizeof(foo1)), memset(&amp;foo2, 0, sizeof(foo2));
<br>[[nodiscard]];
<br>
<br>Does nodiscard apply to foo1, *foo1, foo2 or some combination of them?
<br></blockquote><div><br></div><div>This &quot;nodiscard statement&quot; i=
dea is actually already implemented in compilers today, with a much more se=
nsible syntax. It&#39;s used in Google Benchmark, for example. They spell i=
t <font face=3D"courier new, monospace">benchmark::ClobberMemory()</font>, =
and the implementation is in terms of a no-op &quot;volatile __asm__&quot; =
statement. Programmers who need this sort of thing today should definitely =
be aware of <font face=3D"courier new, monospace">ClobberMemory()</font>.</=
div><div><br></div><div><a href=3D"https://github.com/google/benchmark#prev=
enting-optimisation">https://github.com/google/benchmark#preventing-optimis=
ation</a><br></div><div><br></div><div>This will avoid removing memset&#39;=
s &quot;writes&quot; to &quot;memory&quot;; but of course that doesn&#39;t =
matter to the security angle, unless you&#39;re working on hardware where y=
ou personally know what &quot;write&quot; and &quot;memory&quot; actually m=
ean. (I doubt many participants in this discussion are working on such plat=
forms; and if they are, they aren&#39;t concerned about security in this se=
nse.)</div><div><br></div><div>=E2=80=93Arthur</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/47e783a1-ed11-4c62-be5f-065873b8e4aa%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/47e783a1-ed11-4c62-be5f-065873b8e4aa=
%40isocpp.org</a>.<br />

------=_Part_2574_2092616877.1539150916512--

------=_Part_2573_1166269384.1539150916511--

.