220 35790 article Path: news.gmane.org!.POSTED!not-for-mail From: Richard Smith Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Does guaranteed elision breaks bit_cast? Date: Wed, 6 Dec 2017 13:20:38 -0800 Lines: 162 Approved: news@gmane.org Message-ID: References: <383622f1-4c62-4af6-b684-c3d0fdcd3b9c@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113cd6641d2665055fb287da" X-Trace: blaine.gmane.org 1512595266 19739 195.159.176.226 (6 Dec 2017 21:21:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 6 Dec 2017 21:21:06 +0000 (UTC) To: "std-proposals@isocpp.org" Original-X-From: std-proposals+bncBDVNBJG4YAIBBPN6UHIQKGQENVFSA5A@isocpp.org Wed Dec 06 22:21:01 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wr0-f199.google.com ([209.85.128.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eMh7k-0004qy-5p for gclcip-std-proposals@m.gmane.org; Wed, 06 Dec 2017 22:21:00 +0100 Original-Received: by mail-wr0-f199.google.com with SMTP id g80sf2781309wrd.17 for ; Wed, 06 Dec 2017 13:21:02 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1512595262; cv=pass; d=google.com; s=arc-20160816; b=foxr+qj20nKnILrTBsQ6s5AsspieWEYi1a1LaczSs+sJZxoPBt7JkrgiGKctBiQBeL 5yJuk9w6diuJz4xzoCHPYQ8bYf/PCV/jQBsN4InpGcv3twiSf0fb0gsTwcoZqlFBsndk nd5fzULNiF2/UQkv1MWbjWx3paF7zvLuOAx/RZ/KhWiVJYg0KtNB9BPRAZzzdkHQRSbW hyR6hGaRylOfyoPFQa2xJQPy/H/zjPtrbfyZAOLmz+Bwda+sG3OAWCeW9Kk9JcAekxgG 5K95mY5L2qpB+uDJc5RAWMUN5n1c1myKP7bgPTn27uCFtuKluU+kPMTaso2gAE9jWLkM Uyhw== 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=qVqQa2ho6kITag+OHM/yMTwOWxixTT1InIIa6+OMrKE=; b=p+RGibB99YmRNf+yYJT/3fbUewlkwF4g780ScB0E8n4Oml0xdFYl9qvJ6TsrxNK2gC J6tpSMqUhVoiiLUSHQQfzsmFMXgvMCko7GmyvWmswQykfrlrWE04dsBcnLE1cZ31Q3Q/ 8m02JXozVLeAtZ++AMwgyOPW5IK+aAgTHhytTEIlZQgPpwJkY6/X+oAipD/1PcVt/d9C mZZG/gmieRxdsPk8s+T8IE9vprhYVD+WuzMlNFPjaAwCmXKj3K+mmzRqp8V03GdqRXTT HDY6JCWYxY3kD/ajxBGDUtGZSeCmA7t5al7W7vgZRDKNZjci8iqY9cl3AnP/lXO++pia 953A== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@metafoo.co.uk header.s=default header.b=XuPsFSdl; spf=neutral (google.com: 81.27.85.19 is neither permitted nor denied by best guess record for domain of richard@metafoo.co.uk) smtp.mailfrom=richard@metafoo.co.uk 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=qVqQa2ho6kITag+OHM/yMTwOWxixTT1InIIa6+OMrKE=; b=gyqHdWqMlYBdAu+sP+/Y999vGBLAgZklZQjjhvMamnO91Bm6TDavuBY7794kj2PZrn WimoIbmzdN6zO9L7/7fw7VRehxx+hwAaDKKeU4i+f22rhAyRUNr5SCNC17esR9+pEBPB HVdMDPFEHeFerEAFkhml3wA6JCMLZUmGv9Go4qe8j9yGE06XmTIPIsVi1b6O/LDGyMjM eMZDgpbortGGfSPvSvH0s1QpMF9Hs6EnpPJeximH4O+piKJXSHytHsw5sgI1cHBwgYZz o7uEvoT1134axxQAhyu+311YtVoXl7tmWks6P30JFCZVbKudFDWZ1MyRtB+ePOXsLz7n Hggw== 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=qVqQa2ho6kITag+OHM/yMTwOWxixTT1InIIa6+OMrKE=; b=Ir96KX1jsdHyUluH6zRV8vnxMXdmwJVIgmAgCAyWuRLG0Qv0KhE7WmrKct+kTucZp4 NsCr2DKDOPXFOEk9YLrtF4lrU4Obzxfju6/kRtYGcrbGtXBpe0DKfj1kMN3ZyXRJySI2 ChXzT2U9kLdEW9V9NB7HahILZuedZ1lPNAmZKcx1gvRc0c7HRskfIfSuHR5+DaKYcZdR pEwOoZ+N5B7hMrfZjPRU9ldQV3S9h9k+3B72VbuAYsfqh+A66GG5ROi/eRWXhMLP7b6i swwRxjXtMcsc9dNnckcuKbBG4zSIwOoykhtgLS5A2CnoGoJp80czufsf96Q9OCLoUDy6 k1HQ== X-Gm-Message-State: AKGB3mJtOYEZZV+q/XvC0GbI2dHCRTfptO7mFgNqbJ9Rx9ik1jODEblk CY5VY3+a/UzH3+uWnLCpjWLWrQ== X-Google-Smtp-Source: AGs4zMbiHNp8HCU+28t5PYjLsoKB8gzGVktlsHOB+ne0rXPGMoCIV1Xl5DCBJ0W6u3gQgIL5Jky6XQ== X-Received: by 10.28.63.83 with SMTP id m80mr2164943wma.10.1512595262418; Wed, 06 Dec 2017 13:21:02 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.223.198.3 with SMTP id n3ls3684156wrg.0.gmail; Wed, 06 Dec 2017 13:21:00 -0800 (PST) X-Received: by 10.223.136.80 with SMTP id e16mr22602302wre.21.1512595260821; Wed, 06 Dec 2017 13:21:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1512595260; cv=none; d=google.com; s=arc-20160816; b=sJeLbC8gmDehUvA93lf74ay0UmbeWWDKPZwcTt24c8Nl/MtmpIyjQgZX9U1E5Zwqfj b5BjQVO7MD1+9ApB1ozqUEgYCcQiTOZJHg4XeqmIyvUZ3XqoRbBVzhdS112m4PU/rsCd 1tSqNIXgDBsLLhF59lMiqHG/yt6pQe5OtfHPRwpxzsZhT3LV0GLz36oeSFhxmA6zX3sb gTjqcUgQAQWcZNAVDAtLeo2VxDRKT/BjgmLgLTSaP+oP7lY78vpFJ6wenKcocjBPv+qU 7eqWyZFd/57dAgABJznooY9DDUOcCbAc0rNWzLtKpHL3vCAlnUXijRHwE3PLmZJ6bL1/ 03Ag== 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=lZnRmWNT4OdG/SUPxTcFpmDxL7KSeCA8hpdx+qbBi+M=; b=jJiW8GpfPxj1T6tAjIMprs0GQo4RdvTHigvEsnkxeJG0G/b9v1Y/U0Tvr+r5WykRKi uvvi1Qa6LHzdASwNJlX/7csWN08vz1vAHU03n5oC9wtx5vHgB74l8rl2blXqeEQSFFJr dc1tj2Ez6+0xP3OccEB+WoNXaLjeIZoXHDOmZ8JNs/ZHDvntMPHVPdBgU1IVP141uttA A6vAQ+E5TUjGsfjCjy07kv6c6Bd/rwNl5V+4ROF1mbDSVqqMpgBy93kL80dInJTBoaez jm3m1T75GxUPodGF4Blq9Nl7qoCEq7PA9ATLFGSg6ws7D84OQY1uKrv1LF6UGIsYgH7A PJJg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@metafoo.co.uk header.s=default header.b=XuPsFSdl; spf=neutral (google.com: 81.27.85.19 is neither permitted nor denied by best guess record for domain of richard@metafoo.co.uk) smtp.mailfrom=richard@metafoo.co.uk Original-Received: from uk12.easy-internet.co.uk (uk12.easy-internet.co.uk. [81.27.85.19]) by mx.google.com with ESMTPS id 131si2555697wmj.52.2017.12.06.13.21.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Dec 2017 13:21:00 -0800 (PST) Received-SPF: neutral (google.com: 81.27.85.19 is neither permitted nor denied by best guess record for domain of richard@metafoo.co.uk) client-ip=81.27.85.19; Original-Received: from mail-oi0-f50.google.com ([209.85.218.50]:45098) by uk12.easy-internet.co.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eMh7j-0004mB-IT for std-proposals@isocpp.org; Wed, 06 Dec 2017 21:20:59 +0000 Original-Received: by mail-oi0-f50.google.com with SMTP id x20so3526668oix.12 for ; Wed, 06 Dec 2017 13:20:59 -0800 (PST) X-Received: by 10.202.171.79 with SMTP id u76mr20972704oie.113.1512595259203; Wed, 06 Dec 2017 13:20:59 -0800 (PST) Original-Received: by 10.74.56.21 with HTTP; Wed, 6 Dec 2017 13:20:38 -0800 (PST) In-Reply-To: <383622f1-4c62-4af6-b684-c3d0fdcd3b9c@isocpp.org> X-Gmail-Original-Message-ID: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - uk12.easy-internet.co.uk X-AntiAbuse: Original Domain - isocpp.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - metafoo.co.uk X-Get-Message-Sender-Via: uk12.easy-internet.co.uk: authenticated_id: metafooc/from_h X-Authenticated-Sender: uk12.easy-internet.co.uk: richard@metafoo.co.uk X-Source: X-Source-Args: X-Source-Dir: X-Original-Sender: richard@metafoo.co.uk X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@metafoo.co.uk header.s=default header.b=XuPsFSdl; spf=neutral (google.com: 81.27.85.19 is neither permitted nor denied by best guess record for domain of richard@metafoo.co.uk) smtp.mailfrom=richard@metafoo.co.uk Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:35790 Archived-At: --001a113cd6641d2665055fb287da Content-Type: text/plain; charset="UTF-8" On 6 December 2017 at 11:43, Nicol Bolas wrote: > The new `bit_cast` feature voted into C++20 allows you to do this: > > int i = ...; > float j = bit_cast(i); > > Assuming the two types have the same size. > > The concern is what happens with this: > > int i = ...; > float *f = new(&i) auto(bit_cast(i)); > > Well, the rules of guaranteed elision require that the prvalue returned by > `bit_cast` directly initializes the object. And that object's storage is > the same as the parameter passed to `bit_cast`. > > So... how exactly does that work? Is this just something that is just for > implementers to worry about? Or should there be standard wording to > explicitly forbid this? > Per [expr.new]p19, the invocation of the allocation function is sequenced before the evaluation of the initializer. So first we run the placement new operator. Once it returns, we begin to reuse its storage to hold a different object (the float object we're initializing), so by [basic.life]/1.3, the lifetime of the int object ends, and by [basic.life]/4, properties ascribed to that object (such as the object holding a particular value) cease to apply. The bit_cast happens too late. Guaranteed copy elision might make it a bit more obvious that this could be a problem, but the lifetime and sequencing rules result in this being UB regardless of guaranteed copy elision. Here's another example where it's perhaps slightly more obvious that the code is broken: struct X { int a, b; }; double d; X *p = new (&d) X { 0, d }; Note that an implementation is permitted to store 0 to the first half of d before considering initializing the second half (and in particular, loading from d). This example has never performed a copy of an X object, and it wouldn't matter if it did -- the lifetime of d ends the moment that evaluation of the initializer begins. -- 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/CAOfiQqm-W21i8kdS62gx-XwhXPcsEgkfhr6esE4geGMNzT3Dhg%40mail.gmail.com. --001a113cd6641d2665055fb287da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On 6= December 2017 at 11:43, Nicol Bolas <jmckesson@gmail.com>= wrote:
The new `bi= t_cast` feature voted into C++20 allows you to do this:

