220 38228 article Path: news.gmane.org!.POSTED!not-for-mail From: j c Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: memcpy/memset/etc overloads for volatile memory Date: Mon, 28 May 2018 01:02:37 +0100 Lines: 84 Approved: news@gmane.org Message-ID: References: <420b274b-fc4b-413e-8ce9-b78131c782f7@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000e41f37056d38d5b0" X-Trace: blaine.gmane.org 1527465632 9254 195.159.176.226 (28 May 2018 00:00:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 28 May 2018 00:00:32 +0000 (UTC) To: "std-proposals@isocpp.org" Original-X-From: std-proposals+bncBCR6HLXQUAORBHUOVXMAKGQEAQVYPII@isocpp.org Mon May 28 02:00:28 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f199.google.com ([209.85.161.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fN5aO-0002Kb-8k for gclcip-std-proposals@m.gmane.org; Mon, 28 May 2018 02:00:28 +0200 Original-Received: by mail-yw0-f199.google.com with SMTP id w8-v6sf1226851ywg.22 for ; Sun, 27 May 2018 17:02:39 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1527465759; cv=pass; d=google.com; s=arc-20160816; b=TAMaBmXwt1/eyJIqj8EWPkruWluRSdiWBkBkc3G6pRQkWpD4Q3TTJaYlK6p2RFCRXx XtIKsHsNxwVzZy+/Fm/TUz4pr3Da32k2X0c9KTL+cKU9RFdXVdHkuWB15zjvUqcnhz3K vZVyn2yVBImgDn/mHwj41HYrEBRC/aN+ap3Zpr2s9Ftu/cfo7ruBFOCIXpXihcUOa13t Qv8M5+Xp/Yi9QcGBcW5rTTXakjSrWKdBMBY1JCnJe7gHkoOh7ErSiNZ1pE5XkNrwcKhb MzaD535IrAal98Xn0VwH1PxU1GFGzw+XRUdsNT/gV9WBaxw6ZxyIXzF8jLCaQi0GtY87 XmPg== 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:references:in-reply-to:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=2OejqXqT/a2nJQNpo0obAf10s9lA6rOyel9VYdZtNFs=; b=vnbjOMP+HfzomlXUGpTMwrRTDImpgBxp8qICpwUhPQLBuO/HLsvTSOcEGAgMQnLzN/ fyMIB13yL+b6CCQJdYsasfs2FKKf/8QV5rHtadBbRCcf0zr1oPeN8AoKNLr8ALmTVJ93 TKZSaCwWG25Fc/taYdsyfTGWBrGY58iBFCd1nvUY7tP4tih8r4/CR5LV6Jc97nMrAsf9 x/yZcBZMv7y30cul6kp2MNVPd9iLFasHK51ahd4TfNJrWZnt9ott9nsrjQ3dWoDTYyT5 aBTbvA+AMQIVA7VaGvdVcPNxI48F4wdZS1E1w169s6ZZPXwHK4WXzvBzfTUdz12VQdFz qb1Q== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=kx93S12m; spf=pass (google.com: domain of james.a.cooper@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=james.a.cooper@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:in-reply-to:references: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=2OejqXqT/a2nJQNpo0obAf10s9lA6rOyel9VYdZtNFs=; b=aWpNyBsKlKa7q56n8/BteR7nB3krcrVcECHuPVFqzrFtRas2JbofszILSX+GCfeBNW 2tXvco7fSkTHnqBDPtDeMueYK8vncY9ZI2M9y+GdkVL3fm/yQ+6Hj4PYFrBdSQFhwyov tBshTla8o+EVpWesxZMM1aux7Q1oH0qTS6MS7xxTpLa/27rUlG6pUSRAImKyxfpcGhtM pd6I1INdM78+DUDLZTcUt8hsT7mbIDJ+jNGVUIwFeZeHW3goxwALF4cJM5444OyuEe+k JaWMi5QuyMFg71m4+YH0S5z1WhqAlJHwJ3y3naFo+III2FENAELQreBoAkYQjOUAu4uV i7Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references: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=2OejqXqT/a2nJQNpo0obAf10s9lA6rOyel9VYdZtNFs=; b=OV1SAi5APLHu/d5WjvGsYwZemWHfjTZTo7FD3E9sOkikRd3ntYDw98pfuVNHwxzw// Ae5mIrS6lDlFpeQjEbiQFt4vD1HiBnSlYchwuViRtfpMvTKriyyZKRncmQFwR8sPmAXC Bq8gcTlUPO6JyZBZrzEgOvh6K5VhdMyGDDFMNxoEVH9ExZeDCICYaYstjcpMbx+4fb8Q MK0/Ot3axg1VucaMlaJadJ/ka4U1Y2lVskhT/IMaX5sfoLvRPoR76JpaTLKZs/ZgRLU3 kZKmAiYEnKztLbfLXEyJai7tlFbgAuwnenC3yMA6RpSxQjjN6konwaWieFVCwn5eYAzD k7rQ== X-Gm-Message-State: ALKqPwdqOukEdca/F483DoMmPMthHLJCwaTXxO3T04m/aRoy3WE4X6se M8qURfzlfhyrqUStBWuHDPV9Tw== X-Google-Smtp-Source: ADUXVKL5CJfflEMcQl56hpP0fsGdfsdsZlbYAdhMd6aGesycTMxYDAnuQ0KrVXN0c9N70XLkTxmStw== X-Received: by 2002:a81:5f56:: with SMTP id t83-v6mr983732ywb.96.1527465759119; Sun, 27 May 2018 17:02:39 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:3753:: with SMTP id e80-v6ls644622ywa.43.gmail; Sun, 27 May 2018 17:02:38 -0700 (PDT) X-Received: by 2002:a0d:fb47:: with SMTP id l68-v6mr6094618ywf.446.1527465758049; Sun, 27 May 2018 17:02:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527465758; cv=none; d=google.com; s=arc-20160816; b=zQxMns2V4lek9uNPrx/bTzFJLNBZsp0rOuZE9oNfRwGfW5/V+pMCOaMjna/CA6mvld 2OVmJ3oukMSyo/xoeUC5Ce0HNe/FU4VQC77LiSIp/ojwSYkVHH05q03jVX/q13lueFp4 pugP4/iiGHL8mPaJDBYQzBrQi2R3KpUSChMlzmoIoRJd7GpxwYXJ3cL1ThPZDZvflnB5 XIF3QS1pc/hLFuRQI9ZwBt9gefhabtkOmxGvNAXbB8GaGonlnZQFg+zFzSK5+D+W0auZ E5Gkim5D0AM+YuDHt5nfZBXzb68x+gShfj/U8IqCSUfQu+U/rGypahRNx0Wxt/uXP9JM VsrQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=pAkY2dkPZrAO3Uf8pqqOZeley79a48PIacyvgoYc4IU=; b=aIG+AJPwalsF6PYVTolr9fCC8MSGR3hOCsxPzQsvWbgIwm8UVCKho+FiqutT34hUy5 bHbM2vau8b/DV2iTnuo7n2+r7C/LLT+hxMPulYbY2ZIq5BOWpLSXNG9ZllA7dFP/5c1q fAP4MmhOskM5c/Gvbe9Jr/Qdp3SOcXy7I1CYmo9o3KUb6L73jKESiyDoLcA7EIWgyaGC qf5cWoorSFBmUk9HBySLDxcU84SkIpuveGqd5b2PY4Rm34MhWUQeCkFagABcmp20Xol3 4aiXlx2ShlxhK8SONo6d64mj3EzHsKli3zpEjDRDnue9A+BlR9Yfghjfg2bGPaRZpumR a1eA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=kx93S12m; spf=pass (google.com: domain of james.a.cooper@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=james.a.cooper@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id m84-v6sor8214782ybb.143.2018.05.27.17.02.38 for (Google Transport Security); Sun, 27 May 2018 17:02:38 -0700 (PDT) Received-SPF: pass (google.com: domain of james.a.cooper@gmail.com designates 209.85.220.65 as permitted sender) client-ip=209.85.220.65; X-Received: by 2002:a25:c8c3:: with SMTP id y186-v6mr6160633ybf.496.1527465757644; Sun, 27 May 2018 17:02:37 -0700 (PDT) Original-Received: by 2002:a25:ba04:0:0:0:0:0 with HTTP; Sun, 27 May 2018 17:02:37 -0700 (PDT) In-Reply-To: <420b274b-fc4b-413e-8ce9-b78131c782f7@isocpp.org> X-Original-Sender: james.a.cooper@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=kx93S12m; spf=pass (google.com: domain of james.a.cooper@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=james.a.cooper@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:38228 Archived-At: --000000000000e41f37056d38d5b0 Content-Type: text/plain; charset="UTF-8" On Monday, May 28, 2018, Niall Douglas wrote: > 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 > > Or just stop compilers from doing daft things -- 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/CAFQaeCD83_FBX4cAE%2B9AAEHai4ciCeOaorHY1K94k_Yb0e9wnA%40mail.gmail.com. --000000000000e41f37056d38d5b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Monday, May 28, 2018, Niall Douglas <nialldouglas14@gmail.com> wrote:
On Friday, May 18, 2018 at 9:41:08 PM U= TC+1, dgutson wrote:
This might be interesting.

In some systems, the implem= entation 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 differen= t at the standard-level, but allowing implementations to provide a particul= ar 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/me= mset/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

Or just stop compilers from doin= g daft things=C2=A0

--
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/CAFQaeCD83_FBX4= cAE%2B9AAEHai4ciCeOaorHY1K94k_Yb0e9wnA%40mail.gmail.com.
--000000000000e41f37056d38d5b0-- .