220 40258 article Path: news.gmane.org!.POSTED!not-for-mail From: Daniel Gutson Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: more security concerns Date: Fri, 28 Sep 2018 12:21:42 -0300 Lines: 568 Approved: news@gmane.org Message-ID: References: <94d79dd7-ba3b-4bf8-91ed-e5dc02b33670@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000ee228c0576f00391" X-Trace: blaine.gmane.org 1538147991 17554 195.159.176.226 (28 Sep 2018 15:19:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 28 Sep 2018 15:19:51 +0000 (UTC) To: std-proposals Original-X-From: std-proposals+bncBDE3NBMV6UFBBE4OXHOQKGQEGXFZFNQ@isocpp.org Fri Sep 28 17:19:47 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lj1-f199.google.com ([209.85.208.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g5uYT-0004RQ-HR for gclcip-std-proposals@m.gmane.org; Fri, 28 Sep 2018 17:19:45 +0200 Original-Received: by mail-lj1-f199.google.com with SMTP id 9-v6sf1857409lju.15 for ; Fri, 28 Sep 2018 08:21:56 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1538148116; cv=pass; d=google.com; s=arc-20160816; b=0tZyGlwwmWkMY5zGvB7t44uQDdiJIjsh2ZaOAIbWFo6WuHF8TEpfyZMKB37Iosbbyl FT1zzDn/yHbtw2I+4Qtrv89VTkhuHeOQ1WxfSWB9aslT21xMeUwSwmDPtCeTYOCVqUrY 3sqo3MgAQqCZwGT1fHzkviflr4qcpPjkSOKQsDZrmrKD/xqHpu2vTUFU7ahaYUaNETJj Wxi9D3zPJJV9jmTs68287wFkUA12O5EjsAACaMsM+9Kwztikq9knSZQ0Xo1cG2Nka0mB WbDoT7dFVqI0KOZHU0nBnYozj32IfwEr3fLHf3e6TzhYgIkzZuBTOtijWt5oFLXi2DdK Uutg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:in-reply-to:references:mime-version:dkim-signature; bh=SK+kMLiWH7y2AVrrnXWRGJZbB6iZBgOgEfsh4l/K5ZU=; b=revWv00JPm+qtVqsr3gDj/rcwOCKkIf7DxvGD2YFKLNUNQUTSTreOpnnotRnJ3hoTI 8ZIDvNTY7vlD8dVrV50u8whFMP/Dh8JnnZ7If95lIDuh8G6zYf2fnRvTdqNGNaPQBkso yirvBAYIgllMJEvhdkv/1W80ooHtv6BsT5M+hFmWqRNX2JyQRnkr57Mi0dR0fXW5cZDk BWMTS91YgA0xme2D/aKZw1vClU6Nr19u9Gj+7RrFQ9RW4HYeIUXrasLMyhsAOi6jIfjC Sv7RR38pcYO1JvbIy6Hygv7zLaf/aqDqSXFupzHg27lCQ8VyreA7R8YTg+Z33XuMw+rx gjEQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=LVRWRWma; spf=pass (google.com: domain of danielgutson@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=danielgutson@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=SK+kMLiWH7y2AVrrnXWRGJZbB6iZBgOgEfsh4l/K5ZU=; b=o7SKTpNO1IJ4MN3C0iqtESY9JXoe341iEKi7iioMulw0B4rIRk+r27RUEk2xFwdPqi vjnsQErcuWjDuv306HCNJGLDky9PknRM+UnJAPWOasa3dKFRuUdCTSAstL39fotY9c6j EJD1rQUg685oXxzdfXRSNa7GJnTJodh/rR4B+OOuLTj4mLC8SX1SwVZGWRQRWzkCp1NB E+6HyObiBvPHzsWalruuAPmNRotOA+9nmFazwCTubi4OK8n2gVVfL0FIYlg3V2Quwsu/ bZXZ7OA9sp5UFs8gnKeT2TC62lfvslnSo4R7+6fOOPLv0zD2fqmWmStBL0KFBvPze7b/ a86A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=SK+kMLiWH7y2AVrrnXWRGJZbB6iZBgOgEfsh4l/K5ZU=; b=Xpd2RjGagxHGRK9xkXcIi5h6qA59YGSBvbEAGWuMMRmJ4MGPWK84+EcCnzeWF3LGFA 1oRh/zQrAh70y+niMIGf2P5rA59Afw9/fxeWaYg3lCQrdy5ubLIhILc6J8OjbxbYoOtl ATjTMlJkF1Qj7gZ1VrX+kEJyMpdKE2VBULr78c3UL8EB09kCZlbJMXnRMG5iHB5r5t9k lC+vNLSaN/28zVC/5pDdmtLQyd29o6yFNkubse5zi7IrceV4pjG77aU00RtME57YSLpl /lwv530cyncsYwXAdFyZ97BMgzzvWyvAsJLdCgyXWRhvTNb8S/WgnpxF6lWBym5DOVmO l3QQ== X-Gm-Message-State: ABuFfoiTAjYnQvRT6CNur1lK3jezelO1K7srYAoecDokUPLnD0IZsWlv iI0BHFbpCM4F9dQ+KJmSfGv3yw== X-Google-Smtp-Source: ACcGV62RUqDuDlZiN+rL3Z2t9lfUMTh15AOw3SKSVUJUVvhfiJSJG4mcQdC+YJ7vH83niOxoHqCMQg== X-Received: by 2002:a19:d2d1:: with SMTP id j200-v6mr524669lfg.5.1538148116236; Fri, 28 Sep 2018 08:21:56 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a19:a405:: with SMTP id q5-v6ls715833lfc.21.gmail; Fri, 28 Sep 2018 08:21:54 -0700 (PDT) X-Received: by 2002:a19:2a12:: with SMTP id f18-v6mr10404958lfl.28.1538148114594; Fri, 28 Sep 2018 08:21:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538148114; cv=none; d=google.com; s=arc-20160816; b=EDsQUUTorY3T11oohEZTztz3IM23Uc9/ZIt7fsasoyG9sbxrkHM7RU9XPKOjbb0xFF gIDemIi3PXF7NhOxp6PzRbiSy7JO4fbYG7aTkSDdTh6E99s1Mh6YPO9yQCYteVj2RBQ6 eL3DGu3ru1fLBYuwImD8BO4M0t5N/9Dtt7fZCKNQi4Kd4H0hDS4IVeU+CqrKUu+fitRi jehs9rAJA5lKeVcxY8uQCRPCN+hNbTukcb87QRxKnZ26/45UJkgIjYoFi+sb1v9DCVmh zYQoxlAEtAcYRuSjaaGVz/mXHj8+4StoFd6Lrid83mCbVNPVkEzeghrDPEVsMp2mMsBi 7w7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=OKKQc2L//HF11ar5mWTOUERzCsy3Y1ekXdZFAVzmfbY=; b=IMee7fWqMG9hxnxYxVTH5Y0uGLUneckPDyCfJw046flZNMrnHcDB2xZlr/1to5BPte paTROccMdyPiqnR+mWriK72dN3BL3dPcvRxcqSa5GVVM+wlEN7KrNYOnU6IfUUWL7YsE 51GRihlILg3ipstLwAk6esaI2JWoi2N0ErbubQRHiqE9DTVyoSrQqpKqy3/3msXsB3fl 5aL76V4RLQKCDiKhWgLHPdDuUe4Iy0Kf6czDBdu21tX8ywvV56ypeW0j6Iy9ng1Qcwoi EcS7BgTU/EQGWnorA4c4Sc9y3y9v+beps3diKY9EQ7/m7wAc2/82+IRqwumqhYgRByH+ fAzw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=LVRWRWma; spf=pass (google.com: domain of danielgutson@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=danielgutson@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id 77-v6sor2159018lfr.17.2018.09.28.08.21.54 for (Google Transport Security); Fri, 28 Sep 2018 08:21:54 -0700 (PDT) Received-SPF: pass (google.com: domain of danielgutson@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 2002:a19:1588:: with SMTP id 8-v6mr11259850lfv.36.1538148113718; Fri, 28 Sep 2018 08:21:53 -0700 (PDT) In-Reply-To: X-Original-Sender: danielgutson@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=LVRWRWma; spf=pass (google.com: domain of danielgutson@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=danielgutson@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:40258 Archived-At: --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 > wrote: > >> >> >> El vie., 28 de sep. de 2018 a la(s) 11:36, >> 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, 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 >>>>>> 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 >>>>>>> >>>>>>> . >>>>>>> >>>>>> -- >>>>> 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 >>>>> >>>>> . >>>>> >>>> -- >>> 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 >>> >>> . >>> >> >> >> -- >> 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 >> >> . >> > -- > 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 > > . > --=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


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

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'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).
In no way I pretend to standar= dize optimizations in general nor DSE in particular. Otherwise then CSE wil= l arrive, etc.
=C2=A0

