--94eb2c074a043509470545429c82
Content-Type: text/plain; charset=UTF-8

I'm very interested in the resolution of that issue for the same reasons.

Currently, by my understanding, the idea that any object can be read as a
"sequence" of ((un)signed) char* is not massively useful, when one
seemingly cannot iterate past the first element in that sequence... It then
means even memcpy cannot be implemented without special magic by the
compiler.

--
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/CACGiwhER_fU%3DbVY0nob5Tap9s%3DAPgmeFS6sx6HQfnoPEKJjDVg%40mail.gmail.com.

--94eb2c074a043509470545429c82
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I&#39;m very interested in the resolution of that iss=
ue for the same reasons.<br><br></div>Currently, by my understanding, the i=
dea that any object can be read as a &quot;sequence&quot; of ((un)signed) c=
har* is not massively useful, when one seemingly cannot iterate past the fi=
rst element in that sequence... It then means even memcpy cannot be impleme=
nted without special magic by the compiler.<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhER_fU%3DbVY0nob5Tap9s%3DAPgmeF=
S6sx6HQfnoPEKJjDVg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhER_fU%=
3DbVY0nob5Tap9s%3DAPgmeFS6sx6HQfnoPEKJjDVg%40mail.gmail.com</a>.<br />

--94eb2c074a043509470545429c82--

.

Hello Kazutoshi,

There are plenty of examples of programs that perform byte-oriented access =
in the domain of operating systems and communications protocols. Consider r=
eading or writing a wire-protocol, for example. In fact, you seem to go on =
to give a brief sketch of exactly the sort of byte oriented access people w=
ant to perform.

Rather than speculate on core wording myself, and whether or not the patter=
n you described is undefined behavior, I'll just observe that the Core Work=
ing Group reviewed the proposal (twice - once in Oulu, once in Issaquah) an=
d approved it for adoption.

If you have specific questions about array-of-byte access to object represe=
ntations, then these questions would be completely orthogonal to the std::b=
yte proposal. They would exist today with unsigned char, and they would con=
tinue to exist whether or not std::byte is adopted. So modifying the propos=
al to address that issue is unnecessary. This proposal is about creating a =
distinct type for accessing bytes of memory - something that can also be do=
ne today using unsigned char or char. The semantics of such access should n=
ot be changed by the proposal...it's a different issue.

Hope that helps,

Neil.

-----Original Message-----
From: Kazutoshi Satoda [mailto:k_satoda@f2.dion.ne.jp]=20
Sent: Wednesday, January 4, 2017 2:43 AM
To: Neil MacIntosh <Neil.MacIntosh@microsoft.com>; std-proposals@isocpp.org
Subject: P0298: A byte type definition: with undefined pointer arithmetic?

from P0298R2: https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3A%=
2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0298r2=
..pdf&data=3D02%7C01%7CNeil.MacIntosh%40microsoft.com%7C931c7d44cdb941e437b2=
08d4348e8184%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C63619123404167591=
7&sdata=3DCl8GsBUSn8IgERF6qnnr7G3uCHZBeOmF1cFvwaqajVQ%3D&reserved=3D0
> 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 w=
as about to pass through, I want to understand more concretely what is goin=
g.

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

However, AFAIK, the current standard doesn't (or fails to) give well-define=
d 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=20
> "pointer to cv T", where T and the array element type are not similar=20
> (4.5), the behavior is undefined.

Then, if "Many programs require ..." is saying what I suspect, I think defi=
ning such byte-oriented accesses should be done before (or within) the prop=
osal. It will also resolve CWG issue 1701:
"Array vs sequence in object representation"
https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fwg21.cmee=
rw.net%2Fcwg%2Fissue1701&data=3D02%7C01%7CNeil.MacIntosh%40microsoft.com%7C=
931c7d44cdb941e437b208d4348e8184%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0=
%7C636191234041685924&sdata=3DRP%2BMlYq7xWlz5BrM13jeaG9fUL6U13iUEpApP5Plgk8=
%3D&reserved=3D0

--
k_satoda

--=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/DM5PR03MB282513F1EFF95A2C111963B189610%40DM5PR03=
MB2825.namprd03.prod.outlook.com.

.

------=_Part_2699_1556132105.1483561636496
Content-Type: multipart/alternative;
 boundary="----=_Part_2700_971713874.1483561636496"

------=_Part_2700_971713874.1483561636496
Content-Type: text/plain; charset=UTF-8

On Wednesday, January 4, 2017 at 2:54:36 AM UTC-8, D. B. wrote:
>
> I'm very interested in the resolution of that issue for the same reasons.
>
> Currently, by my understanding, the idea that any object can be read as a
> "sequence" of ((un)signed) char* is not massively useful, when one
> seemingly cannot iterate past the first element in that sequence... It then
> means even memcpy cannot be implemented without special magic by the
> compiler.
>

I think that the rule ought to be that char/unsigned char pointer
arithmetic is valid so long as you don't leave the bounds (or 1 past end)
of the dynamic type of the most-derived object.  Arithmetic with pointers
of other types would be sketchy at best.

It ought to be legal to do this:

struct Meow
{
    int x;
    float y;
    int z;
};

void Function(Meow *meow)
{
    int *p = &meow.x;
    unsigned char *b = reinterpret_cast<unsigned char *>(p);
    b += offsetof(Meow, z) - (offsetof(Meow, x) + sizeof(meow->x));
    int *q = reinterpret_cast<int *>(b);  // OK because pointer is equal to
a valid int * pointer
    *q = *p;   // same as meow->z = meow->x;
}


Melissa

--
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/db74f34b-b0ab-46cb-b94a-eeb96ef10c2d%40isocpp.org.

------=_Part_2700_971713874.1483561636496
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, January 4, 2017 at 2:54:36 AM UTC-8, D. B. w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>I&#=
39;m very interested in the resolution of that issue for the same reasons.<=
br><br></div>Currently, by my understanding, the idea that any object can b=
e read as a &quot;sequence&quot; of ((un)signed) char* is not massively use=
ful, when one seemingly cannot iterate past the first element in that seque=
nce... It then means even memcpy cannot be implemented without special magi=
c by the compiler.<br></div></blockquote><div><br>I think that the rule oug=
ht to be that char/unsigned char pointer arithmetic is valid so long as you=
 don&#39;t leave the bounds (or 1 past end) of the dynamic type of the most=
-derived object.=C2=A0 Arithmetic with pointers of other types would be ske=
tchy at best.<br><br>It ought to be legal to do this:<br><br><div style=3D"=
background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bor=
der-style: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"p=
rettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #606;" class=3D"styled-by-prettify">Meow</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> x</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">float</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> y</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">int=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> z</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"sty=
led-by-prettify">Function</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">(</span><span style=3D"color: #606;" class=3D"styled-by-pret=
tify">Meow</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">meow</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">p </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">meow</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">x</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">unsigned</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">char</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">*</span><span style=3D"color: #000;" class=3D"styled-by-prettify">b <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">reinterpret_cast</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">unsigned</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">char</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">*&gt;(</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">p</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br>=C2=A0 =C2=A0 b </span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">+=3D</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> offsetof</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">(</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Meo=
w</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> z</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">-</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">offsetof</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">(</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Meow<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> x</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">+</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">sizeof</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">me=
ow</span><span style=3D"color: #660;" class=3D"styled-by-prettify">-&gt;</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">x</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">));</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">q </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">reinterpret_cast</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">*&gt;(</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">b</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> =C2=A0</span><span style=3D=
"color: #800;" class=3D"styled-by-prettify">// OK because pointer is equal =
to a valid int * pointer</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">q </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">p</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> =C2=A0 </span><span style=3D"color:=
 #800;" class=3D"styled-by-prettify">// same as meow-&gt;z =3D meow-&gt;x;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></=
