220 30413 article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: P0298: A byte type definition: with undefined pointer arithmetic? Date: Sat, 7 Jan 2017 20:31:02 -0800 (PST) Lines: 181 Approved: news@gmane.org Message-ID: 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_9_1875176364.1483849862138" X-Trace: blaine.gmane.org 1483849868 20030 195.159.176.226 (8 Jan 2017 04:31:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 8 Jan 2017 04:31:08 +0000 (UTC) Cc: neilmac@microsoft.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBBUBY7BQKGQEEOZWYFQ@isocpp.org Sun Jan 08 05:31:03 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-it0-f69.google.com ([209.85.214.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cQ58F-0004AR-Hu for gclcip-std-proposals@m.gmane.org; Sun, 08 Jan 2017 05:31:00 +0100 Original-Received: by mail-it0-f69.google.com with SMTP id n68sf58222578itn.4 for ; Sat, 07 Jan 2017 20:31: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=4dYfNbcSYq8kTxytgztVlfqFUdvXpqF1zaOpPfhAjMM=; b=AfGUh5p5YLFW6Ll7F+HLBttH8lDKmZeu4K2e6cn7MwgtrcElEVTiL/V2qx/e4ZGw/J O1ZcBNIxCEMIh6oukJcwONw29vlm2w3WH6WXFq//A74SyAiSi/Q5UZUbboqefdRtcfzB gy4So6UgEcTJj7UCmxrQZ2+xbCmFBjqV5D+UbRSUlGAEIT9Bt6RMDK2AHDzzQDfJawfi lf52UGx5Bvxnw+P/ZybRBSS5hC4SDBzbI7ziqSiUzttpGZ84H7FEtJR76N+9qQlf3J28 Ij/+meVo+PEjCHPKdR2rSM32P2S01GOkrAOSbQWQ+q1Z3Lpmuu7EHZB+zntv/AhydHJa xiGQ== 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=4dYfNbcSYq8kTxytgztVlfqFUdvXpqF1zaOpPfhAjMM=; b=NHWX2/OpWkPkcOUfbp0q5obD+NlE+9TXfrN/KwRyLC35acTdMYvD5c5vKW3NQUDWjB ELB1s1m/OBd7Ft/Oz98CRjnKR9IHJhXltOjaGfSZ5dXbA+pOMauf9QCf0Xu2QS/vnAcN mjZnANP1jmTvPp7jsWLi7RnPjAumLNtYeGqi9p+zsak6Czuv6o7OfCVuQ9xWDpAswae4 LiMnXZcFafyCzgpwrigefn94D1n6Vd9tofQ3QBEZfhOXA8pQXdXkbQdLTvSiov9AjArb UKg4ZWSMzLhsQEB5+chBPGrzJw4VX8eiEWN4zBY5UD/dpujpgS/yxEDNzuyOpA8NK9Pq zCKA== 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=4dYfNbcSYq8kTxytgztVlfqFUdvXpqF1zaOpPfhAjMM=; b=nulnNa93u1x1oD5Z8bwijCp9s3JnUaxm5y8+iR1UFbT3s4km+3+ldshmPvn7oWc19H m6qUnp7C8OhpfMFa0vxGfNKXbzNcvKOOtTpsegohP8kyeLONR0KjQtPF4l67W49HSdYe XZKc0d3npkWO4DM/4i3VRP/px4xXGqr295AIX961qgtViFEbpVmrI8ahoMBrOebbR7LO cEPtLXdCfLiR0pyzGqP74X2aCu/Fzc7XjXXz+rzmEKtt55BmdbR/KnKybTeG7YGPat5M NgRDz4dAHCF/P5Jm+ipc54V0t+LI+70hwNOvUPwRoQzTfmrXsBxCumV9kgYuq0lgYdKJ +ZQw== X-Gm-Message-State: AIkVDXLVpNm+YbEDJ8X158VEkbLOdHwnBhGFt6dpk04vrSJZSWmtdeLAhN9DAeYUWhnP6w== X-Received: by 10.36.103.2 with SMTP id u2mr1384161itc.30.1483849863367; Sat, 07 Jan 2017 20:31:03 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.46.77 with SMTP id c13ls4653208otd.49.gmail; Sat, 07 Jan 2017 20:31:02 -0800 (PST) X-Received: by 10.157.35.89 with SMTP id k25mr650393otd.11.1483849862778; Sat, 07 Jan 2017 20:31:02 -0800 (PST) In-Reply-To: X-Original-Sender: jmckesson@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:30413 Archived-At: ------=_Part_9_1875176364.1483849862138 Content-Type: multipart/alternative; boundary="----=_Part_10_449851246.1483849862138" ------=_Part_10_449851246.1483849862138 Content-Type: text/plain; charset=UTF-8 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. This is also well-formed. >> >> union { int i ; unsigned char buf[sizeof(int)] ; } u ; >> u.i = 42 ; >> unsigned char * p3 = reinterpret_cast< unsigned char *>( &u ) ; >> p3 + 1 ; // OK >> > > This example also needs std::launder, > 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. You're right about the rest, though. but even with that, p3 would only point to the first byte in the object > representation of u (or, equivalently, u.i), not u.buf[0]. u.buf[0] > doesn't exist (as a live object). It doesn't exist because u.buf itself > doesn't exist, and that's because it was never made the active member. > There's only u.i. Since there is no live array object, the last line is > strictly undefined under the current (but presumably defective) wording. > > > But this one is undefined behaviour? >> >> int i = 42 ; >> unsigned char * p4 = reinterpret_cast< unsigned char *>( &i ) ; >> p4 + 1 ; // Undefined behaviour? >> >> Because the storage for object i is not associated with array of unsigned >> char. >> > > Yes, under the current (but presumably defective) wording. (Also, this > needs std::launder.) > 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. -- 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/c6deb7b7-b65f-4327-80cd-d9fdbaf1d9ea%40isocpp.org. ------=_Part_10_449851246.1483849862138 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Saturday, January 7, 2017 at 8:13:39 PM UTC-5, Chris Ha= llock wrote:
O= n Saturday, January 7, 2017 at 3:07:23 PM UTC-8, Ryou wrote:
[...]
So I think this is = well-formed.