The name of the at= tribute will also be endlessly debated I'm sure. The existing attribute= s 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 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.

Regards
<= div dir=3D"auto">Andy


On Fri, Sep 28, 2018, 7:50 AM Daniel Guts= on <danielgu= tson@gmail.com> wrote:


El vie., 28= de sep. de 2018 a la(s) 11:36, <florian.csdt@gmail.com> escr= ibi=C3=B3:
I compl= etely understood what you meant, and yes what you are proposing is compatib= le with the current language.
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).

Also, after some thinking, in this case, the goal is no= t 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 = 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
=C2=A0
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 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:

void f() {
=C2=A0 [[und= ead]] int sec= ret;
=C2=A0 /* ... */
=C2=A0 secret =3D 0;=
}
That woul= dn't mean the lifetime of the object is extended and it becomes valid t= o access it afterwards.
It would tell the compiler it should behave as-i= f the object could be accessed afterwards.


Le vendredi 28= septembre 2018 16:18:12 UTC+2, Daniel Gutson a =C3=A9crit=C2=A0:


El vie., 28 sept. 2018 11:14, <floria...@gmail.com> escribi=C3=B3:
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't use the value.

= I'm proposing using [[nodiscard]] for statements rather than for declar= ations.
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.


So meaning would be different.
In that respect, another attribute name= might be better.