div><br><br>Melissa <br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/db74f34b-b0ab-46cb-b94a-eeb96ef10c2d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/db74f34b-b0ab-46cb-b94a-eeb96ef10c2d=
%40isocpp.org</a>.<br />

------=_Part_2700_971713874.1483561636496--

------=_Part_2699_1556132105.1483561636496--

.

--001a11443f0c5b0e6305454ab2c3
Content-Type: text/plain; charset=UTF-8

Indeed, that's pretty much what I would like... not for selfish reasons
anymore, since the design where I thought I needed that had *worse* UB that
I had to resolve ;-) but simply because it makes sense, makes the
"sequence" concept at all useful, and means that the so-called special
properties of char* pointers can actually exist.

But when I (thought I) needed this before, it was a fairly simple situation
where an object would have a method invoked on it, taking a pointer to one
of its members, and was then supposed to calculate the offset of that
member within itself and do stuff with it. That hardly seems unreasonable.

--
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/CACGiwhG5mz25RMcPR10YR-D%2BHcSThhhfE6kJORXDf3WoR64qPQ%40mail.gmail.com.

--001a11443f0c5b0e6305454ab2c3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Indeed, that&#39;s pretty much what I would like... n=
ot for selfish reasons anymore, since the design where I thought I needed t=
hat had <i>worse</i> UB that I had to resolve ;-) but simply because it mak=
es sense, makes the &quot;sequence&quot; concept at all useful, and means t=
hat the so-called special properties of char* pointers can actually exist.<=
br><br></div>But when I (thought I) needed this before, it was a fairly sim=
ple situation where an object would have a method invoked on it, taking a p=
ointer to one of its members, and was then supposed to calculate the offset=
 of that member within itself and do stuff with it. That hardly seems unrea=
sonable.<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhG5mz25RMcPR10YR-D%2BHcSThhhfE6=
kJORXDf3WoR64qPQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhG5mz25RM=
cPR10YR-D%2BHcSThhhfE6kJORXDf3WoR64qPQ%40mail.gmail.com</a>.<br />

--001a11443f0c5b0e6305454ab2c3--

.

------=_Part_2888_1589656938.1483613141860
Content-Type: multipart/alternative;
 boundary="----=_Part_2889_1247348354.1483613141860"

------=_Part_2889_1247348354.1483613141860
Content-Type: text/plain; charset=UTF-8

I can't say that I have checked but isn't an array of enum values
equivalent to its underlying type when it comes to size and alignment?

As byte is defined as an enum with a unsigned char as underlying type
pointer arithmetic should be defined as expected: to be bytewise. I don't
think this requires specific mention in the standard text.

Den onsdag 4 januari 2017 kl. 21:33:27 UTC+1 skrev D. B.:
>
> Indeed, that's pretty much what I would like... not for selfish reasons
> anymore, since the design where I thought I needed that had *worse* UB
> that I had to resolve ;-) but simply because it makes sense, makes the
> "sequence" concept at all useful, and means that the so-called special
> properties of char* pointers can actually exist.
>
> But when I (thought I) needed this before, it was a fairly simple
> situation where an object would have a method invoked on it, taking a
> pointer to one of its members, and was then supposed to calculate the
> offset of that member within itself and do stuff with it. That hardly seems
> unreasonable.
>

--
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/f39b3dd8-538e-4b84-8548-a9dc7e3f592a%40isocpp.org.

------=_Part_2889_1247348354.1483613141860
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I can&#39;t say that I have checked but isn&#39;t an array=
 of enum values equivalent to its underlying type when it comes to size and=
 alignment?<div><br></div><div>As byte is defined as an enum with a unsigne=
d char as underlying type pointer arithmetic should be defined as expected:=
 to be bytewise. I don&#39;t think this requires specific mention in the st=
andard text.<br><br>Den onsdag 4 januari 2017 kl. 21:33:27 UTC+1 skrev D. B=
..:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Indeed=
, that&#39;s pretty much what I would like... not for selfish reasons anymo=
re, since the design where I thought I needed that had <i>worse</i> UB that=
 I had to resolve ;-) but simply because it makes sense, makes the &quot;se=
quence&quot; concept at all useful, and means that the so-called special pr=
operties of char* pointers can actually exist.<br><br></div>But when I (tho=
ught I) needed this before, it was a fairly simple situation where an objec=
t would have a method invoked on it, taking a pointer to one of its members=
, and was then supposed to calculate the offset of that member within itsel=
f and do stuff with it. That hardly seems unreasonable.<br></div>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f39b3dd8-538e-4b84-8548-a9dc7e3f592a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f39b3dd8-538e-4b84-8548-a9dc7e3f592a=
%40isocpp.org</a>.<br />

------=_Part_2889_1247348354.1483613141860--

------=_Part_2888_1589656938.1483613141860--

.

--047d7b86e2f893198b054557c27d
Content-Type: text/plain; charset=UTF-8

On Thu, Jan 5, 2017 at 10:45 AM, Bengt Gustafsson <
bengt.gustafsson@beamways.com> wrote:

> I can't say that I have checked but isn't an array of enum values
> equivalent to its underlying type when it comes to size and alignment?
>
> As byte is defined as an enum with a unsigned char as underlying type
> pointer arithmetic should be defined as expected: to be bytewise. I don't
> think this requires specific mention in the standard text.
>

It's worse than that! The problem is that char* itself does not seem to be
allowed to have the special properties it supposedly has, for reading other
objects as a "sequence" o char*, because it is formally undefined to
increment that pointer to the next byte in the "sequence". The linked issue
is an attempt to clarify what this nebulous "sequence" really is and
whether (or why not) it is equivalent to an *array* for the purposes of
indexing/arithmetic.

So if char* isn't allowed to do these things, std::byte won't be,
regardless of any transitive properties it gets from other facets of the
Standard.

--
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/CACGiwhE9c%2Bcgwrp0mVutjoxC7kP5OvH_zoLtOj7fLcNq_h3xHg%40mail.gmail.com.

--047d7b86e2f893198b054557c27d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Jan 5, 2017 at 10:45 AM, Bengt Gustafsson <span dir=3D"ltr">&lt;<a href=
=3D"mailto:bengt.gustafsson@beamways.com" target=3D"_blank">bengt.gustafsso=
n@beamways.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr">I can&#39;t say that I have checked but isn&#39;t an array of =
enum values equivalent to its underlying type when it comes to size and ali=
gnment?<div><br></div><div>As byte is defined as an enum with a unsigned ch=
ar as underlying type pointer arithmetic should be defined as expected: to =
be bytewise. I don&#39;t think this requires specific mention in the standa=
rd text.<span class=3D""></span> <br></div></div></blockquote></div><br></d=
iv><div class=3D"gmail_extra">It&#39;s worse than that! The problem is that=
 char* itself does not seem to be allowed to have the special properties it=
 supposedly has, for reading other objects as a &quot;sequence&quot; o char=