<= code class=3D"m_-6501156243865073061prettyprint">
int i =3D ...;
float j =3D b= it_cast<float>(i);

Assuming the two types have the same siz= e.

The concern is what happens with this:

int i =3D ...;
float *f =3D new(&i) auto(bit_cast<= ;float>(i));

Well, the rules of guaranteed elision require that the prva= lue returned by `bit_cast` directly initializes the object. And that object= 's storage is the same as the parameter passed to `bit_cast`.

So... how exactly does that work? Is this just something th= at is just for implementers to worry about? Or should there be standard wor= ding to explicitly forbid this?

Per [expr.new]p19, the invocation of the allocation function is sequenced = before the evaluation of the initializer. So first we run the placement new= operator. Once it returns, we begin to reuse its storage to hold a differe= nt object (the float object we're initializing), so by [basic.life]/1.3= , the lifetime of the int object ends, and by [basic.life]/4, properties as= cribed to that object (such as the object holding a particular value) cease= to apply. The bit_cast happens too late.

Guarante= ed copy elision might make it a bit more obvious that this could be a probl= em, but the lifetime and sequencing rules result in this being UB regardles= s of guaranteed copy elision. Here's another example where it's per= haps slightly more obvious that the code is broken:

struct X { int a, b; };
double d;
X *p =3D new (&= d) X { 0, d };

Note that an implementation is perm= itted to store 0 to the first half of d before considering initializing the= second half (and in particular, loading from d). This example has never pe= rformed a copy of an X object, and it wouldn't matter if it did -- the = lifetime of d ends the moment that evaluation of the initializer begins.

--
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 htt= ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqm-W21i8kdS= 62gx-XwhXPcsEgkfhr6esE4geGMNzT3Dhg%40mail.gmail.com.
--001a113cd6641d2665055fb287da-- .