220 30411 <117168cf-8ab4-4048-aed6-38b68cb3ebca@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Ryou Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: P0298: A byte type definition: with undefined pointer arithmetic? Date: Sat, 7 Jan 2017 15:07:23 -0800 (PST) Lines: 195 Approved: news@gmane.org Message-ID: <117168cf-8ab4-4048-aed6-38b68cb3ebca@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2235_631660266.1483830443441" X-Trace: blaine.gmane.org 1483830448 12910 195.159.176.226 (7 Jan 2017 23:07:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 7 Jan 2017 23:07:28 +0000 (UTC) Cc: neilmac@microsoft.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDXLJJU3RIMBBLHJYXBQKGQE5IO3FDY@isocpp.org Sun Jan 08 00:07:23 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f72.google.com ([209.85.218.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cQ053-0002Ty-2W for gclcip-std-proposals@m.gmane.org; Sun, 08 Jan 2017 00:07:21 +0100 Original-Received: by mail-oi0-f72.google.com with SMTP id 189sf755636809oif.3 for ; Sat, 07 Jan 2017 15:07:25 -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=UiuGZQ9zUVuN61GdqWgWGEaimurWSBvNrvjVTYeMD3Q=; b=lANCm1c6+0eoO0ufyQiy0q+CjNC+O0Y17kZpRDstCkvWnYn/ep2Bv/VI/yg5D9cLtG Zc81QOwJBC0scW8PEK2F+Ngaz8nq0DfklS8nSclPiDjfNywBeeSKpJ8fucr1JEaw8OA3 2ZJ1czsZShabZ429pvMMlNrf3Fg3dgyhQ1INI8QO0Ub7w+Hx6Ehl/37FFpJelbLleRS+ 21nEWT0uKBgGL/QgDUOuWAVtNb9jrFsMKoq9+597ValT+fcc+yiJ7Y/JwcR3WUmkw0mv AwAxBEzPkjdJoUbmgswGRcT8sKECmyZYMVJm1OtZbsJ31AxIG9aJsOo5M0dvCrMdQbHT M/ug== 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=UiuGZQ9zUVuN61GdqWgWGEaimurWSBvNrvjVTYeMD3Q=; b=H5fxugPDUX1UwPyRxHvXKy8aeYUPASTry6sYXt0cwFfA0IEcLxlrY90fFAyGgJEv0b cKTWMlufclRpoOExABGotbCsucZHO63Bm+P08VcnIwj276SkhfuWCO4aUwZDu4C5W3fk V7KplpLlPurMGMja3kKxV0bX7kYia5RIUEbKSGyYP1z7MNW1SSoaCNu/0ht3oDGjjVmQ 63TgHDwPoB9BLF5kTJvj61GqtJmEsd4g7wtMqVWOunwgiwPljtbim9lhOfAxBDXKN2cl k3LkrlhmlaazFFk81fn6h9Oxsba2OKuxBF5fDwr2biNWUqdsNR7iYIugdp2GPGnGzm9R gqQA== 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=UiuGZQ9zUVuN61GdqWgWGEaimurWSBvNrvjVTYeMD3Q=; b=KfWgV3G3A52F8uUE1galKa3iAjC6JGFSCzZOvG6Ce51Zp32ieKerHi3thHo7USK8Yi yRqLwwBGfzYuFiOVsiYqeHfZkzyymsKtjcSMqRaKigj7Ad0YPSZK68c66bI5fWvH6Yoq x///YcDaiWJe6U4FZfZTfILul2R2eWI6UsYM8zH5hohKvwUXZlHBvQ3htrSUrW830VCy P0jpRbvEax5EYnJ5dZrgjjVaV70XqwNpwSyqemdsiLlrk68ECwAqp2mVWT2XkB+fMjR7 PGkW4fLG9DNyNNqyLOlvTfLnkcb8a32VJ4sTajrnQI3hoYxJpb34jSDGv5Z2nEiFXgDq ogPg== X-Gm-Message-State: AIkVDXJQ2pOQWXa0w/VE7V+2I14NQTzLrZjhCh+zXPsXhqJqYTDnKzqKvtDoLJjp69NVXQ== X-Received: by 10.157.62.90 with SMTP id h26mr2973264otg.136.1483830445085; Sat, 07 Jan 2017 15:07:25 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.58.38 with SMTP id j35ls4361471otc.17.gmail; Sat, 07 Jan 2017 15:07:24 -0800 (PST) X-Received: by 10.157.18.211 with SMTP id g77mr629518otg.14.1483830444082; Sat, 07 Jan 2017 15:07:24 -0800 (PST) In-Reply-To: X-Original-Sender: boostcpp@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:30411 Archived-At: ------=_Part_2235_631660266.1483830443441 Content-Type: multipart/alternative; boundary="----=_Part_2236_1697753840.1483830443441" ------=_Part_2236_1697753840.1483830443441 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wednesday, January 4, 2017 at 7:43:24 PM UTC+9, Kazutoshi SATODA wrote: > > from P0298R2:=20 > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0298r2.pdf=20 > > Motivation and Scope=20 > > Many programs require byte-oriented access to memory. ...=20 > > Could you please show examples of such programs?=20 > > > As I read N4623 (WG21 2016-11 Issaquah Minutes) and saw that the=20 > proposal was about to pass through, I want to understand more concretely= =20 > what is going.=20 > > I suspect that such programs do something like obtaining unsigned char*= =20 > which points to an int object via reinterpret_cast and iterating through= =20 > it as if the pointer points to an element of unsigned char[sizeof(int)],= =20 > as I personally have seen many such programs.=20 > > However, AFAIK, the current standard doesn't (or fails to) give=20 > well-defined behavior to such byte-oriented access on objects of=20 > arbitrary types.=20 > N4618 5.7 [expr.add] p6 says:=20 > > For addition or subtraction, if the expressions P or Q have type=20 > > "pointer to cv T", where T and the array element type are not similar= =20 > > (4.5), the behavior is undefined.=20 > > Then, if "Many programs require ..." is saying what I suspect, I think=20 > defining such byte-oriented accesses should be done before (or within)=20 > the proposal. It will also resolve CWG issue 1701:=20 > "Array vs sequence in object representation"=20 > http://wg21.cmeerw.net/cwg/issue1701=20 > > --=20 > k_satoda=20 > =C2=A7 1.8 p3 said (p0298r2 add "array of N std::byte" to this wording) >If a complete object is created (5.3.4) in storage associated with another= =20 object e of type =E2=80=9Carray of N >unsigned char=E2=80=9D, that array provides storage for the created object= if:=20 So I think this is well-formed. unsigned char storage[ sizeof(int) ] ; int * p1 =3D new(storage) int(42) ; unsigned char * p2 =3D reinterpret_cast(p1) ; p2 + 1 ; // OK This is also well-formed. union { int i ; unsigned char buf[sizeof(int)] ; } u ; u.i =3D 42 ; unsigned char * p3 =3D reinterpret_cast< unsigned char *>( &u ) ; p3 + 1 ; // OK But this one is undefined behaviour? int i =3D 42 ; unsigned char * p4 =3D reinterpret_cast< unsigned char *>( &i ) ; p4 + 1 ; // Undefined behaviour? Because the storage for object i is not associated with array of unsigned= =20 char.=20 --=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/117168cf-8ab4-4048-aed6-38b68cb3ebca%40isocpp.or= g. ------=_Part_2236_1697753840.1483830443441 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wednesday, January 4, 2017 at 7:43:24 PM UTC+9,= Kazutoshi SATODA wrote:
from P= 0298R2: htt= p://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0298r2.pdf<= /a>
> Motivation and Scope
> Many programs require byte-oriented access to memory. ...