*, because it is formally undefined to increment that pointer to the next b=
yte in the &quot;sequence&quot;. The linked issue is an attempt to clarify =
what this nebulous &quot;sequence&quot; really is and whether (or why not) =
it is equivalent to an <i>array</i> for the purposes of indexing/arithmetic=
..<br><br></div><div class=3D"gmail_extra">So if char* isn&#39;t allowed to =
do these things, std::byte won&#39;t be, regardless of any transitive prope=
rties it gets from other facets of the Standard.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhE9c%2Bcgwrp0mVutjoxC7kP5OvH_zo=
LtOj7fLcNq_h3xHg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhE9c%2Bcg=
wrp0mVutjoxC7kP5OvH_zoLtOj7fLcNq_h3xHg%40mail.gmail.com</a>.<br />

--047d7b86e2f893198b054557c27d--

.

On 2017/01/05 4:21 +0900, Neil MacIntosh wrote:
> There are plenty of examples of programs that perform byte-oriented
> access in the domain of operating systems and communications protocols.
> Consider reading or writing a wire-protocol, for example. In fact, you
> seem to go on to give a brief sketch of exactly the sort of byte
> oriented access people want to perform.

It sounds like that what I suspected is going on. Hmm.

> Rather than speculate on core wording myself, and whether or not the
> pattern you described is undefined behavior, I'll just observe that the
> Core Working Group reviewed the proposal (twice - once in Oulu, once in
> Issaquah) and approved it for adoption.
>
> If you have specific questions about array-of-byte access to object
> representations, then these questions would be completely orthogonal to
> the std::byte proposal. They would exist today with unsigned char, and
> they would continue to exist whether or not std::byte is adopted. So
> modifying the proposal to address that issue is unnecessary. This
> proposal is about creating a distinct type for accessing bytes of memory
> - something that can also be done today using unsigned char or char. The
> semantics of such access should not be changed by the proposal...it's a
> different issue.

Now I see your point of view. But I disagree. I think the defined-ness
of byte-oriented access is not orthogonal to the proposal, rather I see
it as a major factor of the impact of the proposal.

If the byte-oriented access results in undefined behavior, adding a new
byte type which help such accesses is harmful by encouraging people to
write programs with undefined behavior, and approving such a feature
will decrease reliability of the standard and the committee. Such
negative impact may outweigh the benefit of the feature.
(I personally think "the benefit" of a new byte type, even when the
said pointer arithmetic were defined, is not so significant; I can live
without it.)

I'll seek a way to ask CWG whether the approval is stable in sight of
the said problems. Please tell me if you (or someone) know a preferred
way.

--
k_satoda

--
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/21f7e054-6461-2687-8dba-3915a63a0873%40f2.dion.ne.jp.

.

I am still not sure you are correct about whether that access pattern is ac=
tually undefined behavior. I'm afraid I'm not a language lawyer ;-)

I would suggest you ask Core the question about undefined behavior via thei=
r mailing reflector.

I'm not sure how adding a new type that is distinct from existing types use=
d to also hold both integers and characters, but has the exact same semanti=
cs as those types worsens the situation. It certainly does nothing to encou=
rage people to write the type of code we are discussing. That sort of code =
is already written - millions of lines of it - and more is written every da=
y. Passing or blocking the byte proposal will have no impact on that. I cer=
tainly don't see what sort of evidence you can point to that adding "byte" =
in addition to "unsigned char", would somehow reduce the reliability of the=
 language.

The intent of the proposal is to enable people to be less ambiguous about t=
heir intended use of a pointer (are they using it to access some object sto=
rage, or an integer, or a character?). I think it is relatively uncontrover=
sial to say that having distinct types for these different purposes makes p=
rograms easier to understand, analyze and maintain.=20

Neil.

-----Original Message-----
From: Kazutoshi Satoda [mailto:k_satoda@f2.dion.ne.jp]=20
Sent: Thursday, January 5, 2017 10:21 AM
To: Neil MacIntosh <Neil.MacIntosh@microsoft.com>; std-proposals@isocpp.org
Subject: Re: P0298: A byte type definition: with undefined pointer arithmet=
ic?

On 2017/01/05 4:21 +0900, Neil MacIntosh wrote:
> There are plenty of examples of programs that perform byte-oriented=20
> access in the domain of operating systems and communications protocols.
> Consider reading or writing a wire-protocol, for example. In fact, you=20
> seem to go on to give a brief sketch of exactly the sort of byte=20
> oriented access people want to perform.

It sounds like that what I suspected is going on. Hmm.

> Rather than speculate on core wording myself, and whether or not the=20
> pattern you described is undefined behavior, I'll just observe that=20
> the Core Working Group reviewed the proposal (twice - once in Oulu,=20
> once in
> Issaquah) and approved it for adoption.
>
> If you have specific questions about array-of-byte access to object=20
> representations, then these questions would be completely orthogonal=20
> to the std::byte proposal. They would exist today with unsigned char,=20
> and they would continue to exist whether or not std::byte is adopted.=20
> So modifying the proposal to address that issue is unnecessary. This=20
> proposal is about creating a distinct type for accessing bytes of=20
> memory
> - something that can also be done today using unsigned char or char.=20
> The semantics of such access should not be changed by the=20
> proposal...it's a different issue.

Now I see your point of view. But I disagree. I think the defined-ness of b=
yte-oriented access is not orthogonal to the proposal, rather I see it as a=
 major factor of the impact of the proposal.

If the byte-oriented access results in undefined behavior, adding a new byt=
e type which help such accesses is harmful by encouraging people to write p=
rograms with undefined behavior, and approving such a feature will decrease=
 reliability of the standard and the committee. Such negative impact may ou=
tweigh the benefit of the feature.
(I personally think "the benefit" of a new byte type, even when the said po=
inter arithmetic were defined, is not so significant; I can live without it=
..)

I'll seek a way to ask CWG whether the approval is stable in sight of the s=
aid problems. Please tell me if you (or someone) know a preferred way.

--
k_satoda

--=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/DM5PR03MB28250208BA0FC6A7AF60F80989630%40DM5PR03=
MB2825.namprd03.prod.outlook.com.

.

On 2017/01/07 8:27 +0900, Neil MacIntosh wrote:
> I am still not sure you are correct about whether that access pattern is
> actually undefined behavior. I'm afraid I'm not a language lawyer ;-)

For me, it seems somewhat easy. Consider the following concrete example:

  int i = 0;
  unsigned char* p = reinterpret_cast<unsigned char*>(&i);
  p + 1;

"p" points to "i", which is an object of type int.

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 are not similar
> (4.5), the behavior is undefined.
and footnote 86:
> An object that is not an array element is considered to belong to a
> single-element array for this purpose; see 5.3.1.

"T" and "the array element type" in the above example are unsigned char
and int, respectively. Then, because unsigned char and int are not
similar, the behavior is undefined.

Can you assert otherwise?

> I would suggest you ask Core the question about undefined behavior via
> their mailing reflector.

Thank you. But I can't do that by myself now because I'm not a member of
national body, and don't have attended a meeting.
https://stackoverflow.com/questions/9070651/c-standards-committee-reflector-mailing-lists

