220 41350 article Path: news.gmane.org!.POSTED!not-for-mail From: "T. C." Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: `bit_cast` and when UB happens. Date: Sun, 13 Jan 2019 17:53:02 -0800 (PST) Lines: 186 Approved: news@gmane.org Message-ID: References: <752cc6a4-24d3-4e86-85a0-3ab0053008d7@isocpp.org> <0119543e-6d78-458a-af85-35f122a0b396@isocpp.org> <0c937122-b9e9-4258-a320-19fede2bfe22@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1413_1306290076.1547430782531" X-Trace: blaine.gmane.org 1547430658 11819 195.159.176.226 (14 Jan 2019 01:50:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 14 Jan 2019 01:50:58 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCQ43G7NQIIRB76W57QQKGQEDQXLO5I@isocpp.org Mon Jan 14 02:50:54 2019 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb1-f199.google.com ([209.85.219.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1girOw-0002xA-6O for gclcip-std-proposals@m.gmane.org; Mon, 14 Jan 2019 02:50:54 +0100 Original-Received: by mail-yb1-f199.google.com with SMTP id f12sf10728695ybp.0 for ; Sun, 13 Jan 2019 17:53:05 -0800 (PST) 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=uMzoOA8sryGXpyG0byXmwkVP1CX4bJZmp75xmbKAxds=; b=fsuTJAUqdBn/e4n+L2ACaYdtGRNuMfrIVTkHxLigTTueZr2jywacNr6sGLxIT5umEA 62G9N2m7E//o4S5k8r5FTZcRxvQuyKz6DNiZdBmZRbmhuLePVN20R2JLPj0OgqWfc2kG a8JwikskNGNvLM0sciuB9WbbLVUoJO06/E1IUlQKDGNQ+VY1208royAkIYe5fd6ylkZt InSBo8Z8EnZvg4X5NAAZz3f8b1kKkfZgDY4DdPuaimn3WIvLetNN+LGmL2YDABGhsGx6 tGCscNpsYCLsunkTN7tcw2xxO2jf3AZEBIg5CwWOuU7dKGlFAJkDi6ZwJYOhdhPwisr7 2BxQ== 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=uMzoOA8sryGXpyG0byXmwkVP1CX4bJZmp75xmbKAxds=; b=Wvy6O3T553Nz+4pK17p6yxzSJ3iRP3N9BrJOZOXCBgkoKqR3OxqygMIDV435yNkCM7 +3SYwEWdvpmX26LLztNHJTth21R2MBnWwBIPxjCp0cmiXxyjR+2OFmq0I1KpYmTZ5ERN 33z9FuCieSTd1CfJUXRPjSJzjW59cDFysAYRjCr/zgBgArKGrRJdbC86/yhIlt8gZp6/ pNL17x0vIrh2/axp8eFS/B6NmquVecfI++isFw5ZsBa5iHOUoGjPGlHSR5MiAtAPR2Hr lcTFHoS51RmBasnzX3erQs7Togo8Wt0cZxIJFBGgzQxSL2Cz/KjifWiHs63zZczyr6bt mwBA== 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=uMzoOA8sryGXpyG0byXmwkVP1CX4bJZmp75xmbKAxds=; b=d76Fw+kWmQvH0St4x2q4As6SWDT/K0zlSgzDVehA3uadpm9SYmJhfIOGorbice66Zp ti3yxLTbaWC4oSrr8vKpauFap/ORJF4KJXJU4MSZIlYSa+YkPAHvT2ojxs2ntiNMzwbM OIKdKPe3RoVnL3LUlkJree1lSBZTEGefN0yZ6zkshRsPnGssmb9aIc4HsK4GphLo9LNK /ugbdezVCW6RvkdiLb72cYx6xDIxpP8CrsqYVc8M1b/b71fJdyQrkrL4COrdTUsef0WK HaX+YFjKSh3/7uRZX8pXpIQYJUCpYuSSXXAb3mzOYdDkc3Z9BkelYBegWGiID0SVhKI4 CEBQ== X-Gm-Message-State: AJcUukcSFRz0EHkoCQ3STBBVrWGm7Uf9P48k566+2qXoCfltpLIXM++m k36nv1xRk/GSslannkNFbZy/Bw== X-Google-Smtp-Source: ALg8bN5YFEy32EyhLaJxwtrKykK/kipZ3dJnlwxIATGLb+p7I5e0HAHvlJPcq2oJLz93gxbtmV5TLg== X-Received: by 2002:a25:60c5:: with SMTP id u188mr4875327ybb.102.1547430784895; Sun, 13 Jan 2019 17:53:04 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a25:c042:: with SMTP id c63ls1739876ybf.4.gmail; Sun, 13 Jan 2019 17:53:03 -0800 (PST) X-Received: by 2002:a25:378a:: with SMTP id e132mr89748yba.0.1547430783349; Sun, 13 Jan 2019 17:53:03 -0800 (PST) In-Reply-To: <0c937122-b9e9-4258-a320-19fede2bfe22@isocpp.org> X-Original-Sender: rs2740@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:41350 Archived-At: ------=_Part_1413_1306290076.1547430782531 Content-Type: multipart/alternative; boundary="----=_Part_1414_1638471212.1547430782531" ------=_Part_1414_1638471212.1547430782531 Content-Type: text/plain; charset="UTF-8" On Sunday, January 13, 2019 at 7:27:23 PM UTC-5, Nicol Bolas wrote: > > > > On Sunday, January 13, 2019 at 6:31:49 PM UTC-5, T. C. wrote: >> >> >> >> On Sunday, January 13, 2019 at 3:12:16 PM UTC-5, Nicol Bolas wrote: >>> >>> P0476R2 specifies when a `bit_cast` yields UB >>> : >>> >>> If there is no value of type `To` corresponding to the value >>>> representation produced, the behavior is undefined. >>>> >>> >>> OK, sure. But what does this really mean? Consider the following type: >>> >>> class specific_bits >>> { >>> public: >>> specific_bits() = default; >>> explicit specific_bits(int j) : j_(j) {} >>> >>> int get_i() const {return i_;} >>> >>> private: >>> int j_; >>> int i_ = 5; >>> }; >>> >>> Now, consider the following operation: >>> >>> auto sb = bit_cast(pair{10, 20}); >>> >>> Let's assume that the sizes of these types are the same. `pair` is >>> TriviallyCopyable, as is `specific_bits`. So, is this well-defined behavior? >>> >>> Well, `specific_bits` is technically just a pair of integers, so it >>> seems like it should be well-defined. However, it is my understanding that >>> it is essentially impossible to change the `i_` member of any >>> `specific_bits` object to any other value. At least, not from outside of >>> the class; anything which would do so would run into UB at some point. >>> >> >> Access control is not watertight enough for that. There are ways you can >> get your hands on a pointer to member to specific_bits::i_, at which point >> you can modify the field ( >> http://coliru.stacked-crooked.com/a/62dd7c4bfeb1eb96). >> > > Why isn't `template struct accessor;` a > compile error? Doesn't it mention a name which is not accessible from that > location? > Access checking is not applied to explicit instantiations (with exceptions not relevant here). See [temp.spec]/6 in the current WP. -- 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/e9d6281d-0256-437a-832f-62d2b885c552%40isocpp.org. ------=_Part_1414_1638471212.1547430782531 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sunday, January 13, 2019 at 7:27:23 PM UTC-5, N= icol Bolas wrote:


