220 38227 <420b274b-fc4b-413e-8ce9-b78131c782f7@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Niall Douglas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: memcpy/memset/etc overloads for volatile memory Date: Sun, 27 May 2018 16:09:29 -0700 (PDT) Lines: 111 Approved: news@gmane.org Message-ID: <420b274b-fc4b-413e-8ce9-b78131c782f7@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_6048_49411746.1527462569626" X-Trace: blaine.gmane.org 1527462445 7082 195.159.176.226 (27 May 2018 23:07:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 27 May 2018 23:07:25 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDGKFT5YZADRBKXVVTMAKGQEPA6ZV2I@isocpp.org Mon May 28 01:07:20 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb0-f199.google.com ([209.85.213.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fN4ky-0001lh-GD for gclcip-std-proposals@m.gmane.org; Mon, 28 May 2018 01:07:20 +0200 Original-Received: by mail-yb0-f199.google.com with SMTP id b17-v6sf4831857ybk.19 for ; Sun, 27 May 2018 16:09:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=iuvzNxzNbqRfnF2Ustg4oI324NMtSFENp5mGVQ8d4xU=; b=fvPQxEsu/llYLfBmm/5zfFQMJBi8NXuSRhtHJMdCmL0xibalC+E227YzKeR+dUwpft PCTxYCJ+Afp+N2eRRdH3qO1VGCUVStJKaSr4316LGs6nZTlrJvbsY+qHty3EnBos1bTA TdAXX2iisrSnaZspxPhIDoYyv3y1KFJew/Vqn0hkaqDoyKANLEImtLYwe3JAaOM+A9ZI 3JQRsMz4Iu9V6RjvOn5bHzxmtR/oBtcMAn/Nkn29PNZDJh/nQTifyKcYAuHIPSX3in1K wnNth6pXhh+me2SRrNhXPrtBmAU1gi3ssQSYOeoApDsVe+Rrz1VAYZPUH53aYXfs5rUu qbPA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=iuvzNxzNbqRfnF2Ustg4oI324NMtSFENp5mGVQ8d4xU=; b=AtP+75Vjv5Fab+yo+YWS8oWmLlPNzWkJTzrrMH7Zwa+82iBpHncKSpfQTENuMG3Wuf B92j0IjQSOrrTi403dg0Vk+NkTFkP3zGUhev/lPqc/OlX+66Me8e6UYp+0m57YqpS/9a CxZqcMSaZUfyPhA7PnVdwas3na6hZucWpDXceO4fufGdYX12E4hOpi7/a+nAQi14UPKX 871rkmE+lNOjlZ5j9l5DS3AWUxRidbbas6ABgowjY5+WN5vNn1cA3UfjxPfsBxuZbiLl j/Jj6fyEIQVewTI+mFdyb+XKC0OqAGdIoQeDapv3PTNzM9COO0T8vmkkoIpXeJmiyRjl O5cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=iuvzNxzNbqRfnF2Ustg4oI324NMtSFENp5mGVQ8d4xU=; b=bVZqeSNlm2Z/Fxak25v+2r5W4r0WDv7FMzYcrcuHkt82m1VwePUWFvIEdC0355qhvL RYPB7IVGab6ZrqGa9uQauZ2S9usmSio3O5FNxf4HrRlNnskgu7xrLP+Vfvvr4tnxRbg6 KqasJsuGzL/Vsw4zYn9C0x+jGZ8x5mjgAMd6bc3MRPhUw8vw+8NukaxcsnQEo0jx+eZA Br/vdz1oljaHY6hpNIPtS+lYXcU4veeHDeqoF6a9jVxlnTIk42bU4lml8vmssrEsaGyJ HCWeIDitP838CHahV8i4RbtCM3nh9ODCbQI0bO48uOFs5n2slXnNDGwqMDA8nH2GX5KK IEvA== X-Gm-Message-State: ALKqPwfsPbdaQwVKxpVv2iFuiT7vLEAAgV0OJ3q29hGhGaTduvEqlE6r tzcIooZiFMh5PK1JSu/CfdbLGA== X-Google-Smtp-Source: AB8JxZqbaNgi2dWbvZzQFFANaMx3AvQZebVUwYbTUl80BMWwhX2YDUn8UxLF1ig2t80TbPkYjdcyPA== X-Received: by 2002:a81:5454:: with SMTP id i81-v6mr2972468ywb.16.1527462571459; Sun, 27 May 2018 16:09:31 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a25:b90e:: with SMTP id x14-v6ls5138344ybj.14.gmail; Sun, 27 May 2018 16:09:30 -0700 (PDT) X-Received: by 2002:a5b:7d1:: with SMTP id t17-v6mr345549ybq.0.1527462570356; Sun, 27 May 2018 16:09:30 -0700 (PDT) In-Reply-To: X-Original-Sender: nialldouglas14@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:38227 Archived-At: ------=_Part_6048_49411746.1527462569626 Content-Type: multipart/alternative; boundary="----=_Part_6049_1616913416.1527462569626" ------=_Part_6049_1616913416.1527462569626 Content-Type: text/plain; charset="UTF-8" On Friday, May 18, 2018 at 9:41:08 PM UTC+1, dgutson wrote: > > This might be interesting. > > In some systems, the implementation of memcpy() & friends cannot be used > for memory-mapped devices. > Usually, mapped memory is marked as volatile. > > I'm proposing to add volatile pointers overloads for the memcpy() function > and friends, without specifying exactly what should be different at the > standard-level, but allowing implementations to provide a particular > behavior. I'm just proposing to add the declaration to the standard. > > Just there this weekend I, yet again, had to write a custom memcpy() implementation because the built-in one can be elided by the compiler during optimisation. I'd like to stop having to write memcpy() personally. I think your idea has two variants: 1. Cannot be optimised out memcpy/memset/memmove etc. I'd suggest secure_memset(), secure_memcpy(), secure_memmove() and so on rather than editions taking a volatile pointer. 2. Said routines, but with additional std::memory_order parameter. With respect to your ideas about i/o, you can't do that yet with the current C++ memory model. There is no concept of making writes visible to main memory, or to i/o devices, in some sequential order in the current C++ standard. The current C++ memory model only speaks of visibility to threads of execution. It doesn't handle visibility to remote hardware, like network cards, hard drives, graphics cards etc. SG1 Concurrency are aware of this limitation, and may in the future decide to address it. I would be sure that well written papers are welcome on that topic. I'd certainly like to see papers land before WG21 proposing secure_*() functions, perhaps with overloads with std::memory_order parameter. The latter should be sent to SG1 I would suspect, the former could just go to LEWG. Niall -- 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/420b274b-fc4b-413e-8ce9-b78131c782f7%40isocpp.org. ------=_Part_6049_1616913416.1527462569626 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Friday, May 18, 2018 at 9:41:08 PM UTC+1, dgutson wrote= :
This might b= e interesting.