I'll seek someone who can forward this to the Core mailing reflector.
(Do you know?)

> I'm not sure how adding a new type that is distinct from existing
> types used to also hold both integers and characters, but has the exact
> same semantics as those types worsens the situation. It certainly does
> nothing to encourage people to write the type of code we are discussing.

If the proposal got adopted, someone will write an example code to
demonstrate the new feature. But it will be hard to make such an example
without violating the above explained language rule.

> That sort of code is already written - millions of lines of it - and
> more is written every day. Passing or blocking the byte proposal will
> have no impact on that.

The situation sounds same with singed integer overflow, or type based
aliasing rule. People write that sort of code at their own risk, or with
a guarantee given by the implementation. But it doesn't mean the
committee can ignore the existing language rule to standardize a new
feature.

> I certainly don't see what sort of evidence you can point to that adding
> "byte" in addition to "unsigned char", would somehow reduce the
> reliability of the language.

If something says "Here is the feature to do X, but X results in
undefined behavior", I can't rely on that, can you?

> The intent of the proposal is to enable people to be less ambiguous
> about their intended use of a pointer (are they using it to access some
> object storage, or an integer, or a character?). I think it is
> relatively uncontroversial to say that having distinct types for these
> different purposes makes programs easier to understand, analyze and
> maintain.

It sounds like that it is also good to add [[type-punned]] attribute for
pointers without touching existing type based aliasing rule, or to add
[[overflow-wraps]] attribute for signed integer types without touching
existing rule on overflow. It might be actually good in some points you
mentioned, but it adds the language another inconsistency which the
standard should reduce/avoid.

--
k_satoda

--
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/6a8ff667-3952-e6dd-a2cb-c0ba642b2ed1%40f2.dion.ne.jp.

.

------=_Part_1912_1678509821.1483818741705
Content-Type: multipart/alternative;
 boundary="----=_Part_1913_1414418781.1483818741705"

------=_Part_1913_1414418781.1483818741705
Content-Type: text/plain; charset=UTF-8

On Wednesday, January 4, 2017 at 2:43:24 AM UTC-8, Kazutoshi SATODA wrote:

> [...] AFAIK, the current standard doesn't (or fails to) give
> well-defined behavior to such byte-oriented access on objects of
> arbitrary types. [...]
>

I, for one, would be shocked if the Committee (or anyone, really) actually
wants byte-oriented pointer arithmetic within objects to be undefined. I
strongly anticipate that CWG will accept issue 1701 as a defect and make it
well-defined. Remember, we're not really talking about the byte accesses
themselves; such aliasing is already well-defined for char and unsigned char.
It is only the charPtr + i (or charPtr[i]) expression that is currently
undefined, and that expression can be awkwardly worked around anyway on
some platforms (e.g., cast to integer, add, cast back to pointer).

--
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/b7eda119-bc5d-4940-b359-45088e6f4d3e%40isocpp.org.

------=_Part_1913_1414418781.1483818741705
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, January 4, 2017 at 2:43:24 AM UTC-8, Kazutos=
hi SATODA wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">[...] AFAI=
K, the current standard doesn&#39;t (or fails to) give
<br>well-defined behavior to such byte-oriented access on objects of
<br>arbitrary types. [...]<br></blockquote><div><br>I, for one, would be sh=
ocked if the Committee (or anyone, really) actually wants byte-oriented poi=
nter arithmetic within objects to be undefined. I strongly anticipate that =
CWG will accept issue 1701 as a defect and make it well-defined. Remember, =
we&#39;re not really talking about the byte accesses themselves; such alias=
ing is already well-defined for <span style=3D"font-family: courier new,mon=
ospace;">char</span> and <span style=3D"font-family: courier new,monospace;=
">unsigned char</span>. It is only the <span style=3D"font-family: courier =
new,monospace;">charPtr + i</span> (or <span style=3D"font-family: courier =
new,monospace;">charPtr[i]</span>) expression that is currently undefined, =
and that expression can be awkwardly worked around anyway on some platforms=
 (e.g., cast to integer, add, cast back to pointer).<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b7eda119-bc5d-4940-b359-45088e6f4d3e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b7eda119-bc5d-4940-b359-45088e6f4d3e=
%40isocpp.org</a>.<br />

------=_Part_1913_1414418781.1483818741705--

------=_Part_1912_1678509821.1483818741705--

.

--f403045eaca849f7c4054586a22d
Content-Type: text/plain; charset=UTF-8

On Sat, Jan 7, 2017 at 7:52 PM, Chris Hallock <christopherhallock@gmail.com>
wrote:

> I, for one, would be shocked if the Committee (or anyone, really) actually
> wants byte-oriented pointer arithmetic within objects to be undefined. I
> strongly anticipate that CWG will accept issue 1701 as a defect and make it
> well-defined.
>

I hope you're right.



> Remember, we're not really talking about the byte accesses themselves;
> such aliasing is already well-defined for char and unsigned char. It is
> only the charPtr + i (or charPtr[i]) expression that is currently
> undefined, and that expression can be awkwardly worked around anyway on
> some platforms (e.g., cast to integer, add, cast back to pointer).
>

Oh, sure, on most platforms/compilers, even the non-workaround syntax just
works, because the compilers don't go to lengths to maliciously subvert
people's intuition. That doesn't make it well-defined per the IS.

In fact, I'm pretty sure that what you said still isn't valid. It's not the
arithmetic that's the problem: it's the fact that it's performed in such a
way as to generate a final pointer that doesn't point into the same
contiguous array as the original source pointer (because a "sequence" of
unsigned char is not an array, formally). By the same token, subtracting or
comparing pointers within such a "sequence" is not valid. See:
https://www.securecoding.cert.org/confluence/display/c/ARR36-C.+Do+not+subtract+or+compare+two+pointers+that+do+not+refer+to+the+same+array
These all seem like adjacent facets of the same issue to me.

--
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/CACGiwhG2gei5%3Dk1tO%2BZVkMjoFSMyEVXwetwBKtKXQRqAXV8mgg%40mail.gmail.com.

--f403045eaca849f7c4054586a22d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Jan 7, 2017 at 7:52 PM, Chris Hallock <span dir=3D"ltr">&lt;<a target=
=3D"_blank" href=3D"mailto:christopherhallock@gmail.com">christopherhallock=
@gmail.com</a>&gt;</span> wrote:<br><blockquote style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gm=
ail_quote"><div dir=3D"ltr">I, for one, would be shocked if the Committee (=
or anyone, really) actually wants byte-oriented pointer arithmetic within o=
bjects to be undefined. I strongly anticipate that CWG will accept issue 17=
01 as a defect and make it well-defined.</div></blockquote><div><br></div><=
div>I hope you&#39;re right.<br><br></div><div>=C2=A0</div><blockquote styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex" class=3D"gmail_quote"><div dir=3D"ltr">Remember, we&#39;re not =
really talking about the byte accesses themselves; such aliasing is already=
 well-defined for <span style=3D"font-family:courier new,monospace">char</s=
