220 30415 <35f251f8-fbe6-46dd-967b-e946a9d54c7c@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Chris Hallock Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: P0298: A byte type definition: with undefined pointer arithmetic? Date: Sun, 8 Jan 2017 01:53:01 -0800 (PST) Lines: 166 Approved: news@gmane.org Message-ID: <35f251f8-fbe6-46dd-967b-e946a9d54c7c@isocpp.org> References: <117168cf-8ab4-4048-aed6-38b68cb3ebca@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1022_114863538.1483869181325" X-Trace: blaine.gmane.org 1483869193 12187 195.159.176.226 (8 Jan 2017 09:53:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 8 Jan 2017 09:53:13 +0000 (UTC) Cc: neilmac@microsoft.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCHINCHEQEFBB7UXZDBQKGQENYKU65Q@isocpp.org Sun Jan 08 10:53:09 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f69.google.com ([209.85.218.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cQA9r-0001jZ-6u for gclcip-std-proposals@m.gmane.org; Sun, 08 Jan 2017 10:52:59 +0100 Original-Received: by mail-oi0-f69.google.com with SMTP id y140sf98265830oie.2 for ; Sun, 08 Jan 2017 01:53:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc: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=iVUYxwzMjBr/bYKz88Ycs1EOmNYHMv2SCJRHZC1O1Eo=; b=U0zT5Wha1tYzHqazimaK5YAJYtMLuQrsKJvTyoqEcpL2oKEmgpME3GwlZHXAq/Yu2h cWXOiP/BEaWsG2xtRwXashBu/jAQFm4m1QmqEWFIfk8WmravmNtbkheOGZ20aq51WAnt DM/K6NnnyDnfxOO4AWdlV8r+PHrDc2LHTgT8k5am3kNtdQpQJKdOu/FgmFNeKk97KBaT mtTGixmBF4TuSjsdHEfQHP1nNDCktA9sGvxYlvQJHGNeEA9XGWUhtk7C9MtXTHyDYkVs T6Aln7aAijadJgAbtmtGeVilLiImd7EvCyE8uSHcfLt/BYbEyW3/7HzFE+O5C4wH3Imq 8zaQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc: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=iVUYxwzMjBr/bYKz88Ycs1EOmNYHMv2SCJRHZC1O1Eo=; b=uzTRU5e9ODqdo6OVNvgoNYia3GaT0HNFyb9JO4kLOJgoX8KgQBkVCFl0rhBg1cY1id c7DWacNFrEOOQQF9f3JVbmodCV0Wb/C6rJwG6zNeZTBTlFPmHAWAaT4qp0Va7Ch+MZDg HQ6lP6SVqGbPOjRuQIJnI37X/l2aCjvPXWPj9j4tQYv+54Yaz7JY81uXjcGycIzA+fAm hujDFvpftPF3s4EvwdMfOMfidbDMxgqOeyyQ59s+MSWankOBWp6oqA0/QOddZZmWrnM4 PlQxLH4rSHM4Exl3mzNqp02X0OHxBHb6pc9DvntKU1sxzxyLkMv8G3G5C9xQy8tyCzzP /iCQ== 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:cc: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=iVUYxwzMjBr/bYKz88Ycs1EOmNYHMv2SCJRHZC1O1Eo=; b=Zf6haRTxLzo9j/X47hOQJESyMJYHQeWu7VggPebOdZofqD4hYyF39mIVWXI8vpy/db YevBqUeT0NQQGinWI7m6PsYDgalgk1ss/Z4peqoSEnF8tEk1zUs6oEivXR6azWK90jWU +bFJXCzoDycArBBZ3HJ+Fa9XVU2cV0bLqdwZLXmR6eBeGYJOhorUOR45RPZvZSPDBiGs IGJ5W16Ap8+G8NJdPXGlmiDjkLDmv3BX6yEz4aUv0RF6aulNREYr0RLADLyjVvSj+sKH o/KlAeZ72JtXvFaAVDmXW4UpVNSsFUVdLmvvj6vTd0XIK45rjg3xVoyafSBuqdlm+QVO AK2g== X-Gm-Message-State: AIkVDXJ6czXZAvqxM5Yw6pjjcBVnVYD5tuS+saRW63A1Iz2LA4EDT4KOPPcn8h2SC5nZOA== X-Received: by 10.157.43.248 with SMTP id u111mr80648ota.91.1483869183267; Sun, 08 Jan 2017 01:53:03 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.4.76 with SMTP id 70ls4619997otc.32.gmail; Sun, 08 Jan 2017 01:53:02 -0800 (PST) X-Received: by 10.157.20.197 with SMTP id r5mr670759otr.9.1483869181944; Sun, 08 Jan 2017 01:53:01 -0800 (PST) In-Reply-To: X-Original-Sender: christopherhallock@gmail.com 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:30415 Archived-At: ------=_Part_1022_114863538.1483869181325 Content-Type: multipart/alternative; boundary="----=_Part_1023_851875949.1483869181325" ------=_Part_1023_851875949.1483869181325 Content-Type: text/plain; charset=UTF-8 On Saturday, January 7, 2017 at 8:31:02 PM UTC-8, Nicol Bolas wrote: > > On Saturday, January 7, 2017 at 8:13:39 PM UTC-5, Chris Hallock wrote: >> >> On Saturday, January 7, 2017 at 3:07:23 PM UTC-8, Ryou wrote: >>> >>> [...] >>> So I think this is well-formed. >>> >>> unsigned char storage[ sizeof(int) ] ; >>> int * p1 = new(storage) int(42) ; >>> unsigned char * p2 = reinterpret_cast(p1) ; >>> p2 + 1 ; // OK >>> >> >> Agreed, except that, since the int object is not pointer-interconvertable >> to storage[0], you also need >> to std::launder the result of the >> cast under C++17. >> > > I think this should be a defect in the pointer-interconvertibility rules. > If an object B provides storage for A (in accord with [intro.object]/3), > then they should be pointer-interconvertible, for the exact same reason as > for member subobjects of unions and the first subobject of a standard > layout struct. > The rules seem odd to me, too. The note at the end of [basic.compound]/4 suggests that the restrictiveness is intentional, at least in part: "An array object and its first element are not pointer-interconvertible, even though they have the same address." So there's something conceptually more to pointer interconvertibility than just sharing the same address. A union is pointer-interconvertible with *all* of its member subobjects, > per [basic.compound]/4: > > one is a standard-layout union object and the other is a non-static data > member of that object > So laundering is not needed. > reinterpret_cast can't return a pointer to u.buf[0] because it doesn't exist. Instead, the reinterpret_cast (or rather, the static_cast it delegates to) returns a pointer to u as a fall-back ("Otherwise, the pointer value is unchanged by the conversion" ). The std::launder is then necessary to convert that to a pointer to the first byte in the object representation of u. Personally, I don't think any of those *should* need `std::launder`. > Byte-wise access to an object has nothing to do with the purposes that > `launder` was invented to solve. > +1 -- 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/35f251f8-fbe6-46dd-967b-e946a9d54c7c%40isocpp.org. ------=_Part_1023_851875949.1483869181325 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Saturday, January 7, 2017 at 8:31:02 PM UTC-8, Nicol Bo= las wrote:
On = Saturday, January 7, 2017 at 8:13:39 PM UTC-5, Chris Hallock wrote:
On Saturday, January 7, 20= 17 at 3:07:23 PM UTC-8, Ryou wrote:
[...]
So I think this is well-formed.
<= br>
=C2=A0 =C2=A0 unsigned char storage[ sizeof(int) ] ;
=C2=A0 =C2=A0 int * p1 =3D new(storage) int(42) ;
=C2=A0 = =C2=A0 unsigned char * p2 =3D reinterpret_cast<unsigned char *>(p1) ;=
=C2=A0 =C2=A0 p2 + 1 ; // OK
=
Agreed, except that, since the int object is not pointer-interconvertable to storage[0], you also need to std::launder the result of the cast under C++17.

The rules seem odd to me, too. = The note at the end of = [basic.compound]/4 suggests that the restrictiveness is intentional, at= least in part: "An array object and its first element are not pointer= -interconvertible, even though they have the same address." So there&#= 39;s something conceptually more to pointer interconvertibility than just s= haring the same address.


A union is pointer-interconver= tible with all of its member subobjects, per [basic.compound]/4:
= > one is a standard-layout union object and the other is a non-static da= ta member of that object
So laundering is not needed.
<= /div>

reinterpret_cast can't return a pointer to u.buf[0] because it doesn't e= xist. Instead, the rein= terpret_cast (or rather, the static_cast it delegates to) returns a pointer to u as a fall-back ("Otherwise, the pointer value is = unchanged by the conversion"). The std::launder is then necessary to convert that = to a pointer to the first byte in the object representation of u.


Pers= onally, I don't think any of those should need `std::launder`. B= yte-wise access to an object has nothing to do with the purposes that `laun= der` was invented to solve.

+1

--
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/35f251f8-fbe6-46dd-967b-e946a9d54c7c= %40isocpp.org.
------=_Part_1023_851875949.1483869181325-- ------=_Part_1022_114863538.1483869181325-- .