In some systems, the implementation of me= mcpy() & friends cannot be used for memory-mapped devices.
Us= ually, mapped memory is marked as volatile.

I'= m proposing to add volatile pointers overloads for the memcpy() function an= d friends, without specifying exactly what should be different at the stand= ard-level, but allowing implementations to provide a particular behavior. I= 'm just proposing to add the declaration to the standard.
Just there this weekend I, yet again, had to= write a custom memcpy() implementation because the built-in one can be eli= ded by the compiler during optimisation. I'd like to stop having to wri= te memcpy() personally.

I think your idea has two = variants:
  1. Cannot be optimised out memcpy/memset/memmove e= tc. I'd suggest secure_memset(), secure_memcpy(), secure_memmove() and = so on rather than editions taking a volatile pointer.
  2. Said routines= , but with additional std::memory_order parameter.
With respe= ct to your ideas about i/o, you can't do that yet with the current C++ = memory model. There is no concept of making writes visible to main memory, = or to i/o devices, in some sequential order in the current C++ standard. Th= e current C++ memory model only speaks of visibility to threads of executio= n. It doesn't handle visibility to remote hardware, like network cards,= hard drives, graphics cards etc.

SG1 Concur= rency are aware of this limitation, and may in the future decide to address= it. I would be sure that well written papers are welcome on that topic.

I'd certainly like to see papers land before WG2= 1 proposing secure_*() functions, perhaps with overloads with std::memory_o= rder parameter. The latter should be sent to SG1 I would suspect, the forme= r could just go to LEWG.

Niall

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/420b274b-fc4b-413e-8ce9-b78131c782f7= %40isocpp.org.
------=_Part_6049_1616913416.1527462569626-- ------=_Part_6048_49411746.1527462569626-- .