pan> and <span style=3D"font-family:courier new,monospace">unsigned char</s=
pan>. It is only the <span style=3D"font-family:courier new,monospace">char=
Ptr + i</span> (or <span style=3D"font-family:courier new,monospace">charPt=
r[i]</span>) expression that is currently undefined, and that expression ca=
n be awkwardly worked around anyway on some platforms (e.g., cast to intege=
r, add, cast back to pointer).<br></div></blockquote><div><br></div><div>Oh=
, sure, on most platforms/compilers, even the non-workaround syntax just wo=
rks, because the compilers don&#39;t go to lengths to maliciously subvert p=
eople&#39;s intuition. That doesn&#39;t make it well-defined per the IS.<br=
><br></div><div>In fact, I&#39;m pretty sure that what you said still isn&#=
39;t valid. It&#39;s not the arithmetic that&#39;s the problem: it&#39;s th=
e fact that it&#39;s performed in such a way as to generate a final pointer=
 that doesn&#39;t point into the same contiguous array as the original sour=
ce pointer (because a &quot;sequence&quot; of unsigned char is not an array=
, formally). By the same token, subtracting or comparing pointers within su=
ch a &quot;sequence&quot; is not valid. See:=C2=A0 <a href=3D"https://www.s=
ecurecoding.cert.org/confluence/display/c/ARR36-C.+Do+not+subtract+or+compa=
re+two+pointers+that+do+not+refer+to+the+same+array">https://www.securecodi=
ng.cert.org/confluence/display/c/ARR36-C.+Do+not+subtract+or+compare+two+po=
inters+that+do+not+refer+to+the+same+array</a> These all seem like adjacent=
 facets of the same issue to me.<br></div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhG2gei5%3Dk1tO%2BZVkMjoFSMyEVXw=
etwBKtKXQRqAXV8mgg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhG2gei5=
%3Dk1tO%2BZVkMjoFSMyEVXwetwBKtKXQRqAXV8mgg%40mail.gmail.com</a>.<br />

--f403045eaca849f7c4054586a22d--

.

--047d7b3a8c2cd526a0054586b0b7
Content-Type: text/plain; charset=UTF-8

That said, if you could elaborate on situations in which you think casting
to int, adding, then casting back formally improves things, then I'd be
interested.

I had a thread here before, about the subtraction issue, and other
workarounds were proposed - which, while ingenious and frankly hilarious in
their inventiveness, really made me wish a lot of things were better
defined. As is, we have this codified concept of 'sequence of unsigned
char' but it doesn't seem *useful* for anything...

--
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/CACGiwhHU_WKe4q-0DFS5pdHcJHAvt%2BL7-gOwM9YzozNMDBAefQ%40mail.gmail.com.

--047d7b3a8c2cd526a0054586b0b7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>That said, if you could elaborate on situations in wh=
ich you think casting to int, adding, then casting back formally improves t=
hings, then I&#39;d be interested.<br><br></div>I had a thread here before,=
 about the subtraction issue, and other workarounds were proposed - which, =
while ingenious and frankly hilarious in their inventiveness, really made m=
e wish a lot of things were better defined. As is, we have this codified co=
ncept of &#39;sequence of unsigned char&#39; but it doesn&#39;t seem <i>use=
ful</i> for anything...<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhHU_WKe4q-0DFS5pdHcJHAvt%2BL7-g=
OwM9YzozNMDBAefQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhHU_WKe4q=
-0DFS5pdHcJHAvt%2BL7-gOwM9YzozNMDBAefQ%40mail.gmail.com</a>.<br />

--047d7b3a8c2cd526a0054586b0b7--

.

------=_Part_2250_211835754.1483824980970
Content-Type: multipart/alternative;
 boundary="----=_Part_2251_1964019998.1483824980970"

------=_Part_2251_1964019998.1483824980970
Content-Type: text/plain; charset=UTF-8

On Saturday, January 7, 2017 at 12:07:59 PM UTC-8, D. B. wrote:
>
> That said, if you could elaborate on situations in which you think casting
> to int, adding, then casting back formally improves things, then I'd be
> interested.
>

Well, not realistic situations, no :). It's just a thought experiment. That
is, there is no point in forbidding this kind of pointer arithmetic, *even
if the Committee and compiler authors wanted to*, because you can acheive
the same effect anyway with various, *well-formed* hacks, such as

   - performing the offset in the integer domain
   - performing the offset in non-C++ code (the ultimate fall-back!)
   - repeatedly incrementing the pointer by 1 and using std::launder on it,
   in a loop (Myriachan's idea in an old thread, IIRC)

--
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/9dd7067b-ec8d-463c-8971-ac49a320f68f%40isocpp.org.

------=_Part_2251_1964019998.1483824980970
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, January 7, 2017 at 12:07:59 PM UTC-8, D. B. w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Tha=
t said, if you could elaborate on situations in which you think casting to =
int, adding, then casting back formally improves things, then I&#39;d be in=
terested.<br></div></div></blockquote><div><br>Well, not realistic situatio=
ns, no :). It&#39;s just a thought experiment. That is, there is no point i=
n forbidding this kind of pointer arithmetic, <i>even if the Committee and =
compiler authors wanted to</i>, because you can acheive the same effect any=
way with various, <i>well-formed</i> hacks, such as<br><ul><li>performing t=
he offset in the integer domain<br></li><li>performing the offset in non-C+=
+ code (the ultimate fall-back!)<br></li><li>repeatedly incrementing the po=
inter by 1 and using <span style=3D"font-family: courier new,monospace;">st=
d::launder</span> on it, in a loop (Myriachan&#39;s idea in an old thread, =
IIRC)</li></ul></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9dd7067b-ec8d-463c-8971-ac49a320f68f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9dd7067b-ec8d-463c-8971-ac49a320f68f=
%40isocpp.org</a>.<br />

------=_Part_2251_1964019998.1483824980970--

------=_Part_2250_211835754.1483824980970--

.

--f403045eaca878256a05458836eb
Content-Type: text/plain; charset=UTF-8

Granted, offsetting has plenty of plausible (and slapstick) workarounds,
but things like subtraction and comparison aren't nearly so lucky. Giving
the object representation *sequence* the same guarantees as *arrays* of
unsigned char would seem to solve this.

However, I can't recall whether there are dry theoretical reasons that the
Committee might prefer to remain vague and noncommittal on this... which
would be fine if not for the "sequence" wording, which to me reads like an
unfulfilled *hint* about such allowances.

FWIW: The code where I thought I needed these was completely refactored to
use arrays, albeit due to other UB that was revealed; otherwise I was
seriously considering retaining the formally disallowed subtraction. So I'm
really just an interested observer for now, without current insights into
what should or shouldn't be allowed, as others might have.

--
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/CACGiwhHW2UG03uzL55cmnCEVx08kZufjTHosZm8MNUYghio-ww%40mail.gmail.com.

--f403045eaca878256a05458836eb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Granted, offsetting has plenty of plausible (and slap=
stick) workarounds, but things like subtraction and comparison aren&#39;t n=
early so lucky. Giving the object representation <i>sequence</i> the same g=
uarantees as <i>arrays</i> of unsigned char would seem to solve this.<br><b=
r></div>However, I can&#39;t recall whether there are dry theoretical reaso=
ns that the Committee might prefer to remain vague and noncommittal on this=
.... which would be fine if not for the &quot;sequence&quot; wording, which =
to me reads like an unfulfilled <i>hint</i> about such allowances.<br><br>F=
WIW: The code where I thought I needed these was completely refactored to u=
se arrays, albeit due to other UB that was revealed; otherwise I was seriou=
sly considering retaining the formally disallowed subtraction. So I&#39;m r=
eally just an interested observer for now, without current insights into wh=
at should or shouldn&#39;t be allowed, as others might have.<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhHW2UG03uzL55cmnCEVx08kZufjTHos=
Zm8MNUYghio-ww%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhHW2UG03uzL=
55cmnCEVx08kZufjTHosZm8MNUYghio-ww%40mail.gmail.com</a>.<br />