Also, it is already possible (but cumbersome) to i= mplement already without volatile:
void f(= ) {
=C2=A0 = int secret_int;
=C2=A0 float secret_float;
=C2=A0 /* ... */
= =C2=A0 secret_int =3D 0;
=C2=A0 secret_float =3D <= span style=3D"color:#066">0
=C2=A0 asm volatile ("&quo= t; ::"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=C2=A0:
Yeah.=C2=A0 But please note that this is= not only for function calls.

= void f()
{
=C2=A0 =C2=A0int s= ecret;
=C2=A0 =C2=A0....
=C2= =A0 =C2=A0secret =3D 0;=C2=A0 //removed due to DSE
}=

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'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= ..,=C2=A0https://www.fluentcp= p.com/2018/09/04/function-poisoning-in-cpp/

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

Contr= ol in that case is a little less granular, indeed. Probably if you're w= riting [[nodiscard]] on a per-expression basis you are not discarding the r= esult already.

Regards

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposal...@isocpp.or= g.
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-xMXo69n1D3dbOMkqt0fjLU44Uq5T= fABp17hQQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-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.

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-propo= sals/c71e2ca9-c5f4-4699-b2c1-b23245eef683%40isocpp.org.


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

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp.or= g/d/msgid/std-proposals/CAFdMc-3rNrze-AUW-FNy6S_FRdWt78LGJyDzDGQPXqsbgHnDoQ= %40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-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%2B2G4SDB1sSvm-Rw%40mail= ..gmail.com.


--
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 temperam= ent?
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 &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-2Bmpf6LM= 2b5MJtBtkSRtDOgFWCMM%3DMqMrviETNyRhN-A%40mail.gmail.com.
--000000000000ee228c0576f00391-- .