Could you please show examples of such programs?


As I read N4623 (WG21 2016-11 Issaquah Minutes) and saw that the
proposal was about to pass through, I want to understand more concretel= y
what is going.

I suspect that such programs do something like obtaining unsigned char*
which points to an int object via reinterpret_cast and iterating throug= h
it as if the pointer points to an element of unsigned char[sizeof(int)]= ,
as I personally have seen many such programs.

However, AFAIK, the current standard doesn't (or fails to) give
well-defined behavior to such byte-oriented access on objects of
arbitrary types.
N4618 5.7 [expr.add] p6 says:
> For addition or subtraction, if the expressions P or Q have type
> "pointer to cv T", where T and the array element type ar= e not similar
> (4.5), the behavior is undefined.

Then, if "Many programs require ..." is saying what I suspect= , I think
defining such byte-oriented accesses should be done before (or within)
the proposal. It will also resolve CWG issue 1701:
"Array vs sequence in object representation"
http://wg21.cmeerw.net/cwg/issue1701

--=20
k_satoda



So I think this is well-formed.

=C2= =A0 =C2=A0 unsigned char storage[ sizeof(int) ] ;
=C2=A0 =C2=A0 i= nt * 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

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

But this one is undefined behaviour?

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

Because= the storage for object i is not associated with array of unsigned char.=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/117168cf-8ab4-4048-aed6-38b68cb3ebca= %40isocpp.org.
------=_Part_2236_1697753840.1483830443441-- ------=_Part_2235_631660266.1483830443441-- .