--f403045eaca878256a05458836eb--

.

------=_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<unsigned char *>(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

<div dir=3D"ltr"><br><br>On Wednesday, January 4, 2017 at 7:43:24 PM UTC+9,=
 Kazutoshi SATODA wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">from P=
0298R2: <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/=
p0298r2.pdf" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D=
&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2F=
sc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0298r2.pdf\x26sa\x3dD\x26sntz\x3d1\x2=
6usg\x3dAFQjCNGff0NBaHg7otGwqaxvADR7o5R2oQ&#39;;return true;" onclick=3D"th=
is.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org=
%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0298r2.pdf\x26sa\x3dD\x26sn=
tz\x3d1\x26usg\x3dAFQjCNGff0NBaHg7otGwqaxvADR7o5R2oQ&#39;;return true;">htt=
p://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2016/<wbr>p0298r2.pdf<=
/a>
<br>&gt; Motivation and Scope
<br>&gt; Many programs require byte-oriented access to memory. ...
<br>
<br>Could you please show examples of such programs?
<br>
<br>
<br>As I read N4623 (WG21 2016-11 Issaquah Minutes) and saw that the
<br>proposal was about to pass through, I want to understand more concretel=
y
<br>what is going.
<br>
<br>I suspect that such programs do something like obtaining unsigned char*
<br>which points to an int object via reinterpret_cast and iterating throug=
h
<br>it as if the pointer points to an element of unsigned char[sizeof(int)]=
,
<br>as I personally have seen many such programs.
<br>
<br>However, AFAIK, the current standard doesn&#39;t (or fails to) give
<br>well-defined behavior to such byte-oriented access on objects of
<br>arbitrary types.
<br>N4618 5.7 [expr.add] p6 says:
<br>&gt; For addition or subtraction, if the expressions P or Q have type
<br>&gt; &quot;pointer to cv T&quot;, where T and the array element type ar=
e not similar
<br>&gt; (4.5), the behavior is undefined.
<br>
<br>Then, if &quot;Many programs require ...&quot; is saying what I suspect=
, I think
<br>defining such byte-oriented accesses should be done before (or within)
<br>the proposal. It will also resolve CWG issue 1701:
<br>&quot;Array vs sequence in object representation&quot;
<br><a href=3D"http://wg21.cmeerw.net/cwg/issue1701" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x=
3dhttp%3A%2F%2Fwg21.cmeerw.net%2Fcwg%2Fissue1701\x26sa\x3dD\x26sntz\x3d1\x2=
6usg\x3dAFQjCNEdha33ZD1IqCkJaeaIY31ywE_feg&#39;;return true;" onclick=3D"th=
is.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwg21.cmeerw.net%=
2Fcwg%2Fissue1701\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEdha33ZD1IqCkJaea=
IY31ywE_feg&#39;;return true;">http://wg21.cmeerw.net/cwg/<wbr>issue1701</a=
>
<br>
<br>--=20
<br>k_satoda
<br></blockquote><div><br></div><div><br></div><div>=C2=A7 1.8 p3 said (p02=
98r2 add &quot;array of N std::byte&quot; to this wording)</div><div>&gt;If=
 a complete object is created (5.3.4) in storage associated with another ob=
ject e of type =E2=80=9Carray of N</div><div>&gt;unsigned char=E2=80=9D, th=
at array provides storage for the created object if:=C2=A0</div><div><br></=
div><div>So I think this is well-formed.</div><div><br></div><div><div>=C2=
=A0 =C2=A0 unsigned char storage[ sizeof(int) ] ;</div><div>=C2=A0 =C2=A0 i=
nt * p1 =3D new(storage) int(42) ;</div><div>=C2=A0 =C2=A0 unsigned char * =
p2 =3D reinterpret_cast&lt;unsigned char *&gt;(p1) ;</div><div>=C2=A0 =C2=
=A0 p2 + 1 ; // OK</div></div><div><br></div><div>This is also well-formed.=
</div><div><br></div><div><div>=C2=A0 =C2=A0 union { int i ; unsigned char =
buf[sizeof(int)] ; } u ;</div><div>=C2=A0 =C2=A0 u.i =3D 42 ;</div><div>=C2=
=A0 =C2=A0 unsigned char * p3 =3D reinterpret_cast&lt; unsigned char *&gt;(=
 &amp;u ) ;</div><div>=C2=A0 =C2=A0 p3 + 1 ; // OK</div></div><div><br></di=
v><div>But this one is undefined behaviour?</div><div><br></div><div><div>=
=C2=A0 =C2=A0 int i =3D 42 ;</div><div>=C2=A0 =C2=A0 unsigned char * p4 =3D=
 reinterpret_cast&lt; unsigned char *&gt;( &amp;i ) ;</div><div>=C2=A0 =C2=
=A0 p4 + 1 ; // Undefined behaviour?</div></div><div><br></div><div>Because=
 the storage for object i is not associated with array of unsigned char.=C2=
=A0</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/117168cf-8ab4-4048-aed6-38b68cb3ebca%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/117168cf-8ab4-4048-aed6-38b68cb3ebca=
%40isocpp.org</a>.<br />

------=_Part_2236_1697753840.1483830443441--

------=_Part_2235_631660266.1483830443441--

.

------=_Part_2349_1282421112.1483838019427
Content-Type: multipart/alternative;
 boundary="----=_Part_2350_1731349889.1483838019427"

------=_Part_2350_1731349889.1483838019427
Content-Type: text/plain; charset=UTF-8

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<unsigned char *>(p1) ;
>     p2 + 1 ; // OK
>

Agreed, except that, since the int object is not pointer-interconvertable
<http://eel.is/c++draft/basic.compound#4> to storage[0], you also need to
std::launder <http://eel.is/c++draft/ptr.launder> the result of the cast
under C++17.


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, 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.)

--
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/d5d59214-e783-4d5c-bc34-1598d3eb34e9%40isocpp.org.

------=_Part_2350_1731349889.1483838019427
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, January 7, 2017 at 3:07:23 PM UTC-8, Ryou wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">[...]<br><=
div>So I think this is well-formed.</div><div><br></div><div><div>=C2=A0 =
=C2=A0 unsigned char storage[ sizeof(int) ] ;</div><div>=C2=A0 =C2=A0 int *=
 p1 =3D new(storage) int(42) ;</div><div>=C2=A0 =C2=A0 unsigned char * p2 =
