220 40402 <20181009062157.GA4566@noemi.bahnhof.se> article Path: news.gmane.org!.POSTED!not-for-mail From: Magnus Fromreide Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: more security concerns Date: Tue, 9 Oct 2018 08:21:57 +0200 Lines: 188 Approved: news@gmane.org Message-ID: <20181009062157.GA4566@noemi.bahnhof.se> 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: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1539065995 16175 195.159.176.226 (9 Oct 2018 06:19:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 9 Oct 2018 06:19:55 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDELLREETMBRBCES6HOQKGQENOAXV2Q@isocpp.org Tue Oct 09 08:19:51 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lj1-f200.google.com ([209.85.208.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g9lN1-00047Z-1a for gclcip-std-proposals@m.gmane.org; Tue, 09 Oct 2018 08:19:51 +0200 Original-Received: by mail-lj1-f200.google.com with SMTP id s7-v6sf184265ljh.3 for ; Mon, 08 Oct 2018 23:22:01 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1539066121; cv=pass; d=google.com; s=arc-20160816; b=qA8tM69CliAbhEgmYMtiegZwuyWmnMf7VFHeamEaFLDnbt72UAkCenH81XKpPFMLR+ aEhjWNOL8rpMg+OQcpw8/trAK6TGOZ3HmhaUrEDjV1WmM7RStuA8NHskF2sd0+Gp/4e3 bYhKN3+76HNBkC+Zolaz3CqmUp+dS+mNX+6DZBA7sK0mReHGK6nBBe40e9F4KfHp6rtV v2EYqROux/w6Y65QEfNbYDx4dyuulqyXyEsXijOAjlf8+mCixq3D2SyGJivyauVGhicM HzG4YKnI8t47DtwqyhTgxrKfquNnLBSMmm3no7LT5tf1OkvjW76SnBLWr+kWvesJf+vr vSRg== 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:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:mail-followup-to:message-id:subject:to:from:date :dkim-signature; bh=K0JTQV44gNefFXXYsvPrChiJ7rm2JAzjrloMPmel/5s=; b=JV8p4IAKkM8PtopKR93R7rlknRPiDepnSF7g7rfb6Grn8y3o21uYZ3WtIXRnqU8vYB 3Jf3Tzx6+rhTEvQgZ8PxMFn16xFLT0L/7DfCX0Z3unzhl/ql0Toljv2gTsodjqrRTn2d ZhV/t0DvHhvBxn7MWlmunUnHfxYCEuH2p8yGeq4+NThYIoitsYnHrA4nRh0iCz4bq+uC KER8ZgpfTCQ7bKl+D+pBKI3VyDIv30zaZGuUZLIFLzowNWFjBHSOFq2+vir4k44cZhnU cQpDITaxmyuxCOOU/qDEOoEJZLVSCh3JbF/llLg/geN3lvGpNArmAQMA+JuKpwwkL+w0 buUg== ARC-Authentication-Results: i=2; mx.google.com; spf=pass (google.com: domain of magfr@lysator.liu.se designates 2001:6b0:17:f0a0::3 as permitted sender) smtp.mailfrom=magfr@lysator.liu.se; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=liu.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent: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=K0JTQV44gNefFXXYsvPrChiJ7rm2JAzjrloMPmel/5s=; b=ySN/DTBGD6wGXlLcmaJWtoUlLHwBsFVuzRxsSC28e7MSBj2au2EmbriEpcQVz86kOc c6DZt7XmT0Fcj4HbX9yfaENUGcXMwAqUYzyG7P7mCz6wirvaUDAS4fJ2+FwN+LWFEt/4 nBTrzshHQMsH99lU1ryBP+9jGCUdr9sxj+jPutaXit0XPqizqP718nacjVqxPxLoNz4M g+Dh5wB7psjTMp9vt5jAG4RY74+pARKz1WvPcnsBn460mp4mKOhyJtd6QLjlA3BkJhmj OQYF6Bf8yjPypL5FNo0xqhgTdmSqH4XiEGqxvsPCOTol2e9mpC6 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent: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=K0JTQV44gNefFXXYsvPrChiJ7rm2JAzjrloMPmel/5s=; b=X2IRIExuszgWSG/AqCTPJRC2GHH/7BWik66qu70Te4GrqaJT2+r+7DsGfwZcfmTyNE hBnwEj2+tvlXICnZBvrkvQgtetF3DGZLHveUJ4pDMZmW+/kzm+0Dbjz9ZSM7xP8PpheD Zgf8578l/uIfAXuAiN1FqXqv0OjPTCw6BRX3h8MKIJz2QPE1tPfIOe4NoB6h/VYN0uxT n9XlFknvycCI5z5CRy4qFkdtqzsCS56wqbQrDghx6LxEo/eL4UcQ2aWmEgMb2oLbSnnV vfAXlXvN77/StksI0bqWEqz X-Gm-Message-State: ABuFfohoRlZuGdIj0Ch+/rCdcVa5Va7OLK+zsEmXRu7TijfYeiiRmbX3 njLlzSpncEkfgTEyF7KsDu6/Uw== X-Google-Smtp-Source: ACcGV60zJgpApSbRiID6EglLt4cFLkoU7wlaMxDCSmRqVHZ41gxfEnD6h0Eo0Z6ZuGusWv0znT5qbg== X-Received: by 2002:a19:6453:: with SMTP id b19-v6mr707749lfj.6.1539066121611; Mon, 08 Oct 2018 23:22:01 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a2e:7308:: with SMTP id o8-v6ls136254ljc.21.gmail; Mon, 08 Oct 2018 23:22:00 -0700 (PDT) X-Received: by 2002:a2e:b04b:: with SMTP id d11-v6mr8884328ljl.93.1539066120125; Mon, 08 Oct 2018 23:22:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539066120; cv=none; d=google.com; s=arc-20160816; b=DdCsIlRKNVpmVodBwpF1fSh9KlHiHXj7B5WQPyd8xhW59fLgPUHOhGab7fgVq91asE A2cQzmLs0Ts8lt4oF4D0KvWUq+pbjFqvA1IsRQ4R8P+qVoWm/Dy+pGnlIaFYjRhfoZka D3mv0mSUWLjr00epXspNBINbK66bNl+1PuABjseGfwic0q/TYEdkgLQ28dwgA1N9y7EN 4mItM8mhwMHueq7WnLj0euMiqFeGmlZKyPfkqDAgWDEMUQmMGQiabk8jFVD4AwY0H30D Oz6CYVS1b0ucrxmOYYvtKiUqEwUkD42vb2fOm0e2xcB1970mKaxjk2MD45D8Vdc8yNRp kQRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:mail-followup-to :message-id:subject:to:from:date; bh=mmqLT3INisazJgQgKM+3HXeRWde5v0XN9KpvbY7/djk=; b=VGXHpyxWrtVs2+efGuDXswatGMYHBy4YFBJpu2fEJXafRYDf754xt4/va8hNaYg84n w+oMIg/9cFCPPjl48G1T+PpIMSJnucRkFocyP0Q3tLRY2ggXm7SNZERNrL20SaSzgMtO RI2nJFYKDf9FEugmypSlGvU8TAgkjf2A67pfHyWLq0o48JaQAnjBs49c/MLvOYJL7iGl ZB5ECH0wv4EvBNtLestAlqGuiBLSpvYuYVzqrJwH7YN6v9OfwD0453Kfmjjv+HIWmYoG ixER2yyVcOlFkolimIviKHkZGoyq9TbvrmM93RLeO53ZpZczb7cKK3VDqlVZd4QIpA/T WQAQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of magfr@lysator.liu.se designates 2001:6b0:17:f0a0::3 as permitted sender) smtp.mailfrom=magfr@lysator.liu.se; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=liu.se Original-Received: from mail.lysator.liu.se (mail.lysator.liu.se. [2001:6b0:17:f0a0::3]) by mx.google.com with ESMTPS id q75-v6si12688269lfq.6.2018.10.08.23.22.00 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 08 Oct 2018 23:22:00 -0700 (PDT) Received-SPF: pass (google.com: domain of magfr@lysator.liu.se designates 2001:6b0:17:f0a0::3 as permitted sender) client-ip=2001:6b0:17:f0a0::3; Original-Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 674D240015 for ; Tue, 9 Oct 2018 08:21:59 +0200 (CEST) Original-Received: from noemi.bahnhof.se (h-155-4-131-135.NA.cust.bahnhof.se [155.4.131.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 3D1B340013 for ; Tue, 9 Oct 2018 08:21:59 +0200 (CEST) Mail-Followup-To: std-proposals@isocpp.org Content-Disposition: inline In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP X-Original-Sender: magfr@lysator.liu.se X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of magfr@lysator.liu.se designates 2001:6b0:17:f0a0::3 as permitted sender) smtp.mailfrom=magfr@lysator.liu.se; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=liu.se 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:40402 Archived-At: 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, > escribi= =C3=B3: > > > >> > >> > >> Le dimanche 7 octobre 2018 06:44:28 UTC+2, Daniel Gutson a =C3=A9crit = : > >>> > >>> > >>> > >>> El vie., 28 de sep. de 2018 a la(s) 11:36, =20 > >>> escribi=C3=B3: > >>> > >>>> I completely understood what you meant, and yes what you are 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 . > >> To post to this group, send email to std-pr...@isocpp.org . > >> To view this discussion on the web visit=20 > >> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/dba0bf6d-= 92da-440e-8e61-af336cacd537%40isocpp.org=20 > >> > >> . > >> > > >=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. .