=C2=A0 =C2=A0 unsigned char stor= age[ sizeof(int) ] ;
=C2=A0 =C2=A0 int * p1 =3D new(storage) int(= 42) ;
=C2=A0 =C2=A0 unsigned char * p2 =3D reinterpret_cast<un= signed char *>(p1) ;
=C2=A0 =C2=A0 p2 + 1 ; // OK
<= /div>

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-int= erconvertibility rules. If an object B provides storage for A (in accord wi= th [intro.object]/3), then they should be pointer-interconvertible, for the= exact same reason as for member subobjects of unions and the first subobje= ct of a standard layout struct.

This is also well-formed.

=C2=A0 =C2=A0 union { int i ; unsigned char buf[sizeof(int)] ; }= u ;
=C2=A0 =C2=A0 u.i =3D 42 ;
=C2=A0 =C2=A0 unsigned = char * p3 =3D reinterpret_cast< unsigned char *>( &u ) ;
=C2=A0 =C2=A0 p3 + 1 ; // OK

This = example also needs std::l= aunder,

A union is pointer-interco= nvertible with all of its member subobjects, per [basic.compound]/4:=

> one is a standard-layout union object and the other is a non-s= tatic data member of that object

So laundering is not needed. You= 9;re right about the rest, though.

but even with that, p3 would only point to the first = byte in the object representation of u (or, equivalently, u.i), not u.buf[0]. u= ..buf[0] doesn't exist (as a live object). It doesn't exist b= ecause u.buf itsel= f doesn't exist, and that's because it was never made the active me= mber. There's only u.= i. Since there is no live array object, the last line is strictly un= defined under the current (but presumably defective) wording.


But this one is undefined behaviour?

=C2=A0= =C2=A0 int i =3D 42 ;
=C2=A0 =C2=A0 unsigned char * p4 =3D reint= erpret_cast< unsigned char *>( &i ) ;
=C2=A0 =C2=A0 p4 = + 1 ; // Undefined behaviour?

Because the st= orage for object i is not associated with array of unsigned char.=C2=A0

Yes, under the current (but presumably defect= ive) wording. (Also, this needs std::launder.)

Personall= y, I don't think any of those should need `std::launder`. Byte-w= ise access to an object has nothing to do with the purposes that `launder` = was invented to solve.

--
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/c6deb7b7-b65f-4327-80cd-d9fdbaf1d9ea= %40isocpp.org.
------=_Part_10_449851246.1483849862138-- ------=_Part_9_1875176364.1483849862138-- .