=3D reinterpret_cast&lt;unsigned char *&gt;(p1) ;</div><div>=C2=A0 =C2=A0 p=
2 + 1 ; // OK</div></div></div></blockquote><div><br>Agreed, except that, s=
ince the <span style=3D"font-family: courier new,monospace;">int</span> obj=
ect is not <a href=3D"http://eel.is/c++draft/basic.compound#4">pointer-inte=
rconvertable</a> to <span style=3D"font-family: courier new,monospace;">sto=
rage[0]</span>, you also need to <a href=3D"http://eel.is/c++draft/ptr.laun=
der"><span style=3D"font-family: courier new,monospace;">std::launder</span=
></a> the result of the cast under C++17.<br><br><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>This is also =
well-formed.</div><div><br></div><div><div>=C2=A0 =C2=A0 union { int i ; un=
signed char buf[sizeof(int)] ; } u ;</div><div>=C2=A0 =C2=A0 u.i =3D 42 ;</=
div><div>=C2=A0 =C2=A0 unsigned char * p3 =3D reinterpret_cast&lt; unsigned=
 char *&gt;( &amp;u ) ;</div><div>=C2=A0 =C2=A0 p3 + 1 ; // OK</div></div><=
/div></blockquote><div><br>This example also needs <span style=3D"font-fami=
ly: courier new,monospace;">std::launder</span>, but even with that, <span =
style=3D"font-family: courier new,monospace;">p3</span> would only point to=
 the first byte in the object representation of <span style=3D"font-family:=
 courier new,monospace;">u</span> (or, equivalently, <span style=3D"font-fa=
mily: courier new,monospace;">u.i</span>), not <span style=3D"font-family: =
courier new,monospace;">u.buf[0]</span>. <span style=3D"font-family: courie=
r new,monospace;">u.buf[0]</span> doesn&#39;t exist (as a live object). It =
doesn&#39;t exist because <span style=3D"font-family: courier new,monospace=
;">u.buf</span> itself doesn&#39;t exist, and that&#39;s because it was nev=
er made the active member. There&#39;s only <span style=3D"font-family: cou=
rier new,monospace;">u.i</span>. Since there is no live array object, the l=
ast line is strictly undefined under the current (but presumably defective)=
 wording.<br><br><br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div></div><div>But this one is undefined behaviour?</div><di=
v><br></div><div><div>=C2=A0 =C2=A0 int i =3D 42 ;</div><div>=C2=A0 =C2=A0 =
unsigned char * p4 =3D reinterpret_cast&lt; unsigned char *&gt;( &amp;i ) ;=
</div><div>=C2=A0 =C2=A0 p4 + 1 ; // Undefined behaviour?</div></div><div><=
br></div><div>Because the storage for object i is not associated with array=
 of unsigned char.=C2=A0</div></div></blockquote><div><br>Yes, under the cu=
