220 39568 article Path: news.gmane.org!.POSTED!not-for-mail From: Arthur O'Dwyer Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: D1031R1 draft 1 LLFIO with proposed C++ object model and lifetime changes for mapped memory support Date: Mon, 6 Aug 2018 13:40:12 -0700 (PDT) Lines: 109 Approved: news@gmane.org Message-ID: References: <096f1d1c-3e2e-4df8-91ee-6f1cf4d31aad@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1715_2054760768.1533588012975" X-Trace: blaine.gmane.org 1533587889 32221 195.159.176.226 (6 Aug 2018 20:38:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 6 Aug 2018 20:38:09 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDLZJYWNDQIK5ZFC3MCRUBAACLK5E@isocpp.org Mon Aug 06 22:38:05 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb0-f198.google.com ([209.85.213.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fmmGS-0008H1-NW for gclcip-std-proposals@m.gmane.org; Mon, 06 Aug 2018 22:38:04 +0200 Original-Received: by mail-yb0-f198.google.com with SMTP id y8-v6sf14448263ybm.15 for ; Mon, 06 Aug 2018 13:40:15 -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=PlZZGl/thPqaf5FOA6L9/Zx7C/mJEs3lAF1nFOK/i2o=; b=Z+DYVpw6YjbttbNcEVLRCqcOiYz7LTSs/A1L8755zEb1z/JNwWw5qx5sje+hCh6+nx 3r1CCGsLMWBFetBzaaZlMUFg42/iKvU+q91tpopbIdiw+YKhwo31Ky7KpS5FCf4/uEBg 2PV4A3kWuvWSpepyYYkZ6nCgTjZaWnG9Sb3FwJosE4ftkEjsGm8c4uKJHNnjxQeh3Wyd zhvGmQ8SJ+mKe4jt+tFn291PNYXYhvEWDTJAMeVGDGpK/ElZGBtpyAGbqskPJGjzUZzu UBc1SOKo8cGMZgv4cwpdQDINg1+3SkHNt3wio46TfuLP2befuO1Z4RuzfIqzONkgrgjK 7+0w== 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=PlZZGl/thPqaf5FOA6L9/Zx7C/mJEs3lAF1nFOK/i2o=; b=lGq8vks62bUc8odfXtQo6aByHjkg9Q5jxPJv10Z/Lvoa4z28hSxnOeqdaaWkRK804+ BoKmKdkvNUHZVXaXRaAsnlsWRmNOdcby8AdV0wPJy7R0V5edynkHA3NNQQljX1p3SMUh MzhWkHQl2kt+nMGUb7efkKFEG5AFlacmzK97rAE/j0KYkqurcIt8MRngkQ9f/SoENR5t ksAaEXuU+wc5hZqaWsDOJDL8H6Y7bGCeDgPw7OyhC8IBp6C+dpFVjfXJHSPqrCR+jwNo EMvEfpgKEB8PQVjiLEQnQG+C7J8Z1vxKw0YWC9siJCMwB67SgnnOKoDzg9e+B6mBa1HO dZIg== 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=PlZZGl/thPqaf5FOA6L9/Zx7C/mJEs3lAF1nFOK/i2o=; b=VSzBNiL6UZe/7XOJU7SKuXfglMlqI7hwTKptSmRvfrGGJOyL+hFqWBPqLKYu6DU7XR lzvok0mYoLCZ7FFceF5w5j6EAUhfmNAnmRJhB+RO544iaiocbjSHCJAIud5uI9wRPnMj 0VpDM16YOJ31rAvkFNrTRePG4MVFhxISA2qdpvzT7SllzuQRqY+7kAlgbyPCbmSVmB97 jd9tCJKdOmOLiuqVTtN10mgRO2OTp5MhjyJssL7DEw9qTa5NQ+5AB1rKBbssL6a12KSM QLH9n6VQOklflRlkYLwnsGdQnO1sdOVsi5s8TBNCXQOb8Hl8QNombzXrM88pX9U6xe5J HLIA== X-Gm-Message-State: AOUpUlHl5nlwlWG107gbRWNEdvtKP2o0xM9s8dscgPYruGgLrFVhq1lT 4NmK6xz37aeN6Pq+cwqX66Rxzg== X-Google-Smtp-Source: AAOMgpcLMsPLsOeiec6N33SXzOkDGj4zJVIGIARiHPgGhV56m2wzw2+DEhhbEdpzyKeMf0nIEoTu4A== X-Received: by 2002:a81:440c:: with SMTP id r12-v6mr5691506ywa.209.1533588015148; Mon, 06 Aug 2018 13:40:15 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:52cf:: with SMTP id g198-v6ls2312466ywb.38.gmail; Mon, 06 Aug 2018 13:40:14 -0700 (PDT) X-Received: by 2002:a81:5705:: with SMTP id l5-v6mr408586ywb.6.1533588013713; Mon, 06 Aug 2018 13:40:13 -0700 (PDT) In-Reply-To: <096f1d1c-3e2e-4df8-91ee-6f1cf4d31aad@isocpp.org> X-Original-Sender: arthur.j.odwyer@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:39568 Archived-At: ------=_Part_1715_2054760768.1533588012975 Content-Type: multipart/alternative; boundary="----=_Part_1716_1459947070.1533588012975" ------=_Part_1716_1459947070.1533588012975 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tuesday, July 31, 2018 at 12:08:27 PM UTC-7, Niall Douglas wrote: > > So after many weeks of pondering and writing this outside of work each=20 > day, please find attached an early draft of revision 1 of P1031 destined= =20 > for San Diego. Changes since R0: > > - Wrote partial draft TS wording for deadline, handle, io_handle,=20 > mapped, mapped_view, native_handle_type and file_io_error. > - Added impact on the standard regarding potential changes to the C++= =20 > object model. > - Added impact on the standard regarding the proposed=20 > [[no_side_effects]] et al contracts attributes. > > `class mapped` is referred to as `mapped_span` in two places. `class handle`'s move-constructor is marked [[move_relocates]] even though= =20 `class handle` has a virtual destructor. Your P1029R0=20 =20 proposes that this should mean the attribute is silently ignored. My D1144 proposes that if you were to mark `class handle` as=20 [[trivially_relocatable]], the compiler would trust you; but that wouldn't= =20 change the fact that you'd be lying to it, and you'd get UB at runtime when= =20 the compiler incorrectly assumed it could replace some arbitrary derived=20 class's destructor with a `memcpy`. Should we open a side thread to talk about under what circumstances it=20 might be okay to memcpy a thing with a virtual destructor? (My D1144 has a= =20 well-formed opinion on the topic, but I admit I don't do much mixing of=20 classical polymorphism with move-semantics in my own code.) =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/d4821a6e-7825-4bef-9ba7-c5ddf57b4853%40isocpp.or= g. ------=_Part_1716_1459947070.1533588012975 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tuesday, July 31, 2018 at 12:08:27 PM UTC-7, Niall Doug= las wrote:
So = after many weeks of pondering and writing this outside of work each day, pl= ease find attached an early draft of revision 1 of P1031 destined for San D= iego. Changes since R0:
  • Wrote partial draft TS wording for dead= line, handle, io_handle, mapped, mapped_view, native_handle_type and file_i= o_error.
  • Added impact on the standard regarding potential changes t= o the C++ object model.
  • Added impact on the standard regarding the = proposed [[no_side_effects]] et al contracts attributes.

`class mapped` is referred to as `= mapped_span` in two places.

`class handle`&#= 39;s move-constructor is marked [[move_relocates]] even though `class handl= e` has a virtual destructor.
Your=C2=A0P1029R0 proposes = that this should mean the attribute is silently ignored.
My D1144= proposes that if you were to mark `class handle` as [[trivially_relocatabl= e]], the compiler would trust you; but that wouldn't change the fact th= at you'd be lying to it, and you'd get UB at runtime when the compi= ler incorrectly assumed it could replace some arbitrary derived class's= destructor with a `memcpy`.

Should we open a side= thread to talk about under what circumstances it might be okay to memcpy a= thing with a virtual destructor? =C2=A0(My D1144 has a well-formed opinion= on the topic, but I admit I don't do much mixing of classical polymorp= hism with move-semantics in my own code.)

=E2=80= =93Arthur

--
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/d4821a6e-7825-4bef-9ba7-c5ddf57b4853= %40isocpp.org.
------=_Part_1716_1459947070.1533588012975-- ------=_Part_1715_2054760768.1533588012975-- .