On Sunday, January 13, 2019 at 6:31:49 PM UTC-5, T. C. wrote:


On Sunday, J= anuary 13, 2019 at 3:12:16 PM UTC-5, Nicol Bolas wrote:
P0476R2 specifies when a `bit_cast` yields UB:

If there is no= value of type `To` corresponding to the value representation produced, the= behavior is undefined.

OK, sure. But what does this re= ally mean? Consider the following type:

class specific_bits
{
public:
=C2= =A0 =C2=A0 specific_bits() =3D default;
=C2=A0 =C2=A0 explicit spe= cific_bits(int j) : j_(j) {}
=C2=A0 =C2=A0
=C2=A0 =C2=A0 int get_i() const {return i_;}

private:
=C2=A0 =C2= =A0 int= j_;=C2=A0 =C2=A0 int i_ =3D 5;
};

Now, consider the following operation:<= br>
auto sb =3D bit_cast<specific_bits>(pair<int,= int>{10, <= span style=3D"color:#066">20});

Let's assume that the sizes of these types are the = same. `pair` is TriviallyCopyable, as is `specific_bits`. So, is this well-= defined behavior?

Well, `specific_bits` is technically just a pair o= f integers, so it seems like it should be well-defined. However, it is my u= nderstanding that it is essentially impossible to change the `i_` member of= any `specific_bits` object to any other value. At least, not from outside = of the class; anything which would do so would run into UB at some point.


Why isn't `template struct accessor<speci= fic_bits, &specific_bits::i_>;` a compile error? Doesn't it ment= ion a name which is not accessible from that location?

Access checking is not applied to explicit inst= antiations (with exceptions not relevant here). See [temp.spec]/6 in the cu= rrent WP.=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 https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/e9d6281d-0256-437a-832f-62d2b885c552= %40isocpp.org.
------=_Part_1414_1638471212.1547430782531-- ------=_Part_1413_1306290076.1547430782531-- .