rrent (but presumably defective) wording. (Also, this needs <span style=3D"=
font-family: courier new,monospace;">std::launder</span>.)<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d5d59214-e783-4d5c-bc34-1598d3eb34e9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d5d59214-e783-4d5c-bc34-1598d3eb34e9=
%40isocpp.org</a>.<br />

------=_Part_2350_1731349889.1483838019427--

------=_Part_2349_1282421112.1483838019427--

.

------=_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<unsigned char *>(p1) ;
>>     p2 + 1 ; // OK
>>
>
> Agreed, except that, since the int object is not pointer-interconvertable
> <http://eel.is/c++draft/basic.compound#4> to storage[0], you also need to
> std::launder <http://eel.is/c++draft/ptr.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

<div dir=3D"ltr">On Saturday, January 7, 2017 at 8:13:39 PM UTC-5, Chris Ha=
llock wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">O=
n Saturday, January 7, 2017 at 3:07:23 PM UTC-8, Ryou wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div dir=3D"ltr">[...]<br><div>So I think this is =
well-formed.</div><div><br></div><div><div>=C2=A0 =C2=A0 unsigned char stor=
age[ sizeof(int) ] ;</div><div>=C2=A0 =C2=A0 int * p1 =3D new(storage) int(=
42) ;</div><div>=C2=A0 =C2=A0 unsigned char * p2 =3D reinterpret_cast&lt;un=
signed char *&gt;(p1) ;</div><div>=C2=A0 =C2=A0 p2 + 1 ; // OK</div></div><=
/div></blockquote><div><br>Agreed, except that, since the <span style=3D"fo=
nt-family:courier new,monospace">int</span> object is not <a href=3D"http:/=
/eel.is/c++draft/basic.compound#4" target=3D"_blank" rel=3D"nofollow" onmou=
sedown=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Feel.=
is%2Fc%2B%2Bdraft%2Fbasic.compound%234\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAF=
QjCNFdUq4Tnm-sQBVdpKIgsyCGNf2Tig&#39;;return true;" onclick=3D"this.href=3D=
&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fba=
sic.compound%234\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFdUq4Tnm-sQBVdpKIg=
syCGNf2Tig&#39;;return true;">pointer-interconvertable</a> to <span style=
=3D"font-family:courier new,monospace">storage[0]</span>, you also need to =
<a href=3D"http://eel.is/c++draft/ptr.launder" target=3D"_blank" rel=3D"nof=
ollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%=
3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fptr.launder\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNE3gE82aH27Bz_fvgvMTdRh5wmtZg&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Feel.is%2Fc%2B%2Bdraft=
%2Fptr.launder\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE3gE82aH27Bz_fvgvMTd=
Rh5wmtZg&#39;;return true;"><span style=3D"font-family:courier new,monospac=
e">std::launder</span></a> the result of the cast under C++17.<br></div></d=
iv></blockquote><div><br>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.<br><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><div></div><div>This is also well-formed.</div><div><br></div=
><div><div>=C2=A0 =C2=A0 union { int i ; unsigned char buf[sizeof(int)] ; }=
 u ;</div><div>=C2=A0 =C2=A0 u.i =3D 42 ;</div><div>=C2=A0 =C2=A0 unsigned =
char * p3 =3D reinterpret_cast&lt; unsigned char *&gt;( &amp;u ) ;</div><di=
v>=C2=A0 =C2=A0 p3 + 1 ; // OK</div></div></div></blockquote><div><br>This =
example also needs <span style=3D"font-family:courier new,monospace">std::l=
aunder</span>, </div></div></blockquote><div><br>A union is pointer-interco=
nvertible with <i>all</i> of its member subobjects, per [basic.compound]/4:=
<br><br>&gt; one is a standard-layout union object and the other is a non-s=
tatic data member of that object<br><br>So laundering is not needed. You&#3=
9;re right about the rest, though.<br><br></div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><div dir=3D"ltr"><div>but even with that, <span style=3D"=
font-family:courier new,monospace">p3</span> would only point to the first =
byte in the object representation of <span style=3D"font-family:courier new=
,monospace">u</span> (or, equivalently, <span style=3D"font-family:courier =
new,monospace">u.i</span>), not <span style=3D"font-family:courier new,mono=
space">u.buf[0]</span>. <span style=3D"font-family:courier new,monospace">u=
..buf[0]</span> doesn&#39;t exist (as a live object). It doesn&#39;t exist b=
ecause <span style=3D"font-family:courier new,monospace">u.buf</span> itsel=
f doesn&#39;t exist, and that&#39;s because it was never made the active me=
mber. There&#39;s only <span style=3D"font-family:courier new,monospace">u.=
i</span>. Since there is no live array object, the last line is strictly un=
defined under the current (but presumably defective) wording.<br><br><br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><di=
v>But this one is undefined behaviour?</div><div><br></div><div><div>=C2=A0=
 =C2=A0 int i =3D 42 ;</div><div>=C2=A0 =C2=A0 unsigned char * p4 =3D reint=
erpret_cast&lt; unsigned char *&gt;( &amp;i ) ;</div><div>=C2=A0 =C2=A0 p4 =
+ 1 ; // Undefined behaviour?</div></div><div><br></div><div>Because the st=
orage for object i is not associated with array of unsigned char.=C2=A0</di=
v></div></blockquote><div><br>Yes, under the current (but presumably defect=
ive) wording. (Also, this needs <span style=3D"font-family:courier new,mono=
space">std::launder</span>.)<br></div></div></blockquote><div><br>Personall=
y, I don&#39;t think any of those <i>should</i> need `std::launder`. Byte-w=
ise access to an object has nothing to do with the purposes that `launder` =
was invented to solve.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c6deb7b7-b65f-4327-80cd-d9fdbaf1d9ea%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c6deb7b7-b65f-4327-80cd-d9fdbaf1d9ea=
%40isocpp.org</a>.<br />

------=_Part_10_449851246.1483849862138--

------=_Part_9_1875176364.1483849862138--

.

------=_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<unsigned char *>(p1) ;
>>>     p2 + 1 ; // OK
>>>
>>
>> Agreed, except that, since the int object is not pointer-interconvertable
>> <http://eel.is/c++draft/basic.compound#4> to storage[0], you also need
>> to std::launder <http://eel.is/c++draft/ptr.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
<http://eel.is/c++draft/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"
<http://eel.is/c++draft/expr.static.cast#13>). 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

<div dir=3D"ltr">On Saturday, January 7, 2017 at 8:31:02 PM UTC-8, Nicol Bo=
las wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On =
Saturday, January 7, 2017 at 8:13:39 PM UTC-5, Chris Hallock wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Saturday, January 7, 20=
17 at 3:07:23 PM UTC-8, Ryou wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr">[...]<br><div>So I think this is well-formed.</div><div><=
br></div><div><div>=C2=A0 =C2=A0 unsigned char storage[ sizeof(int) ] ;</di=
v><div>=C2=A0 =C2=A0 int * p1 =3D new(storage) int(42) ;</div><div>=C2=A0 =
=C2=A0 unsigned char * p2 =3D reinterpret_cast&lt;unsigned char *&gt;(p1) ;=
</div><div>=C2=A0 =C2=A0 p2 + 1 ; // OK</div></div></div></blockquote><div>=
<br>Agreed, except that, since the <span style=3D"font-family:courier new,m=
onospace">int</span> object is not <a href=3D"http://eel.is/c++draft/basic.=
compound#4" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&=
#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fbas=
ic.compound%234\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFdUq4Tnm-sQBVdpKIgs=
yCGNf2Tig&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.=
com/url?q\x3dhttp%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fbasic.compound%234\x26sa\=
x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFdUq4Tnm-sQBVdpKIgsyCGNf2Tig&#39;;return =
true;">pointer-interconvertable</a> to <span style=3D"font-family:courier n=
ew,monospace">storage[0]</span>, you also need to <a href=3D"http://eel.is/=
c++draft/ptr.launder" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"thi=
s.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Feel.is%2Fc%2B%2Bd=
raft%2Fptr.launder\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE3gE82aH27Bz_fvg=
vMTdRh5wmtZg&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.goog=
le.com/url?q\x3dhttp%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fptr.launder\x26sa\x3dD=
\x26sntz\x3d1\x26usg\x3dAFQjCNE3gE82aH27Bz_fvgvMTdRh5wmtZg&#39;;return true=
;"><span style=3D"font-family:courier new,monospace">std::launder</span></a=
> the result of the cast under C++17.<br></div></div></blockquote><div><br>=
I think this should be a defect in the pointer-interconvertibility rules. I=
f an object B provides storage for A (in accord with [intro.object]/3), the=
n they should be pointer-interconvertible, for the exact same reason as for=
 member subobjects of unions and the first subobject of a standard layout s=
truct.<br></div></div></blockquote><div><br>The rules seem odd to me, too. =
The note at the end of <a href=3D"http://eel.is/c++draft/basic.compound#4">=
[basic.compound]/4</a> suggests that the restrictiveness is intentional, at=
 least in part: &quot;An array object and its first element are not pointer=
-interconvertible, even though they have the same address.&quot; So there&#=
39;s something conceptually more to pointer interconvertibility than just s=
haring the same address.<br><br><br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;"><div dir=3D"ltr"><div></div><div>A union is pointer-interconver=
tible with <i>all</i> of its member subobjects, per [basic.compound]/4:<br>=
&gt; one is a standard-layout union object and the other is a non-static da=
ta member of that object<br></div></div></blockquote><blockquote class=3D"g=
mail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(=
204, 204, 204); padding-left: 1ex;"><div>So laundering is not needed. <br><=
/div></blockquote><div><br><span style=3D"font-family: courier new,monospac=
e;">reinterpret_cast</span> can&#39;t return a pointer to <span style=3D"fo=
nt-family: courier new,monospace;">u.buf[0]</span> because it doesn&#39;t e=
xist. Instead, the <span style=3D"font-family: courier new,monospace;">rein=
terpret_cast</span> (or rather, the <span style=3D"font-family: courier new=
,monospace;">static_cast</span> it delegates to) returns a pointer to <span=
 style=3D"font-family: courier new,monospace;">u</span> <span style=3D"font=
-family: courier new,monospace;"></span> as a fall-back (<a href=3D"http://=
eel.is/c++draft/expr.static.cast#13">&quot;Otherwise, the pointer value is =
unchanged by the conversion&quot;</a>). The <span style=3D"font-family: cou=
rier new,monospace;">std::launder</span> is then necessary to convert that =
to a pointer to the first byte in the object representation of <span style=
=3D"font-family: courier new,monospace;">u</span>.<br><br><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>Pers=
onally, I don&#39;t think any of those <i>should</i> need `std::launder`. B=
yte-wise access to an object has nothing to do with the purposes that `laun=
der` was invented to solve.<br></div></div></blockquote><div><br>+1<br></di=
v></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/35f251f8-fbe6-46dd-967b-e946a9d54c7c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/35f251f8-fbe6-46dd-967b-e946a9d54c7c=
%40isocpp.org</a>.<br />

------=_Part_1023_851875949.1483869181325--

------=_Part_1022_114863538.1483869181325--

.

On 2017/01/07 21:52 +0900, Kazutoshi Satoda wrote:
> On 2017/01/07 8:27 +0900, Neil MacIntosh wrote:
>> I would suggest you ask Core the question about undefined behavior via
>> their mailing reflector.
>
> Thank you. But I can't do that by myself now because I'm not a member of
> national body, and don't have attended a meeting.
> https://stackoverflow.com/questions/9070651/c-standards-committee-reflector-mailing-lists
>
> I'll seek someone who can forward this to the Core mailing reflector.
> (Do you know?)

I contacted to member of Japanese national body, and the discussion has
been forwarded to core-at-lists.isocpp.org. (Though I can't see the
mails by myself.)

--
k_satoda

--
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/1f2399be-3019-d3f7-0ec2-995968dcb92f%40f2.dion.ne.jp.

.